ZAMBIA ODOO IMPLEMENTER QUESTIONS | SERPA ODOO ERP

The finance director is ready to approve the ERP contract, but the first ZRA Smart Invoice rejection arrives after go-live. The invoice has a missing commodity classification, the implementation partner says the connector is third-party software, and nobody can say who owns the fix.

That is why choosing an Odoo partner Zambia should start with evidence, not a sales demonstration. As of 31 December 2025, the Zambia Revenue Authority recorded 41,111 taxpayers registered on Smart Invoice, up from 26,329 in 2024. A local Odoo implementation now has to stand up to tax, audit and integration scrutiny from day one.

We recommend asking the following 10 questions before you sign. Ask for a live demonstration, a named owner and a contractual deliverable for each answer. A presentation is not acceptance evidence.

1. Are you listed in Odoo’s official Zambia partner directory?

Ask the implementer to show their current listing in Odoo’s official Zambia partner directory and state their present partner status. Check the live listing yourself on the day you make the decision, rather than relying on a logo in a proposal or an old certificate.

This confirms an active relationship with Odoo. It does not prove that the team can configure Zambia tax localisation or connect your invoices to ZRA Smart Invoice. Those are separate tests, and they need separate proof.

A board should ask who will do the work, not only which company signed the partner agreement. Require the proposed project manager, functional consultant, technical lead and local escalation contact to be named in the statement of work. That matters when a specialist shown during pre-sales is not the person configuring production.

Evidence to request: a live directory listing, the delivery team structure, and a responsibility matrix covering finance, integration, data migration and support.

2. Which Odoo version, edition and hosting model are you proposing?

Ask the implementer to specify the Odoo version, edition and hosting model in the contract. Then establish who owns the database, custom source code, administrator access and backups at handover.

These details determine how you upgrade, recover data and change suppliers later. An ERP that cannot be administered or extracted without the original implementer creates an operational dependency that may only become visible during an audit, acquisition or support dispute.

Require an exit plan before implementation begins. It should identify the database handover process, source-code repository access, backup frequency, restoration responsibilities and the documents you will receive. If the provider cannot state these items clearly before signing, do not approve custom development.

Judgement call: if your Odoo scope is limited to a small, standard deployment with no bespoke integration, a lighter exit schedule may be proportionate. For a multi-entity business with Smart Invoice, banks, payroll or POS interfaces, treat ownership and handover evidence as non-negotiable.

Evidence to request: architecture diagram, hosting responsibilities, sample backup and restore procedure, source-code ownership clause, and handover checklist.

3. Can you demonstrate Zambia fiscal localisation before posting starts?

Ask for a demonstration of Zambia fiscal localisation configured for your legal entity before any journal entry is posted. Odoo documentation states that fiscal localisation cannot be changed after a journal entry has been posted.

This is the step finance teams skip when pressure builds to load opening balances. Once journals exist, changing the foundation is no longer a simple configuration exercise. The result can be rework, delayed cutover and an accounting database that no longer reflects the agreed chart-of-accounts design.

The demonstration should show the chart of accounts, journals, tax configuration and company settings. Your finance lead should approve it in writing before the migration team loads opening balances, invoices or bank activity.

Take an illustrative distributor with several operating branches and a finance manager preparing a month-end cutover. The implementer loads opening balances first, then the accountant identifies that the approved Zambia tax setup is incomplete. The immediate cost is not a licence fee, it is the time spent reversing and reloading records while management loses confidence in the cutover date. In that situation, we would pause migration and approve the localisation pack before any further posting.

Evidence to request: a legal-entity configuration demonstration, approved chart-of-accounts mapping and signed finance acceptance before opening entries are loaded.

4. How will you test every tax treatment we actually use?

Ask how VAT, zero-rated, exempt, export, reverse-VAT and turnover-tax cases will be configured and tested against your actual products, customers and transactions. Do not accept a generic tax demonstration using sample items that do not resemble your trading model.

Require mapped tax codes, tax grids and a signed accountant test pack. The reason is practical: a tax configuration can look correct on one domestic invoice while failing when a credit note, export sale or reverse-VAT transaction is posted.

Your test pack should include expected accounting entries, tax report treatment and sample documents for every material scenario. The finance team, not only the implementation team, should sign off the results.

Evidence to request: transaction-to-tax mapping, test scripts, expected results, exception handling and signed acceptance from your accountant or tax lead.

5. Can you prove the ZRA Smart Invoice integration works under failure conditions?

Ask the implementer to demonstrate how Odoo invoices, credit notes, stock items and customer data integrate with ZRA Smart Invoice through the VSDC API. ZRA’s API specification requires commodity-level UNSPSC classification and provides endpoints for Smart Invoice data.

The test must cover more than a successful invoice. Ask to see a credit note, an item with commodity classification, an API rejection, a retry process and an outage scenario. The most common procurement mistake is accepting a generic invoice connector without seeing what happens when ZRA returns an error or connectivity fails.

ZRA published VSDC API Specification version 1.0.8 in May 2026. Ask which API version the implementer supports, how it monitors specification changes and who pays for future connector updates. These answers belong in the commercial agreement because an interface that works today may need controlled changes later.

