Odoo ZATCA e-invoicing in Saudi Arabia

Which Odoo ZATCA e-invoicing duties the platform handles in Saudi Arabia

Odoo's Saudi localization covers ZATCA Phase 1 QR codes through the base module l10n_sa, Phase 2 API integration through l10n_sa_edi, and e-invoicing from Point of Sale through l10n_sa_edi_pos. Authority onboarding, certificates and the outcomes of each submission still depend on the company and its own ZATCA registration, and the software cannot complete those steps on the company's behalf. A Saudi operator therefore needs a clear split between what the platform generates and processes and what the business must obtain, hold and answer for. This section sets out that split so the team can plan the work before any configuration starts.

The platform helps with the invoice-level duties that come from Odoo's sales and accounting documents. The base localization adds the Phase 1 QR code to invoices, and the Saudi localization preconfigures sales, purchase and withholding taxes with standard VAT at 15 percent, which gives the tax setup a working baseline. With l10n_sa_edi installed, the Phase 2 integration path covers the electronic submission flow to the authority. With l10n_sa_edi_pos installed, the same e-invoicing duties extend to sales made at the point of sale. Confirm in Odoo's Saudi Arabia localization documentation which invoice types, document flows and POS configurations each path supports, because an installed module does not show that every invoice type the business issues is covered.

Several duties stay outside the software. The company must register with ZATCA, complete onboarding for each company record in Odoo, obtain and renew certificates and keys, and decide who holds those credentials. It must keep legal entity data such as its VAT registration number and address correct, decide which invoice types it issues in which situations, and respond to rejected or returned submissions. Record retention, the authority's ongoing reporting expectations and advice on how the rules apply to specific transactions also sit with the business and its advisers. If the company runs Odoo on its own infrastructure, check the edition question early. Odoo's pricing page places on-premise hosting with the Custom plan, and on-premise use of the upgrade service requires an Enterprise subscription, so confirm which localization modules each edition and hosting option supports before the design is fixed.

DeployOpen's part is the preparation work. We plan and set up the configuration for each company record, review the tax mapping against the 15 percent standard VAT and the withholding setup, and prepare a test database by duplicating production with neutralization so that test submissions do not touch live data. We also assemble the configuration records and test evidence the company will need when its auditors or the authority ask how the system was set up. DeployOpen prepares configuration and evidence. It does not issue certifications, attestations or audit reports, and it does not decide whether a given invoice meets the legal requirements. Those judgments belong to the company, its advisers, and the independent auditors or authorities involved.

Three decisions should be made before the build starts. First, who owns the ZATCA relationship and the certificate lifecycle on the company side, and who approves changes to tax or invoice settings. Second, which Odoo version the company will run. Standard support for Odoo 19.0 runs until September 2028 and for 18.0 until September 2027, while 17.0 standard support ended in September 2026. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Upgrades can affect localization behavior, so the test database should rerun the invoice and POS cases before production moves. Third, the POS sales that must be covered. Agree a checklist of test invoices for each duty, and keep the results with the configuration records for go-live.

How each ZATCA requirement maps to Odoo modules and settings

This table compares each ZATCA-related requirement area with the Odoo module that addresses it, the configuration it needs, and the points you must still confirm. Read each row as a checklist: the capability column says what the module provides, and the final column lists what you should verify with ZATCA or in your own environment before go-live. The main takeaway is that the Saudi localization covers the module-level features, but the connection to ZATCA, the company setup and the tax treatment of your transactions remain your responsibility to confirm.

