Which Odoo FBR module should you use, and when do you need a custom connector?

An off the shelf Odoo FBR module is usually sufficient when you are on a current Odoo version that a maintained module supports and your scenario set is one of the common cases. A custom connector becomes necessary when your sector's scenario list is wide or unusual, for example steel, petroleum, textile with cotton ginner purchases, pharmaceuticals at fixed rate or third schedule goods, because generic modules concentrate on the common cases.

The decision is not really "which module". It is whether a module is the right shape of solution for your business at all. This guide works through that from the requirements side, because the requirements are published and checkable, and they are the only stable thing in this market. If you would rather have the whole thing handled, that is our Odoo integration service.

What is actually on the shelf

Searching the Odoo apps store for FBR digital invoicing on 22 August 2026 returns a set of separately published modules, including l10n_pk_fbr_integration from Zalino Tech for Odoo 19, l10n_pk_fbr_digital_invoice from Pokutsoft for Odoo 19, fbr_digital_invoicing from ClickSoft for Odoo 18, fbr_integration_digital_invoicing from EyrisNext for Odoo 18, de_digital_invoicing from Dynexcel for Odoo 18, and fbr_digital_invoicing_integration from CodersCloud for Odoo 14. You can see the current list on the Odoo apps store.

Three structural facts matter more than any individual listing.

Each module targets one Odoo version. The listings above run across versions 14, 18 and 19. An Odoo module is not version portable in any meaningful sense, so the module that solves your problem this year is a thing you have to re buy, or wait for, at your next Odoo upgrade. That is a recurring dependency, not a one off purchase.

The prices are spread across two orders of magnitude, from free to several hundred US dollars for a single module. A price spread that wide across products claiming to do the same job usually means they are not doing the same job. It is a signal to check scope, not a signal to buy the cheapest.

Nobody on the app store is a licensed integrator by virtue of publishing a module. Under rule 150XE of the Sales Tax Rules 2006, integration of a notified registered person has to be carried out through a licensed integrator, or through PRAL. Buying software is not the same as arranging integration. We cover that separately in how to choose a licensed FBR integrator.

The requirements any connector has to meet, bought or built

This is the useful part, because it is published and it does not change with the vendor. Chapter XIV of the Sales Tax Rules 2006, as substituted by SRO 69(I)/2025, sets out what an integrated person's system must do. Read it as a specification and use it as a checklist against whatever you are considering.

The invoice fields

Rule 150R(13) lists twenty six particulars that an electronic invoice must carry. Several of them do not exist as first class concepts in stock Odoo and have to be modelled somewhere: the FBR invoice number in its prescribed format, the verifiable QR code at seven by seven millimetres, the software registration number, the FBR digital invoicing logo, the seller and recipient registration numbers, HS code, unit of measurement, sales tax withheld at source, extra tax, further tax, federal excise duty payable in sales tax mode, and the applicable SRO with its serial number. A retailer issuing invoices to the general public is relieved of four of those, but only if it is not also a manufacturer or importer.

If a module's description does not mention HS codes and units of measurement, be sceptical. Those two fields cause more rejections than anything else, and we have a separate guide on HS codes on an FBR invoice and on why invoices carry two units.

The reference data

FBR does not accept free text where it publishes a code list. PRAL's Technical Specification for DI API, version 1.12 documents reference endpoints for provinces, document type codes, item description codes, SRO item codes, transaction type codes, units of measurement, SRO schedules, sale type to rate mapping, and the permitted units of measurement for a given HS code. A connector that hard codes these instead of reading them will drift out of correctness the first time FBR updates a schedule. Ask whether the module syncs reference data or ships a snapshot of it.

The behaviours that are not about the invoice at all

