Pakistan FBR Digital Invoicing

The obligation, and the gap

Pakistan's Federal Board of Revenue has moved registered persons onto digital invoicing. A sales tax invoice must be transmitted electronically at the point of issue, the response carries an invoice reference number, and the printed or shared document must display that reference along with a QR code that lets anyone verify the invoice against FBR's records. Submission goes through a licensed integrator's API rather than direct upload, and the regime arrives with dated deadlines by taxpayer category.

SAP Business One holds everything the submission needs — the A/R Invoice, its lines, its sales tax computation, the Business Partner's registration details — and can transmit none of it. There is no FBR field on the document, no place to store an invoice reference number or QR payload, no submission log, and nothing stopping a user from issuing an invoice that was never reported.

Sites without an integration end up in one of two bad states. Either invoices are re-entered into an integrator's portal, which means the ERP and the tax record can silently diverge and nobody can prove which invoice was reported; or invoices are issued from SAP Business One and reported later in a batch, which puts every unreported document at risk and makes a rejection something you discover after the customer already has the paperwork.

ECOSIRE builds the submission lane inside SAP Business One so the reported invoice and the posted invoice are the same document.

What ECOSIRE builds

Submission at the point of issue

When an A/R Invoice is added, the add-on assembles the FBR payload from the posted document and submits it through your licensed integrator's API. The response — invoice reference number, QR payload, timestamp, and status — is written straight back onto the document via the Service Layer. A submitted invoice is identifiable in the system without asking anyone.

The payload is built from the document itself: seller registration details from your company configuration, buyer registration and status from the Business Partner master (with UDFs for the identifiers SAP Business One does not hold natively), document type and issue date, line detail with item identification, HS code where applicable, quantity, unit of measure, value excluding tax, applicable sales tax rate and amount, further tax and extra tax where they apply, withholding treatment, and the document totals reconciled against what posted.

Hard stop on non-compliant issuance

This is the part that matters most. Business logic prevents an in-scope A/R Invoice from being treated as issued until submission has succeeded or a defined exception path has been taken with a recorded reason and an approver. Print layouts refuse to render the compliant document without an invoice reference number, so a customer cannot be handed a document that FBR has never seen. Exceptions are visible, attributable, and reportable rather than being the default behaviour under pressure.

QR and reference number on the printed invoice

We render the QR code and the invoice reference number onto your sales tax invoice layout in Crystal Reports, positioned and labelled per the regime's presentation requirements, alongside the seller and buyer registration numbers and the sales tax breakdown drawn from the document's own tax lines. If your layout also needs branding or Urdu content, that is layout work we scope alongside.

Credit notes and cancellations

A/R Credit Memos are submitted as debit or credit documents referencing the original invoice's reference number, so an adjustment is traceable to what it adjusts. Cancellation and correction flows follow the regime's rules rather than deleting anything: the original submission record is retained, the corrective document carries its own reference, and the log shows the chain.

Validation before the API sees it

We validate locally first: buyer registration format and presence, sales tax arithmetic reconciled to the posted document, mandatory field completeness, HS code presence where the item requires it, and rate consistency against your tax code configuration. Failures are surfaced on the document with the specific field named, so users fix master data instead of retrying blindly against a rate-limited API.

Submission log and reconciliation

Every attempt is recorded in a log UDT: payload reference, request timestamp, integrator response code, invoice reference number, error text, retry count, and the user who triggered it. On top of that we build a reconciliation view answering the question an auditor asks — which A/R Invoices in this period have no accepted submission, and why. That view is also what you use before a filing period closes.

Resilience and retries

API outages happen and cannot be allowed to stop invoicing entirely. Failed submissions queue with retry and backoff, a scheduled job drains the queue, and named recipients are alerted when a document exhausts retries or when the queue depth crosses a threshold. Nothing is dropped, and nothing is silently pending.

Sandbox first, always

The build is exercised end to end against your integrator's sandbox before any production credential is used, and the environment in force is displayed in the interface so nobody confuses a sandbox reference number for a real one.

Who this is for

Sales-tax-registered persons in Pakistan running SAP Business One 10.0 who are in scope for FBR digital invoicing or have a deadline approaching, manufacturers and distributors issuing high volumes of sales tax invoices where portal re-entry is not survivable, and groups with a Pakistani entity on SAP Business One that must submit while other entities stay on their existing processes.

Compatibility

Built for SAP Business One 10.0 on Microsoft SQL Server or SAP HANA, on-premise or cloud-hosted. Delivered as an add-on using the Service Layer (REST) and the DI API, with UDFs, UDTs, and UDOs for registration data, submission logging, and configuration, approval procedures for the exception path, and Crystal Reports for the compliant layout. No modification of SAP system tables.

How delivery works

1. Scoping call. We confirm your registration status and category deadline, your licensed integrator (or help you shortlist one and understand what their onboarding requires from you), which document types and numbering series are in scope, your sales tax code configuration and how it maps to the required rate fields, whether further tax, extra tax, or withholding apply to you, and who owns the exception approval.

2. Fixed quote. You receive a written scope covering the payload mapping, local validation rules, the integrator API integration, the issuance block and its exception path, the layout changes, the reconciliation view, and the acceptance criteria — with a fixed price and delivery date.

3. Build. We develop against a copy of your company database, so mapping and validation meet your real items, HS codes, tax codes, and Business Partner data rather than demo data.

4. Install in test. We install into your test company against your integrator's sandbox and run a documented acceptance pass: submit each in-scope document type, verify reference number and QR write-back, print the compliant layout, force a rejection and resolve it, exercise the exception path with an approver, submit a credit note against an original, and confirm the reconciliation view reports correctly. You sign off against the criteria from step 2.

5. Install in production. After sign-off we install into production during an agreed window, switch to live credentials, and submit a first real invoice under supervision — verifying the reference number resolves on FBR's verification channel before the lane is opened to all users.

6. Support. A defect-fix window follows go-live. We state plainly which parts are ours (mapping, validation, issuance control, layout, logging) and which sit with your integrator contract and your FBR registration.

Build-to-order, stated plainly

There is no pre-built download and no trial version. The build starts after you approve a fixed quote and is fitted to your integrator, your tax code configuration, and your document flow. Typical lead time is one working week from approval, with integrator onboarding and credential issuance often the longest pole — we recommend starting that in parallel with the scoping call. ECOSIRE is not a licensed integrator and does not act as one; that relationship stays between you and your integrator.