Finance teams invoicing in Zambia face a problem Odoo core does not solve: an invoice is not legally complete when it is posted in the ERP. It becomes valid only once it has been transmitted to the Zambia Revenue Authority's Smart Invoice service, accepted, and returned with its fiscal identifiers so the printed document can carry them. Out of the box, account.move knows nothing about that round trip. Teams bridge the gap by hand — re-keying every invoice into a separate Smart Invoice client, exporting spreadsheets at month end, or building fragile scripts on top of the JSON-RPC API. The results are predictable: mismatched totals between the ERP and the fiscal record, invoices that were posted but never fiscalised, credit notes with no traceable link to the original document, and an audit trail that lives in two systems that were never reconciled.

We build a dedicated Odoo module that makes fiscalisation a first-class part of the invoicing workflow. The module extends account.move and account.move.line with the fields the regime actually needs — fiscal status, submission and response timestamps, the returned invoice number and verification data, the reference to the original document on a credit note — and models the ZRA transport as its own object so device/API credentials, endpoints and the branch or taxpayer identifiers are configured per company rather than hard-coded. Posting an invoice raises a submission record; a queued job (or an ir.cron on smaller installations, your choice at scoping) handles transmission, retries and the response, so a slow or unavailable endpoint never blocks a user's action_post(). Tax treatment is derived from your existing master data — account.tax, fiscal positions, product categories and UoM — through an explicit mapping model rather than guesswork, so the classification a document carries is auditable and changeable by an accountant instead of a developer.

One posting produces both required outputs. The machine payload is assembled from the same lines that produce the human-readable document, so the two can never diverge: a QWeb report inheriting your existing invoice template renders the fiscal number, verification QR code and any statutory wording, while the transmitted payload is stored verbatim alongside the response. Rejections are treated as a workflow, not an error log — a rejected document lands in a dedicated state with the authority's reason code surfaced on the form, an activity raised for the responsible user, and a guarded correction path that either amends and resubmits or issues a properly linked credit note, with every attempt retained. Access is governed through ir.model.access.csv plus record rules so only the finance roles you nominate can resubmit or override, and every state change is written to the chatter and to an immutable submission log for archiving.

The module targets Odoo 17.0, 18.0 and 19.0 and is built against your edition. It depends only on account and standard framework services, so it works on Community; where you run Enterprise we use the accounting features you already have (bank reconciliation, follow-up, consolidated reporting) rather than duplicating them. Multi-company and multi-branch setups are handled through company-scoped configuration, and integration points are exposed over XML-RPC/JSON-RPC where a POS, e-commerce front end or third-party billing system needs to trigger fiscalisation from outside Odoo.

This is build-to-order, not a marketplace download. We start with a short scoping call to confirm your ZRA registration model, the document types in scope, your tax mapping and your Odoo version and edition. From there we write the manifest and models, build against a copy of your database, and deliver typically 2–4 weeks from confirmed scope. You get the installable source for your version, a staging deployment for UAT, a documented rollback, training for the finance team, and a post-go-live support window — plus the git repository, so the code is yours to keep and extend.