• Offline mode. Rule 150XC provides that invoices generated during a failure of the software, or during an internet or power interruption, "shall be clearly identified as invoices issued in the offline mode and shall be uploaded within 24 hours of restoration". A connector that posts synchronously when a user clicks confirm, and simply errors when FBR is unreachable, does not satisfy this. It needs a queue, a retry, and an offline flag.
• Debit and credit notes. Rule 150S(2) requires these to be issued electronically through the integrated system as well, not just sales invoices. See our guide on debit notes and credit notes.
• Fault reporting. Rule 150XA obliges the integrated person to report operational failure, damage, disruption or tampering to the Board and the Commissioner within twenty four hours. Good tooling makes that visible. Most modules do not think about it at all.
• Retention. Rule 150S(1) requires invoices to be retained for six years on electronic media, and rule 150T requires storage such that the information as originally transmitted can be re created at the time of a departmental audit. That is a data retention design question, not a checkbox.
• Logging. Rule 150R(4)(g) requires every adjustment, modification or cancellation to be recorded with logs, and system events to be recorded.
• Annexure C. Rule 150R(5) provides that Annexure C of the sales tax return is auto filled from the electronic invoices issued. If what your connector posts is wrong, your return is wrong, automatically. This is the reason field mapping deserves more care than it usually gets.
• Outlets. Rule 150R(2) requires you to register your outlets, points of sale or invoicing machines, and rule 150R(3) provides that no supply shall be made except through them. Multi branch and multi company Odoo installations have to model that correspondence explicitly.

What sandbox testing actually involves

Testing is not a formality, and it is the stage where the difference between modules becomes visible. FBR defines named scenarios, and which ones apply to you is a function of your declared business activity, not your preference.

Section 9 of the DI API technical specification lists twenty eight scenarios, SN001 through SN028. SN001 and SN002 are the ordinary cases, standard rate goods to a registered buyer and to an unregistered buyer. The rest are sector specific: steel melting and re rolling, ship breaking, reduced rate, exempt, zero rated, third schedule goods, cotton ginners in the textile chain, telecommunication services, toll manufacturing, petroleum products, electricity supply to retailers, gas to CNG stations, mobile phones, processing and conversion, goods and services with federal excise duty in sales tax mode, electric vehicles, cement and concrete block, potassium chlorate, CNG sales, goods listed in SRO 297(I)/2023, and drugs at a fixed rate under serial 81 of the Eighth Schedule. Scenarios SN026 to SN028 cover sales to end consumers and apply only if you are registered as a retailer in your sales tax profile.

Section 10 of the same document then maps business activity and sector to the applicable scenario set. A manufacturer in a general sector is expected to clear eleven scenarios. A textile manufacturer gets the same eleven plus the cotton ginners case. A steel manufacturer has a completely different set. This is the single most useful test of a module you are evaluating: ask which scenario identifiers it has actually cleared, and compare that to the list for your sector. A module built and tested against SN001 will look perfect in a demo and stall the moment you need SN008 or SN012.

On mechanics, the technical specification notes that the API URLs are the same for sandbox and production, with sandbox endpoints carrying an _sb suffix, and that routing is determined by which security token is used. The token is issued by PRAL, passed as a bearer token in the Authorization header, and documented as having a validity of five years. Our separate guide on FBR sandbox testing covers the process end to end.

On the static IP question

You will be told, frequently, that FBR requires a static IP address and that it must be whitelisted before you can go live. It is worth being precise about what is and is not published, because this is a real cost and a real delay if it applies to you.

What a static IP means. Most Pakistani broadband and fibre connections are dynamic, meaning your public address changes from time to time. A static IP is a fixed address your internet provider assigns permanently to your connection, and it is a paid add on or a business grade plan feature rather than something included by default.

What we could verify. We could not find a static IP or IP whitelisting requirement in FBR's own published material. It does not appear in the DI API technical specification version 1.12, which documents authentication as a bearer token in the Authorization header and says nothing about source addresses. It does not appear on FBR's digital invoicing FAQs or its technical assistance page. It is not in Chapter XIV of the Sales Tax Rules.

