Israel Invoices integration: allocation numbers in your system
The Israel Tax Authority is lowering, step by step, the invoice amount above which a buyer cannot deduct input VAT without an allocation number (מספר הקצאה). Each step brings thousands of new businesses into the model, and for each of them the question is not accounting but systems: where will the number on the invoice come from.
In short
An allocation number is required when four conditions hold at the same time: the invoice is above the current threshold, it carries VAT, the recipient is a licensed VAT dealer (עוסק מורשה), and the recipient asked for a number. Without it the buyer loses the input VAT deduction, so the buyer is the one who demands it. Technically the number is requested from the Tax Authority through an OAuth2 API before the invoice is finalized, stored in the invoice record and printed on it. The common point of failure is not the API but the scenarios around it: what the system does when the Tax Authority does not answer, when no number is issued, and who notices.
When a number is required and when it is not
| Condition | What it means for the system |
|---|
| Amount above the threshold | The threshold excludes VAT and is lowered on the Tax Authority's schedule. It must not be hard-coded: it is a parameter that accounting changes |
| The invoice carries VAT | Zero-rated and VAT-exempt invoices do not receive a number |
| The recipient is a licensed VAT dealer | You need the customer's verified VAT number. If it is wrong, the request will be refused. |
| The recipient asked for a number | A number can also be requested for an invoice below the threshold. The system has to be able to request one for any invoice, not only for invoices above the threshold. |
The current threshold and its schedule are published by the Tax Authority, and the technical requirements for software are collected in its guidelines for software vendors (in Hebrew). Businesses on a cash basis receive separate approval on a transaction account, but input VAT is not deducted against it.
How it works technically
The Tax Authority provides an API with OAuth2 authorization in user-restricted mode. That means the number is requested on behalf of a specific business, and the business has to authorize its representatives in its personal area at the Tax Authority. The authorization is valid for up to a year, and renewing it belongs in a calendar reminder, not in an error message.
- Every request needs a unique invoice identifier. Sending the same invoice again must not create a second request.
- The request carries the registration number of the accounting software. An in-house system without registration sends a placeholder value, and that is worth deciding in advance.
- The number received is stored in the invoice record, printed on the document, and included in the PCN874 report.
- The Tax Authority will not accept an invoice dated more than two weeks back: check the date before sending.
- There is a sandbox for testing and a batch request option for several invoices at once.
An error can look like success. On refusal, the API responds with HTTP 200, and the sign of refusal is a zero confirmation number and a list of error codes in the response body. An integration that checks only the status code will record a refusal as an issued number. It is the first thing we check in someone else's integration.
When the Tax Authority does not answer
The Tax Authority has an emergency procedure, and it has to be built in ahead of time, not on the day of the outage.
- The business orders a small stock of emergency numbers in advance. Each number can be used once.
- An emergency number may be used only after several failed attempts to get a regular one, and those attempts have to be logged.
- When the connection is restored, every invoice that used an emergency number is reported to the Tax Authority through a separate API endpoint.
- If no number was issued because of a technical failure in the Tax Authority's systems, the director may allow the deduction without it. The log of failed attempts is the evidence.
A separate scenario: the Tax Authority can refuse a number if it suspects an improper invoice. A notice then arrives with options: cancel the request, complete the transaction without a number, shift the VAT liability to the buyer, or contact the control room. The system has to show the refusal to a person, not retry silently.
Where the integration usually goes
| System | What changes |
|---|
| ERP and accounting software | Number request at issue, storage, printing, PCN874 report. Often a vendor update is enough, if the software is registered |
| In-house billing | The whole cycle: authorization, request, log, emergency numbers, resending. This is where most mistakes happen |
| B2B online store | Verify the customer's VAT number at checkout, and request the number before the invoice is sent. |
| Store connected to an ERP | Decide which system requests the number. If both do, numbers are duplicated. If neither does, the invoice goes out without one. |
What we do
We test an existing integration by scenario, not by status code: refusal, outage, retry, stale date, wrong customer number, expired authority. Or we build the integration into your own system, with a log and an emergency procedure from day one.
The question of credit notes is settled together with your accountant: the Tax Authority's technical document and practical guides disagree on it, and the system should follow the position your accounting team is prepared to defend.
Frequently asked questions
What is an invoice allocation number in Israel?
A nine-digit number the Israel Tax Authority issues for a tax invoice. Without it, the buyer cannot deduct input VAT on an invoice above the current threshold.
What is the current threshold?
The threshold excludes VAT and is lowered on the Tax Authority's schedule. Take the current value from the Tax Authority, and keep it in the system as a configurable parameter rather than as a number in the code.
What if the Tax Authority API is down?
Use emergency numbers ordered in advance after several failed attempts, log the attempts, and report each such invoice once the service is back. If no number was issued because of a failure on the Tax Authority's side, the deduction may be allowed without it.
Why does the integration seem to work but no numbers appear?
Most often because the refusal arrives with HTTP 200. The sign of refusal is in the response body: a zero confirmation number and error codes. A system that checks only the status code treats a refusal as success.
Do we need to replace our ERP?
Usually not. If the software is registered and the vendor has released an update, that is enough. Work is needed when an in-house system issues invoices, or when several systems issue invoices to the same customer.
Where to start
Tell me which system issues your invoices, and how many systems issue invoices to the same customer. Those two answers show whether an update is enough or whether an integration is needed.
Talk to me
Related: Integrations, ERP development in Israel
SLAtech LTD