Implementation & rollout at scale
Scoping, configuration, data migration and go-live, department by department, across a large user base and several levels of approval.
Odoo Riyadh · ERP for Saudi organisations
An Odoo that invoices in Arabic.And records who approved what.
Azinove is an Odoo Partner based in Strasbourg and working across Europe and the Gulf. We implement Odoo for organisations in Riyadh and elsewhere in Saudi Arabia: documents authored in Arabic, invoicing configured for the e-invoicing regime that applies to the entity, approval and access rules an internal audit function can follow, and hosting placed where policy requires it.
Odoo Partner · Arabic-first documents · E-invoicing setup
See our workTalk to the engineers who would do the work
Tell us what you run today and what is not working. You get a considered answer, not a sales sequence.
When this service is useful
When the invoice and the approval decide the timetable.
In Saudi Arabia the trigger for an ERP project is rarely a feature list. It is an invoice that has to leave in a defined structure, in Arabic, and an approval that has to be provable afterwards.
- 01
Invoicing requirements are what forced the question
The current system does not produce invoices in the structure expected of them and does not exchange them with the authority’s platform, so finance compensates by hand every month.
- 02
Official documents have to go out in Arabic
Product names, account labels and payment terms exist only in English, and the print templates were never designed to run right to left, so invoices are corrected manually before they are sent.
- 03
Approvals happen outside the system
Purchase requests and payments are approved by email, messaging or paper signature, and nobody can reconstruct who approved what, and when, for internal audit.
- 04
IT and procurement review before anything is signed
IT and procurement ask where the system runs, where backups are kept, who holds access and what support covers — and expect those answers in writing before a supplier is registered.
How we frame the problem
The invoice, the approval chain and the audit trail are one design.
All three rest on the same data. Treating them as three consecutive projects is exactly what makes the correction expensive later.
The problem
E-invoicing gets treated as a printing question and approvals are postponed until after go-live, so the system ends up built on data that is sufficient for neither.
Our intervention
We design the document first — its fields, its stored Arabic values, its numbering and its structured output — then the approval matrix and the access rules, and only then configure and test with the organisation’s own documents.
The intended result
Invoices that leave in the language and structure expected of them, each with an approval history internal audit can follow from the request through to the accounting entry.
Guardrails
What we state precisely on a Saudi engagement.
Invoicing and authority are the two subjects where a vague answer causes the most damage later.
- 01
We configure Odoo for the invoicing and tax requirements that apply to your entity and connect it to the e-invoicing platform using your entity’s own registration. Which requirements apply to you, from what point and in what form, is confirmed with your tax adviser or auditor — we implement, we do not advise on tax.
- 02
Arabic output is not a single setting: interface language, stored field values, print layouts and third-party modules each behave differently, and we assess them before committing to a scope.
- 03
We implement the approval matrix your management signs off in writing. The system enforces it; it does not decide it, and changing it is a management decision rather than a configuration one.
- 04
Our engineering team is in Europe and we claim no office or staff inside the Kingdom. Hosting region, backup location, retention and who holds administrative access are written into the engagement rather than implied.
Talk to the engineers who would do the work
Tell us what you run today and what is not working. You get a considered answer, not a sales sequence.
Capabilities
What we do with Odoo for a Saudi organisation.
The same four areas we cover everywhere, shaped around what a Riyadh organisation actually has to prove.
Arabic-first documents & records
Interface languages, field values stored in Arabic, right-to-left print layouts and document numbering sequences.
Custom modules & integration
Bespoke modules in Python and OWL, and API connections to the e-invoicing platform and to the systems already in use.
Hosting, support & compliance configuration
Hosting in the Kingdom, in Europe or in a cloud account you own, upgrades, support, and Odoo configured for the invoicing and tax rules that apply to your entity.
Possible deliverables
What a Saudi rollout actually produces.
The proposal states which of these are in scope and which department or entity each one covers.
- Approval matrix and access model: roles, delegation levels, segregation of duties, period locks
- Invoice design: fields, stored Arabic values, numbering sequences and structured output
- Arabic and English print layouts for invoices, purchase orders and statements
- E-invoicing integration configured and exercised in a test environment, within the agreed scope
- Migration plan, validated opening balances and reconciled master data: vendors, items, cost centres
- Hosting, backup, retention and access documentation, plus Arabic training material and an operating runbook
Example scopes
Three ways a Saudi engagement usually starts.
Example scopes rather than fixed packages. The number of approval levels and the state of the invoice data change the work more than the industry does.
First Odoo for a Riyadh organisation
Configure the entity end to end: Arabic documents, an approval matrix, and invoicing set up for the regime confirmed for that entity.
- Implementation
- Arabic-first
- E-invoicing
Invoicing and document rework on an existing Odoo
Bring an installation already in production up to the invoice structure and Arabic output it needs, and connect it to the e-invoicing platform.
- E-invoicing
- Documents
- Existing system
A governance layer for a large user base
Approval routes, roles, segregation of duties, record history and reporting across departments and cost centres.
- Approvals
- Access control
- Internal audit
How the engagement runs
How a Riyadh rollout runs.
Most of the work is remote. What sets the pace is the number of functions that have to review each decision.
- 01
Frame
Entities, documents, approval levels, access rules and any hosting constraint are settled with finance, IT and internal audit in the room.
- 02
Configure & build
Documents, approval matrix and any custom module are built on a test database with the organisation’s own data.
- 03
Validate
Finance, internal audit and IT check documents, approval traces and access rights, and invoice exchanges are exercised in a test environment.
- 04
Go live & support
Cutover happens in an agreed window, department by department, followed by support with agreed hours and days.
No commitment · Clear scope · Arabic or English
Frequently asked questions
Questions from Saudi finance and IT leadership.
What decides an ERP in the Kingdom is usually the document, the approval and the location of the data.
Invoices that leave in the language and structure expected of them, each with an approval history internal audit can follow from the request through to the accounting entry.
01Can Odoo produce invoices that meet Saudi e-invoicing requirements?
Odoo can be configured to issue invoices in the structure the regime expects and to exchange them with the ZATCA e-invoicing platform (Fatoora): document fields, stored Arabic values, numbering sequences, structured output and the integration itself. What a website cannot tell you is which requirements apply to your entity, or from what point — that depends on your entity’s own situation and is confirmed with your tax adviser or auditor. We build against what they confirm, and adjust it under an agreed support scope when the rules move.
02Our documents have to be in Arabic. What does that mean technically?
Three separate things, and only the first is a setting. The interface language is chosen per user and switches the screen right to left. The stored field values — product names, unit labels, account names, payment terms — are translated record by record and have to be entered by someone who knows the business; an empty Arabic value prints as an English one. And the print layout has to be authored right to left, with fonts that render Arabic correctly in the PDF, alignment that holds for numbers and totals, and room for the additional fields an invoice carries. English can sit on the same document where a counterparty needs it.
03Can Odoo carry our approval levels and give internal audit something to trace?
Yes. Approval steps can follow amount, cost centre, department or document type, with delegation when an approver is away. Access rules separate duties so the person who creates a vendor is not the person who pays it, periods are locked once closed, and record history shows who changed what and when. The reports internal audit will ask for are part of the build rather than something produced afterwards, and the matrix itself stays yours to decide.
04Where can the system be hosted?
In a region inside the Kingdom, in a cloud account or tenancy your organisation already owns, or in the European Union. The region, the location of backups, retention periods and who holds administrative access are stated in the engagement, so IT and procurement have a precise answer during supplier review. If an internal policy or a contract requires the data to stay in the Kingdom, that is a hosting decision we design around at the start rather than a late discovery.
05You are based in Europe. How does that work for an organisation in Riyadh?
Our engineering team is in Strasbourg. We have no office or staff inside the Kingdom, and we would rather say so than imply otherwise. In practice the time difference is one to two hours depending on the season, so the working day overlaps almost entirely; the working weeks differ at their edges, which matters for cutover windows, month-end and support cover. We work with named contacts, decisions recorded in writing in Arabic and English, and on-site phases when a go-live or a training programme justifies them.
Related capabilities
What a Saudi rollout usually touches next.
The core Odoo offer, the neighbouring Gulf market, and the security review that comes with a large deployment.
Let’s discuss the need
What is forcing the decision — the invoice, or the approvals?
Tell us what your entity issues, who has to approve it, the languages your documents go out in, and any constraint on where the system can run. We will come back with a scope.
No commitment · Clear scope · Arabic or English