That does not prove it is never asked for. Individual integrators and PRAL support may impose network controls of their own, and requirements communicated by helpline do not always reach the published documentation. What it does mean is that this is a question to put directly to your integrator or to PRAL before you buy an ISP product for it, and to ask them to point at the requirement rather than assert it. If you self host Odoo on an office connection there may be perfectly good operational reasons to want a fixed address anyway, but that is a decision about your infrastructure, not a compliance obligation we can source.

So: module, or custom connector?

A module is likely fine when

• You are on a current Odoo version that a maintained module supports, and you plan to stay there.
• You sell one broad category of goods at standard rate, mostly to registered buyers, so your scenario list is short.
• Your invoicing follows stock Odoo. Sales order to invoice, no unusual billing.
• Your volume is modest enough that a manual retry after a failure is tolerable.
• You have someone who can read Odoo logs when something goes wrong.

A custom connector becomes the sensible option when

• Your scenario set is wide or unusual. Steel, petroleum, textile with cotton ginner purchases, pharmaceuticals at fixed rate, third schedule goods, or any mix of these. Generic modules concentrate on the common cases because that is what sells.
• You are on an Odoo version nobody publishes for, or you have a major version upgrade coming. Migrating a third party module you do not control is frequently harder than migrating code you do.
• Your Odoo is heavily customised. Subscription billing, project billing, custom invoice workflows, a modified account.move, or a POS layer alongside back office invoicing. Modules assume the stock model and break loudly against a modified one.
• You need both FBR and a provincial authority. If you supply goods federally and services in Punjab, you are dealing with two systems, and the app store modules address the federal one. That is a design problem, and it is why we treat PRA digital invoicing as its own service line.
• Continuity matters. Rule 150XC's offline requirement and a high invoice volume together mean you need queueing, retry, idempotency on resubmission, and a reconciliation view showing which invoices are unacknowledged. That is engineering, not configuration.
• You have multiple companies or many outlets. The mapping between Odoo companies and warehouses and your registered outlets under rule 150R(2) has to be explicit and auditable.
• You cannot get a straight answer about who maintains the module. An abandoned connector is a compliance liability with your name on it, not the publisher's, because rule 150R(2) and rule 150X put the obligation and the consequence on the integrated person.

The honest middle path

In practice a lot of good outcomes are neither. They are a maintained module used as a starting point, with a thin extension module of your own holding the parts specific to you: your sale type mapping, your HS code and unit of measurement discipline, your scenario coverage, your queue behaviour. That keeps the vendor's work where it is useful and puts the parts most likely to be wrong for your business under your own control, and it makes the next Odoo upgrade a smaller piece of work than a fully custom build would.

Whichever route you take, the integration itself still has to run through a licensed integrator or PRAL under rule 150XE. That is a separate arrangement from the software, and it is worth understanding before you commit to either.

Primary sources

• Chapter XIV, Sales Tax Rules 2006, procedure for licensing, issuance of electronic sales tax invoices and integration of registered persons: download1.fbr.gov.pk Chapter XIV
• SRO 69(I)/2025 dated 29 January 2025, substituting Chapter XIV: download1.fbr.gov.pk SRO 69(I)/2025
• SRO 1413(I)/2025 dated 1 August 2025, turnover banded integration schedule superseding SRO 709(I)/2025: download1.fbr.gov.pk SRO 1413(I)/2025
• Sales Tax General Order 01 of 2026 dated 30 March 2026: download1.fbr.gov.pk STGO 01 of 2026
• Technical Specification for DI API version 1.12, PRAL: download1.fbr.gov.pk DI API v1.12
• FBR digital invoicing FAQs: fbr.gov.pk/faqs
• Odoo apps store module listings, observed 22 August 2026: apps.odoo.com

Last verified: 22 August 2026. Every rule, scenario and requirement above was read from the primary sources listed. Module names, publishers and versions were observed on the Odoo apps store on that date and change without notice. General information, not tax advice. Confirm your own obligations and applicable scenarios with FBR, PRAL or your tax consultant.