Pakistan FBR Digital Invoicing

The problem

A registered business in Pakistan under the digital invoicing regime cannot simply post a sales invoice and hand the customer a printout. The invoice has to be transmitted to the FBR service, an invoice reference number has to come back, and the printed or emailed document has to carry that number together with a verifiable QR code. For point-of-sale flows the expectation is real time, not an overnight batch. For sales tax reporting, the transmitted values and the values you post to the ledger have to reconcile, month after month, invoice by invoice.

Dynamics 365 Finance & Operations has no Pakistan localization for this. There is no standard FBR service integration, no IRN storage on the invoice header, no QR rendering on the invoice report, and no reconciliation view between what F&O posted and what FBR accepted. Teams either invoice outside the ERP — which destroys the audit trail and the sales tax position — or they run a manual double-entry into a portal, which fails the moment volume or headcount changes.

The practical risk is not theoretical. A transmission that silently fails leaves you with a posted invoice that has no reference number, a customer holding an unverifiable document, and a reporting period that will not tie out.

What ECOSIRE builds

ECOSIRE builds an FBR digital invoicing extension for your F&O environment, written against your configuration and your document flows. It is not a shrink-wrapped download — it is developed after scoping and delivered into your own pipeline.

Real-time transmission

On posting, the extension assembles the FBR payload from the posted invoice: seller registration details, buyer registration or CNIC where applicable, line-level item description, HS code, quantity, value, sales tax and any further tax or extra tax components. It calls the FBR service, handles the response, and writes the returned invoice reference number back onto the invoice record inside the same logical unit of work. If the service is unreachable, the document is queued rather than lost, and a batch job retries it with backoff.

QR and document output

The returned reference is rendered as a QR code and placed on the invoice report alongside the human-readable number. Report extension is done through the standard SSRS report and DP class extension pattern, so your existing invoice layout and any branding you have applied are preserved rather than replaced.

Sales tax mapping

Sales tax codes, tax groups and item tax groups are mapped to the tax rate and tax type values FBR expects, with explicit handling for zero-rated, exempt and reduced-rate lines. Withholding and further tax scenarios are configured rather than hard-coded. Ledger dimensions on the posted invoice are read and preserved.

POS and high-volume flows

Where retail or counter sales are in scope, transmission is wired into the point-of-sale invoice flow so a receipt is not handed over without a reference number. Throughput is managed with a dedicated batch group so a spike in retail volume does not starve other batch work.

Platform mechanics

• X++ extension model using event handlers, extension classes and Chain of Command. No overlayering.
• Data entities for the FBR configuration, the transmission log and the invoice reference, exposed over OData.
• Batch framework jobs for retry, bulk resubmission and reconciliation between posted invoices and accepted transmissions.
• A reconciliation workspace listing posted invoices with no accepted reference, so a period close cannot quietly go out with gaps.
• Full request and response archival per document for audit and dispute handling.
• Number sequence integrity: the FBR reference is stored as a distinct field and never overwrites your internal invoice number.

Who this is for

Pakistani registered businesses running Dynamics 365 Finance & Operations that fall inside the digital invoicing requirement — manufacturers, distributors, importers, and retail operations with counter sales. It fits groups where Pakistan is one legal entity inside a multi-country F&O instance and the requirement must be scoped to that entity alone.

It also fits organisations whose finance team currently reconciles a portal export against a ledger export in a spreadsheet each month, and wants that reconciliation to live inside F&O.

How delivery works

1. Scoping call. We review your legal entity, sales tax setup, invoice types in scope, whether POS flows are included, your registration status and your expected volume. We confirm the FBR service endpoints and credentials you hold.

2. Fixed quote. A written scope covering payload mapping, report changes, batch jobs, entities and acceptance criteria, at a fixed price.

3. Build. Development against the same platform and application version you run, with mapping-layer unit tests and payload validation.

4. Install in test. The deployable package moves through your LCS/sandbox pipeline into test. We run the full cycle against the FBR sandbox with your own data and hand you a test script for sign-off.

5. Production. The same package is promoted after sign-off. We support the first live transmissions and the first period close.

6. Support. A defined support window follows go-live, with source code in your hands from the start.

Lead time and honesty

This is built for you after the quote is signed, typically two to four weeks to a working install in test. There is no instant download, no free trial, and nothing generic sitting on a shelf. The engineering effort is in getting the payload, the tax mapping and the failure handling right for your business — and that only exists once we have looked at your setup.