If you are a sales-tax-registered retailer or business in Pakistan, the FBR Digital Invoicing mandate means every taxable Sales Invoice must be posted to FBR's system in real time and carry a valid fiscal invoice number and QR code before you hand it to the customer. ERPNext out of the box knows nothing about FBR — it has no field for the buyer's NTN/STRN, no concept of FBR's sale-type scenarios, no call to the FBR sandbox or production endpoint, and no way to stop a POS receipt from printing until FBR has accepted it. Teams try to bridge this with spreadsheets, a separate government portal, or manual re-keying, which breaks reconciliation and creates compliance exposure the moment volume rises. This is the gap the build closes.

ECOSIRE builds a proper Frappe app — its own module, DocTypes, and hooks.py doc events — that plugs FBR fiscalization into the ERPNext documents you already use. We add the mandatory tax fields (seller and buyer NTN/STRN, NIC for unregistered buyers, HS codes, sale type, province, and FBR-specific tax rates) as custom fields on Sales Invoice, POS Invoice, Customer, and Item so the data is captured at source rather than patched afterward. A dedicated FBR Settings single DocType holds your API credentials, environment toggle (sandbox vs production), and seller registration details, encrypted using Frappe's password fieldtype.

The submission itself runs server-side. On the on_submit doc event we build the FBR JSON payload, map each line to the correct FBR scenario (SN001–SN028 style sale types), run pre-submission validation to catch a bad STRN or missing HS code before the network call, and POST it to the FBR Digital Invoicing API via a whitelisted method. When FBR returns the invoice reference number (IRN) and validation response, we write it back onto the document, generate the FBR QR code and fiscal number, and expose them in a custom Print Format so the compliant invoice prints correctly. Failed submissions are caught, logged to an FBR Invoice Log DocType, surfaced to the user, and left safely re-submittable — a scheduler event retries transient failures so a dropped connection never leaves an invoice unfiscalized. For the counter, a client script and the POS integration push the invoice the instant it is finalized so the cashier gets the QR-bearing receipt in-flow.

Because this is build-to-order, nothing is auto-downloaded. We start with a short scoping call, confirm your registration profile, sale types, POS setup, and ERPNext version (v15 or v16), then build against the FBR sandbox first. You get a documented, installable Frappe app with role-based permissions, tested end to end on a staging site with a rollback plan, and a support window after go-live. Typical delivery is one working week from confirmed scope, depending on the number of sale-type scenarios and whether you also want automated FBR reconciliation reporting.