FBR Digital Invoicing in 2026: Who Must Comply, What It Costs, and How to Get It Working

If your business holds a sales tax registration in Pakistan, FBR expects every sales invoice you issue to reach its system the moment you issue it, with an FBR invoice number and a QR code printed on it. The rollout was rescheduled several times in 2025, and the old dates are still quoted online, so a lot of owners are unsure whether it applies to them yet. This guide sets out what FBR's own notifications say: who is covered, which date applies, what a missed deadline costs, the three ways to connect, and the technical details that make most first attempts fail.

The short answer: if you are registered for sales tax, your date has already passed

The legal basis is section 23 of the Sales Tax Act, 1990. It lets FBR require any class of registered person to integrate their invoicing system with FBR's computerised system for real-time reporting of sales. FBR used that power in three notifications during 2025. Each one replaced the one before it:

• SRO 709(I)/2025, 22 April 2025. The first mandate. It covered corporate and non-corporate registered persons, with go-live dates in mid-2025.
• SRO 1413(I)/2025, 1 August 2025. Replaced 709 with a schedule by turnover. The last group was due on 1 December 2025.
• SRO 1852(I)/2025, 24 September 2025. Replaced 1413. This is the schedule in force. Its last row, "registered persons other than listed above", had to be issuing electronic invoices by 31 December 2025.

So every sales tax registered person has been inside the mandate for nine months. Much of the confusion comes from FBR's own website. Its Digital Invoicing FAQ page still quotes the original June and July 2025 dates from SRO 709, and its "Legal Provisions" page still links SRO 709 and not the notifications that replaced it. We checked KPMG's July 2026 global e-invoicing timeline as well. It lists no Pakistani change after the December 2025 milestones.

You will also find articles quoting a "July 2026 deadline". We could not trace that date to any FBR notification, so it is not in this guide.

Every date in the schedule that applies now

These are the dates from SRO 1852(I)/2025, exactly as FBR published them. "Turnover" means the turnover declared in your sales tax returns for the last twelve months.

The notification lists three steps in order: registration, then testing, then live invoices. Testing is where FBR's sandbox checks your software against your line of business, covered below.

What a missed deadline costs, and the waiver most owners do not know about

The penalty is in section 33 of the Sales Tax Act, serial 25A. Since the Finance Act, 2025 it covers anyone who is required to integrate under section 23 and either does not integrate, or integrates but then fails to issue electronic invoices. The amounts go up with each default:

The same entry includes a proviso that matters to anyone who is late. If you integrate with FBR's system before the penalty for the second default is imposed, the Commissioner waives the penalty for the first default. So integrating late still costs far less than not integrating: the first Rs 500,000 can be waived, and the larger penalties never start.

FBR's FAQ also says that registered persons notified for e-invoicing "may seek extension under the relevant rules". If you are partway through, have your adviser request one in writing.

Who does not need it, and who is likely to be added next

Two developments from 2026 change the picture. Check whether either applies to you before you spend money.

Small shopkeepers who opt into the fixed-tax scheme

In July 2026 FBR notified a Special Procedure for Small Shopkeepers (Income Tax SRO 1166, reported by Dawn on 29 July; the draft was SRO 1109(I)/2026 of 14 July). It is open to individuals whose income comes mainly from one retail shop with annual turnover up to Rs 200 million. They pay 1% of gross turnover, with a minimum of Rs 25,000. The draft states plainly that eligible shopkeepers under the scheme are "not required to install a sales tax POS system or digital invoicing infrastructure". Several groups are excluded:

• More than one shop. Owners of more than one shop cannot use the scheme.
• Tier-1 retailers. They remain under the separate point-of-sale integration regime.
• Jewellers and professionals. Doctors, engineers and lawyers are named in the exclusions.
• Anyone who crossed Rs 200 million. If turnover went over that figure in any of the previous three years, the scheme is not available.

Service businesses, under a draft income tax rule

On 18 February 2026 FBR published draft SRO 288(I)/2026. It would replace Chapter VIIA of the Income Tax Rules with a new version, "Online Integration of Businesses". The schedule lists air-conditioned restaurants, guest houses and marriage halls, courier and cargo firms, clinics, laboratories, private hospitals, gyms, event photographers, chartered and cost accountants, exchange companies, private schools above Rs 1,000 a month per child, and larger retailers. Those businesses would issue real-time invoices with an FBR number and QR code, display an "Integrated with FBR" sign, and could be required to record each point of sale on CCTV for at least a month. It is a draft. It takes effect only after a final notification and a general order that sets dates. If you run one of these businesses, plan for it, but do not buy anything because of it yet.

The three ways to connect, and what each one costs

Every route ends at the same FBR web API. What changes is who builds the connection and who fixes it when something breaks.

