Israel Invoice Reform 2026: Allocation Number Rules Explained

01 What an allocation number actually is

An allocation number (מספר הקצאה, mispar haktza'ah) is a nine-digit code the Israel Tax Authority issues for any tax invoice above a legally set threshold. It isn't cosmetic. It's a digital confirmation that the transaction was reported to the Israel Invoices system (חשבוניות ישראל), and it has to appear on the original invoice itself before the buyer can rely on that invoice to deduct input VAT.

The seller (whoever issues the invoice) requests it, usually because the buyer is asking for it. The request goes through the accounting software's API connection to the Tax Authority (the SHAAM system), or manually through the gov.il portal, one invoice at a time. There is no batch shortcut on the manual route, which is exactly where the operational strain shows up.

If you're an English-speaking owner running a business in Israel, this is worth saying plainly: the reform has been rolling out in Hebrew-only for two years, and most English-language guidance for olim doesn't mention it. Nefesh B'Nefesh's tax resources don't cover it. The global compliance-vendor sites that do treat Israel as one line in a 40-country comparison table, written for a compliance officer, not for the person actually approving invoices this month.

02 The timeline: how the threshold stepped down to NIS 5,000

The reform launched on 5 May 2024 with a threshold of NIS 25,000 before VAT. From 1 January 2025 it dropped to NIS 20,000. From 1 January 2026 it dropped again to NIS 10,000. And from 1 June 2026, the threshold sits at NIS 5,000 before VAT.

If you're reading this in July 2026, the threshold has already dropped. This isn't a future deadline to plan around, it's been your operating reality since 1 June. Every invoice above NIS 5,000 now needs a valid allocation number before the receiving side can deduct the input VAT on it.

03 What this means in practice: the volume math

At a NIS 25,000 threshold, most of a mid-sized business's smaller transactions never touched the reform at all. At NIS 5,000, almost every supplier invoice is now in scope.

A concrete example. A business receives 300 supplier invoices a month, and previously only about 40 crossed the NIS 25,000 line. Back then, someone in the back office requested roughly 40 allocation numbers a month: about two a day. Under the NIS 5,000 threshold, that same business may find 220-250 of those 300 invoices now cross the line. That's a jump from 2 requests a day to 10-12, and every one that gets missed or entered with an error is VAT your customer can't deduct.

This has stopped being a task one person handles at month-end. It's a daily work queue now, and once the volume jumps fivefold, the human error rate climbs right along with it.

04 The real exposure is on the buyer's side, not just the seller's

Most businesses focus on "how do I issue an invoice with an allocation number," and that's a fair, necessary question about your own outgoing invoices. But the heavier financial exposure sits on the accounts-payable side, when you're the one receiving invoices from suppliers.

If an invoice above the threshold arrives without a valid allocation number, or with an incorrect one, you can't deduct the input VAT on that transaction. That's money out of your pocket, not the supplier's. And as the count of invoices crossing NIS 5,000 spikes, so does the manual checking required on every incoming invoice: is there an allocation number, does it match the amount and the supplier, and is it actually valid?

05 What's a question for your accountant, and what's an operations question

There are two different kinds of questions here, and it's worth keeping them separate.

Questions for your accountant (רואה חשבון): how specific document types are classified under the reform, what happens in edge cases like credit invoices or transactions between related companies, how to appeal if the Tax Authority rejects a request, and what retroactive exposure you carry if gaps already happened. These are questions of interpretation and law, not process. Your accountant stays the authority here, automation doesn't replace them.

Questions that are fundamentally operational, and therefore automation questions: how do you make sure every incoming and outgoing invoice gets an allocation number without someone remembering to request it manually, how do you handle volume that's grown several times over without adding headcount, and how do you build a control layer that catches a problem invoice before it enters the books, not after, when you're already fixing it retroactively.

One Anglo-specific wrinkle worth naming: most Israeli accounting software (Hashavshevet, Rivhit, and the like) is Hebrew-only, and so is the gov.il portal for manual requests. If you're an English-speaking owner without a Hebrew-fluent back-office hire, checking whether an allocation request failed means someone reading Hebrew error messages inside Hebrew software. That's exactly the kind of bottleneck worth automating rather than living with.

06 Where automation fits in

At its core, this is a document-intake problem. A supplier invoice comes in (scan, PDF, email), the relevant data gets pulled out of it, and a system checks whether the amount crosses the current threshold and whether a valid allocation number is present. If the number exists and matches, it's entered directly into the accounting software or ERP. Edge cases (an invoice with no number, a mismatched number, or a borderline amount) route to a person for approval instead of getting quietly absorbed into the volume.

This doesn't replace your accountant, and it doesn't replace human judgment on anything unusual. It takes the repetitive, predictable volume off the table so the back office can spend its attention on the exceptions instead of the data entry, with a human still signing off on anything the system flags.

07 What a sane monthly rhythm looks like once this is running

Before automation, the monthly rhythm usually goes like this: invoices pile up through the month, someone batches allocation checks in a rush before close, missing or mismatched numbers surface as a scramble at month-end, and by then some of them are already paid, which means fixing them retroactively with your accountant instead of catching them on the way in.

After, the rhythm shifts. Invoices get checked against the threshold and the allocation number the same day they arrive. Anything clean flows straight into the ledger. Anything flagged sits in a small daily queue for a person to clear, instead of a monthly pile nobody wants to touch. Month-end close stops being the moment you discover the reform-related problems from three weeks ago, because there aren't three weeks of backlog left to discover.

A Hebrew version of this guide covers the same ground at marwin.co.il/he/guides/israel-invoices-2026, worth forwarding to your bookkeeper or accountant if they'd rather work from the Hebrew framing of the same rules.

08 Readiness checklist: ten things to stop doing manually

• Confirmed with whoever issues your invoices (accounting software or ERP) that it's connected to the Tax Authority's API and requests allocation numbers automatically above NIS 5,000
• Checked that the authentication token for the Tax Authority connection is valid, and that someone owns renewing it every three months
• Mapped how many of your incoming (AP) invoices actually cross the NIS 5,000 threshold, based on last month's real numbers, not an estimate
• Assigned someone to check that the allocation number on a supplier invoice matches the amount and transaction details
• Built a process for what happens when an invoice arrives without an allocation number: who holds the payment, who follows up with the supplier
• Asked your accountant whether you have retroactive exposure on invoices that already went through without a valid allocation number
• Have a way to know, without counting manually, how many allocation requests were rejected or stuck in the last month
• Checked whether your back-office team is still manually keying some of this into the gov.il portal instead of going through an automatic connection
• Have a control layer that catches a problem invoice before it enters the books, not after it's already been paid
• Sent this guide (or its Hebrew twin) to your bookkeeper or accountant so you're both working from the same threshold timeline

Questions we actually get

Do I need an allocation number for an invoice under NIS 5,000?

No. The requirement only applies to tax invoices above the current threshold, which is NIS 5,000 before VAT as of 1 June 2026. Invoices below that line aren't subject to the allocation-number requirement.

What is an allocation number, in plain English?

A nine-digit code the Israel Tax Authority issues for a tax invoice once it's been reported to the Israel Invoices system (חשבוניות ישראל). It's printed on the original invoice and serves as confirmation the transaction was registered correctly. In Hebrew it's called מספר הקצאה (mispar haktza'ah).