Requirement area	Odoo capability	Configuration needed	Confirm with ZATCA or your environment
Phase 1 QR code on invoices	Base Saudi localization (l10n_sa) provides QR code support	Install l10n_sa on the database and set the company's Saudi fiscal data	Confirm the QR content and layout your invoice templates produce match what you must present to customers
Phase 2 API integration for e-invoicing	l10n_sa_edi enables ZATCA Phase 2 API integration	Install l10n_sa_edi, then register each company's credentials and onboarding details in Odoo	Confirm which onboarding stage and API environment apply to each legal entity and which credentials your team holds
E-invoicing through Point of Sale	l10n_sa_edi_pos enables e-invoicing from the Point of Sale app	Install l10n_sa_edi_pos alongside l10n_sa_edi, then test POS sales, returns and receipts on a test database	Confirm with your ZATCA advisor how simplified invoices from POS should be issued and reported for your business
Sales taxes	Saudi localization preconfigures sales taxes with standard VAT at 15 percent	Review the preconfigured sales tax records and map them to products and customers that need different treatment	Confirm the VAT rate and tax category for each product or service with your tax adviser, including any exempt or zero-rated items
Purchase taxes	Saudi localization preconfigures purchase taxes with standard VAT at 15 percent	Review purchase tax records and assign them to vendor bills and expense accounts used by your team	Confirm input VAT recovery treatment and the accounts your accountants expect for each purchase type
Withholding taxes	Saudi localization preconfigures withholding taxes	Check the withholding tax records, the accounts they post to and which vendors they apply to	Confirm which payments are subject to withholding and the rates that apply with your tax adviser
Per-company setup	Localization settings apply per company in a multi-company database	Set fiscal country, currency, address, tax identifiers and journals for each company before enabling e-invoicing	Confirm each legal entity's registration details and that invoice numbering and journals are separate per entity
Edition and hosting	The Enterprise edition is needed for the Phase 2 modules, and multi-company use depends on the plan	Confirm your Odoo edition, plan and hosting type support the modules and multi-company setup you need	Confirm the license, subscription and hosting options with Odoo before planning the build
Version and upgrade path	Localization modules follow Odoo's supported versions and upgrade cycle	Pin the target Odoo version, test the upgraded database and re-check module behavior before each major upgrade	Confirm the Odoo version and its support end date, and any ZATCA changes that apply to your version

How Phase 1 QR codes, Phase 2 integration and POS invoices differ in Odoo

The l10n_sa module is the Saudi base localization. It adds QR code support to invoices in the standard Odoo localization and preconfigures sales, purchase and withholding taxes with standard VAT at 15 percent. Phase 1 works inside Odoo, so the module by itself does not send invoices to a government endpoint.

Data leaving Odoo: the invoice as printed or emailed, with the QR code embedded. Confirm the QR code fields against the Phase 1 requirements with your ZATCA advisor.
Before enabling: a company record with Saudi Arabia set as the country, a VAT registration number entered in the format the localization expects, and tax mappings checked against your own rate schedule.
Edition and plan: confirm with Odoo that l10n_sa is available in the edition and hosting type you plan to run.
Hosting limit: Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, so a self-hosted team must confirm its plan before design starts.
Ongoing work: check printed invoice layouts after each Odoo upgrade, because the QR output sits on the document template.

Confirm the QR content, printed layout and tax mappings with your advisor before the first live invoice.

Onboarding each Saudi company and branch in one Odoo database

Each legal entity or branch that shares an Odoo database needs its own complete, correct company record before any e-invoice is issued, because every ZATCA invoice carries the identity of the seller that issued it. Odoo's pricing page includes multi-company only in the Custom plan, and only Custom can be hosted on Odoo.sh or on-premise. Confirm the plan and hosting model against the entity structure before the design is fixed, since moving a shared database to a different plan later is a change to the commercial agreement as well as to the system.

Company-level settings are where most onboarding errors appear. For each company, check the legal name, VAT registration number, registered address, currency, and fiscal position. Then review the tax configuration. The Saudi localization preconfigures sales, purchase and withholding taxes with standard VAT at 15 percent, but each entity must confirm that its default taxes, tax accounts and fiscal position are assigned to that company and not inherited from another. Set up separate journals and invoice sequences for standard invoices, simplified invoices and credit notes, so numbering is continuous and independent within each entity and each branch.

ZATCA onboarding credentials are tied to a taxpayer and its devices, so the team must confirm with ZATCA and with Odoo's Saudi localization documentation how credentials are requested, assigned and stored for each company in a shared database. Ask whether each entity or branch needs its own registration, which credentials Odoo records against each company, and who holds the certificates and the renewal schedule. Document the answer in the design before configuration starts, because a credential attached to the wrong company will not show up as a visible error until invoices are rejected or carry the wrong seller details.

Test each company separately before go-live, not only the parent company. For every entity, issue sample standard invoices, simplified invoices, credit notes and, where point of sale is used, simplified invoices from each branch's POS session. Check the QR code content, the XML output where Phase 2 applies, the tax totals, the sequence numbers and the journal the document posts to. Run these tests on a duplicated test database with neutralization, so production data and live submissions are not affected. Record the results per company so the sign-off covers every entity that will issue invoices from day one.

