Israel E-Invoicing: Allocation Number Requirements Explained

Israel's invoice allocation number (mispar haktzaa) is a unique 9-digit code issued by the Israel Tax Authority (ITA) through its SHAAM platform for every B2B invoice that exceeds the mandatory threshold amount. The system operates on a Continuous Transaction Controls (CTC) clearance model: before a supplier can send an invoice to a buyer, the invoice data must first be transmitted to the ITA for real-time validation. Only after the tax authority approves the transaction and returns an allocation number is the invoice considered valid for tax purposes.

The financial consequence is straightforward and significant. An invoice that lacks a valid allocation number cannot be used by the buyer to deduct input VAT. For the buyer, this means paying VAT with no recovery mechanism. For the supplier, it means issuing documents that their customers cannot fully use, creating friction that can damage commercial relationships and delay payments.

Israel built this clearance system to address a specific, well-documented problem: fictitious invoice fraud. Fabricated invoices had been used systematically to claim illegitimate VAT deductions, costing the Israeli government billions of NIS annually in lost tax revenue. Rather than relying solely on post-filing audits to catch fraudulent claims, the allocation number system shifts enforcement upstream, blocking fictitious transactions before they enter the tax system. The approach has proven effective at scale, with the ITA reporting that it has already thwarted tens of billions of NIS worth of fraudulent activity since implementation began.

The Israel e-invoicing allocation number requirements are not static. The ITA is progressively lowering the invoice threshold through a phased schedule running to June 2026, which means a growing number of businesses and transactions will fall within scope over the coming months. Companies operating in Israel, trading with Israeli suppliers, or advising clients on Israeli tax compliance need to understand both the current rules and the trajectory of this expanding mandate.

How Invoice Fraud Drove Israel's Allocation Number System

The allocation number system did not emerge from bureaucratic ambition. It was built to solve a specific, measurable crisis: fictitious invoices were draining billions from Israel's tax base every year.

The scheme worked like this. Criminal networks would generate fake invoices from shell companies or hijacked business registrations, then sell them to willing buyers. The buyers would use these invoices to claim VAT input deductions on transactions that never occurred, pocketing the difference. At scale, this created a parallel economy of paper-only transactions that siphoned tax revenue while funding organized crime.

The identity theft problem made enforcement nearly impossible through traditional means. A 2023 Israel State Comptroller report found that roughly 80% of fraudulent invoices were distributed through identity theft and straw men who had taken control of dormant companies. Criminals would acquire the registration details of legitimate but inactive businesses, issue invoices under those identities, and disappear before auditors could respond. By the time the Israel Tax Authority (ITA) flagged the fraud, the damage was done and the trail had gone cold.

This is the core insight that shaped the system's design: post-hoc enforcement does not work against fictitious invoice prevention at scale. Auditing invoices after they have been filed, deducted, and refunded means the government is always reacting to fraud that has already succeeded. The allocation number system flips this dynamic by requiring pre-clearance. Every invoice above the threshold must receive a unique allocation number from the ITA before it carries any tax deduction value. If the supplier's profile triggers risk indicators, the ITA can deny the allocation number entirely, blocking the fraudulent invoice before it ever enters the buyer's accounting system.

The results have been striking. Since the system reached full implementation, the Tax Authority has blocked fictitious invoices worth an estimated NIS 25 billion in tax fraud, halting approximately NIS 1 billion in fraudulent VAT monthly and blocking around 1,000 suspicious invoices per week. These are not projected savings from a policy paper. They represent actual fraudulent transactions that the real-time clearance mechanism identified and stopped.

The legislative framework was strengthened in parallel. Amendment No. 280 to the Income Tax Ordinance, effective August 2025, tied expense deductibility directly to invoice authenticity. Under these rules, a business that claims a tax deduction based on an invoice lacking a valid allocation number faces denial of the deduction itself, not just penalties. This creates a direct financial incentive for buyers to verify allocation numbers on every qualifying invoice they receive, effectively turning the entire business community into a first line of defense against fictitious invoices.

Alongside Amendment No. 280, new company ownership reporting requirements target the identity theft pipeline by requiring more transparent disclosure of who actually controls a business entity, making it harder to operate through straw men and hijacked registrations.

The system's demonstrated effectiveness during the pilot phase had a direct impact on the rollout schedule. The original implementation timeline targeted 2028 for full completion across all invoice thresholds. When early data confirmed that real-time clearance was catching fraud at the volumes described above, the government accelerated the timeline to June 2026. For finance teams planning their compliance roadmap, this acceleration signals that the system is not experimental or provisional. It is a permanent fixture of Israel's tax infrastructure, backed by measurable results that make rollback politically untenable.

---

How the CTC Clearance Process Works

