Odoo Accounting Consultant, Jordan

The Jordan fiscal package and the sales tax report

Odoo's fiscal localizations install accounts, taxes and reports per country, and their contents change from version to version. For a Jordanian company I install the package for the exact version you plan to use in a test database and compare it with how your accountant currently prepares the sales tax return and the financial statements.

The comparison covers:

• Accounts. Whether the default chart supports your statements, or needs accounts for intercompany balances, dated checks, advances and project work in progress.
• Tax records. Which sales tax treatments are created where each one posts, and whether any treatment your advisor uses is absent.
• Report lines. Whether the tax report totals align with the boxes your accountant fills in, so the report can be used directly instead of rebuilt.
• Fiscal positions. Automatic switching for services supplied to clients abroad and other cases your advisor specifies, driven by the customer record rather than a clerk's memory.

I test the result by entering a representative month of invoices and bills and comparing Odoo's tax report with your accountant's figures for the same month. Differences become configuration changes. Tax treatments and current obligations are confirmed by your tax advisor; my job is to make Odoo apply them consistently. Wider platform choices are covered on my Odoo consultant Jordan page.

E-invoice status visible from the ledger

Jordan's tax department runs a national e-invoicing platform that expects structured invoice data. Whether the Jordan localization or a separate module handles submission for your version and edition has to be verified, and which invoices are in scope is for your tax advisor to confirm. Once a route is chosen, finance needs control over it from inside Odoo Accounting rather than from a separate log.

I design that control:

• Status on documents. Customer invoices and credit notes show whether they were submitted, accepted or failed, with filters the accountant can use for any period.
• Platform references. The reference returned by the platform is stored on the document and, where required, printed on the customer copy through the invoice report.
• Correction discipline. Submitted invoices are never reset and edited; corrections go through linked credit notes, and only named users can create them.
• Failure handling. A failed submission alerts a named person, and the fix is recorded so the audit trail stays intact.
• Monthly match. An export from the platform is matched to Odoo by document number and total, and differences are cleared before the tax report is approved.

Bilingual invoice layouts that carry the platform reference are specified in English and their Arabic wording checked by your staff. The ERP integration service explains how the connection itself is specified and tested.

Rounding settings that keep fils totals exact

Setting the dinar's currency precision to three decimals is necessary but not sufficient. Several other Odoo settings interact with it, and a mismatch between them still produces small differences between invoice lines, tax and totals.

The settings I review together:

• Currency rounding for the dinar, confirming amounts are stored at fils level.
• Price accuracy for product prices, so unit prices with three or more decimals are not truncated before multiplication.
• Tax calculation rounding, which Odoo can apply per line or globally on the document. The choice changes results on multi-line invoices, so your accountant decides, and it must match how the e-invoicing platform computes totals.
• Cash rounding where cash or certain payment methods require rounding to a coarser unit, posted to a dedicated account.
• Other currencies in the same database, which keep their own precision, so a company billing in dollars and dinars is tested in both.

I then run a test set designed to break things: fractional quantities, line discounts, several tax treatments on one invoice and credit notes against partial lines. Each result is compared with a manual calculation. A difference of one fil looks trivial until it appears on every invoice sent to the platform, so this test is part of acceptance rather than an afterthought.

Intercompany and analytic accounting for regional work

Many Jordanian firms are one part of a regional structure: an Amman company employing developers or analysts, a Gulf entity holding client contracts, sometimes a shared services arrangement for finance or HR. Revenue, costs and staff time cross company lines constantly, and management wants margin by client and project regardless of which entity booked it.

In Odoo Accounting I combine two tools:

• Intercompany rules and accounts. When the Jordanian company recharges services to a Gulf sister company, the matching bill appears in the receiving company, posted to a dedicated intercompany account in each. A monthly report compares the pairs.
• Analytic plans. Separate analytic dimensions for client, project and business line, with distribution rules that spread shared costs such as rent, tools and management time on a basis your finance lead agrees.
• Currency handling. Each company keeps its own currency; foreign currency balances are revalued under your accountant's method, with the rate source recorded.
• Recharge basis. The method for pricing internal services is documented and applied consistently. Transfer pricing questions belong to your tax advisor.

Project margin reports then draw on analytic data across companies, while each company's statutory books stay intact. The project costing page explains the margin side in more general terms.

Edition, bank imports, dated checks and the close

For finance, Enterprise matters more than it might appear. It provides the complete Accounting application, including the reconciliation interface, financial reports, assets, deferrals and follow-ups, and vendor-maintained localization work may depend on it. Community needs extra modules for much of this, maintained by whoever wrote them. I compare both against your monthly workload in the version you plan to use.

Bank statements usually arrive as files; confirm whether online synchronization covers your Jordanian banks before counting on it. Reconciliation models then absorb bank fees, internal transfers and repeat receipts. Checks are common in Jordanian commerce, including dated ones, so received and issued checks sit in outstanding accounts until cleared, with a report of checks due by date so the cash forecast is realistic.

The close then runs in order: banks reconciled, checks reviewed, platform match done, intercompany agreed, revaluation posted, tax report approved and lock dates set. Opening balances are loaded and proven through my ERP data migration checks. A small services firm needing only invoicing may be better served by a lighter tool. More context: the Odoo Accounting overview, my Jordan ERP consultant page and the Jordan hub.