Choose invoicing software by both its ordinary billing workflow and the Smart Invoice route applicable to the business. A good-looking PDF, customer balance or configurable tax field does not establish ZRA integration or certification. Keep the business invoice, its numbering, the tax-system transaction and the debtor record traceable without treating them as interchangeable identifiers.
ZRA’s official solution guide distinguishes desktop/tablet, mobile, online and integrated Certified Invoicing System routes. Its current site also links an API specification updated on 2 October 2026. Use those sources for the applicable technical questions; do not assume a generic accounting package is certified because it can print a tax line. ZRA solutions, updated API specification.
Which invoicing route should the business investigate?
Begin with the business’s actual tax registration and existing accounting system. The ZRA guide describes different eligibility boundaries. Its mobile solution is stated for Turnover Tax taxpayers rather than VAT taxpayers; the desktop/tablet description excludes taxpayers with accounting packages.
The online solution is described for service-industry taxpayers issuing few invoices. The integrated route is described for businesses with accounting packages or ERP systems and involves certification. These are source descriptions, not a determination of the correct route for a particular business.
If the position is unclear, obtain current guidance through ZRA’s stated support route before selecting software. This article does not provide a tax-registration decision, an exhaustive statutory field checklist or a claim that Spout has certified an invoicing system.
How do the documented solution types compare?
| Route | ZRA description | Selection question |
|---|---|---|
| Desktop/tablet | Locally installed application, with stated suitability limits | Does the business fit the current eligibility description? |
| Mobile | Android-based route described for Turnover Tax only | Is the taxpayer registration appropriate for this route? |
| Online | Browser-based route described for qualifying service activity | Does the actual invoice workflow fit? |
| Integrated CIS | Accounting/ERP integration after certification | What certification and current interface evidence exists? |
The comparison preserves the source boundaries. It does not claim that every business can choose freely among all four routes or that a software vendor’s marketing description establishes ZRA acceptance.
Which invoice fields need evidence rather than guesswork?
Ask the proposed system to map its fields to the applicable current interface and transaction type. The updated ZRA specification includes customer TPIN handling, invoice references and tax-total concepts, but the meaning and applicability depend on the endpoint and transaction.
Do not turn a field encountered anywhere in a large API document into a universal mandatory printed-invoice requirement. Establish the relevant section, request or response and business context. Keep the source version with the mapping so an older implementation example does not silently become the current specification.
Also distinguish taxable totals, tax amounts and the commercial amount due. A label alone does not establish the correct calculation or rate for the business. Use the applicable requirements and actual test evidence rather than inventing a default tax percentage. Versioned ZRA technical reference.
Why must numbering and tax references remain separate?
A business may have an internal invoice identifier and additional transaction or device references from its tax-system workflow. Preserve the relationship rather than overwriting one reference with another. The updated specification includes last-invoice concepts, which should be interpreted within their documented process.
For comparison, Odoo documents restrictions on invoice resequencing, including duplicate-producing sequences and locked periods. That is evidence of product behaviour, not proof that an Odoo installation meets ZRA requirements. A numbering control in an accounting package and a certified tax integration answer different questions.
Ask the demonstrator to show an ordinary invoice, a correction and the resulting references. Do not renumber historical records merely to make a new sequence look tidy. Retain the links needed to explain the original document and later adjustment. Odoo invoicing and resequencing.
An original invoice-identity and debtor test
Use controlled sample records to complete this test:
Customer identity: internal customer record and the applicable tax identification evidence.
Commercial document: invoice reference, date, line items and agreed payment terms.
Tax mapping: relevant interface section, source version and mapped request/response fields.
Submission state: proposed, submitted, accepted or unresolved, according to actual evidence.
Reference links: internal invoice, tax-system result and any correction document.
Debtor position: amount billed, credits and payments represented in the chosen accounting workflow.
Exception: failed submission, duplicate attempt or missing reference, with a named investigation owner.
Reconciliation: the evidence explaining why the customer balance and tax records have their observed states.
The test is an original evaluation artefact. It does not certify a product or create a compliant invoice by itself. Fill it with results from the applicable authorised test process.
How should a software demonstration handle failures?
Ask what happens when a submission result is unknown. The system should not casually create a new invoice or repeat an external transaction without checking the existing reference. Record how an operator investigates and resumes the workflow.
Then inspect a debtor record after a partial payment or correction in the test environment. A tax-system acceptance and a customer payment are separate events. Do not mark a customer paid merely because an invoice was accepted elsewhere.
Preserve original documents and the reasons for changes. A dashboard total without its supporting records is weak evidence when a customer or authority asks how the position arose.
What should determine the purchase decision?
Choose a system whose applicable route, documented integration status and demonstrated billing workflow fit the business. Require current certification evidence where relevant rather than assuming it from a generic feature list.
Discuss the software requirements through Spout’s web development service or start an enquiry with the comparison and unresolved mapping questions.
Keep the integration evidence separate from a sample invoice screenshot. Ask the vendor to identify the actual certified system, relevant version and the environment used for its demonstration. If the demonstration uses an older interface document, record that difference and obtain the current mapping before accepting the implementation. Also inspect how a customer statement links payments and credits to the original invoice without erasing its tax-system references. A readable statement and a successful submission are both useful, but neither supplies evidence for the other.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.