Pakistan FBR Digital Invoicing Compliance

The problem

Registered persons in Pakistan are being brought into FBR digital invoicing on hard deadlines, and the requirement is not a report you file later — it is a per-invoice transaction. Each sales invoice has to be submitted to FBR's service, validated against their schema, and returned with an FBR invoice number and QR data that must appear on the printed or emailed document you give the buyer.

NetSuite has no native path for this. There is no Pakistan digital-invoicing connector in the box, no field to hold the FBR invoice number, no HS-code-aware line structure, and no way to stop an unsubmitted invoice from being sent to a customer. Most teams end up keying invoices twice — once in NetSuite, once into a portal or a middleware screen — which guarantees drift between your ledger and what FBR holds, and puts the burden of proof on you when the two disagree.

The practical failure mode is worse than a missing feature. An invoice that was rejected by FBR at 11pm looks identical in NetSuite to one that was accepted, unless something in the system records the difference.

What ECOSIRE builds

This is a build-to-order SuiteScript 2.1 project delivered as an unmanaged bundle or SDF project that you own. We scope it against your account and your registration status, build it, install it in your sandbox, then production.

Real-time submission

A User Event script on Invoice, Cash Sale, Credit Memo and Debit Memo records fires on approval and hands the transaction to a submission routine that calls the FBR digital invoicing endpoint over HTTPS using N/https. Credentials and tokens are held in NetSuite secure strings and referenced by script, never stored in a readable custom field or hardcoded in source. The response — FBR invoice number, QR payload, status, and any validation error — is written back to the transaction inside the same processing flow, so an approved invoice always carries its true submission state.

High-volume accounts get a Map/Reduce batch path as well, so a day's invoices can be submitted, retried and reconciled without blocking users at approval time. Which mode you run in — or whether you run both — is a scoping decision based on your daily volume and your tolerance for submission latency.

Payload construction and validation

The payload builder maps NetSuite data into the structure FBR expects: seller registration and business details, buyer registration or CNIC-basis identification, invoice type and reference for notes, and a line array carrying description, HS code, quantity, unit of measure, value excluding tax, sales tax rate and amount, further tax and any extra tax where applicable, plus the invoice-level totals. Item records gain HS code and tax-treatment fields; customer records gain registration-status fields, with validation so an unregistered buyer cannot be silently invoiced under a registered-buyer rate.

A pre-submission validation routine runs the same checks the service will run — required identifiers present, line totals reconciling to header totals, rate and HS code combinations valid for the item — and blocks the submission with a readable message instead of shipping a request that will bounce.

Evidence, print and reprint

Every submission attempt writes to a custom record holding the request payload, the raw response, the FBR invoice number, the QR string, HTTP status, timestamp and user. Transaction body fields (custbody_ecs_fbr_invoice_no, custbody_ecs_fbr_qr, custbody_ecs_fbr_status, custbody_ecs_fbr_submitted_date) drive an Advanced PDF/HTML template that renders the FBR invoice number and a QR image on the printed and emailed invoice. A SuiteFlow workflow prevents emailing or printing an invoice that has not been accepted, unless a named role overrides it — and the override is logged.

Corrections and notes

Credit and debit notes are submitted with the correct document type and a reference to the original FBR invoice number, so the correction chain is traceable on both sides. Cancellation and resubmission behaviour is agreed in scoping against your process, because how you handle a rejected-then-corrected invoice is an accounting decision before it is a technical one.

Multi-entity

In OneWorld, each Pakistani subsidiary carries its own registration details, credentials and endpoint configuration, so a group instance serving several registered entities keeps them properly separated. Custom segments and departments flow into your reporting saved searches, not into the FBR payload, unless your scope requires otherwise.

Who it is for

Registered persons in Pakistan running NetSuite: manufacturers and importers with HS-code-heavy item masters, distributors and wholesalers issuing high daily invoice volume, and groups with a Pakistani subsidiary inside a OneWorld account. It also fits companies currently double-keying into a portal who want the ledger and the FBR record to come from one place.

How delivery works

1. Scoping call. We review your NetSuite account — version, edition, OneWorld or single instance — your registration and sector, which transaction types are in scope, your item master's HS code readiness, your tax code setup, and how your team currently prints and emails invoices. We look at live records.

2. Fixed quote. A written scope: the scripts, records, fields, payload mapping, print template changes and workflow rules we will build, with assumptions stated and a fixed price.

3. Build. Development in your sandbox or a development account using SuiteScript 2.1 and SDF, against the agreed mapping table.

4. Install in test. Sandbox install first, then submission testing against the FBR sandbox or test credentials where available, using your own invoices and your own item and customer data — including the messy ones.

5. Production install. After sandbox sign-off, we install into production, load per-entity configuration, set deployment statuses and role permissions, and run a supervised first live batch with your team.

6. Support. A defined support window for defect fixes, mapping adjustments and team questions. Changes driven by later FBR schema or rule updates are quoted separately, and we say so plainly rather than folding them into a vague maintenance promise.

Lead time is typically 2 to 4 weeks from signed quote to sandbox install, driven mainly by transaction types in scope, item master readiness and how fast FBR credentials are issued to you.