• PRAL, free of charge. FBR's FAQ says PRAL acts as a licensed integrator and "shall provide free of cost integration services to the registered persons on demand". FBR itself charges no fee. What PRAL does not supply is your invoicing software, so you still need a system that produces the data.
• A licensed integrator. FBR's list currently names eight firms, EY Ford Rhodes among them. They may charge a configuration and integration fee, capped at a threshold FBR can set. This route suits you if your invoices come from an older ERP that nobody wants to modify.
• Accounting or POS software that speaks the API itself. PRAL issues the business a security token, and your own software sends each invoice with it. This is the cleanest route when you are already changing accounting software, because the invoice, the ledger entry and the FBR number are created in one step. We should be open that we sell one of these: our Accounts module is built to FBR's DI API v1.12 and sits in the Tax Filing & Compliance add-on, which is priced separately from the base plan.

FBR digital invoicing is not something you install once and forget. It changes how every sale you make is recorded, so choose the route that matches how you already invoice, not whichever demo is cheapest.

If you run a shop or restaurant through a till rather than typed invoices, the same logic applies to your point-of-sale system. Our POS guide covers what a modern till should record even before any tax rule makes you.

What your software actually has to send

PRAL's technical specification (DI API v1.12) is public, and it is more specific than most sales pitches suggest. Every invoice is a JSON message that carries:

• Seller and buyer identity. NTN or CNIC, business name, address, and a province taken from FBR's own province list. The buyer's NTN or CNIC can be omitted only when the buyer is unregistered.
• Each line item. HS code, description, a unit of measure that FBR accepts for that HS code, quantity, value excluding tax, rate, sales tax, further tax, extra tax, withholding, discount, and the SRO schedule and serial number where a reduced rate or exemption applies.
• The sale type. Standard rate, reduced rate, exempt, zero-rated, third-schedule goods, services and so on.
• A reference for debit notes. A debit note has to carry the FBR invoice number of the original invoice (22 digits for an NTN seller, 28 for a CNIC seller).

FBR replies with the invoice number. The specification requires every invoice to show the Digital Invoicing System logo and a QR code of version 2.0 (25x25), printed at 1.0 x 1.0 inch. The security token is valid for five years, and FBR uses the token you send to tell a sandbox test apart from a live invoice.

The test scenarios are set by your line of business

The specification defines 28 sandbox scenarios, SN001 to SN028. Which ones you have to pass depends on your business activity and sector. A manufacturer in "all other sectors" has to pass eleven, from standard-rate sales to registered and unregistered buyers through to exempt, zero-rated and mobile-phone sales. A retailer selling to end consumers has its own three (SN026 to SN028), and those apply only if your sales tax profile registers you as a retailer. This is the reason a generic "FBR-ready" invoice template often fails testing: it handles the standard-rate scenario and nothing else.

Where integrations fail, from building one

We built our own integration directly against this specification. Read that way, the spec shows where the problems come from. Almost none of them are about sending the data. They come from reference data and setup:

• Free-text provinces and units. FBR validates province, HS code and unit of measure against its own reference lists, which are available through the API. Software that lets a clerk type "Lahore, Punjab" or "pcs" will be rejected. Pull the values from FBR's lists instead.
• Getting the buyer's registration status wrong. A registered buyer sent as unregistered, or the other way round, changes the tax and gets the invoice rejected. The API has a lookup (Get_Reg_Type) for exactly this, so use it on every invoice instead of trusting the customer file.
• Posting before validating. The API has a separate validate method that checks an invoice without issuing a number. Validate first and post second. Otherwise every mistake becomes a live invoice that then needs a debit or credit note.
• Nothing that catches failed submissions. If the internet drops at the moment of posting, the sale has happened but FBR has no record of it. Your software needs a queue that shows every unsent invoice and retries it. Check this before you rely on any system.
• The token and the network. The token belongs to your registration. In our own build, FBR's gateway also checked where requests came from, so a system hosted in the cloud needed a fixed outgoing address. Ask any vendor how they handle that before you sign.

Your next step, depending on where you are

• Not integrated yet. Integrate before any second-default penalty is imposed; the first penalty can then be waived. Ask PRAL for free integration if your current software can produce the data, and ask your tax adviser to confirm your category under SRO 1852.
• A small shop under Rs 200 million. Check whether the SRO 1166 fixed-tax scheme suits you before buying any invoicing system. Its exemption from digital invoicing may be the cheapest route to compliance.
• Changing accounting software anyway. Choose a system that issues, validates and retries FBR invoices from inside the ledger, so you are not paying for a separate integration layer. Our Accounts module works this way, and the same system handles ZATCA Phase 2 if you also trade in Saudi Arabia. For the wider question of what a small business needs from an ERP, see ERP for small businesses.
• A service business named in the draft income tax rule. Watch for the final notification. Plan your point-of-sale setup now so that a short deadline does not catch you out.

If you want someone to check which route fits your invoices, tell us how you invoice today and we will say honestly whether our system is the right fit or whether PRAL's free route is enough. This guide explains the rules but is not tax advice. Your adviser should confirm the category and date that apply to your registration.