What to store in your ERP once FBR answers

Answer first. The dependable test for “filed” is simple: FBR returned an invoice number that isn’t blank, and no line came back with an error. Keep that number against the invoice in your own system, along with the per-line results, a status, the time, the exact payload you sent and FBR’s reply exactly as it arrived. From then on, treat the invoice as locked — there is no API call that edits or cancels a filed invoice, so changing it in your system changes nothing at FBR. And if an invoice’s reply never arrived, find out whether FBR has it before sending it again, because FBR will happily accept the same invoice twice.

When an invoice is actually filed

FBR’s rejections don’t look like failures at the network level. The call succeeds with HTTP 200 whether the invoice was accepted or not; the verdict sits in the response body. It can be subtler still: FBR’s own documentation shows an invoice-level status reading as accepted while a single line underneath carries a rejection. Checking only that the call worked will quietly mark rejected invoices as done.

So build around one rule, a non-blank FBR invoice number plus a clean result on every line, and treat everything else as a failure that needs fixing. Put it in a status field that finance actually looks at.

What to store, field by field

If your invoicing runs through eInvoicePro, the payload sent and FBR’s raw response are kept for every invoice and can be fetched back, and a failed invoice can be retried on its own without resending the rest of its batch. Storing a copy in your own system as well means the record lives where your finance team already works.

Reading the FBR number

The FBR invoice number has a structure worth knowing. It starts with the seller’s registration number, then the letters DI, then a 13-digit timestamp counted in milliseconds. In FBR’s published example, 7000007DI1747119701593, the tail works out to 12:01:41 Pakistan time on 13 May 2025, when FBR accepted the invoice, which is not necessarily when you created it. Keep it as text, exactly as FBR sent it: it is an identifier rather than a quantity, and it is longer for a seller registered on a CNIC than on an NTN.

The QR code on the printed invoice encodes that number and nothing more — no amounts, no buyer. Scanning it only tells you which record to look up at FBR, which is why the number, not the image, is what your system needs to hold.

The invoice that got no answer

A rejection is easy to deal with. The riskier case is an invoice that got no answer at all, because of a timeout or a dropped connection. It does happen that FBR records the invoice while the reply is lost on its way back to you. Because FBR doesn’t turn away a repeat of an invoice it already holds, sending it again creates a second live invoice, and cancelling that one uses up part of a limited monthly cancellation allowance.

Two safeguards work together here. An idempotency key on your own submission (eInvoicePro’s API accepts one) means a retry after a network timeout on your side is recognised as the same invoice rather than a new one. But that protects your side of the connection; it cannot make FBR itself idempotent. So for any invoice left in an unknown state, the rule is: find out whether FBR has it before sending it again.

Locking the invoice afterwards

From the moment FBR issues its number, FBR’s copy is the one that matters. Its API offers no way to cancel, delete or edit an invoice. What exists instead, since Sales Tax General Order 01 of 2026 took effect on 30 March 2026, is a manual route: a valid e-invoice raised by genuine mistake can be cancelled, deleted or edited inside FBR’s own system within 72 hours of being generated, and beyond that only with the Commissioner Inland Revenue’s prior approval. None of that can be driven from your ERP — there is nothing to automate, queue or batch.

So the invoice in your system should behave accordingly. Lock it for editing once it is filed, and route any correction to someone who can make it in FBR’s portal, then record what was done against the invoice. A debit note for a later adjustment is a new document that references the original FBR number, not an edit to the original. Our guide to correcting or cancelling an FBR invoice covers the rules in detail, including the trap that editing a single line permanently removes your ability to cancel that invoice.

Six years of records

Records have to survive six years, and the rules expect them to reproduce what was transmitted, as it stood at the time. Printed PDFs struggle to prove that. A copy of the payload you sent and FBR’s reply proves it directly, so keep both alongside the number.

Reconciliation is the other half. Your sales tax return’s Annexure-C is populated from the e-invoices FBR has on record, so comparing your own sales register with FBR-accepted invoices every day catches a missing or duplicated invoice while there is still time to act, not when the return and your books disagree.

Where it goes in your system

Most accounting systems don’t have a field for an FBR invoice number, so it is added. How depends on the system:

• SAP, NetSuite and Business Central support custom fields on the invoice header (a transaction body field in NetSuite, a table extension in Business Central) which is the natural home for the number and status.
• Odoo can carry extra fields on the invoice through a small module where your hosting allows one.
• QuickBooks Online and Zoho Books offer custom fields on invoices, usually enough for the number and a status.
• Tally is best left untouched: keep the FBR record in the filing layer, keyed on the voucher it belongs to, rather than writing back into the company file.

Wherever the number lives, the printed invoice should carry it with the QR code, and your team should be able to search for an invoice by either your number or FBR’s.

FAQs

Is the QR code enough on its own? No. The QR code simply encodes the FBR invoice number; on its own it proves nothing until someone checks that number against FBR’s records. Keep the number itself against the invoice.

Can we fix a filed invoice by editing it in our ERP? Editing it in your ERP changes nothing at FBR. Corrections are made in FBR’s own system within 72 hours of generation for a genuine mistake, and with the Commissioner’s approval after that.

Why keep the payload if we have the FBR number? Because the rules ask for a record that can re-create the information as it was when transmitted. Master data changes; a copy of exactly what you sent, and exactly what FBR returned, does not.

What should happen when FBR rejects one line of a multi-line invoice? The invoice is not filed. Fix the cause (usually an HS code, unit or sale type on that item) and resubmit the whole invoice. Treat it as failed until every line comes back clean.

Does an idempotency key stop FBR filing an invoice twice? It stops your own retries after a network timeout from creating a duplicate submission on your side. It cannot make FBR itself reject duplicates, so check before resending an invoice whose outcome is unknown.

Related reading: how FBR digital invoicing works, correcting an FBR invoice and the eInvoicePro API.