Israel's allocation number system follows a Continuous Transaction Controls (CTC) model, meaning the Israel Tax Authority (ITA) inserts itself directly into the invoicing flow between supplier and buyer. Unlike post-audit systems where tax authorities review transactions after the fact, CTC clearance happens in real time, before the invoice reaches the buyer.

Here is what the process looks like in practice:

Step 1: The supplier creates the invoice. The supplier generates an invoice in their ERP or accounting system as they normally would.

Step 2: Invoice data is submitted to the ITA. Before the invoice can be sent to the buyer, the supplier (or their system) transmits the invoice data to the ITA through the SHAAM platform, which is the ITA's online tax services portal. This submission must use a structured JSON format, though the invoice itself can exist in any format internally.

Step 3: The ITA validates the supplier and transaction. The ITA runs real-time checks against the supplier's tax standing, registration status, and transaction details. This is the enforcement layer that makes the system effective against fraud.

Step 4: A 9-digit allocation number is issued. If validation passes, the ITA returns a unique mispar haktzaa (allocation number), a 9-digit identifier tied to that specific transaction. This number serves as proof that the ITA has reviewed and approved the invoice.

Step 5: The allocation number is added to the invoice. The supplier must embed the allocation number on the invoice before delivering it.

Step 6: The invoice is sent to the buyer. Only now does the invoice reach the buyer's accounts payable system, carrying the ITA's allocation number as a mark of legitimacy.

The critical point for compliance planning: the invoice cannot legitimately reach the buyer without passing through the ITA first. This is what distinguishes Israel's CTC clearance model from reporting-only regimes where invoices flow freely and tax data is reported separately.

When the ITA Denies an Allocation Number

The ITA can refuse to issue an allocation number in real time. If a supplier is flagged as suspicious, has outstanding tax compliance issues, or if the transaction triggers fraud indicators, the Israel Tax Authority invoice clearance process blocks that invoice entirely. No allocation number means no valid tax invoice, which means the buyer cannot claim an input VAT deduction on that transaction.

This denial mechanism is the system's sharpest tool against fictitious invoice schemes. Fraudulent suppliers are stopped before their invoices enter any buyer's accounting system, rather than being caught months or years later during an audit.

One operational question finance teams should plan for: SHAAM processing delays. The ITA has not published a formal SLA or fallback procedure for system unavailability, which means businesses should build clearance response times into their invoicing timelines rather than assuming instantaneous turnaround. For most transactions, allocation numbers are issued within seconds, but suppliers should avoid leaving clearance requests to the last moment before delivery deadlines.

Document Types Subject to Allocation Numbers

Three document types fall under the allocation number requirement:

• Heshbonit Mas (tax invoice) is the primary document type. Any B2B tax invoice above the applicable threshold must carry an allocation number.
• Heshbonit Zikui (credit invoice) is used for corrections and refunds. Credit invoices must reference the allocation number of the original tax invoice they are correcting, creating a traceable chain back to the approved transaction.
• Heshbonit Mas Sochen (agent tax invoice) was added in version 2.0 of the technical specifications. This covers invoices issued by agents acting on behalf of principals, a common arrangement in certain Israeli industries.

What Is Not Covered

The mandate currently applies only to B2B transactions above the threshold amount. B2C transactions (sales to consumers) and B2G transactions (sales to government entities) are excluded from the allocation number requirement. This reflects where fictitious invoice fraud is concentrated: criminal networks exploited B2B VAT deductions, not consumer sales or government procurement. Whether the scope will eventually extend to B2C or B2G has not been announced.

A Common Point of Confusion: Format vs. Clearance

One detail that trips up many finance teams: the allocation number requirement does not mandate a specific invoice delivery format between trading partners. You can still exchange invoices on paper, as PDFs, or through EDI. The structured JSON format is required only for the submission to the ITA through SHAAM. What matters is that the allocation number issued by the ITA appears on whatever version of the invoice ultimately reaches the buyer, regardless of format.

Implementation Timeline and Threshold Amounts

Israel's electronic invoicing mandate follows a phased rollout that progressively lowers the invoice amount threshold, bringing more transactions into scope with each step. The original timeline targeted 2028 for full implementation, but strong results during the pilot phase prompted the Israel Tax Authority to accelerate completion by two full years.

Here is the complete schedule:

Phase	Threshold (per invoice)	Effective Date	Status
Pilot launch	NIS 25,000	May 2024	Completed
Phase 2	NIS 20,000	January 2025	Completed
Phase 3	NIS 10,000	January 2026	Active
Final phase	NIS 5,000	June 2026	Upcoming

