Pakistan FBR Digital Invoicing for ERPNext

Key Features

`on_submit` doc-event hook on `Sales Invoice` posts the FBR-schema JSON payload to the FBR digital invoicing API and writes back the IRN and QR code

Dedicated `FBR e-Invoice Log` DocType stores IRN, QR payload, FBR status code, and full request/response JSON per invoice for audit and reconciliation

QR code and IRN rendered into a compliant sales-tax invoice print format ready for customer delivery and FBR verification

NTN and STRN format-and-checksum validation on Customer and Company via `validate` hooks, blocking bad tax numbers before FBR submission

Provincial sales-tax handling through Item Tax Templates and Tax Categories mapped to PRA (Punjab) and SRB (Sindh) rates per line item

Withholding-tax automation on Purchase Invoice and Payment Entry via server scripts, keyed to configurable withholding-section rate tables

Whitelisted `@frappe.whitelist()` methods expose submit, retry, and status-check actions callable from client scripts and the Frappe REST API

`scheduler_events` background job retries failed or queued FBR transmissions and surfaces a rejected-invoice worklist

Role profiles and permission rules separate FBR-submit rights from view-only access, enforced server-side on every API method

Client scripts add a real-time FBR status indicator and a manual re-submit button on the Sales Invoice form

Single FBR Settings DocType holds API credentials, environment (sandbox vs production), seller registration details, and retry policy

Idempotent submission guard prevents duplicate IRN requests if an invoice is re-submitted or the job retries

Sales-tax and withholding register reports built as Query/Script Reports for monthly FBR and provincial return preparation

Compatible with Frappe/ERPNext v15 and v16; installed as a standalone app so core and future updates stay clean

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Pakistani businesses brought under FBR's digital invoicing mandate face a hard deadline problem: every taxable Sales Invoice must be transmitted to FBR in real time, validated, and returned with an Invoice Reference Number (IRN) and QR code before it is a legally valid tax document. ERPNext core gives you a solid Sales Invoice DocType, a tax template engine, and print formats — but it has no knowledge of FBR's e-invoicing API, no IRN/QR field on the invoice, no NTN/STRN validation, and no concept of provincial sales-tax authorities like PRA (Punjab) or SRB (Sindh). Teams end up double-keying invoices into the FBR portal, reconciling by hand, and risking rejected or non-compliant documents. This is exactly where native ERPNext runs out of road.

ECOSIRE builds a dedicated Frappe app (for example fbr_einvoicing) that installs onto your existing ERPNext v15 or v16 site without forking core. The app adds custom fields and a linked FBR e-Invoice Log DocType to capture the IRN, QR payload, FBR status, and full request/response for every submission. A hooks.py doc event on Sales Invoice on_submit calls a whitelisted server-side method that builds the FBR-schema JSON payload, signs and posts it to the FBR digital invoicing endpoint over the Frappe requests layer, then writes the returned IRN and QR back onto the invoice and its print format. NTN/STRN are validated on the customer and company records via a validate hook so bad tax numbers are caught before submission, never at the FBR gateway.

Provincial tax and withholding are modelled as first-class ERPNext concepts rather than bolted on. We configure Item Tax Templates and Tax Categories so a Punjab-registered service line picks up the correct PRA rate while a Sindh line picks up SRB, and we automate withholding-tax deduction on purchase and payment documents using server scripts and configurable rate tables keyed to withholding sections. Failed FBR transmissions are not lost: a scheduler_events background job retries queued invoices and flags anything that stays rejected, so your finance team gets a clean worklist instead of silent gaps. Role profiles and permission rules restrict who can submit to FBR and who can only view logs, and the whitelisted API methods enforce those permissions server-side.

Because this is a build-to-order engagement, nothing is a black box you download blind. It starts with a scoping call to confirm your FBR registration type, provincial footprint, invoice volume, and ERPNext version, then we build against your actual chart of accounts and tax setup. You receive the installable app source, staged UAT on a copy of your data, and a controlled go-live. Typical delivery is 2 to 4 weeks from confirmed scope, depending on the number of provincial authorities and withholding scenarios in play.

What you get

Installable Frappe app source code for the version built for your ERPNext site (v15 or v16), with a private git repository handover

Installation and configuration on your instance: FBR Settings, API credentials, tax templates, role profiles, and print format

FBR sandbox integration and a compliant production go-live once credentials are validated

Technical documentation: DocType and field reference, hooks.py events, whitelisted methods, and scheduler jobs

