Odoo in Israel: Connecting Odoo to Morning, iCount, Hashavshevet and Allocation Numbers

Connecting Odoo to Israeli invoicing and accounting means using Odoo's external API to move customers, sales orders and invoices into a system that issues Israeli tax documents, such as Morning or iCount, or into the books your accountant keeps in Hashavshevet. Odoo 19 exposes that API at /json/2, and only Odoo's Custom plan includes it.

Odoo is an ERP with sales, inventory, CRM and accounting apps in one database. Israeli businesses that adopt it often keep an Israeli system for tax documents and for the books, so the real project is the bridge between them. This guide covers that bridge: the API itself, what Odoo's Israeli localization includes and what it does not, and the integration patterns that survive real invoices.

What does Odoo's external API look like in 2026?

Odoo's external API lets another system call Odoo model methods over HTTP, and since Odoo 19 two generations exist side by side. The new one is JSON-2: every call is a POST to /json/2/<model>/<method>, for example /json/2/res.partner/search, with an API key in an Authorization: bearer header and, when the server hosts several databases, an X-Odoo-Database header. Each database documents its own models, fields and methods on its /doc page.

The older generation is XML-RPC and JSON-RPC, which is what Odoo 18 and earlier offer and what most examples online use. You call authenticate on /xmlrpc/2/common to get a user id, then execute_kw on /xmlrpc/2/object with the database name, the user id, the password or API key, the model, the method and its arguments. Odoo's documentation states that the /xmlrpc, /xmlrpc/2 and /jsonrpc endpoints are scheduled for removal in Odoo 22, in fall 2028.

• API keys. Available since Odoo 14. A user creates one under Preferences, Account Security, New API Key, and it takes the place of the password in scripts. Odoo shows the key once and cannot display it again.
• Plan. Odoo's documentation says access to data through the external API is available only on the Custom pricing plan, not on One App Free or Standard. Odoo's pricing page lists "External API" among the Custom plan's features.
• Transactions. Every JSON-2 call runs in its own SQL transaction, and calls cannot be chained into one. Odoo's advice is to call a single business method that does the related work, such as action_confirm on sale.order, rather than several writes in a row.

Check the plan before anything else. A business on Standard that has been promised an integration has nothing to connect to until the subscription changes.

Does Odoo's Israeli localization handle allocation numbers?

Odoo's Israeli localization module does not say it does. The core module is l10n_il, named "Israel - Accounting", and its own description lists three things: a generic Israeli chart of accounts, taxes and a tax report, and multiple fiscal positions. It depends only on Odoo's base account module. Allocation numbers, the Tax Authority's online allocation service and Israeli document types such as a tax invoice-receipt (חשבונית מס קבלה) are not mentioned, and the Odoo 19 fiscal localizations documentation has no page for Israel.

A technical description, not tax advice. Under the Israel Invoices model (חשבוניות ישראל), a tax invoice above a threshold needs an allocation number issued by the Tax Authority for the customer to deduct its input VAT. The Tax Authority's VAT directive 01/2025 lists that threshold as NIS 20,000 in 2025, NIS 10,000 from 1 January 2026 and NIS 5,000 from 1 June 2026. Which of your invoices this applies to is a question for your accountant.

For the system, the consequence is concrete: an invoice posted in Odoo has no route to an allocation number unless something adds one. If you consider a third-party module for that, judge it on its documentation, its supported Odoo version and who maintains it. What changes once issuing an invoice depends on an external service is covered in allocation numbers and what they mean for your system.

Three ways to connect Odoo to Israeli invoicing and accounting

The first pattern keeps the legal document inside a system built for Israeli rules and gives Odoo the work it is good at. Its cost is a second system and a sync that must never issue the same document twice. A typical flow:

1. A salesperson confirms a quote, and action_confirm turns the sale.order into a confirmed order.
2. Your integration service polls for orders changed since its last run, using the write_date field every Odoo model carries, and reads the order and its res.partner customer.
3. It finds or creates the customer in the invoicing system by tax ID and issues the document there.
4. It writes the document number and the PDF link back to the Odoo order, in a field added for the purpose, so Odoo users see what was issued.
5. It records the Odoo order id against the document id, so a retry after a timeout never issues a second document.

The invoicing side of that flow is covered in automating invoices with the Morning API.

The Odoo records an invoicing integration touches

Decide in writing which partner field holds the Israeli business number (ח"פ or עוסק מורשה number). If one salesperson types it into vat and another into company_registry, the integration creates duplicate customers in the invoicing system.

What goes wrong when Odoo meets Israeli systems?

• Two systems issuing documents. Odoo posts an invoice and the Israeli system issues another for the same sale. Pick one issuer per document type and switch the other off.
• Credit notes mapped as negative invoices. An out_refund in Odoo has to become a credit document in the invoicing system, not an invoice with a minus sign.
• Chained calls that half succeed. Creating a customer and then an order in two JSON-2 calls leaves an orphan customer when the second call fails. Make each step safe to repeat.
• Code written for XML-RPC only. It works today and stops with Odoo 22. New work on Odoo 19 should use JSON-2.
• A plan change nobody connected to the integration. Moving from Custom to Standard ends external API access.
• An integration user with admin rights. The API key carries every permission of its user, so give the integration its own user with only the access it needs.

What to have ready before you start

• The Odoo version and where it runs: Odoo Online, Odoo.sh or on-premise.
• Confirmation that the subscription is on the Custom plan.
• A dedicated integration user and its API key, stored like a password.
• A decision on which system issues each tax document, agreed with your accountant.
• The field mapping for the tax ID, VAT rates and document types in both systems.

If you are still choosing where Odoo fits against an Israeli ERP or an accounting package, ERP vs CRM vs accounting sets out the difference, and connecting an Israeli ERP to anything covers the same bridge from the other side. For what a project like this costs, see the pricing page.

Sources

• Odoo 19.0 documentation - External JSON-2 API (API keys, plans, XML-RPC deprecation)
• Odoo source - l10n_il module manifest ("Israel - Accounting")
• Israel Tax Authority - VAT directive 01/2025, the Israel Invoices model (PDF, Hebrew)