What's the current threshold, and how did we get here?

From 1 June 2026, it's NIS 5,000 before VAT. The threshold came down in stages: NIS 25,000 from May 2024, NIS 20,000 from January 2025, NIS 10,000 from January 2026, and NIS 5,000 from June 2026.

Who requests the allocation number, me or my supplier?

The seller (whoever issues the invoice) is the one who requests and receives the allocation number from the Tax Authority. But you, as the recipient, take the financial hit if the number is missing or wrong, because without it you can't deduct the input VAT on that invoice.

What happens if an invoice arrives without an allocation number?

If the amount is above the threshold and there's no valid allocation number, the input VAT on that transaction can't be deducted. That's a direct cost that lands on the receiving business, not on whoever issued the invoice.

My accounting software is Hebrew-only, how do I even see if allocation numbers failed?

Most Israeli bookkeeping software and the gov.il portal for manual requests are Hebrew-only, which is a real problem if you're an English-speaking owner without Hebrew-fluent back-office staff. If your software has an API connection to the Tax Authority, allocation numbers should be requested and matched automatically, with failures flagged somewhere you can see them without reading Hebrew line by line. If you're relying on someone manually checking the gov.il portal, failures are easy to miss until a customer complains their VAT deduction was rejected. The practical fix is a control layer that surfaces failed or missing numbers in a language and format you can actually act on.

Does the allocation number apply to every invoice?

No. It applies to tax invoices above the current threshold: B2B transactions with a VAT component between registered dealers (עוסק מורשה), where the buyer wants to deduct input VAT. VAT-exempt invoices, or sales with no VAT deduction involved, aren't subject to the requirement. For edge cases (credit invoices, related companies, unusual document types) ask your accountant rather than assuming.

Is this a question for my accountant or an automation question?

Both, in different lanes. Document classification, edge cases, and appeals to the Tax Authority belong with your accountant. Making sure no invoice gets missed once daily volume has grown several times over is an operations and automation question.