Invoice rejected or FBR system down? The 72-hour and 24-hour rules

Since SRO 69(I)/2025 — the Statutory Regulatory Order (SRO) that rewrote Chapter XIV of the Sales Tax Rules 2006 — every sales-tax-registered business in Pakistan transmits its invoices to the Federal Board of Revenue (FBR) in real time. Real-time systems fail in real time too: a submission bounces, a typo slips through, the internet dies in the middle of a shift. The rules anticipate all three problems. What they demand is not perfection; it is that you know which clock is running.

Three different problems, three different rules

Most businesses lump everything into one bucket called "the invoice didn't go through". FBR's framework splits it into three situations, each with its own fix:

The first distinction matters most. A rejected invoice never received an FBR invoice number, so there is nothing to correct inside FBR's system: you fix the data and submit again. The 72-hour rule applies only to invoices FBR has already accepted as valid.

The 72-hour window for fixing an accepted invoice

A Sales Tax General Order (STGO) is FBR's operational instruction under the tax law. STGO 01 of 2026, dated 30 March 2026, governs corrections: an integrated business may cancel, delete, or edit a valid electronic invoice generated due to a bona fide mistake — a genuine slip, not a rewrite of the sale — only through FBR's computerized system, and only within 72 hours of the invoice's generation.

After 72 hours, any change requires the prior approval of the concerned Commissioner Inland Revenue, under conditions FBR may specify. As of August 2026 the detailed approval procedure has not been published, which in practice means: do not build your workflow around it. Treat the 72 hours as the whole game.

What the system actually lets you change

PRAL (Pakistan Revenue Automation Ltd) is FBR's technology arm and its free-of-cost licensed integrator, and its Digital Invoicing user manual (version 1.6, updated April 2026) sets operational limits that are tighter than the bare 72-hour rule:

• The invoice header and the FBR invoice number cannot change. A revised invoice keeps the original number and date.
• Edits are item-level only: you adjust lines, not the document itself.
• Each item can be edited only once.
• Cancellations and modifications combined are capped at 10% of your previous month's sales.
• An invoice already included in a submitted sales tax return, or linked to Annexure-C (the sales annexure of the return), cannot be changed at all. Invoices flow into return data after 72 hours or at month-end, whichever comes first.

Read together, the message is clear: the window exists for genuine mistakes caught quickly. A business that leans on cancellations as a routine workflow will hit the 10% cap, and the system is built to notice.

Missed the window? Debit and credit notes

A mistake found on day five is not a dead end; it takes a different road. FBR's own FAQ says the mechanism for modifying an issued e-invoice — goods returned, a supply cancelled, a change in the nature or value of a sale — is a debit or credit note under section 9 of the Sales Tax Act 1990. Under rule 150S(2) these notes are issued electronically through the same integrated system and retained for six years, exactly like invoices.

Licensed integrators document the system's validations: a note must cite the original invoice's reference number, be dated on or after it, be issued within 180 days of it, and cannot exceed the original invoice's quantities or tax amounts. Each note is submitted like an invoice and receives its own FBR number and QR code.

When the system is down: two 24-hour clocks

Downtime is not hypothetical. As this article goes up, FBR itself has IRIS and the Digital Invoicing system offline for planned maintenance of more than 52 hours, from after midnight on Saturday 8 August to early Monday morning, 10 August 2026, announced on FBR's own website with advice to complete time-sensitive work beforehand.

The outage rule sits in the SRO 69 chapter itself. Rule 150XC is drafted around failure on your side of the connection: your e-invoicing or POS software going down, including through an internet or power failure. Invoices issued during the disruption must be clearly marked as offline-mode invoices and uploaded within 24 hours of the service being restored. Note the wording — the clock runs from restoration, not from when each invoice was issued. Nobody expects an upload while the connection is still dead. For downtime on FBR's or an integrator's side, FBR's FAQ says only that the Act and Rules must be followed; in practice, the same mark-offline-and-upload flow is what integrated systems run whenever invoices cannot reach FBR live.

There is a second, less-known duty in the same chapter. Rule 150XA requires an integrated business to report any operational failure, disruption, or inoperative e-invoicing hardware or software to the Commissioner within 24 hours, with reasons and documentary evidence. So two clocks run: 24 hours to report the disruption, and 24 hours after restoration to upload the backlog.

One engineering detail decides whether those clocks are manageable: PRAL's manual notes that failed submissions are not retried automatically. If your software does not queue offline invoices and resubmit them itself, someone on your staff will be doing it by hand, on a deadline.

Why invoices get rejected, and why it stops

Rejections cluster around a handful of causes that licensed integrators document as named validation errors:

• HS code problems. The Harmonized System (HS) code is the international commodity classification FBR requires on every invoice line. Missing, invalid, or mismatched-to-sale-type codes are the most common bounce.
• Unit of measure (UoM) mapping. FBR maintains a list of permitted units per HS code. One integrator's guide gives the example of rice: accepted in kilograms or tonnes, rejected if billed in pieces.
• Buyer numbers in the wrong format. A National Tax Number (NTN) must be 7 digits and a CNIC (the computerized national identity card number) 13 digits, with no dashes.
• The rest: tax calculation mismatches, duplicate invoice reference numbers, and dates not in YYYY-MM-DD format.

Notice what these share: none of them are about your customer or your sale. They are master-data mapping problems. Fix the mapping once — the right HS code on each product, the UoM FBR accepts for it, validated buyer records — and that whole class of rejection stops recurring. In our integration work this mapping is the step where most do-it-yourself attempts stall, and it is genuinely a fix-once job, not a monthly fire drill.

Your billing never stops; the filing follows

The practical summary: keep selling. The regime assumes that software fails, connections drop, and humans mistype; that is why the offline route and the correction window exist at all. What it does demand is that somebody owns three clocks: 72 hours for corrections, 24 hours to report a disruption, and 24 hours after restoration to upload.

That is a monitoring job, and, in the interest of honesty, it is one we sell. VectorIT's FBR integration service includes a support retainer that watches your filings, fixes rejections at the mapping level, and keeps offline queues inside the rules. If you want to see what a compliant invoice looks like end to end, raise one yourself in our live demo. And if you are staring at a rejected invoice right now, send us your STRN (Sales Tax Registration Number) and the error message; a straight answer costs nothing.