Configuring Odoo for ZATCA e-invoicing in a sensible order

This sequence moves a Saudi company from platform decisions to a documented, signed-off ZATCA setup in Odoo. Each step closes with a named artifact, so every legal entity can be checked before invoices go live.

Confirm plan, edition and hosting
Before any module is installed, confirm the Odoo edition, the subscription plan and the hosting model in writing. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that multi-company and custom modules are included only in Custom, so these points shape the rest of the build. Confirm with Odoo which features your chosen edition and plan include for Saudi e-invoicing. Owner: the client's IT lead with the implementation partner. Output: a signed environment record listing edition, plan, hosting, Odoo version and the test and production database names.
Install Saudi localization and e-invoicing modules
Install the Saudi base localization, l10n_sa, which provides Phase 1 QR code support. Then add l10n_sa_edi for the Phase 2 API integration and l10n_sa_edi_pos if point of sale invoices must be reported through the same route. Install on the test database first, then record the exact module versions and dependencies. Confirm in the Odoo Saudi Arabia localization documentation for your version which modules need an Enterprise subscription. Output: an installed-module list for each database, with versions, reviewed and kept with the environment record.
Verify company identity and tax data
Each legal entity that issues invoices needs correct identity data before the first invoice is generated. Check the legal name, commercial registration details, VAT registration number, address and currency for every company record in the database, including any branches that issue invoices. In a multi-company setup, confirm that each company holds its own data and that no invoice can be issued under the wrong entity. The implementation team and the client's finance lead check the records against the official documents. Output: a company data sheet per legal entity, signed by the finance lead.
Confirm VAT and withholding tax setup
The Saudi localization preconfigures sales, purchase and withholding taxes, with standard VAT at 15 percent, according to Odoo's localization documentation. Do not assume the preconfigured taxes match your business. Review each tax, its rate, its account mapping and its use on products and services, and confirm withholding tax applies to the transactions where your finance team expects it. Test a sample of sales and purchase documents and check the totals. Output: a tax mapping sheet listing each tax, its rate, its accounts and the transactions it covers, approved by the finance lead and tax adviser.
Configure and test Phase 1 QR output
Configure the QR code output provided by the base localization on the invoice template used for standard invoices. Create a set of sample invoices that covers the common cases: standard sales, credit and debit notes, discounts, multiple tax lines and foreign currency where relevant. Decode the QR payload from each sample and compare its fields with the invoice values. Keep the printed and PDF versions aligned. Test on the test database only until the results match. Output: a sample invoice test pack with decoded QR results and a pass or fail note for each case.
Configure Phase 2 integration in test
Configure the Phase 2 integration provided by l10n_sa_edi against ZATCA's test environment, using the credentials and onboarding steps that apply to the company's registration. Keep the test credentials and the production credentials in separate places and confirm which database each one belongs to. Submit sample invoices, including credit and debit notes, and record each response, including rejections and the reasons given. Repeat until the expected results are consistent. Confirm the current onboarding requirements directly with ZATCA, since they can change. Output: a test submission log with request, response and resolution for each invoice.
Enable POS and test simplified invoices
If point of sale sales must be e-invoiced, enable the POS integration through l10n_sa_edi_pos and configure each point of sale terminal, journal and receipt template. Run a set of simplified invoice tests from POS covering cash and card sales, returns, discounts and mixed tax rates. Check that each simplified invoice carries the required QR output and reaches the integration path set up in the previous step. Test in parallel with the sales invoice tests, because POS and back office often share tax and journal settings. Output: a POS test invoice set with results for each terminal.
Document configuration and obtain sign-off
Write down the final configuration for each company: modules, versions, tax mapping, identity data, QR and integration settings, POS terminals and the test results that support each decision. Record who approved each element and when. Store the record with the environment record from the first step, and keep a copy of the test packs. Changes after sign-off should go through a documented change process, and a test copy of the production database can be created for trials. Output: a per-company configuration record and a signed sign-off form, kept for audit.

What evidence Odoo produces for an e-invoicing review

