Bilingual e-invoice acceptance checklist for Saudi Odoo 19 projects

Build one evidence pack for every acceptance scenario

Create an acceptance register with a stable scenario ID, legal entity, sales journal, environment, document type, source transaction, tester, business reviewer and execution time. Attach or link the source data, human-readable output, XML, API request and response references, final status, sharing artefact and defect decision. Redact credentials and unnecessary personal data while preserving the values needed for review.

Record expected results before execution. The reviewer should be able to distinguish a missing prerequisite, invalid test input, configuration defect, rendering defect, provider response and unresolved statutory question. A screenshot of a successful screen without its source transaction and response is not a complete evidence pack.

Use the checklist in both languages with the same scenario IDs. English and Arabic reviewers can then discuss the same document and decision without creating parallel, contradictory registers.

Cover the full document and failure matrix

At minimum, include every standard and simplified invoice scenario used by the organisation and the related credit and debit notes. Separate direct invoices from point-of-sale documents, and distinguish business, government and consumer parties where they affect the scenario.

Add partial and full adjustments, zero-rated and exempt supplies where used, foreign-currency transactions, multiple lines and tax treatments, discounts, long Arabic descriptions, page-overflow samples and corrected or rejected submissions. Include boundary cases from actual operations rather than selecting only the simplest valid invoice.

For each row, state whether clearance or reporting is expected, which Fatoora environment and Odoo journal are involved, what final status must be observed, and who accepts the Arabic output and financial values. If a scenario is not applicable, record the business reason and reviewer instead of leaving an unexplained blank.

Confirm master data and configuration before judging output

Reviewed 5 November 2026. The Odoo 19 Saudi localisation requires accurate company and contact data for onboarding. Verify seller and buyer identifiers, addresses, VAT numbers, SAR currency and scenario-specific fields before treating an API result as meaningful.

Confirm the legal entity and sales journal, Odoo version and edition, installed modules, tax mapping, sequence approach, invoice date and time handling, original-invoice reference logic and environment. Record who supplied the expected VAT treatment. Standard 15% VAT applies only where legally applicable; zero-rated and exempt options are separate reviewed scenarios.

Each production-bound journal needs separate onboarding evidence. The environment register confirms that Sandbox, Simulation or Production is unmistakable in the evidence pack. Simulation invoices are not legally valid, and a non-production result is not relabelled as a production outcome.

Inspect the Arabic human-readable document visually

Human-readable invoices and associated notes must be in Arabic; additional languages are allowed. Review the actual output on screen and as the intended shared file, not only the field values in Odoo. Include the fonts and rendering path that production users will employ.

Check Arabic shaping and letter joining, right-to-left alignment, font embedding or availability, headers and footers, logo placement, page breaks, repeated table headings, line wrapping and totals. Long party names, addresses, product descriptions and adjustment reasons must remain readable without clipping or overlapping.

Verify seller and buyer names, identifiers, addresses, invoice and supply dates, document number, line quantities, unit prices, discounts, taxable amounts, VAT amounts, totals and note reasons. Mixed-direction tokens such as ZATCA, CSID, XML, UBL and product codes should not reorder adjacent numbers or punctuation. Where English is included as an additional language, compare its meaning with the Arabic rather than assuming parity.

Compare structured XML with the transaction and rendered invoice

Phase 2 API submission is XML. Reviewers compare the structured payload with the approved Odoo transaction and the human-readable output. The ZATCA specification hub and detailed guideline are the primary references for current technical rules.

Trace document identifiers, issue and supply dates, seller and buyer parties, tax identifiers, currency, line values, allowances or charges, tax categories and totals. Check that original-invoice references and reasons appear in credit and debit note payloads. Technical XML elements can be English while the customer-facing human-readable information remains Arabic.

Use schema or technical validation where available, then perform a business comparison as well. A structurally valid payload can still contain an incorrect party or amount. Record validation-tool version and output where used, and link any discrepancy to the source field, mapping or configuration responsible.

Keep XML, PDF/A-3, QR and cryptographic-stamp evidence distinct

Odoo 19 can generate PDF/A-3 with embedded UBL 2.1 through Send. That output can support a sharing journey, but it is not the Phase 2 clearance payload. Store the XML submission and the PDF/A-3 sharing file as separate artefacts with the same scenario ID.

QR and cryptographic-stamp behaviour is checked against the applicable phase and document type. Do not apply a visual assumption from a simplified sample to a standard document, or treat the presence of a code as proof of the whole integration journey. The acceptance row names the expected marker or behaviour, the official reference used and the actual observation.

