Allocation Numbers: What the Israel Invoices Model Means for Your System

The Israel Invoices model requires tax invoices meeting the statutory conditions to carry an allocation number issued by the Tax Authority. For a software system the implication is sharp: issuing an invoice stopped being a local operation that always succeeds and became dependent on an external service. That is an architectural change, not an extra field.

To be clear: this article describes engineering implications only. It is not tax advice and does not determine what applies to your business - for any question about applicability, thresholds or reporting obligations, the business's accountant is the address. For general context see also allocation numbers for developers.

What changes architecturally

Before the model, issuing an invoice was essentially a write: the system allocated a sequential number, wrote a record, produced a PDF. No external dependency, therefore no real failure path.

Now there is a call to an external service inside the flow. And everything true of an external call is true here:

• It can be slow. If it sits inside a customer's HTTP request, your response time depends on it.
• It can fail. And now a state exists that did not before: a paid order with no invoice.
• It can time out and still succeed. The familiar problem from every invoicing integration.

The practical conclusion: invoice issuance should leave the user's synchronous path. The customer pays, receives confirmation, and issuance happens in the background - with a queue, controlled retries, and an error queue a human sees. A system that issues an invoice inside the checkout request will fail on precisely the day the external service is slow.

The threshold - and why it must not be hard-coded

The obligation applies above a certain amount. That threshold has changed more than once during 2026, as part of a phased rollout.

I am deliberately not stating a number here: any figure I write may be inaccurate by the time you read it, and an inaccurate number in an article becomes an inaccurate number in code. Take the current threshold from the Tax Authority or from the business's accountant.

What does matter in engineering terms, and will not change:

1. The threshold must be a configuration parameter, never a constant in code. A threshold change should be a settings update - not a deploy.
2. A hard-coded value fails silently. If the threshold drops and the code still checks the old one, the system simply will not request a number for invoices that require it. Nothing crashes, nobody finds out - until an audit.
3. The threshold is on the document, not the customer. The same customer can generate invoices above and below it. The check belongs at document level.
4. Record which threshold was in force at the moment of issuance, alongside the document. In a later enquiry that is the evidence the system behaved correctly at the time.

Who actually makes the call

In most cases - not you.

If the business issues invoices through an invoicing system such as Morning, iCount, EZcount, Rivhit or SUMIT, that system handles issuance against the Tax Authority. You are not required to implement it, and you should not want to.

What is required of you:

• Confirm the system the client uses actually supports it and on which version or plan - a question for their support, in writing, before you quote.
• Handle the response. If issuance failed because no number was obtained, your system must know that and not treat it as success.
• Store what comes back alongside the rest of the document details.

If the business issues invoices from a system you built from scratch, that is an entirely different story requiring an accountant's involvement throughout rather than only at the end.

Failure paths - design them before the happy path

This is the most commonly skipped part. Three scenarios need an agreed answer before go-live:

1. The service is unavailable at issuance time

What do you do? Hold the document and retry? Issue without and correct later? Block the transaction?

That is a business and accounting decision, not a technical one. The developer should not choose it, and the system should not choose it alone. Get it in writing from the accountant.

2. A timeout that may have succeeded

The familiar problem: you sent a request, got no response, and do not know whether the document was issued. A timeout is not a failure - it is an absence of knowledge.

Do not retry automatically. Store your own unique reference on the order and check whether a matching document already exists before any retry. A missing document is fixed in a minute; a duplicate tax document needs a cancellation, an offsetting document and a paper trail.

3. Failures accumulating

If the service was down for an hour, there is now a queue of pending invoices. Somebody needs to know.

An error queue nobody checks is an error queue that does not exist. You need an alert when the queue exceeds a sensible size, and a person who looks at it in the morning.

Checklist

1. Establish with the accountant what applies to the business - do not infer it from an article, including this one.
2. Confirm in writing that the invoicing system in use supports issuance, and on which plan.
3. Move issuance out of the synchronous path into a background queue.
4. Threshold as a configuration parameter, never in code.
5. Record with every document which threshold was in force.
6. Get in writing what to do when the service is unavailable.
7. Duplicate protection before issuing the first production document.
8. An alert on a filling error queue.