Each card below is either a record Odoo generates during ZATCA e-invoicing or a record your team must keep around it. Together they let a reviewer trace an invoice from its QR output through submission to the configuration and test environment that produced it. DeployOpen prepares this evidence but does not issue any attestation, and your own policy and advisers should set how long each item is kept.

Invoice records with QR output

Each issued invoice is a record in Odoo's accounting, and for Phase 1 the base l10n_sa localization writes the QR code onto it. Keep the invoice number, issue date, seller and buyer tax data, VAT amounts and the generated QR value together as the reviewer's starting point. Check that a sample of invoices reproduces the same QR output after a restore from backup. Confirm with your advisers how long issued invoices and their PDF copies must be kept.

Phase 2 submission status and responses

When l10n_sa_edi is installed, each invoice carries submission status and the responses returned by the ZATCA integration. Record which environment each submission went to, the onboarding state of the company, and every rejected or warning response with the action your team took. Confirm which fields and attachments your Odoo version stores, and whether raw API responses are kept in the database, in logs or in both, because reviewers often ask for the original response.

Tax configuration exports

The Saudi localization preconfigures sales, purchase and withholding taxes with standard VAT at 15 percent, so a reviewer will want to see what your company actually uses. Export tax definitions, fiscal positions, rounding settings and journal mappings at each release and before each change, and store every export with the l10n_sa version that was installed when it was taken. Compare an export from the test copy with production before you rely on it.

Change records for localization and tax settings

Every change to tax rates, fiscal positions, journals, number sequences or the Saudi localization modules needs a record of who made it, when, why and who approved it. Tracked fields and chatter capture some field-level edits, but a change ticket that links the reason, the test evidence and the approval is what a reviewer can follow. Keep custom module code in Git with reviewed commits, and keep infrastructure changes in the same change system.

Database test copies used for validation

Validation runs on a duplicated database, and Odoo documents duplication with neutralization for test copies. Keep a record of each copy: its source, the date it was taken, the Odoo version, the installed modules, and which integration endpoints and credentials were disabled. Store the test scripts, results and sign-off beside it, so reviewers can see what was tested and what was not. Confirm with your policy how long these copies and their results are retained.

Keeping ZATCA configuration working through Odoo upgrades and support windows

Plan each Odoo upgrade as a change to your ZATCA setup, because the support calendar sets the deadlines for both. Odoo 19.0 receives standard support until September 2028, and Odoo 18.0 until September 2027. Odoo 17.0 standard support ended in September 2026. Security patches are provided only during standard support, so a company still running 17.0 has no vendor security fixes for its localization or its integration code. Ask which version your database runs today, when its standard support ends, and which upgrade path your partner proposes before you commit to a go-live date for Phase 2.

Your hosting type decides how upgrades reach you. Odoo Online and Odoo.sh require major version upgrades every two years, and Odoo SaaS versions arrive every two to three months. On-premise deployments can use the upgrade service only with an Enterprise subscription, and the Community edition has no access to it. Confirm your edition and subscription status early, because a Community database would need a different upgrade method and a separate budget line. Ask the partner to separate the one-time upgrade effort from the recurring subscription and support fees in the quote.

Test every upgrade in the upgraded test database before it touches production. Odoo's upgrade service creates this copy, so run the test on it, not on a manual duplicate. Check the base l10n_sa localization, the Phase 2 connection through l10n_sa_edi, and the Point of Sale path through l10n_sa_edi_pos. Confirm that QR codes still render on Phase 1 invoices, that standard VAT at 15 percent and the sales, purchase and withholding tax mappings still match your records, and that a simplified invoice from POS still generates correctly. Keep the test copy neutralized and verify that it cannot submit documents to live ZATCA endpoints.

Retest the localization after every upgrade, including minor changes that do not look tax related. Localization modules change with the core, and a change to tax, journal or sequence logic can break invoice numbering or the data sent to ZATCA. Assign one named owner for the upgrade calendar, a sign-off step for the tax and e-invoicing tests, and a rollback plan that covers the production database. Ask your partner to state in writing which localization tests run after each upgrade, who performs them, and what evidence they leave for your compliance records.

What Odoo does not cover for your ZATCA program

Odoo's Saudi localization handles invoice mechanics inside the database. The gaps below sit with people, authority processes and systems around it. Each card names who owns the item and what to confirm with ZATCA or an accredited adviser before go-live.

