The requirement reads as one line: sales invoices are transmitted to FBR and the returned invoice number and QR code appear on the customer's receipt. Shops discover the difficulty later, at the counter, and it is rarely the part they prepared for.
The invoice number is not yours
Most shops number their own invoices, and that number means something internally, a sequence, a book, a branch. Digital invoicing introduces a second number that you do not generate and cannot predict, and it is the one that has to be printed. So the receipt now carries two identities for the same sale, and reconciliation has to know which is which.
That has a practical consequence for the layout of a 58mm receipt, where there is not much room to explain anything. It also matters at the point where a customer returns goods: the credit has to reference the invoice FBR knows about, not only the one in your own book.
The QR is a rendering problem before it is a compliance problem
A QR code on thermal paper is only useful if it scans. Print it too small and error correction cannot recover it; print it in the wrong density and the bars bleed. This is the kind of detail that passes a demo and fails on the fifth roll of paper, because the demo printer was new and the shop's is three years old.
The decision nobody makes until it is urgent
Then the connection drops.
At that moment there are exactly three options, and a shop that has not chosen in advance ends up choosing badly under pressure:
- Stop billing. Compliant, and completely unacceptable, the queue is real and the customers leave.
- Bill without submitting, and hope. The sale completes and the invoice is never sent. This is the option that looks like it worked, and it is the one that produces a gap between what you sold and what you declared.
- Bill, queue the invoice, submit it when the line returns. The only answer that keeps both the counter and the ledger honest.
The third option sounds obvious written down. It is also the one that requires the software to have been built for it: the sale must complete locally, the submission must survive a restart, and the queue must be something a person can look at and see what is still outstanding. A silent retry is not enough, if nobody can see the backlog, nobody knows it is growing.
What to check before you buy
Ask the four questions that separate a system built for this from one that had invoicing added later:
- What happens to a sale when FBR is unreachable, and can I see the queue afterwards?
- Is tax applied per item, so exempt and zero-rated goods are treated correctly rather than averaged across the basket?
- Does the FBR invoice number print on the receipt, on the printer I already own?
- What about provincial sales tax on services, PRA, SRB, KPRA, BRA, not just federal sales tax?
None of these is exotic. All four are the difference between compliance being part of billing and compliance being an evening data-entry job that somebody eventually stops doing.