Israel Invoice (Allocation Numbers): What It Means for Your Systems

Scope note before anything else. This is a guide to system design, not to tax compliance. Israel's invoice allocation-number requirement has been introduced in phases with thresholds that have changed over time, and whether it applies to your business, at what threshold, and from when is a question for your accountant and for the Tax Authority's current published guidance. Do not take compliance conclusions from this page - including any figure you might find elsewhere on the internet, which may well be out of date.

What I can usefully cover is the part developers have to solve: what changes architecturally when issuing an invoice requires a call to an external authority, and how to build so that dependency does not become your weakest link.

The Structural Change

Before, issuing an invoice was a local operation. Your system, or your invoicing provider, generated a document with a number from your own sequence and that was that. The only parties involved were you and the customer.

Under an allocation-number regime, issuing certain invoices involves obtaining an identifier from the tax authority's system as part of the process. That is a synchronous dependency on an external service you do not control, inserted into a flow that previously could not fail for network reasons.

Everything difficult about this follows from that one sentence.

Where It Sits in the Flow

The naive implementation puts the authority call inline: customer checks out, your code requests an allocation number, waits, then produces the document. This works in testing and fails in production, because now a slow or unavailable government endpoint is a failed checkout.

The better shape separates the commercial event from the document issuance:

1. Record the sale. The order is captured and confirmed to the customer immediately. This step has no external dependency and must never fail because of one.
2. Queue the issuance. A job is created referencing the order, with the order reference as its idempotency key.
3. A worker obtains what it needs and issues. With retries and backoff, and with the result recorded against the order.
4. Surface the state. Pending, issued, or failed - visible to whoever needs to know, not buried in a log.

This is the same architecture that any external-dependency integration needs, and it is worth building properly here because the consequences of getting it wrong are financial rather than cosmetic.

Failure Modes to Design For

The lost-response case deserves particular attention. If your request reached the authority and was processed but the reply did not reach you, a blind retry risks a duplicate. Every request must carry an idempotency key derived from your own order reference, and your code must check its own records before issuing a second request.

Certificates and Credentials

Integrations with government systems typically involve credentials or certificates that expire on a fixed schedule. This is a boring operational detail that causes disproportionate damage, because expiry tends to be discovered at the worst moment.

Track expiry dates as monitored data, not as a calendar reminder in someone's inbox. Alert at a generous margin - weeks, not days. Keep the credentials in a secrets store, not in configuration files, and document who is able to renew them, because that person being on holiday is a real scenario.

Should You Build This Yourself?

For most businesses, no. If you issue documents through a cloud invoicing provider, they handle the authority integration as part of their product and keep it current as the rules change. That is precisely what you are paying them for, and reimplementing it yourself takes on maintenance of something that will change again.

Building it yourself is reasonable when you issue documents directly from your own system - a marketplace, a high-volume platform, a product where invoicing is core rather than incidental - and the provider's model does not fit. In that case, treat it as a real integration project with monitoring and an error queue, not as a function call added to existing code.

The middle path, which suits a lot of custom systems, is to keep issuing through a provider's API and let them handle the authority. Your system holds the commercial logic, their system holds the compliance surface.

What to Ask Your Accountant

Before any of the engineering, get written answers to these. They determine the whole design:

• Does the requirement apply to our business, and from what date and threshold?
• Which document types are affected, and which are not?
• What is our procedure if the authority is unavailable when we need to issue?
• Who is responsible for renewing the credentials, and what is the process?
• What records must we retain, and for how long?

These are compliance questions with real answers, and the answers shape the architecture. Getting them before building is far cheaper than retrofitting.

The Short Version

Treat the authority as an unreliable external dependency, because architecturally that is exactly what it is. Never let it block a sale. Make every request idempotent. Monitor credential expiry. And unless invoicing is core to your product, let a provider carry the compliance surface for you.

To design an issuance flow that holds up, book a free call. Related: automating invoices with the Morning API, how to automate invoicing, and the Israeli software stack.