ZIG AND USD FISCAL RECEIPTS IN ODOO | SERPA ODOO ERP

A Harare counter sale is paid in USD, but the printed receipt shows ZiG. The cashier has entered the correct total in Odoo, yet the fiscal device transmitted a different tender amount to the Fiscalisation Data Management System, FDMS. That mismatch can turn a routine sale into an audit problem.

For Zimbabwean VAT-registered businesses, Odoo ZIMRA fiscalisation is not a matter of making an invoice template look correct. Odoo must feed an approved fiscal device, virtual fiscal device or FDMS API that transmits each sale and generates a verifiable fiscal output. As of 6 October 2026, the configuration must account for both ZiG and USD at the point of sale, in accounting and in the fiscal payload.

We see the same mistake most often in businesses that have already configured attractive Odoo invoice layouts. The layout is only the visible layer. ZIMRA assesses what reaches FDMS, what the QR validation returns and whether the printed document matches the transaction recorded.

The compliance point that changes the Odoo design

ZIMRA administers VAT fiscalisation in Zimbabwe. A VAT-registered business must fiscalise every point-of-sale transaction and transmit every sale through a compliant fiscal device to FDMS. This requirement means an ordinary Odoo PDF invoice cannot be treated as a fiscal receipt merely because it includes a VAT number, a QR code or the words “tax invoice”.

A proper implementation has three connected records:

1.       The Odoo transaction: The sale order, POS order or customer invoice holds the customer, products, taxes, currency and payment information.

2.       The fiscal submission: The approved device, virtual fiscal device or FDMS API receives the correct transaction data and returns the fiscal result.

3.       The customer document: The printed or electronic fiscal tax invoice reflects the data submitted and contains the verifiable fiscal reference.

The distinction matters because ZIMRA’s FDMS validation portal must return “VALID”. A QR code by itself is not evidence that the document is valid. The QR code must lead to a fiscal transaction that FDMS recognises.

Odoo supports invoice journals, customer records, taxes, fiscal positions and multi-currency transactions. Zimbabwe-specific FDMS compliance, however, requires an integration and validation process beyond Odoo’s standard invoice and receipt layout features. Odoo’s official Point of Sale documentation explains how receipts and invoices are generated within the system, but it does not substitute for ZIMRA fiscal-device requirements.

What each ZiG and USD fiscal receipt must show

Since 10 June 2026, ZIMRA requires the actual transaction currency and amount tendered to appear for both ZiG and USD transactions. The receipt must also show the correct goods or service description, taxable value, VAT amount and total.

The standard VAT rate is 15.5% in 2026. This rate needs to be consistent in Odoo, in the fiscal-device payload and on the final fiscal receipt. A 15.5% tax calculation in Odoo paired with a different fiscal submission is still a mismatch.

A compliant fiscal tax invoice must include the following information:

| Receipt requirement | Odoo configuration point | Why it matters | | “Fiscal Tax Invoice” label | Fiscal receipt template generated after FDMS response | An ordinary sales invoice should not be passed off as a fiscal document. | | Supplier name, address, VAT number and business-partner number | Company record and fiscal integration settings | ZIMRA needs to identify the registered supplier that made the supply. | | Buyer details where applicable | Customer form and POS customer selection | Buyer data now affects both compliance and input VAT evidence. | | Serial number and issue date | Fiscal device or FDMS response fields | These establish the specific fiscal transaction and time of issue. | | Item description and quantity | Product catalogue and order lines | Generic descriptions make audit matching difficult. | | Transaction currency and amount tendered | Separate USD and ZiG payment methods | The receipt must reflect what the customer actually paid. | | Supply value, VAT amount and consideration | Tax mapping and fiscal payload | These figures allow ZIMRA and the buyer to test the VAT calculation. |   Where a business quotes tax-inclusive prices, the fiscal receipt must clearly show the VAT-inclusive statement and rate. Where prices are tax-exclusive, the supply value, VAT and consideration should reconcile line by line. Do not leave this to a visual invoice template. Test the figures in the FDMS response.

Taxes must be remitted in the currency of trade, except income tax. That rule is why a USD sale needs to remain a USD sale through Odoo posting, fiscalisation and VAT reporting. Converting the display currency on a receipt while submitting another currency to FDMS creates a record that will not reconcile.

Configure Odoo for currency-by-currency control

For businesses accepting both currencies, we recommend separate operational controls rather than one shared payment flow. The additional setup takes time during implementation, but it gives finance teams a clearer audit trail and reduces correction work later.

Step 1: Create distinct USD and ZiG journals

Set up separate sales and payment journals for USD and ZiG transactions. The journal naming should be obvious to a cashier and to the finance team, for example, “POS USD” and “POS ZiG”.

This separation helps prevent a sale received in USD from posting into a ZiG workflow. It also gives the finance team a practical starting point when reconciling Odoo records to FDMS submissions and payment collections.

Step 2: Configure payment methods around actual tender

Each POS payment method should identify the currency tendered. Cash USD, cash ZiG, USD card and ZiG transfer may need separate treatment where they are recorded and settled differently.

The amount tendered is not an optional cosmetic field. ZIMRA requires it to be correct on the fiscal record. If a customer tenders US$100 for a US$92 sale, the transaction data needs to handle the actual tender and change correctly where the fiscal process requires it.

Step 3: Lock the currency through the fiscal payload

Map the Odoo transaction currency to the fiscal integration field, then test both USD and ZiG scenarios. The team should inspect the transmitted data, not only the printed document.

A useful test is to process one identical product basket in each currency. Compare the Odoo order, fiscal-device response and printed receipt. If any one shows a different currency, taxable value, VAT or total, stop the rollout and correct the mapping.

Step 4: Set 15.5% VAT and test inclusive pricing

