FBR Digital Invoicing: A Practical Guide for Pakistani SMBs

When SRO 288(I)/2026 was notified on 18 February 2026, it replaced the entire Chapter VIIA of the Income Tax Rules 2002. The practical effect is that the set of businesses expected to integrate their invoicing with the FBR computerised system is much broader than before — and the rule set for amendments, cancellations, and error handling is considerably tighter.

First, the mechanics. Every tax invoice you issue must be transmitted, in a structured JSON schema, through a licensed integrator to the FBR platform. The platform acknowledges with an Invoice Reference Number (IRN) — a UUID — and you must render a QR code containing a canonical payload on the invoice before you send it to your customer. The minimum QR size is 7×7 mm; we recommend 12 mm for legibility.

The second thing that changes is the edit window. Valid electronic invoices may only be cancelled, deleted, or edited directly within the FBR system, and only within 72 hours of issuance. After 72 hours, any change requires prior approval from the Commissioner Inland Revenue — and that is a meaningfully different operational posture than "I'll fix it next month in my ERP".

In practice, this means your accounting software has to do four things well. It has to: (1) validate the JSON schema before transmission, including all HS codes and tax IDs; (2) handle the licensed-integrator transport with proper idempotency keys, because network hiccups should not result in duplicate submissions; (3) maintain a 72-hour mutation guard at the application layer, not just as a UI hint; and (4) support a Commissioner-approval workflow for anything outside that window.

If your current system cannot do all four, you do not have an FBR integration. You have a filing. That is the distinction SRO 288(I)/2026 is really drawing.

There is one more wrinkle worth flagging: the POS retail rule is a separate regime with its own SRO track. If you operate an outlet-facing point-of-sale, you have two integrations to maintain, not one. The data flows are similar but the registration and reporting cadence differ.

Our read of the regulation is that the FBR has deliberately made the edit window tight to push quality upstream. The rule is effectively: "get it right the first time." That has implications for your approval workflows. A draft invoice that sits in a queue for two days before a supervisor approves it and only then gets transmitted is a workflow that will bite you inside the 72-hour window. We have seen teams move their approval gate before issuance, not after, and that is the correct direction of travel.

Finally, a note on the licensed-integrator model. It is tempting to build the integration yourself, and the JSON schema is not complicated. Resist the temptation. The integrator's value is not in the transformation; it is in being on the short list when the FBR pushes a breaking schema change overnight — which has happened twice in the last nine months — and in owning the SLA for the transmission channel. Outsource the boring part.