If the PDF/A-3 file is selected for customer delivery, open it with the intended viewer and inspect Arabic rendering, page structure and embedded-file presence using the agreed technical check. Confirm that any later correction creates a controlled new version rather than an ambiguous replacement in the evidence pack.

Execute standard-invoice clearance scenarios

In the usual Phase 2 flow, standard tax invoices, typically B2B or B2G, follow clearance. Document type and scenario control exceptions, so the matrix does not treat B2B as an absolute synonym. Use the applicable ZATCA references and qualified review to establish the expected path.

Capture the source invoice before submission, validation results, submission reference, response, final clearance status, human-readable Arabic invoice and selected sharing output. Compare financial values across all three representations. If the integration exposes warnings or additional status information, retain it with the reviewer interpretation.

Repeat for each entity, journal and materially different scenario. Test a correction after rejection, an adjustment after the original document has been accepted, and an unavailable or unknown response path where safe. The reviewer signs the actual observed outcome rather than the intended design alone.

Execute simplified-invoice reporting scenarios

Simplified tax invoices, typically B2C, are reported within 24 hours in the usual Phase 2 flow. Record the issuance time, reporting process, response and final status evidence for the applicable scenario. Include the point-of-sale or direct-sales origin where relevant.

Verify the simplified document's Arabic output, required party and transaction data, QR or stamp behaviour, line and tax values and customer delivery. Where offline or delayed operation is part of the design, test the queue, recovery and monitoring process against current requirements without assuming that an unreported document has completed its journey.

Test simplified credit and debit notes separately, including original-invoice reference, reason, partial values and final reporting status. The evidence pack shows both the customer-facing adjustment and the integration result, not just a changed total in Odoo.

Test credit and debit notes as linked documents

Odoo 19 supports credit and debit notes with a ZATCA-compliant reason and original-invoice reference. Start each test from an identified original scenario and record its document ID, environment and final status. Avoid testing an adjustment against an ambiguous or unrelated source invoice.

Check the reason in the Arabic output and structured data, original-invoice reference, dates, quantities or amounts, VAT, totals and currency. Include full and partial adjustments and cases with several lines. Where a sequence of adjustments is allowed by the business process, verify the cumulative result and the user's ability to trace each step.

Also test user permissions and accounting review. The person who can create an operational adjustment may not be the person authorised to approve its financial or fiscal submission. The checklist names both actions and retains the final status for the original and adjusted documents.

Prove rejection, timeout and duplicate-prevention handling

Include invalid or incomplete party data, rejected structured content, unavailable service, timeout, unknown status and repeated user action where these can be exercised safely. The aim is to test operational control, not to generate uncontrolled production requests.

For each failure, capture the response, user-visible message, document state, log reference and whether a retry is permitted. Identify who investigates, who corrects master data or configuration, who authorises resubmission and how finance establishes the authoritative final status.

After correction, link the new attempt to the original scenario and compare identifiers to prove that duplicate documents or submissions were not created unintentionally. Redact secrets from logs and screenshots, but retain enough technical context for ZATCA, Odoo or provider support to investigate if needed.

Validate sharing, retention and reviewer sign-off

Test the intended delivery route to the customer or internal reviewer. Confirm that the recipient can open the selected human-readable format, read the Arabic content and relate it to the correct invoice or note. Where both XML and PDF/A-3 are shared, verify that they represent the same document version.

The evidence index names the controlled storage location, retention owner, access group and link to the source transaction. Production evidence is separated from training and simulation artefacts so that non-legal test invoices cannot be mistaken for live documents.

Sign-off includes the technical tester, finance reviewer, Arabic business reviewer and process owner. Each records accepted scope, exceptions and required follow-up. The release authority reviews unresolved high-impact defects before production approval; acceptance of one scenario is not copied onto another journal or entity without evidence.

Carry acceptance into hypercare and change control

During hypercare, sample real operational scenarios using the same checklist. Monitor rejected or unknown statuses, repeated master-data corrections, Arabic rendering complaints, adjustment references and differences between XML and customer-visible output. Link support issues to existing scenario IDs so trends are visible.

Changes to invoice templates, fonts, localisation modules, taxes, journals, credentials, Odoo version or provider configuration trigger an impact assessment and targeted rerun. A later product demonstration does not close a scenario in the approved Odoo 19 baseline.

Public OXP2026 sessions on e-invoicing onboarding and acceptance and evidence and version boundaries are educational implementation material only, not Saudi technical rules, Oakland references or customer endorsements. Official ZATCA sources and the Odoo 19 Saudi localisation remain the product and regulatory baseline; your own evidence pack determines the release decision.