As of early 2026, the NIS 10,000 threshold is in effect, meaning any invoice at or above that amount requires an allocation number from the SHAAM system before it can serve as a valid tax document. The final reduction to NIS 5,000 arrives in June 2026, completing Israel's e-invoicing rollout well ahead of the original 2028 target.

The threshold applies to the individual invoice amount, not annual turnover. This distinction matters. A supplier does not need to exceed a revenue ceiling to fall within scope. A single invoice that meets the threshold triggers the allocation number requirement, regardless of the issuing business's size or total billing volume.

The practical impact of each threshold reduction is straightforward: more businesses and more transactions come into scope. Consider a company whose invoices typically fall in the NIS 12,000 to NIS 18,000 range. During the pilot phase with a NIS 25,000 threshold, none of those invoices required allocation numbers. Under the current NIS 10,000 threshold, every one of them now requires clearance. When the threshold drops to NIS 5,000 in June 2026, even relatively small B2B transactions will need allocation numbers before they carry legal validity for VAT purposes.

Finance teams planning for the June 2026 deadline should audit their invoice volumes against the NIS 5,000 mark now. The acceleration of Israel's e-invoicing mandate from 2028 to 2026 leaves less runway than many organizations originally anticipated.

---

Technical Requirements: JSON Format and SHAAM Integration

Businesses submitting invoices for allocation numbers must transmit structured data to the Israel Tax Authority's SHAAM platform through one of two channels: a direct API integration or the ITA's web portal. Both channels accept invoice data in JSON format, a notable departure from the XML-based standards (UBL, CII, Peppol BIS) dominant in European e-invoicing mandates.

The JSON submission model is deliberately streamlined. The ITA requires summary-level invoice data only, not line-item detail. A typical submission includes the supplier and buyer tax identification numbers, invoice date, invoice number, total amount before VAT, VAT amount, and total amount including VAT. This is a significantly simpler data model than many EU CTC systems, which often mandate full line-item breakdowns with product codes, quantities, and unit prices. For finance teams evaluating integration complexity, this distinction matters: the SHAAM integration is lighter than what a Peppol or Italian SDI connection demands.

One mandatory field deserves specific attention: the Accounting Software Number. Every JSON submission must include this identifier, which registers the specific software system that generated the invoice. The ITA uses this field to trace invoices back to their originating platform, adding another layer to the anti-fraud architecture. Businesses should confirm with their ERP or accounting software vendor that their product carries a registered Accounting Software Number before attempting submissions.

Version 2.0 of the technical specifications, released in late 2024, expanded the data model with new fields and document types. Among the additions is the Agent Tax Invoice (Heshbonit Mas Sochen), which covers transactions where an agent issues invoices on behalf of a principal. Organizations that integrated with an earlier version of the spec should review the v2.0 documentation for required schema changes, particularly if they handle agent-based billing arrangements.

For high-volume businesses, API integration between ERP systems and the SHAAM platform is the only practical path. The web portal works for occasional manual submissions, but any organization issuing more than a handful of invoices per day will find manual entry unsustainable and error-prone. Most major Israeli accounting software providers have built native SHAAM integrations; international ERP platforms may require middleware or custom development to connect.

As noted in the clearance process section, the JSON submission goes to the ITA for clearance, but the invoice delivered to the buyer can arrive in any format the trading partners already use. The SHAAM integration requirement applies only to the tax authority submission channel.

---

Israel vs EU E-Invoicing: Key Differences

Finance teams managing compliance across multiple jurisdictions need a clear mental model for how Israel's system compares to the EU frameworks they already know. The differences are structural, not just cosmetic. Israel and the major EU mandates diverge on clearance model, data format, document scope, data granularity, and enforcement mechanism.

The closest European parallel to Israel's system is Italy's FatturaPA e-invoicing system. Both are continuous transaction controls (CTC) pre-clearance models, meaning the tax authority sits directly in the invoice flow and must approve the document before it reaches the buyer. Italy's SDI (Sistema di Interscambio) issues a receipt number that functions similarly to Israel's allocation number: without it, the invoice is not considered fiscally valid. The critical difference is format. Italy mandates FatturaPA XML, while Israel requires JSON payloads submitted to the SHAAM system.

France's upcoming e-invoicing mandate represents a fundamentally different architecture. France is implementing a post-audit model with e-reporting. Transaction data flows to the tax authority, but the DGFiP does not insert itself into the invoice delivery chain. Suppliers send invoices to buyers through certified platforms, and transaction summaries are reported separately. There is no pre-clearance step and no allocation number equivalent that gates VAT deduction eligibility. Germany's XRechnung, meanwhile, is narrower still: a format standard for B2G invoices rather than a comprehensive CTC mandate.

