Your invoice has a tidy PDF and a clear QR code. Has ZATCA accepted it? That is where a useful Odoo integration test starts. Finance needs to see each invoice’s status, understand a rejection and know who will resolve it, rather than hunt through messages at the start of the day. Odoo records the Authority’s response in the invoice record and keeps the XML alongside it. That record is one part of readiness testing, together with correct data, journal onboarding and the invoice types your business actually issues. At ToDoOps we connect those details to setup and training. See our approach to Odoo implementation.

How does finance track Odoo invoice status with ZATCA?

A hypothetical scene: the finance officer opens the invoice log at the start of the day. Most of yesterday’s invoices were accepted, two carry a warning, and one was rejected. She opens the invoice record, reads the response and the reason for rejection, and passes the case to the colleague who owns follow-up. Once the data is corrected, the invoice is resent with Retry. She does not hunt through sales messages or ask who sent what.

What is the difference between clearing a standard invoice and reporting a simplified one?

Under ZATCA’s May 2023 resolution (item Second, 3a and 3b, resolution reference), standard tax invoices and their notes go through Clearance before being given to the customer. Simplified invoices and their notes are submitted by Reporting within 24 hours of issuance. That window applies only to simplified invoices and runs from issuance. Do not judge the type by a common label such as “business” or “consumer” invoice; use the official invoice type in your documents.

Invoice type What should we verify?
Standard tax invoices and notes Clearance before provision to the customer, with the response and XML checked.
Simplified invoices and notes Reporting within 24 hours of issuance, with each invoice’s response checked.

A message that travels successfully over the network is not an accepted invoice. The technical guide (technical guide reference, sections 4.3.1 and 4.3.2) distinguishes three outcomes: acceptance, acceptance with a warning, and rejection. That guide dates from June 2022, so read it together with the later resolution above. Your company’s mandatory enrolment date is set by the Authority, so confirm it with them directly.

How does Odoo 19 tie the invoice to its record and data?

According to Odoo’s 19.0 Saudi Arabia documentation (Odoo reference), the l10n_sa_edi module handles the Phase 2 integration, and l10n_sa_edi_pos handles simplified invoices issued from point of sale. For the wider module set, see Odoo apps.

On submission, the invoice’s chatter shows the Authority’s response and the XML is saved with the invoice, leaving a trail you can return to. Installing the app alone does not complete the picture. Setup covers:

  • Correct company data: name, address, VAT number, and registration ID.
  • Onboarding each sales journal separately. If each branch or point of sale has its own journal, one may be working with the Authority while another is not ready, so invoices in the same company can meet different fates.
  • An OTP supplied by the company’s authorised person through the Fatoora portal during onboarding.

You can see how sales and inventory connect in the ToDoOps simulation. It is a sales-and-inventory simulation with hypothetical data, not a ZATCA test.

How do we test safely before production?

Odoo’s documentation separates three environments: Sandbox for ready-made testing, Simulation (Pre-Production) for testing your company’s own setup, and Production. We suggest the following, which is our own editorial approach and not an official ZATCA checklist:

  1. Test in the test environment with the invoice types you actually use, including deliberately incomplete cases.
  2. Train users to read the response, fix the cause of a rejection, and retry.
  3. Move to Production only with the authorised person’s permission.

Two points to know before moving: once an invoice is sent in Production, the integration cannot return to Sandbox or Simulation, and an invoice accepted in Production is not reset to draft as a fix. Follow the appropriate regulatory procedure instead.

What do we do with the results of 40 test invoices?

A hypothetical example: 40 simplified test invoices were created, 38 were accepted (2 of them with a warning), and 2 were rejected.

Status and count Suggested follow-up
Accepted without warning: 36 Review a sample and check that the response and XML are saved.
Accepted with warning: 2 Read the warning and identify any data or setup correction.
Rejected: 2 Fix the cause, retry and verify the result.
Total: 40 38 accepted, including 2 with warnings; 2 rejected.

Naming an owner for each case is a necessary step, but it is not enough on its own to start production. In this example, the team reviews the warnings, resolves the rejected cases and checks the responses again. Those results inform the go-live decision alongside the remaining project tests and coverage of the actual invoice types and journals. The authorised person records the decision in writing.

Which acceptance questions come before the go-live decision?

These are practical questions of our own making:

  • Is the company data correct? It goes into every invoice sent.

  • Have we tested every invoice type we use? The clearance path differs from the reporting path.

  • What do we do on a warning or rejection? The team writes the procedure down instead of improvising each time.

  • Is the corrective document understood where needed? So the accountant knows when to use it.

  • Who owns follow-up? A named person, not a department.

  • Can we show the XML and the response? They are the invoice’s trail when questions arise.

  • Were users trained on the same test?

  • Is the go-live decision written down, and who approved it?

What does ToDoOps handle in an integration project?

We start by analysing your company’s scope: how many branches and sales journals you have, which invoice types you issue, and who follows up each path. Then we configure the setup, run the testing, and train your team to read the response, fix a rejection, and retry. The steps and their order depend on your project.

The benefit reaches both sides: finance works from clear cases instead of searching through messages, and the owner can see how far readiness has come and who owns each item before approving the start. For an initial Odoo implementation budget, use the ToDoOps calculators. Your project’s quotation items are defined after the scope review.

Common questions

Is installing the integration module enough to start e-invoicing?

No. You need correct company data, each sales journal onboarded, the invoice types you actually use tested, and a go-live decision.

Does a successful submission mean the invoice was accepted?

No. The outcome is acceptance, acceptance with a warning, or rejection, and you read it from the response in the invoice record.

Can I reset an invoice accepted in Production to draft to fix it?

No. Follow the appropriate regulatory procedure for your case, with your specialist.

Are all my invoices cleared before they reach the customer?

Only standard tax invoices and their notes. Simplified invoices and their notes are reported within 24 hours of issuance.

Define your scope before the first live invoice

Not every company uses the same invoice types or the same journals. Start by identifying the invoice types your company actually issues, the sales journals you work with, and who follows up each case. Then choose a test sample that covers that scope: every type you use, every journal, and both a clean case and a deliberately incomplete one.

If you want to identify the gaps and the setup steps needed before go-live, contact ToDoOps and we will review the scope with you and organise setup, testing, and training. For a first cost estimate try the calculators, and to see the rest of what we offer visit the homepage.

References

  • ZATCA — Resolution on E-Invoicing Controls and Implementation Specifications, May 2023, item Second 3a and 3b (printed page 3): official text and the Authority page.

  • ZATCA — E-Invoicing Detailed Technical Guidelines, Version 1, June 2022, sections 4.3.1 (p. 49) and 4.3.2 (p. 50): guidelines.

  • Odoo — 19.0 documentation, Saudi Arabia localisation section: the l10n_sa_edi and l10n_sa_edi_pos modules, the Sandbox, Simulation, and Production environments, sales journal onboarding, the invoice record, XML, and retry. Reviewed: 28 October 2026.