No allocation number came back. How to tell a bug in your request from a Tax Authority decision, what codes 460, 461 and 462 mean, and the four alternatives.
Key takeaways
- The Approval service can return HTTP 200 and still not approve the invoice: the tell is `confirmation_number` of "0" together with `approved` set to false.
- Code 460 is documented as "Invoice not approved" - the data is correct and the invoice was not approved. Code 461 says the unapproved invoice exists with no decision sent; 462 says it exists and the decision was sent.
- The 400 family, such as 431 for an incorrect `vat_number` or 434 for "Invoice date is too old for approval", points at the content of your request.
- When no allocation number is returned for a substantive reason, the specification defines four alternatives the software presents, plus a separate `Invoice-decision` service for reporting the choice.
- Every call must carry a unique `INVOICE_ID`, and that identifier is what holds the whole story together across a hearing request, a cancellation or a retry.
When the service returns no allocation number, the first job is separating a technical rejection from a Tax Authority decision. An HTTP 400 with a field code is a bug in your request. An HTTP 200 whose approved field is false is a decision, and the accounting software is expected to offer the user four alternatives and report the choice back.
This is a technical description of an interface and a workflow, not tax, legal or accounting advice.
What the service actually returns for an unapproved invoice
The supplier-side allocation service runs at https://ita-api.taxes.gov.il/shaam/production/Invoices/v2/Approval in production and at the matching tsandbox address for testing, authenticated with OAuth2. A successful response carries status 200, the message "Invoice approved", a long confirmation_number and approved set to true.
The failure that catches new implementations is that the negative answer also arrives as 200. The specification states that if the confirmation number value is 0, or the approved output field is false, the error list must be checked. Code that treats HTTP 200 as success will print an invoice with no allocation number and never know.
Which failure is your bug and which is a decision?
The line runs between the shape of the request and the substance of the decision, and the response marks it: the error object carries a location field valued "request" for content errors and "approval" for decision errors.
| Code | Where it appears | What is documented | What it points at |
|---|---|---|---|
| 431 | HTTP 400 | "VAT Number is incorrect" on vat_number | Validity of the number you sent |
| 434 | HTTP 400 | "Invoice date is too old for approval" on invoice_date | The document date in the request |
| 460 | HTTP 200 | "Invoice not approved" | A decision, not your data |
| 461 | HTTP 200 | Unapproved invoice exists, no decision sent | Wait or call again |
| 462 | HTTP 200 | Invoice exists and the decision was sent | No further action |
| 401 | HTTP 401 | Cannot pass the required security checks | The token and the OAuth2 setup |
| 406 | HTTP 406 | Server cannot fulfil the request | Permission for the VAT number |
| 422 | HTTP 422 | Parameters do not match the schema | Validation against the spec |
The four alternatives the software has to offer
Per the specification, when the service returns no allocation number for a substantive rather than a technical reason, the accounting software presents four alternatives to the user and updates the Tax Authority with the choice:
- Abandon or cancel the invoice. Cancellation proceeds normally. The specification notes that where a tax invoice is cancelled, the guidance is not to include the invoice or the cancellation in the PCN874 file.
- Continue issuing the invoice with no allocation number. The specification states that such an invoice carries, prominently, the sentence that input tax may not be deducted against it.
- Reverse charge. Performed by an additional call carrying a zero-rate invoice with the same details, the same
Invoice_Id, and the value 3 in theactionfield. - Request a hearing. Filed through the Authority's service channels. If the invoice is released as a result, the allocation service is called again.
Three of the four have a dedicated service: Invoice-decision v1, with three endpoints - /Cancel, /Continue and /FurtherObjection. Reverse charge does not go through it; it goes back to the Approval service itself.
What to do while the customer is standing there
- Stop the print. An invoice that reached a screen or a printer before the response was inspected is the real damage.
- Classify the response: HTTP code,
approvedvalue,confirmation_numbervalue and the inner error code. - If it is the 400 family, fix the request and resend it with the same
INVOICE_ID. - If it is a decision, present the four alternatives and record who chose and when.
- Report the choice through
Invoice-decision, or throughApprovalfor reverse charge.
Why INVOICE_ID is the most important field in the flow
INVOICE_ID is defined as a unique identifier of up to 50 characters, and it accompanies the invoice on every call. The specification says explicitly that where a hearing was requested and the invoice was released, the allocation request is repeated with the same Invoice_Id as the original invoice. The same identifier carries the reverse-charge call and the decision-update service.
The engineering consequence: this cannot be a counter generated at print time. It has to be stored on the document record before the first call, survive a restart, and be retrievable a week later when somebody asks what happened to that invoice. If your older system has no such column, that is the first thing to add - see preparing a legacy system for Israel Invoice.
What breaks downstream when there is no allocation number?
The allocation number does not end at the printout. The specification defines a "short allocation number" - the last nine characters of the allocation number - and requires it in the detailed VAT report on the transaction record, on both the sales and the input side, as a nine-digit numeric field.
- An invoice printed with no allocation number leaves a hole in the detailed report file.
- The specification notes that on a cancelled tax invoice, neither the invoice nor the cancellation is included in PCN874.
- A preliminary document such as a proforma or transaction account carries document code 332, and tax invoices are linked to it by a call with
ACTION=4. - The specification states that the printout highlights the nine rightmost digits under an allocation-number heading, alongside the internal reference number.
Background on the file itself and what goes into it is in the PCN874 detailed VAT reporting file.
What to log so you can answer your accountant tomorrow
- The
INVOICE_IDand the exact request body sent, with no credentials in the log. - The HTTP code, the
approvedvalue,confirmation_numberand everyerrorsobject as received. - The call time and the attempt count, so a momentary outage is distinguishable from a stable decision.
- The alternative chosen, who chose it, and the response from
Invoice-decision. - A link from the invoice record to the row that went out in the detailed report.
Without that journal, a simple question such as "why did this invoice go out without a number" becomes an hour of archaeology. With it, it is one query.
Sources
Frequently asked questions
Does HTTP 200 mean the invoice was approved?
Not necessarily. The specification describes a 200 response in which `confirmation_number` is "0" and `approved` is false, and instructs that the error list be checked in that case. Your check belongs on the output fields themselves, not on the HTTP status code alone.
What is the difference between code 461 and code 462?
Per the specification, 461 indicates that the unapproved invoice exists and no decision was sent for it, while 462 indicates the invoice exists, the decision was already sent, and no further action is needed. They separate an open state awaiting a decision from a closed one.
Can an invoice be resubmitted after a fix?
Yes. A content error is corrected and resent. After a hearing in which the invoice was released, the specification directs you to call the allocation service again with the same `Invoice_Id` as the original invoice, so the allocation number received is updated in the system.
How do you handle many invoices at once?
The specification describes a `MultiApproval` service that accepts a batch in a single call and returns allocation numbers keyed to each invoice's `INVOICE_ID`. An invoice that came back with an error code inside the batch is fixed and resent individually, not as a new batch.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.