Create and apply the correct 15.5% VAT tax rules for the relevant taxable supplies. Then test tax-inclusive and tax-exclusive product prices separately if the business uses both models.

The reason is simple: a tax-inclusive price can look correct to the cashier while the taxable base sent to FDMS is wrong. The finance team should approve sample receipts before opening a new branch, outlet or POS configuration.

Step 5: Build buyer-detail capture into the sale

Buyer-detail transmission to FDMS became mandatory by 31 May 2025. Capture the buyer’s name, address, TIN, contact details and VAT number where applicable.

If the buyer has no TIN, do not force placeholder data into the fiscal-device buyer block. ZIMRA’s direction is to capture buyer details elsewhere on the receipt. This is a common implementation error because teams try to make every Odoo customer field fit into a mandatory fiscal field.

Step 6: Generate the fiscal document only after approval

The Odoo layout should use the successful FDMS response to produce the fiscal tax invoice. It should carry the fiscal reference, QR-verifiable data and the required receipt fields.

If the device or API is unavailable, do not allow staff to describe a standard PDF as a fiscal receipt. Put a documented exception procedure in place, then resolve and validate the transaction according to the approved fiscalisation process.

Two practical examples of where controls fail

Take a Bulawayo hardware retailer with twelve staff, two tills and monthly sales of about US$40,000. The retailer accepts USD cash, ZiG transfers and card payments, but initially uses one Odoo payment method called “Cash”. A cashier can select the payment method, print a receipt in USD and close the session, even though the fiscal submission identifies the tender as ZiG.

The management team may not see the problem until a customer asks for a VAT invoice or finance tries to reconcile daily sales. We would separate payment methods, require customer selection for VAT invoice requests and run matched test sales in each currency. The cost is mainly implementation time and staff training; the alternative is a backlog of receipts that cannot be relied on for VAT evidence.

Take a wholesaler with a US$250,000 monthly turnover that invoices registered customers from Odoo Accounting. Its sales team captures buyer names but leaves TIN and VAT number fields blank because those fields were not required in its old template. The invoice looks complete, yet the buyer’s input-tax record may not auto-populate in TaRMS if FDMS does not show “VALID” with accurate buyer details.

From 1 December 2025, TaRMS-FDMS integration restored the normal 12-month input-tax claim period. By June 2026, domestic input-tax invoices auto-populate in TaRMS only where FDMS shows “VALID” and buyer details are accurate. For a wholesaler, the better choice is to make buyer verification part of customer onboarding, not a task left to the invoice clerk at month-end.

Validate before finance relies on the receipt

ZIMRA compliance is not complete when a receipt prints. It is complete when the underlying FDMS transaction is valid and the data agrees across the sale, fiscal record and accounting entry.

Use this close-of-day control for every outlet:

4.       Reconcile Odoo POS or invoice totals to the fiscal-device or FDMS transaction totals by currency.

5.       Compare USD sales to USD collections and ZiG sales to ZiG collections. Do not net the currencies for this control.

6.       Check a sample of receipts through FDMS validation and confirm the result is “VALID”.

7.       Review buyer details on VAT invoices, especially TIN and VAT numbers for registered buyers.

8.       Investigate cancelled, retried and duplicated fiscal submissions before the accounting period closes.

9.       Mark any reprint as “copy”. Reprinting an original without identifying it as a copy creates avoidable document-control risk.

The person at the counter usually sees only whether paper came out of the printer. The finance controller needs evidence that the fiscal record is valid, that the amount tendered is correct and that the receipt can support the buyer’s VAT position.

When a standard Odoo layout is enough, and when it is not

If a Zimbabwean business is VAT-registered and makes POS sales, do not rely on a standard Odoo invoice layout as its fiscalisation solution. It may be suitable for a commercial quotation, pro forma or internal invoice workflow, but it is not sufficient for ZIMRA FDMS compliance without an approved fiscal integration.

If the business does not make fiscalised POS sales, the precise design depends on its supplies, VAT registration status and ZIMRA obligations. That boundary should be confirmed before implementation because the wrong decision affects process design, device selection and compliance evidence.

For multi-entity groups, configure fiscal controls per legal entity and per Zimbabwean registration. Do not assume that one group template, one VAT setup or one customer master automatically creates an auditable result across entities. The company issuing the receipt must be the company whose fiscal and VAT details appear in FDMS.

Frequently Asked Questions

Can Odoo print a ZIMRA-compliant fiscal receipt by itself?

No. Odoo can produce invoices and POS receipts, but a Zimbabwean fiscal receipt requires an approved fiscal device, virtual fiscal device or FDMS API integration that submits the transaction and returns a valid fiscal result. The final document must be QR-verifiable and show “VALID” in FDMS.

Must USD and ZiG sales use separate Odoo journals?

ZIMRA’s rules focus on accurate transaction currency, tender amount and fiscal reporting. Separate journals and payment methods are the practical control we recommend because they make currency reconciliation and audit testing clearer.

What buyer details are required on a fiscal tax invoice?

Capture the buyer name, address, TIN, contact details and VAT number where applicable. If there is no TIN, place the buyer details elsewhere on the receipt rather than entering a substitute value in the fiscal-device buyer block.

Why does FDMS validation affect input VAT?

As of June 2026, domestic input-tax invoices auto-populate in TaRMS only when FDMS shows “VALID” and the buyer details are accurate. An invoice that looks correct but fails validation can therefore create a tax-credit problem for the buyer.

A ZiG and USD fiscalisation project should finish with tested transactions, FDMS validation evidence and reconciliations that the finance team can repeat. Request a Consultation with Serpa for Odoo ZIMRA fiscalisation and a readiness review of your Odoo receipts, payment flows and FDMS integration.