Registration and onboarding decisions

Deciding which legal entities, branches and taxpayer records go through ZATCA registration, and in what order, is a decision the company makes. Odoo's Saudi localization configures tax and QR fields, but it does not decide how many organizational units need separate onboarding or which records map to which registration. Owner: the company's tax and finance leads. Confirm the registration steps, required company data and sequence with ZATCA directly or with an accredited adviser before enabling Phase 2 in production.

Certificates and device credentials

ZATCA issues the certificates and credentials that the Phase 2 integration uses to sign and submit invoices. Odoo can store and use them once entered, but it cannot request, renew or revoke them on the company's behalf. Owner: the finance systems owner, with access controls set by IT security. Confirm the issuance, renewal and revocation process, who may hold credentials, and where private keys will be stored before go-live.

Monitoring ZATCA rule changes

ZATCA can change technical requirements, invoice formats and onboarding rules over time. A localization module reflects the code version the company runs, so a rule change can arrive before or after the matching Odoo update. Owner: the compliance lead, with the partner planning upgrades. Assign a named person to review ZATCA publications on a fixed schedule, and confirm with the authority which changes apply to your Odoo version.

Accuracy of master data

Invoices carry seller and buyer identifiers, addresses, tax categories and product or service classifications that staff enter or import. A configured system can flag missing fields, but it cannot confirm that a customer's tax number or a product's tax treatment is correct. Owner: the finance data owner, with sales and procurement responsible for their own records. Set entry rules, schedule periodic reviews of customer and product records, and check imports before go-live.

Audit and certification

An audit or certification is an assessment by an independent body, and the software does not provide one. DeployOpen prepares systems, controls and evidence for assessment, but does not issue audit reports, attestations or certifications. Owner: the company's compliance function, with the assessor it engages. Confirm with ZATCA which evidence it expects, and ask any adviser to map the implementation to that list before scheduling an assessment.

Integrations beyond Odoo modules

Invoice data often flows from Odoo into a separate ERP, tax engine, data warehouse or reporting tool. Each connection needs its own field mapping, error handling and reconciliation, and Odoo's modules do not cover systems outside its database. Owner: the integration team that runs the other systems. Confirm which system is the source of record for each invoice field, how rejected submissions reach users, and who approves changes to mappings.

Questions buyers ask about ZATCA e-invoicing with Odoo

What drives the cost of Odoo ZATCA e-invoicing work?

The main cost drivers are the Odoo edition and plan, the number of companies that must onboard, whether point of sale issues simplified invoices, how much integration testing the Phase 2 link needs, and the condition of your existing data. DeployOpen does not publish prices. We quote from a written scope that lists each company, each POS, each integration test and each data cleanup task, so you can compare it with your own team's estimate.

Costs fall into two groups. One-time costs cover configuration, testing, onboarding and documentation. Recurring costs come from your Odoo subscription, which depends on plan and user count, and from any support retainer you choose. Odoo's pricing page lists per-user monthly prices for each plan, so check those against your headcount. Ask for a quote that separates these items.

How long does ZATCA configuration take in Odoo?

No fixed duration applies to every company, so the timeline comes from the written scope. It depends on how many companies onboard, how many point of sale terminals issue simplified invoices, how much Phase 2 integration testing is required, and how clean your master data is for customers, products and taxes. Phase 1 QR code setup through the base Saudi localization is usually a smaller task than a Phase 2 API integration with full testing, because the integration adds connection, certificate and validation work.

The ZATCA onboarding steps your organization completes with the tax authority also run on their own schedule. Ask for a timeline in writing after scoping, and ask which milestones depend on your onboarding status rather than on the build.

What do our finance and IT staff need to provide?

Finance staff provide the tax setup and sign-off, including the VAT treatment of each product and service, the withholding tax rules that apply to your suppliers, and the chart of accounts that invoices post to. They also confirm the company legal data that appears on invoices, approve test invoices and own the reconciliation after go-live.

IT staff provide access to the Odoo environment, the hosting account or data center where the database runs, the test copy of the database, network paths to the ZATCA endpoints, and a named owner for certificates and secrets. Agree these responsibilities in the scope so that each handover has an owner and a date.

