ZRA Smart Invoice for Odoo
Smart Invoice is not an invoicing project
Worth settling first, because it decides the size of the work and most descriptions of it are wrong.
Fiscalisation in Zambia does not stop at the document you hand a customer. The VSDC wants your item master, your stock movements in and out, your purchases, your imports and your manufacturing adjustments. A sale posts against inventory the authority already believes you hold. If Odoo and the VSDC disagree about what is on the shelf, the invoice is not the thing that fails.
That is why this lands as an inventory and manufacturing integration wearing an e-invoicing name. Teams that scope it as “add QR codes to the invoice PDF” discover the rest of it in the week before go-live, which is the expensive time to discover it.
The integration
Two core modules, on Odoo 17, across Accounting, Sales, Purchase, Inventory, Manufacturing and Point of Sale. zra_smart_invoice carries the ZRA API layer. zra_pos carries fiscal receipting at the till.
Sales and POS
Sales post to ZRA in real time. Invoices and receipts come back carrying the SDC ID, receipt sign and verification QR, rendered on a fiscal invoice layout built for the ZRA fields rather than bolted onto the standard template. Credit notes and debit notes sync as their own document types. POS orders post with a fiscal QR receipt, including reprint handling, because a till reprint that mints a second fiscal document is a compliance problem rather than a printing one.
Purchases and imports
Smart Invoice purchases and imports pull from ZRA into Odoo and become purchase orders, stock pickings and vendor bills. This direction is the one usually left out. Without it the finance team is keying documents the authority already holds, and the two records drift within a month.
Stock and manufacturing
Item master, stock in and out, and stock master state sync to the VSDC. Manufacturing goes with it: bills of materials, manufacturing orders and unbuild adjustments post as stock movements so a production run does not leave the fiscal record describing inventory that no longer exists.
Tax and reporting
Zambian tax structure configured across standard-rated VAT, MTV, exports, exempt supply, LPO and reverse VAT, with fiscal positions for national, international and LPO trade. Item classifications, codes and ZRA notices refresh on a scheduled job. MTV tax and vendor bill MTV reports run inside Odoo.
- Authority
- Zambia Revenue Authority, Smart Invoice via VSDC
- Odoo version
- 17
- Apps touched
- Accounting, Sales, Purchase, Inventory, Manufacturing, Point of Sale
- API surfaces
- Sales, purchases, imports, items and inventory, stock in/out, stock master, initializer, notices and codes
- Device setup
- TPIN, branch ID and device serial at initialisation
- Availability
- Built to order. Not a published module.
The work, honestly
The API is documented and the modules exist. What sets the timeline is your master data and how many of your document flows are not plain domestic sales.
-
01
Scope and branches
Which entities, which branches, which tills. Device initialisation is per branch and per device, and a branch nobody mentioned in scoping is a re-run of the setup rather than a configuration change.
-
02
Item master
Classifications, codes, units and packaging mapped to what the VSDC accepts. This takes longer than everything else here and is underestimated more often than everything else here.
-
03
Document mapping
Domestic sales are the easy case. Exports, exempt supply, LPO, reverse VAT, credit and debit notes each route differently and each needs deciding before go-live.
-
04
Stock and manufacturing posting
Which movements post, which do not, and what an unbuild means to the fiscal record. If you manufacture, this is where the design work sits.
-
05
Purchase and import pull
The inbound direction, scheduled, with the rules for what becomes a purchase order and what becomes a vendor bill.
-
06
First full cycle
Sales, POS, returns, purchases, imports and one MTV report, run end to end before the team is on its own.
What needs to be true first
- Taxpayer registration
- Active TPIN, with branch identifiers for every location that issues documents.
- Device registration
- Per branch and per device, initialised with TPIN, branch ID and serial. Registration is yours; we configure against it.
- Sandbox access
- Non-negotiable. We do not take on a statutory integration without it, because a compliance system exercised only against real documents is one nobody has tested.
- Item master quality
- Classifications, codes, units and packaging complete before go-live. The VSDC rejects what it does not recognise.
- Named owner
- Someone accountable for the error queue and for the reprint and cancellation rules at the till. An operations role, not an IT one.
- Odoo version
- Built on 17. Other versions are a porting conversation rather than a dead end, and not a free one.
Running in production
Built and running on Odoo 17 across the full fiscal surface: sales, POS, purchases, imports, stock and manufacturing. Client under NDA.
The part that took the project was not the API. It was deciding what a manufacturing unbuild means to a fiscal record the authority already holds, and making the till behave correctly when a cashier reprints a receipt that has already been fiscalised.
Integration engineering · GST e-invoicing, India · Odoo implementation
Fiscalising in Zambia, or already stuck?
Tell us your branch and till count, your Odoo version, and whether you manufacture. That is most of what determines the shape of the work, and we can size it in one reply.