End-user guide plus a live training session for finance and accounts staff

UAT on a staging copy of your data with a documented rollback plan before production cutover

Post-go-live support window for bug fixes and FBR-schema adjustments

Configured PRA/SRB provincial tax and withholding rate tables matched to your registration

Who this is for

Finance Controller at an FBR-mandated company

Needs every sales-tax invoice transmitted to FBR with a valid IRN and QR at submission time, without double-keying into the FBR portal, and a clean worklist for anything rejected.

ERPNext administrator or in-house Frappe developer

Wants FBR compliance delivered as a proper standalone app with hooks, whitelisted methods, and scheduler jobs — not core patches — so v15/v16 updates and the git repo stay maintainable in-house afterward.

Tax and compliance manager operating across provinces

Handles PRA and SRB provincial sales tax plus withholding sections and needs correct rates applied per line and reliable registers to prepare monthly FBR and provincial returns.

CFO or owner of a mid-sized trading or services firm

Wants a fixed-scope, supported path to the FBR digital invoicing mandate with UAT and rollback, rather than an open-ended internal project or a risky manual workaround.

How Pakistan FBR Digital Invoicing for ERPNext Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
FBR digital invoicing integration	Built-in via on_submit hook, IRN/QR written back automatically	Possible but you design the API layer and schema yourself	Varies; often generic or not FBR-schema current	None — no FBR API awareness at all
NTN/STRN validation	Validate hooks on Customer/Company with checksum checks	Must be coded and maintained in-house	Sometimes basic format check only	Plain text field, no validation
Provincial tax (PRA/SRB)	Item Tax Templates + Tax Categories mapped per authority	You model and maintain each authority yourself	Rarely covers multiple provincial authorities	Generic tax templates, no provincial mapping
Withholding tax automation	Server scripts on purchase/payment, section rate tables	Hand-built rules per withholding section	Often out of scope	Manual entry per transaction
Failure handling and retries	Scheduler retry job + rejected-invoice worklist + full log	You build the queue and logging	Usually fire-and-forget, limited logging	Not applicable
Fit to your ERPNext setup	Built against your chart of accounts, taxes, and version	Fully bespoke but slow and costly to build	Generic; you adapt your process to it	Generic core only
Ownership and maintainability	Standalone app, full source + git repo handover	You own it but also own all the risk	Vendor-locked, limited source access	N/A
Support and FBR schema updates	Post-go-live support window + optional retainer	Your team on the hook for every FBR change	Depends on vendor SLA and roadmap	None

Frequently Asked Questions about Pakistan FBR Digital Invoicing for ERPNext

Is this an app I can download and install myself right now?

No. This is a build-to-order engagement, not a Frappe Cloud Marketplace download. ECOSIRE builds the app against your ERPNext version and tax setup, installs it on your instance, and supports it. You receive the full source and git repository at handover.

How long does delivery take?

Typically 2 to 4 weeks from confirmed scope. The exact timeline depends on your ERPNext version, invoice volume, the number of provincial authorities (PRA, SRB, etc.) involved, and how many withholding scenarios need modelling. We confirm a firm date after the scoping call.

Which ERPNext and Frappe versions are supported?

We build for Frappe/ERPNext v15 and v16. The app is installed as a standalone Frappe app rather than a core fork, so your ERPNext core and future updates stay clean and maintainable.

How does the FBR integration actually work technically?

A `hooks.py` doc event on `Sales Invoice` `on_submit` calls a whitelisted server method that builds the FBR-schema payload, posts it to the FBR digital invoicing API, and writes the returned IRN and QR back to the invoice and print format. Every call is logged in a dedicated DocType, and a scheduler job retries failures.

How are provincial taxes (PRA/SRB) and withholding handled?

Provincial sales tax is modelled with Item Tax Templates and Tax Categories mapped to the correct authority rate per line, and withholding tax is automated on purchase and payment documents via server scripts keyed to configurable withholding-section rate tables. We configure these to your actual registration during delivery.

What about support and updates after go-live, including FBR schema changes?

Every engagement includes a post-go-live support window for bug fixes and adjustments if FBR changes its digital invoicing schema or validation rules. Longer-term maintenance and enhancement retainers are available. Because you hold the source and git repo, your own team can also extend it.

Do you handle NTN and STRN validation?

Yes. NTN and STRN are validated for format and checksum on Customer and Company records via `validate` hooks, so invalid tax numbers are caught inside ERPNext before an invoice is ever submitted to FBR.