Invoice Allocation Numbers: What Changes in a Business Owner's Workflow

This is a technical and operational description of what changes in the working routine, not tax advice. Any question about liability, deduction or filing goes to an accountant or a licensed representative. What can be described: an allocation number is a nine-digit number obtained online from the Israel Tax Authority, and without it the recipient of the invoice cannot deduct the input VAT.

What actually changed in the work

Before the model, issuing a tax invoice was a local act: the software produced a document and it was sent. Under the Israel Invoices model, an invoice above the threshold involves an online request to the Tax Authority for a number, and the number is printed on the invoice. The Tax Authority describes the service on its request for an allocation number for a tax invoice page.

The practical meaning: issuing an invoice has become an action that depends on an external connection. Most of the time that is entirely invisible - the software asks and gets a number in seconds - and precisely for that reason it is worth knowing in advance what happens when it does not.

From which amount it applies

The threshold falls in stages, so the figure correct today is not necessarily correct in six months. That is why a threshold written once into an internal procedure is a risk: a business that defined "above 10,000" and stopped looking will issue invoices with no number in a band where one is already required.

The safe operational rule is not to hard-code the threshold into a procedure but to let the software decide by its current setting, and to confirm once a quarter that the software is up to date.

Who is actually harmed

This is the least intuitive point. An invoice issued without a valid allocation number, at an amount that requires one, harms the recipient first - they are the one who cannot deduct the input VAT included in it.

So the business consequence is not with the authority but with the customer. A business customer who finds that the invoice they received does not allow a deduction will come back asking for a correction, which makes this a customer service matter rather than a bureaucratic one. It is also what makes the receiving-side check part of the supplier onboarding checklist.

What to do when the number does not come back

It happens, and in most cases for a simple technical reason. The three common scenarios:

1. A momentary connection fault - the request failed; a retry usually resolves it.
2. A permissions or connection problem - the software is not properly connected to the online services.
3. A substantive refusal - the request was declined for a reason relating to the business or the transaction details.

The third is the only one that is not a computer problem, and the only one requiring a call to the accountant or representative. What you should not do in any of the three: issue the document without a number and move on assuming it will work itself out. Technical depth on handling refusals is in an invoice rejected on its allocation number.

Three situations that cause confusion in practice

The first is a transaction split across several invoices. A business dividing a project into three payment stages finds two of them below the threshold and one above, so the invoices are not alike - and that confuses both the issuer and the recipient. What resolves it is letting the software decide by the actual amount rather than expecting a person to remember.

The second is foreign currency. When an invoice is denominated in another currency, what the amount is for threshold purposes is not a technical conversion question but one for the accountant, so it should not be inferred from today's rate.

The third is credit notes. A credit note is not a tax invoice, and how it relates to the threshold is exactly the kind of detail worth settling with the representative before a whole series of documents is produced on an assumption.

The other side: checking invoices you receive

The Tax Authority also runs a service for verifying supplier invoice details against an allocation number. Operationally that means there is a way to check, so a business receiving large invoices can place the check at the right point - before payment, not after.

The right moment for it is exactly the moment the supplier's other documents are checked, so it fits naturally into a weekly payment run: the same stop, the same list, one more check.

What to verify in your software

Four checks, once a quarter, ten minutes in total:

1. That an invoice above the threshold was issued recently and the number actually appeared on it.
2. That the software shows a clear message when the request fails, rather than issuing silently.
3. That the threshold setting in the software matches the current threshold.
4. That whoever issues invoices knows what to do when an error appears.

The second check is the important one. Software that fails silently produces a run of problem documents with nobody aware, and it surfaces weeks later through a customer - the most expensive way to find out.

What it means for a business issuing few large invoices?

A business issuing five invoices a month is affected more than one issuing five hundred, because for them every invoice is a large amount and every fault holds up a whole payment. At a business with a high volume of small invoices, a large share never crosses the threshold at all.

What follows is a simple order of priority: the larger the average invoice, the more it matters that the software is connected and current, and that there is a known answer to what happens if it is not. For a business with a low average invoice, it is simply less urgent.

Sources

• Israel Tax Authority - request an allocation number for a tax invoice
• Israel Tax Authority - verify supplier invoice details by allocation number
• An invoice rejected on its allocation number
• Allocation numbers - the technical side for developers
• Book a call