What FBR digital invoicing is, technically.
Digital invoicing is the requirement under SRO 1842(I)/2023 (and subsequent amendments) that every sales tax invoice be transmitted to FBR through the PRAL portal at the moment of issuance. The supplier gets back an invoice number with a unique 22-digit IRN (Invoice Reference Number) and a QR code that must print on the physical or PDF invoice. The customer can scan the QR and verify the invoice is real. The buyer cannot claim input tax on any invoice that does not have a valid IRN.
The transmission happens over a REST API. Your POS or accounting system POSTs a JSON payload to a PRAL endpoint. PRAL validates the payload, returns the IRN and QR string, and you print the invoice. End-to-end latency is typically 800ms to 2 seconds. If PRAL is down, FBR allows up to 24 hours offline mode with batched submission, but you must reconcile every offline invoice within that window or you lose the ability to claim output tax on those sales.
Who must enable it in 2026.
All Tier-1 retailers (point-of-sale operators above PKR 100 million annual revenue, chain stores, malls). All registered service providers above PKR 10 million annual taxable supplies. All sales tax registered B2B sellers in the steel, sugar, cement, beverage, and (newly added in 2026) pharmaceutical sectors. The threshold has been dropping every year. Plan as if you will be in scope within 18 months even if you are not today.
Enforcement is sharper than it used to be. A Faisalabad textile mill that issued PKR 14 million of paper invoices in March 2026 with no IRN received a notice in May, was fined PKR 25 million (3x the unrecorded tax), and had its sales tax registration suspended for 60 days. The way out was retroactive transmission of the missing invoices, which is possible but humiliating because the IRN issued shows the actual transmission date and your customer cannot claim input tax on backdated paperwork.
Step 1: PRAL onboarding.
Go to fbr.gov.pk and apply for a PRAL digital invoicing license under your sales tax registration number (STRN). Submit your STRN, NTN, business address, expected monthly invoice volume, and the technical contact email. PRAL issues an OAuth client ID and secret within 7-10 working days, plus access to the sandbox environment for testing. Do not skip sandbox. The first time your system hits the production endpoint with a malformed payload, you spend a day debugging while invoices pile up.
A Karachi supermarket chain with 12 branches and an average of 6,000 invoices a day applied in February 2026. PRAL approved in 9 days, sandbox testing took 4 days, production go-live was on a Sunday at 2 AM to avoid impact on the daily rush. Day-one issuance: 5,900 invoices, all stamped with IRN, zero rejections. The pre-launch checklist is the difference between this and the alternative.
Step 2: the API payload.
The minimum invoice payload is JSON with these fields: seller STRN, seller NTN, buyer STRN (if registered) or CNIC (if walk-in), invoice number (your sequence), invoice date, invoice type (sale, debit note, credit note), line items (description, HS code, quantity, unit, unit price, sales tax rate, sales tax amount), and totals. A typical payload for a single grocery transaction is 800-1,200 bytes. You sign the payload with your client secret, POST to the endpoint, and parse the response.
Sample payload (abbreviated): { "sellerNTN": "1234567-3", "sellerSTRN": "0123456789012", "buyerSTRN": "9876543210987", "invoiceDate": "2026-04-09", "invoiceNumber": "INV-2026-04-09-04321", "items": [{ "description": "Surf Excel 500g", "hsCode": "3402.2000", "qty": 4, "unitPrice": 540, "taxRate": 17, "taxAmount": 367.20 }], "totalExclTax": 2160, "totalTax": 367.20, "totalInclTax": 2527.20 }. The response returns the 22-digit IRN and the QR string ready to encode.
Step 3: the QR code on the printed invoice.
Every printed or PDF invoice must show a QR code that decodes to a JSON object containing: seller NTN, IRN, invoice date, total inclusive of tax, and a SHA-256 hash of the payload. A walk-in customer can scan it with the FBR Tax Asaan app and confirm the invoice is in the PRAL database. If the QR scan fails or the hash mismatches, the customer can report the seller. Three reports in a quarter trigger an audit.
Printer setup is the part nobody warns you about. Thermal printers at 203 DPI struggle with QR codes smaller than 18mm square. If your receipt template prints the QR at 12mm, half the customer phones cannot scan it. Bump to 22mm. For PDF invoices on email, 35mm is comfortable. Nonari renders the QR at the correct size for each output channel automatically and embeds the IRN as both QR and human-readable string for accessibility.
The 12 error codes you will see.
PRAL returns numbered errors. The top dozen in 2026: 4001 invalid STRN format (must be 13 digits), 4002 buyer STRN not active (check ATL before issuing), 4003 HS code mismatch (your declared HS does not match the rate), 4004 tax rate not allowed for HS code, 4005 duplicate invoice number in your sequence, 4006 invoice date in future, 4007 invoice date older than 24 hours (no backdating), 4008 quantity must be positive (use credit note for returns), 4009 unit price below cost (suspected under-invoicing).
Error 4010 line total mismatch (your math does not add up), 4011 SHA hash mismatch (payload was modified after signing), 4012 OAuth token expired (refresh every 60 minutes). For each error, your POS should retry with corrected fields or queue the invoice for manual review. Never silently drop the invoice; FBR can tell from the gap in your sequence. Nonari keeps an exceptions queue with the error code and the fix workflow visible to the cashier.
- 4001-4002: STRN problems, fix the registration field.
- 4003-4004: HS code or tax rate mismatch.
- 4005-4007: invoice number or date issues.
- 4008-4010: line item math errors.
- 4011: hash mismatch, payload modified post-signing.
- 4012: OAuth token expired, refresh and retry.
Staying live: monitoring and offline mode.
PRAL uptime in 2026 is approximately 99.4 percent, which sounds high until you realize that is 50 hours a year of downtime. During downtime, FBR allows offline mode: issue invoices with a temporary IRN (TIR-prefixed), queue them locally, and submit in batch within 24 hours of PRAL recovering. Most POS systems handle this badly because they did not test the offline path. A Lahore pharmacy lost three hours of sales in March 2026 because their integration crashed when PRAL returned a 503.
The correct architecture is a local write-ahead log: store the payload locally first, attempt transmission, retry on failure with exponential backoff, alert if the queue depth exceeds 50 invoices. Reconcile the local log against the PRAL daily summary every morning. Nonari treats the local DB as the source of truth and PRAL as a side effect, which means a network outage is a transient inconvenience rather than a business stoppage.