Take an illustrative wholesaler with a large catalogue and sales staff issuing invoices throughout the day. The project team tests one service invoice, but no one tests whether stock items carry the required UNSPSC classifications or whether a credit note references the original fiscal document correctly. The first failure emerges after go-live, when staff start holding invoices while they wait for technical support. We would require item-level test evidence before authorising production cutover.

Evidence to request: live or controlled VSDC demonstration, API version statement, UNSPSC sample mapping, error log, retry procedure, outage process and upgrade ownership.

6. Which Smart Invoice registration path applies to our business, and who owns onboarding?

Ask which ZRA Smart Invoice registration path applies to your company and who will complete onboarding, testing and production cutover. ZRA states that eligibility includes taxpayers registered for VAT, turnover tax, insurance premium levy, tourism levy, certain excise taxes, rental tax or income tax.

The key issue is ownership. A project can stall when finance assumes the implementer will manage ZRA onboarding, while the implementer assumes the client will obtain credentials, complete testing and approve cutover.

Name one accountable person on your side and one on the implementation side. Set deliverables for registration, credentials, test transactions, production confirmation and internal training. This creates an auditable path from system configuration to live fiscal operation.

Evidence to request: onboarding plan, named owners, cutover checklist, required client inputs and written production acceptance criteria.

7. Will we receive a monthly VAT workpaper and an auditable review process?

Ask whether the implementation will produce a reconciled monthly VAT workpaper, tax report export and audit trail, and who signs these off before ZRA filing. Odoo’s tax-return workflow includes review, submission, payment and tax-period locking.

Do not assume that an Odoo tax report is itself the ZRA submission. Confirm the exact filing process, the reconciliation between source transactions and tax totals, the approver and the evidence retained for audit.

This matters most after a correction. Finance should be able to identify the source document, the tax treatment, the adjustment and the approval without relying on an individual consultant’s memory.

Evidence to request: sample VAT workpaper, tax report output, reconciliation template, filing responsibility matrix and tax-period lock procedure.

8. What is the migration order, and what will count as accepted data?

Ask how opening balances, customers, suppliers, inventory, fixed assets and unreconciled bank items will be migrated. Odoo documentation notes that the sequence of accounting master-data migration is critical because later records depend on earlier records.

Require an agreed data-migration plan that states what will be cleaned, who validates each data set and what acceptance criteria apply. “Data loaded” is not an acceptance criterion. A proper criterion might be that agreed balances reconcile to approved source reports and that sample stock, supplier and customer records behave correctly in Odoo.

Unreconciled bank items deserve particular attention. If they are migrated without a clear approach, the first bank reconciliation can expose historical differences that should have been resolved before cutover.

Evidence to request: migration sequence, data templates, reconciliation reports, exception log, mock-migration results and signed acceptance criteria.

9. Which integrations are included, and who supports each one?

Ask for a complete integration register covering banks, payroll, POS, e-commerce, mobile money and Smart Invoice. For each interface, require a named owner, interface specification, test evidence, service level and change-control cost.

An integration is not “included” merely because a connector exists. Your business needs to know which records move between systems, how duplicates are handled, what happens when an interface fails and who investigates the failure.

This is especially important where several legal entities or sales channels feed one finance environment. A missing stock or credit-note message can create a mismatch between operations, customer documents and tax reporting.

Evidence to request: interface inventory, data-flow diagrams, test evidence, support contacts, service levels and priced change-control terms.

10. What happens after go-live when tax rules, Odoo releases or staff change?

Ask what post-go-live support covers, including tax-rule changes, Odoo upgrades, security patches, training, response times and a local escalation route. Require a support SLA, release calendar, named Zambia resources and either a fixed price or a clear rate card.

Ongoing support is part of implementation ROI. A lower initial proposal can become costly if each tax adjustment, training request or interface issue is treated as unpriced change work.

Ask how the provider will test upgrades against your tax configuration and Smart Invoice integration before production deployment. The answer should include a test environment, business acceptance process and rollback responsibility.

Evidence to request: support SLA, escalation matrix, release calendar, upgrade test process, training plan and commercial rate card.

A practical scorecard for the selection meeting

Score each shortlisted implementation partner against the evidence, not the confidence of the sales presentation.

Frequently Asked Questions

Does official Odoo partner status prove Smart Invoice compliance?

No. A current Odoo partner listing proves an active relationship with Odoo, but it does not replace a demonstration of Zambia fiscal localisation and ZRA Smart Invoice integration. Ask for both forms of evidence.

Can Zambia fiscal localisation be changed after opening balances are posted?

Odoo documentation states that fiscal localisation cannot be changed after a journal entry is posted. Approve the localisation, chart-of-accounts mapping and tax setup before loading opening balances.

What should we test in a ZRA Smart Invoice integration?

Test invoices, credit notes, commodity-level UNSPSC classification, ZRA error responses, retries and outage handling. ZRA’s VSDC API specification is the relevant technical reference, and version 1.0.8 was published in May 2026.

Who should sign off the tax configuration?

Your finance or tax lead should sign the mapped tax codes, tax grids and test results. The implementer configures the system, but the legal entity remains accountable for its tax treatment and filing process.

The right Odoo ERP implementation gives finance real-time visibility, operations a unified process and leadership an auditable route from transaction to report. Before you appoint an implementer, ask for proof that it can meet Zambia’s tax and integration requirements in your environment. Request a Consultation through our Odoo partner Zambia service.