FBR Digital Invoicing Documentation: DI API Spec, Endpoints & Reference APIs (2026)

When people search for FBR digital invoicing documentation (or FBR e-invoicing documentation), they usually want one of three things: the official PRAL technical specification, the JSON shape of an invoice, or the list of endpoints their software must call. The authoritative source is PRAL's Technical Documentation for the Digital Invoicing (DI) API — the current version is 1.12 — together with FBR's Digital Invoicing User Manual on the IRIS portal. Everything a compliant integration does is defined there: field names, data types, required vs optional fields, sandbox test scenarios and the full sales error-code list.

The spec splits into two halves. The first is the invoice payload — a header (invoice type, date, seller and buyer NTN/CNIC, province, address, registration type) plus an items array (HS code, rate, UoM, quantity, values, sales tax, SRO schedule and item serial). The second is a set of reference APIs you call to fill those fields with FBR-approved values instead of guessing. If a field's value does not come from the matching reference API, FBR is likely to reject the invoice.

There are two action endpoints per environment. Validate performs a dry run and returns the same pass/fail response as a real post without recording anything; Post submits the invoice for real and returns the FBR Invoice Reference Number (IRN). Sandbox and production use parallel paths (postinvoicedata_sb vs postinvoicedata), but routing is ultimately decided by the Bearer token you send — a sandbox token stays in sandbox even on a production-looking URL. Authentication is a single Authorization: Bearer token with five-year validity.

Around those, the documentation lists the lookup (reference) APIs: Provinces, Document Types, HS Code / item description, Transaction Types, UoM, HS Code to allowed UoMs (HS_UOM), Sale Type to Rate, SRO Schedule, SRO Item, plus registration checks (STATL active-taxpayer status and Get_Reg_Type). The rule of thumb: pick sale type from Sale Type to Rate, pick the rate string it returns, then confirm the UoM against HS_UOM for your HS code. Our companion guides on the API sample payload and the sandbox test scenarios walk through a working request field by field, and the error-codes reference explains every rejection the docs can throw back.

You do not need to read the specification to be compliant if you use a licensed-integrator platform — that is the whole point of the documentation existing. The platform implements the spec once, keeps up with each new SRO and version bump, and gives you a form instead of a JSON editor. The documentation still matters to you for two reasons: it tells you which reference value to choose when the software asks (for example, which sale type and SRO schedule your goods fall under), and it lets your accountant confirm that what is being posted matches your actual tax position.

Digi Invoice is built directly on DI API v1.12: it validates and posts each invoice in real time, pulls the reference-API values for you, and decodes FBR's numeric rejection codes into plain-language fixes so you are not cross-referencing a PDF at the counter. If you are integrating your own ERP instead, start from the PRAL spec and the FBR User Manual, test every applicable sandbox scenario for your business activity and sector until each is marked successful, and only then request your production token.