Skip to content
Azinove, Home

Odoo Riyadh · ERP for Saudi organisations

Odoo for organisations in Riyadh, invoicing in Arabic.And recording who approved what.

Azinove is an Odoo Partner working across Europe and the Gulf: our engineering team is in Strasbourg, France, and the group is headquartered in Bahrain. 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

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.

or

No commitment · Your details are not shared or resold.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 04

    Our engineering team is in Strasbourg, France, and the group is headquartered in Bahrain; 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.

or

No commitment · Your details are not shared or resold.

Odoo partner for Saudi Arabia

An official Odoo Partner, headquartered next door in Bahrain.

An organisation in Riyadh wants to know who the partner is and where it is. These are the facts that can be checked.

The group’s headquarters

Azinove W.L.L

Flat 105, Building 1853, Road 1546, Block 815, Isa Town, Kingdom of BahrainCommercial registration CR 190436-1Office line and WhatsApp: +973 3329 9634

Azinove is an official Odoo Partner. Its headquarters, Azinove W.L.L, is in Isa Town, Bahrain; its engineering team, Azinove SAS, is in Strasbourg, France. Forty-five projects and more delivered across the group.

We have no office or staff inside the Kingdom. Riyadh organisations are served remotely from Bahrain and Strasbourg, with on-site missions from Bahrain for scoping, go-live and training.

Delivered in the Gulf

  • Sovereign Estate

    Bilingual public website for an owners-association manager in Bahrain.

  • LandLording

    Property platform and mobile app for the Bahraini market.

Saudi configuration

What we configure for the Saudi rules.

Capabilities we set up in Odoo, not tax advice: which requirements apply to your entity, and from when, is confirmed with your tax adviser or auditor.

How these rules work, and how Odoo handles them, is in our guide Odoo for VAT and e-invoicing in Bahrain and Saudi Arabia.

  • ZATCA e-invoicing (Fatoora) phase 2 integration: structured invoices, clearance and reporting, tested in the sandbox before go-live
  • Arabic-first invoices, quotations and statements, with English on the same document where a counterparty needs it
  • Hijri dates alongside Gregorian dates on the documents that need them
  • WPS payroll files for salary transfers through the Wage Protection System
  • Approval matrices, separation of duties and locked periods, with the history internal audit asks for
  • Hosting inside the Kingdom, in a tenancy you own, or in the European Union, stated in the engagement

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.

01

Implementation & rollout at scale

Scoping, configuration, data migration and go-live, department by department, across a large user base and several levels of approval.

02

Arabic-first documents & records

Interface languages, field values stored in Arabic, right-to-left print layouts and document numbering sequences.

03

Custom modules & integration

Bespoke modules in Python and OWL, and API connections to the e-invoicing platform and to the systems already in use.

04

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.

01

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
02

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
03

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.

  1. 01

    Frame

    Entities, documents, approval levels, access rules and any hosting constraint are settled with finance, IT and internal audit in the room.

  2. 02

    Configure & build

    Documents, approval matrix and any custom module are built on a test database with the organisation’s own data.

  3. 03

    Validate

    Finance, internal audit and IT check documents, approval traces and access rights, and invoice exchanges are exercised in a test environment.

  4. 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.

05Your engineering team is in Strasbourg. How does that work for an organisation in Riyadh?

Our engineering team is in Strasbourg, France, and the group is headquartered in Bahrain. 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.

06Is Azinove an Odoo partner in Saudi Arabia?

Azinove is an official Odoo Partner. The group is headquartered in Bahrain (Azinove W.L.L, Isa Town, commercial registration CR 190436-1) and its engineering team is in Strasbourg, France. We are not a Saudi-registered company and have no office in the Kingdom; Saudi organisations are served from Bahrain and Strasbourg.

07Do you implement Odoo in Riyadh?

Yes. Scoping, configuration, migration and support run remotely from Isa Town and Strasbourg, in the same working day as Riyadh, with on-site missions from Bahrain, an hour’s flight away, for the phases that need presence: scoping workshops, go-live and training. The e-invoicing integration with the ZATCA platform is built and tested for the entity registered in the Kingdom.

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.

Explore all services

No commitment · Clear scope · Arabic or English

Odoo guides

Before you put a Gulf entity on Odoo.

Bahrain VAT, Saudi ZATCA e-invoicing, Bahrain HR and payroll, Saudi trading and distribution, Bahrain contracting, and what a compliant Odoo setup looks like, written by the team that configures it.

Odoo for a trading and distribution company in Saudi Arabia: inventory, imports, multi-currency and bilingual invoicing

What a Saudi trading, wholesale or distribution company needs from Odoo: warehouses and routes, reordering rules, landed costs with customs duty and freight, FIFO or average cost valuation, purchases in dollars, euros or yuan with riyal accounting, B2B price lists and credit control, barcode picking and delivery batches, Arabic and English invoices cleared by ZATCA, and the reports that show margin per customer and ageing stock.

Odoo HR and payroll in Bahrain: GOSI, LMRA work permits and the Wage Protection System

What a Bahrain employer needs from Odoo HR and payroll: employee files with CPR and work-permit expiry, Labour Law hours, overtime and leave, GOSI contributions for Bahraini and expatriate staff, the LMRA Wage Protection System file, work-permit fees and end-of-service rules, and what has to be built because Odoo ships no Bahrain payroll localization.

Odoo for a contracting company in Bahrain: projects, timesheets, progress billing, retention and subcontractors

What a construction, MEP, fit-out or engineering contractor in Bahrain needs from Odoo: one project per contract with milestones and tasks, timesheets that carry real labour cost, an analytic account per site, progress invoices from milestones or percentage of completion, down payments, a clear way to book retention, subcontractor purchase orders with bill control, materials and equipment from stock, and a profitability dashboard the project manager and the accountant both trust.