Retail POS / API integration
2 min readHamza Enterprise: FBR invoices at sale time
Tax invoice generated on every sale
Pakistani retail cannot treat FBR as a month-end spreadsheet. Each sale needs an authorized digital invoice — or the shop is out of compliance the same afternoon.
- My contribution
- POS backend & FBR integration
- Scope
- Sale-time authorization and digital invoices
- Stack
- Laravel / FBR API / POS
01 /The problem
Staff already run a POS under pressure. Adding FBR after closing means missed invoices, mismatched totals, and a tax trail that does not match the till. The integration had to sit on the sale itself, not in a back-office batch that nobody remembers to run.
FBR’s authorization API is unforgiving: payloads, item codes, and timing have to be right or the invoice is not fiscal. Failures needed to be visible at the counter, not buried in a log.
02 /What shipped
The Laravel POS posts to FBR as part of completing a sale. On success, the system stores the fiscal identifiers and prints / PDFs an invoice the customer can take — sales report in real time instead of a night-end dump.
Error paths are first-class: if authorization fails, the cashier sees it immediately so the shop does not silently accumulate non-compliant tickets. Line items, discounts, and payments stay aligned with what FBR received.
03 /Result
Tax compliance is no longer a separate job. Every completed sale can carry an FBR-backed invoice — the operational loop recruiters care about: regulated API, production POS, and a paper trail that matches the register.
The takeaway
Move invoice authorization into the sale, where staff can act on the result.