The network infrastructure also diverges sharply. EU member states are converging on the Peppol network for cross-border e-invoicing interoperability, with several countries adopting Peppol as their domestic framework as well. Israel operates an entirely independent national system through SHAAM, with no current Peppol integration or interoperability pathway. Companies trading with Israeli counterparts cannot route invoices through their existing Peppol infrastructure.

Dimension	Israel	Italy (SDI)	France (2026 mandate)	Germany (XRechnung)
Clearance model	CTC pre-clearance	CTC pre-clearance	Post-audit e-reporting	No CTC (format standard)
Data format	JSON via SHAAM API	FatturaPA XML	Factur-X / UBL via PDP	XRechnung (UBL/CII)
Document scope	B2B (above threshold)	B2B + B2C + B2G	B2B + B2G (phased B2C)	B2G only
Data granularity	Summary-level totals	Full line-item detail	Full line-item detail	Full line-item detail
Enforcement mechanism	Allocation number required for VAT deduction	SDI receipt required for fiscal validity	Penalties for non-compliance	Rejection of non-compliant B2G invoices
Network	SHAAM (national, independent)	SDI (national)	Peppol + certified PDPs	Peppol

Two distinctions in that table deserve emphasis. First, Israel's summary-level data requirement is notably lighter than the line-item detail demanded by EU systems. The SHAAM system validates invoice totals and tax amounts rather than individual line items, which simplifies the data preparation burden but also means the tax authority is performing a different kind of validation. Second, Israel's enforcement mechanism is uniquely binary: no allocation number means the buyer cannot claim the VAT deduction at all. EU penalties for e-invoicing non-compliance are typically financial fines or invoice rejection, not a direct block on input tax recovery.

---

Managing Israeli Invoice Allocation Numbers in Your AP Workflow

For AP departments receiving invoices from Israeli suppliers, the allocation number system creates a direct financial stake in validation. The core rule is straightforward: if an invoice exceeds the current threshold amount and lacks a valid allocation number, the buyer cannot deduct input VAT on that transaction. That lost deduction hits your bottom line directly, making allocation number verification a non-negotiable step in your accounts payable process.

Every incoming Israeli invoice above the threshold should pass through three validation checks before approval:

1. Determine whether the invoice amount exceeds the current threshold. Compare the total (inclusive of VAT) against the threshold in effect at the invoice date. As of early 2026, the active threshold is NIS 10,000, dropping to NIS 5,000 from June 2026. Invoices below the applicable threshold do not require an allocation number and can proceed through your standard workflow.

2. Verify a 9-digit allocation number is present. The allocation number should appear on the invoice document itself, typically near the invoice header or alongside tax details. A missing or incomplete number on an above-threshold invoice is grounds for rejection.

3. Confirm the allocation number corresponds to the supplier and invoice details. The number is tied to the specific transaction cleared through the Israel Tax Authority. A valid-looking number that does not match the supplier's tax ID, invoice amount, or date may indicate an error or a fraudulent document.

The declining thresholds deserve particular attention from AP teams. An invoice for NIS 7,000 processed before June 2026 sits below the current NIS 10,000 threshold and requires no allocation number. That same amount invoiced after June 2026 will exceed the new NIS 5,000 threshold and require one. Update your validation rules and approval workflows each time the threshold changes, or you risk approving non-compliant invoices that appeared compliant under the previous threshold.

When a supplier sends an invoice above the threshold without a valid allocation number, do not process payment against it. Request a corrected invoice that includes the allocation number before approving the transaction. Most Israeli suppliers operating above the threshold are already integrated with the ITA's clearance system and can reissue quickly. Consider adding a dedicated allocation number field to your AP system's Israeli invoice template so that above-threshold invoices missing the number are flagged automatically before they enter your approval queue.

The VAT deduction denial is the primary enforcement mechanism, and it is severe enough to warrant attention on its own. Rather than relying on separate penalty schedules, Israel's system creates a financial incentive structure where every buyer has a direct stake in verifying allocation numbers on incoming invoices.

The allocation number requirement does not exist in isolation. Businesses processing Israeli invoices must also account for Israel's withholding tax requirements for vendor invoices, which operate independently. A single invoice may require both an allocation number for VAT purposes and correct withholding tax treatment. AP teams should build both checks into their Israeli invoice processing workflow rather than treating them as separate compliance tracks.

For organizations receiving invoices from multiple Israeli suppliers in varying formats, the manual verification burden adds up quickly. Hebrew right-to-left documents arrive alongside English-language invoices, some above threshold with allocation numbers that need verification, others below it. Sorting, validating, and extracting the relevant fields from each document individually is where compliance breaks down at volume. Tools built for multi-language invoice processing can extract and validate invoice data from Israeli suppliers at scale, pulling the allocation number alongside vendor details, amounts, dates, and tax breakdowns in a single pass, regardless of document language or format.