Odoo Accounting Consultant, Saudi Arabia

Shaping the Saudi chart around audit and zakat reporting

The Saudi localization installs a chart of accounts and VAT taxes as a template. Saudi companies typically need to change it for two readers who are not in the finance team: the external auditor, who prepares or reviews financial statements under the standards applicable in the Kingdom, and the zakat or tax advisor, who builds the zakat base from balance sheet and profit and loss items.

The adaptations I most often make with a Saudi finance team:

• Current and non-current splits: receivables, payables, loans and retentions separated by maturity, because both the auditor and the zakat calculation care about it.
• Fixed asset classes: accounts per class with matching asset models, so cost, additions and depreciation by class come straight from the ledger.
• Related parties: dedicated accounts or tagged contacts for owners, sister companies and directors.
• Provisions: end-of-service benefits and other provisions held in their own accounts with movement visible.
• Branches: handled through analytic plans rather than a copy of every account per branch.

Account names can carry both Arabic and English, which helps when the auditor's working papers are in one language and management reports in the other. Computing zakat stays with your advisor; Odoo's job is to hold balances in the shape they need. This is part of the solution design rather than a technical detail.

VAT grids, fiscal positions and tying e-invoices to the return

The Saudi VAT return in Odoo is driven by tax grids: tags on each tax that send net and VAT amounts to specific boxes. With your advisor I review each sales and purchase tax against the box it should feed, paying attention to:

• Zero-rated supplies, such as exports and other categories your advisor confirms apply to you.
• Exempt supplies, kept apart from zero-rated ones because they affect input VAT recovery differently.
• Reverse charge on services imported from abroad, posting both sides automatically from the vendor bill.
• Real estate transactions, which in the Kingdom are generally subject to a separate tax regime and should not be pushed through VAT taxes by default.

Fiscal positions apply those outcomes per customer or supplier. Foreign vendors get the reverse charge position, export customers the zero-rated one, and so on, which removes the need for staff to choose taxes manually.

The check I add for Saudi clients is a monthly tie-out between e-invoices and the return. Every invoice and credit note cleared or reported to ZATCA should appear in Odoo's VAT figures for the same period, and the totals should agree. When they do not, the cause is usually a credit note created outside the normal flow or an invoice posted in the wrong period. Posting discipline and a tax lock date after each filing keep the two aligned.

Withholding tax, mada settlements and Saudi bank reconciliation

Payments to non-resident suppliers for services, royalties and similar items can attract withholding tax in the Kingdom. Whether a payment is subject to it, and how it is treated, is your advisor's call. The Odoo question is how it gets recorded. Some Odoo versions include withholding support in the Saudi localization; otherwise a defined routine records the withheld amount against a liability at payment and reconciles it when paid to ZATCA. I check which applies in your version before designing the vendor payment process.

Bank synchronization coverage for Saudi banks is limited, so most Saudi teams import statements in CSV or Excel. Reconciliation models then handle the patterns that repeat every day:

1. mada and card settlements: terminal and online settlements arriving net of fees, split between cleared sales and charges.
2. SADAD and bank transfers: customer payments matched to invoices by reference, which works far better when the invoice number travels with the payment.
3. Salary transfers: payroll debits matched to the payroll liability, since payroll and GOSI often run in a separate system.
4. Bank fees and VAT on fees: posted automatically to expense and recoverable input VAT.

For branch-heavy retail and food businesses, I also set a rule for cash deposits from each branch so they reconcile against the right point of sale sessions. The finance automation page explains the wider approach.

Branches, group companies, analytics and edition choice

Saudi companies often trade through several branches under one commercial registration and one VAT number, sometimes alongside related companies with their own registrations. The structure in Odoo follows the legal reality. Branches under one VAT number can be analytic plans within one company, or branch companies where your Odoo version supports them, sharing a tax identity but keeping separate journals and document sequences. Each separately registered entity becomes its own company.

Between companies, intercompany rules can create the matching bill when one company invoices another. That feature has historically been tied to Enterprise, so confirm it in your version. For group reporting, I check what consolidation tooling your edition and version include; many Saudi groups still consolidate with their auditor or in a reporting tool.

Analytic accounting does most of the management work: profit by branch, project, contract or cost center, with distribution models that spread shared costs. Contractors often run a project plan and a department plan side by side.

The edition decision is decisive here. In most versions the ZATCA connector, the full Accounting app with VAT reports, reconciliation tools and intercompany rules sit in Enterprise, while Community offers invoicing. Replacing those with community modules for a regulated invoice flow is a risk I would only accept with strong technical support. Check the current edition list before you commit.

Opening balances for a Saudi cutover, and when Odoo is not enough

Saudi migrations usually come from Tally, local Arabic accounting packages or an older ERP. Because invoices after go-live must be compliant from the first document, the cutover date is fixed and the opening position must be ready. I agree with your finance team and auditor what is loaded:

• Trial balance at a period end, ideally aligned with the last audited or reviewed figures.
• Open customer invoices and vendor bills, individually, with original dates for aging.
• Customer advances and contract retentions, with any VAT already accounted for.
• Fixed assets with cost and accumulated depreciation per asset.
• End-of-service provision per employee or in total, as your advisor prefers.

Every load is reconciled back to the old system's reports. ERP data migration describes the sign-off steps.

Odoo Accounting will not compute zakat, and it is not the obvious choice for groups that need formal IFRS consolidation across many entities, or for businesses that want every financial report produced natively in Arabic layouts without customization. In those cases I compare alternatives, including Business Central in Saudi Arabia. E-invoicing onboarding and hosting are covered on Odoo in Saudi Arabia, product detail on Odoo Accounting, and my wider work on ERP consultant Saudi Arabia and the Saudi hub.