Can our internal team implement ZATCA e-invoicing on Odoo alone?

Yes, an internal team can do it if it has Odoo functional knowledge, someone who understands Saudi VAT and invoice content requirements, and developers who can work with Odoo modules and integration code. The hard parts are usually the Phase 2 integration testing, the point of sale setup and the handling of existing data, which need time that competes with normal operations.

Ask your team to test the parts it has not done before, such as certificate handling and rejected-invoice flows. If the internal team lacks any of these skills, use a partner for those parts only. Compare your own effort estimate with the written scope from a partner before you decide.

Do we need Phase 1 QR codes before Phase 2 API integration?

The Saudi base localization, l10n_sa, provides Phase 1 QR code support. The l10n_sa_edi module enables the Phase 2 API integration for e-invoicing, and l10n_sa_edi_pos extends e-invoicing to Point of Sale. Phase 2 is built on the same invoice data as Phase 1, so the base localization is the starting point for both.

Which phase applies to each company depends on the ZATCA rules and the onboarding status of that company. Confirm the current requirements with your tax advisor and the ZATCA guidance before you set the plan, and record which phase each company must support on which date.

Which Odoo plan and hosting type does multi-company ZATCA need?

Only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company support. If you run several Saudi companies in one Odoo database, you need the Custom plan. On-premise use also requires an Enterprise subscription, which is activated with the subscription code.

The Enterprise source code is not publicly available, so the Community edition is not a like-for-like option for every requirement. Odoo's documentation for the Saudi localization does not settle in this page whether every ZATCA module is available in Community, so confirm the module list for your edition with Odoo before you commit to a design.

How do Odoo's support windows affect a ZATCA project?

Odoo standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Odoo 19.0 was released in September 2025 with standard support until September 2028. Odoo 18.0 is supported until September 2027. Odoo 17.0 standard support ended in September 2026, so a new ZATCA build should not start on it.

Security patches are provided only during standard support, and extended support is limited to Odoo.sh for select versions and on-premise. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Plan the upgrade into the project budget and test the upgraded test database before production.

How should we test simplified invoices from point of sale?

Test point of sale invoices in a copy of the production database that has been duplicated and neutralized, so no live customer messages or external submissions leave the test environment. Use the l10n_sa_edi_pos path, and cover each POS terminal, each company and each payment method your shops use. Check that standard VAT at 15 percent, which the Saudi localization preconfigures, is applied correctly to sales, refunds and any discount.

Also test the withholding tax cases your suppliers trigger and the rejected-invoice flow. Confirm the exact test cases and the testing environment that ZATCA expects for onboarding with the authority's documentation and your tax advisor before you sign off.

How DeployOpen scopes and delivers ZATCA configuration and evidence

DeployOpen plans, configures, tests and documents Odoo ZATCA e-invoicing for Saudi companies inside the client's own infrastructure, starting from a written scope that names each company, invoice type and integration point. Engagements are fixed-scope, so the deliverables, the evidence and the acceptance checks are agreed before build work begins.

How we scope

The written scope lists each Saudi legal entity, its VAT registration data and the Odoo database or company it lives in.
We confirm which ZATCA phase applies to each entity and whether the l10n_sa_edi and l10n_sa_edi_pos modules are in scope.
Scope records simplified and standard invoice flows, POS sales, VAT at 15 percent and any withholding tax treatment to be configured.

How we build

We install and configure the Saudi localization per company, then set sales, purchase and withholding tax mappings against your chart of accounts.
Onboarding steps for each company are run in a non-production copy first, so device registration and certificate handling can be tested safely.
Test invoices cover standard, simplified and credit or debit note cases, with QR code output checked against the agreed acceptance list.

How we hand over

Handover includes a configuration record per company, covering tax settings, journals, POS links and integration endpoints.
Operating runbooks describe onboarding, certificate renewal, rejected-invoice handling and the steps to reconcile ZATCA responses with Odoo records.
Evidence packs hold test results, change records and configuration exports, prepared for your internal and external reviewers.

How we support

Ongoing support, upgrades and testing after go-live are available as a retainer, scoped in writing.
Odoo version changes are planned against the documented support windows, with the upgraded test database tested before any production move.
Confirm with your team and the Odoo documentation which Odoo edition, hosting type and module versions your ZATCA design depends on.