FBR Invoice Failed to Post? Timeouts, No Auto-Retry, and How to Recover Safely
FBR's Digital Invoicing system does not auto-retry a failed submission — if the connection dropped mid-post, your invoice is not in FBR. How to tell a rejection from a transport failure, verify before re-sending, and recover without creating duplicates.
First rule: no invoice number means no invoice
PRAL's Digital Invoicing user manual is explicit about connection loss: the system does not automatically retry a failed upload. Until the DI API returns statusCode 00 with an FBR invoice number (IRN), nothing has been e-invoiced — a request that timed out, errored or never completed left no invoice in FBR's system, and the taxpayer must resubmit it.
That single rule resolves most panic. The question after any failure is not "what happened to my invoice inside FBR" but "did FBR ever return an invoice number?" If yes, the invoice exists and must not be posted again. If no, it does not exist yet and can be safely re-sent once the underlying problem is fixed.
Rejection vs transport failure — read the response
A rejection is a completed conversation: FBR received the payload, validated it, and answered with statusCode 01 plus an errorCode pointing at the exact field — 0091 for extraTax sent on a reduced-rate item, 0077 for a missing SRO reference, 0099 for a UoM that does not match the HS Code, and so on. Fix the flagged field and resubmit; the errorCode list in PRAL's spec is the map.
A transport failure is an incomplete conversation: a network timeout, an HTTP 401 (the bearer token is missing, expired or the wrong environment's token), or an HTTP 500 from the gateway (a server-side fault PRAL asks taxpayers to report). No validation verdict was delivered. 401s are fixed on your side by correcting the token; repeated 500s go to the PRAL DI CRM (dicrm.pral.com.pk) or the FBR helpline rather than blind retries.
Recover without creating duplicates
The safe sequence after an ambiguous failure — a timeout where you cannot tell whether FBR processed the request — is verify first, then resubmit. Check whether an invoice number was recorded in your software's response log, and look the invoice up in the Search Invoice screen of the Digital Invoicing module on IRIS. If an IRN exists, the post succeeded and the failure was only in delivering the response to you.
Only when no IRN exists anywhere do you post again. This is also why a save-then-post design matters in invoicing software: the invoice is stored locally as a draft first, so a failed FBR call never loses the document — the draft simply stays available to send again. Digi Invoice follows exactly this pattern, keeping every failed submission editable with its decoded FBR error alongside it.
Reduce failures before they happen
Most "failed" posts are predictable rejections, and FBR provides a dry-run endpoint precisely for them: validateinvoicedata checks a payload against the full rule set without issuing an invoice number. Validating before posting turns a would-be rejection into an editable warning, which matters commercially once a customer is standing at the counter.
For the transport side: keep sandbox and production tokens strictly separated (the token, not the URL, decides the environment), renew tokens before their five-year expiry, keep the whitelisted IPs current, and monitor for repeated gateway errors. A business that validates first, posts second and verifies before any retry will almost never issue a duplicate or lose an invoice.