FBR Invoice Number, QR Code and Recordkeeping Explained

A trustworthy invoice record connects three things: the business’s own invoice reference, the response returned by the external system, and the customer-facing invoice document. Confusing these layers creates gaps in support, reconciliation and audit trails.

Keep the internal reference permanent

Generate a unique internal invoice reference before submission and never recycle it. It should link the source sale, approval, request attempts, responses, printed invoice and any later adjustment. Human-readable numbering can coexist with a database identifier, but both should remain stable.

Store returned identifiers as results

The technical specification’s response examples include invoice-level and item-level status information and, for successful processing, an invoice number issued by the FBR system. Store returned identifiers exactly as received. Do not predict, manufacture or edit them.

If an invoice is invalid, the absence of a returned invoice number is not a reason to insert a placeholder that resembles a valid number. Keep status and identifier in separate fields.

Generate the QR code from approved data

The public specification includes requirements for the Digital Invoicing logo and QR code printing. Your implementation should use the current official format and dimensions and generate the QR from the approved value after a successful response—not from a draft reference.

Test QR readability on the actual printer, paper size and PDF output used by the business. A code that looks sharp on a monitor may be unreadable after scaling or low-quality thermal printing.

Design the invoice document carefully

Keep seller, buyer, date, item, quantity, values and tax presentation readable. Display the external identifier and QR only when the workflow has the evidence to support them. Avoid presenting a validated draft as if it were an accepted production invoice.

Use version-controlled templates so changes to branding or layout do not accidentally remove required information.

Retain a complete evidence trail

For each invoice retain the approved business record, submitted payload or secure equivalent, timestamp, environment, response, status, returned identifier, rendered document and user actions. Access should be role-based, and logs should avoid exposing credentials.

Reconcile daily: every approved invoice should be unsubmitted with a reason, awaiting a controlled retry, rejected with an owner, or accepted with a returned identifier. Unknown status is an operational exception.

Verify the latest printing specification

The public DI API specification reviewed for this article documents QR Code Version 2.0 (25×25) and 1×1 inch dimensions. Specifications can change; check the current official version before changing invoice templates or going live.