Pakistan FBR Digital Invoicing Bridge

The compliance gap sits between your books and the tax authority

Under Pakistan's digital invoicing regime, a registered person cannot simply print a sales tax invoice and hand it over. The document has to be transmitted to the FBR digital invoicing system, and the invoice number and QR code returned by that system have to appear on the copy the buyer receives. Miss the transmission and you have issued a document that does not satisfy the requirement, however correct the arithmetic is.

Zoho Books is a capable ledger with a well-documented REST API, a workflow engine and Deluge scripting. What it does not have is any awareness of the FBR schema. There is no Pakistan digital invoicing connector, no place to store an NTN in a way the tax payload understands, no HS code on the item master, no province of supply on the transaction, and no concept of further tax, extra tax or sales tax withholding as separately reported amounts. So finance teams end up running two systems in parallel: they raise the invoice in Books, then re-key it into a portal or an intermediate spreadsheet, then paste the returned number back by hand. Every re-key is a chance for the Books sales register and the transmitted set to drift apart, and that drift only surfaces at return-filing time when nobody has the hours to spare.

ECOSIRE builds the missing piece as a fixed-scope project, delivered into your own Zoho organization. Nothing here is a pre-built product you download today. We scope your setup, quote a fixed price, build it, and install it.

What ECOSIRE builds

A Pakistan tax data model inside your Zoho org

The first half of this work is data, not code. We add custom fields to the Zoho Books Contact record for NTN or CNIC, registration status, buyer type and province, so the values are captured once on the customer and inherited by every transaction rather than typed per invoice. On the Item record we add HS code, unit of measure and rate description. On Invoice, Credit Note and Debit Note we add the fields the payload needs and the fields the response returns: sale type, scenario reference, FBR invoice number, QR payload and transmission timestamp.

Tax itself is modelled with native Zoho Books taxes and tax groups so that the sales register and the transmitted payload are derived from the same numbers. Further tax, extra tax and withholding are set up as distinct taxes rather than folded into a single rate, because the payload reports them separately and a blended rate cannot be unblended after the fact.

The transmission layer in Deluge

Transmission runs as Deluge custom functions attached to Zoho Books workflow rules, so the call fires at a defined lifecycle point you choose, typically on approval or on marking the invoice as sent. Calls go out with invokeurl through a named Deluge Connection, which means the FBR token lives in the connection store and not in a script body that anyone with edit rights can read.

The payload builder is deliberately table-driven. Sale types, scenario references and tax category mappings live as records in a Zoho Creator app, not as literals in code, so when the published schema changes you edit rows instead of paying for a redevelopment cycle.

Validation before anything leaves your org

A rejected submission is more expensive than a blocked one. Pre-flight rules stop a document that has no NTN on a registered buyer, an exempt or zero-rated line with no reason recorded, a goods line with no HS code, or a rounding difference beyond tolerance between line tax and header tax. The user sees a specific message on the invoice, in Books, before the document is issued.

The document the buyer actually receives

The returned invoice number and QR payload are written back to the invoice, the QR image is attached through the Books API, and a custom Zoho Books print template renders the number, the code and the timestamp on the PDF. Your team keeps working in Books; the compliant artefact comes out the other end.

Notes, corrections and the audit trail

Credit and debit notes are transmitted carrying the reference of the original document, taken from the source invoice rather than re-entered. Every attempt is logged: request payload, response payload, HTTP status, user and timestamp, in a Zoho Creator app with a scheduled function that re-attempts transient failures and escalates hard rejections by email to a named owner.

Reconciliation you can hand to your auditor

A monthly report compares the Zoho Books sales register against the set of accepted transmissions and lists the exceptions: issued but never transmitted, transmitted but rejected, transmitted with a value that no longer matches the current invoice. That list is short if the bridge is healthy, which is exactly why it is worth running.

Who this is for

Registered Pakistani businesses already running Zoho Books as their book of record. It suits distributors, manufacturers and B2B service firms with steady invoice volume, where re-keying is a daily cost rather than an occasional annoyance. It suits groups running several Zoho Books organizations under one holding structure, because the same mapping tables and the same log app cover all of them. If you also operate under the retail point-of-sale regime, that is a separate obligation with a separate technical path and we scope it separately rather than pretending one build covers both.

How delivery works

1. Scoping call. Forty-five to sixty minutes, screen shared. We look at your Zoho Books organization, your current tax setup, three or four real invoices including a credit note, your registration position and who controls your FBR credentials.

2. Fixed quote. You get a written scope, the field mapping, the assumptions, and one price. If the scoping call reveals your Zoho plan lacks the automation features this needs, we tell you before you commit rather than after.

3. Build. Typically two to four weeks depending on how many document types and entities are in scope. You get a mid-build checkpoint with working transmissions against the sandbox.

4. Install in test. Everything goes into a test Zoho Books organization first and runs against the FBR sandbox with your own scenarios. You transmit your own invoices and sign off on the evidence pack.

5. Production cutover. We are on the call for the switch to production credentials, the first live batch and the first credit note.

6. Support window. Thirty days of defect fixes and schema-change patches after go-live, with an optional ongoing arrangement after that.

What this is not

ECOSIRE is not an FBR-licensed integrator and does not act as your tax agent. The bridge transmits from your Zoho organization using credentials issued to you, and responsibility for what is filed remains yours. We do not prepare or submit your returns. And there is no instant download or free trial: this is engineered per organization, and the first artefact you see is a quotation, not a zip file.