Israeli VAT Allocation Numbers: What They Are and How VirtuAc Detects Them

If you process invoices for Israeli businesses, the VAT Allocation Number (Mispar Haktza’a) is one of the most consequential pieces of data on any high-value document. Miss it, and a legitimate tax deduction becomes disallowable. Include a wrong number, and your client faces scrutiny from the Israeli Tax Authority (Rashut HaMisim). Yet the allocation number is also one of the most frequently missed fields in automated invoice processing, precisely because it does not appear on every invoice and its position on the document varies.

This post explains what the allocation number is, when it is legally required, what it looks like, and how VirtuAc’s post-processing pipeline finds it reliably even when standard key-value extraction fails.

What Is the VAT Allocation Number?

The Mispar Haktza’a is a pre-transaction authorization number issued by the Israeli Tax Authority. Its purpose is to create an auditable link between a specific large transaction and the Tax Authority’s records, allowing the authority to verify that the supplier has properly declared the transaction and that the associated VAT has been accounted for.

The allocation number system was introduced as part of Israel’s effort to reduce VAT fraud in large commercial transactions. Before the system existed, a common fraud pattern involved creating fictitious invoices for large amounts and claiming the VAT credit without any corresponding real transaction. The allocation number requirement forces both parties to interact with the Tax Authority’s system before the transaction is recorded, making fictitious invoices much harder to construct plausibly.

From the accountant’s perspective, the allocation number is proof that the Tax Authority acknowledges this specific transaction. Without it, the VAT component of a qualifying invoice cannot be reclaimed as input tax credit, regardless of how genuine the underlying transaction is.

The Legal Requirement: When Is It Mandatory?

Under Israeli VAT regulations (specifically, the relevant provisions of the Value Added Tax Law and accompanying Tax Authority circulars), a VAT Allocation Number is required for any transaction where the VAT component alone exceeds ILS 25,000.

To put this in practical terms: a transaction with a gross value of approximately ILS 141,000 (at the standard 17% VAT rate) will have a VAT component of approximately ILS 20,500, which is below the threshold. A transaction with a gross value of approximately ILS 175,000 will have a VAT component of approximately ILS 25,500, which exceeds the threshold and therefore requires an allocation number.

The threshold applies to the VAT amount, not the total invoice amount. For transactions at the margin, it is worth calculating the VAT component precisely rather than estimating from the gross.

The requirement applies across all business sectors. There is no industry exemption. Real estate transactions, equipment purchases, professional services, and construction contracts are all subject to the same rule when the VAT threshold is exceeded.

The supplier is responsible for obtaining the allocation number from the Tax Authority before issuing the invoice. In practice, this is done through the Tax Authority’s online portal, which issues the number immediately upon request. The number must then be printed on the invoice. A supplier who issues an invoice for a qualifying transaction without an allocation number is in breach of their own obligations, but the accountant or business receiving the invoice also bears risk if they attempt to deduct VAT on a document that lacks the required number.

The Format of the Allocation Number

The allocation number consists of 16 digits arranged in four groups of four, separated by hyphens. The format is:

xxxx-xxxx-xxxx-xxxx

For example: 1234-5678-9012-3456.

The number is always exactly 16 digits. There are no letters, no spaces, and no variation in structure. This fixed format is useful for automated detection: a regex pattern can identify an allocation number unambiguously within any block of text.

The hyphens are part of the standard printed format. In some OCR contexts, the hyphens may be misread as spaces or omitted entirely, so robust detection must handle the patterns xxxxxxxxxxxx (16 digits with no separators) and xxxx xxxx xxxx xxxx (16 digits with spaces) in addition to the canonical hyphenated form.

Where the Allocation Number Appears on the Invoice

The Israeli Tax Authority specifies that the allocation number must appear on the invoice document, but it does not mandate a precise location. This means the position varies by supplier and by invoicing software.

Common positions include:

Top of the invoice, near the header. Many invoicing software systems reserve a prominent position near the invoice number and date for the allocation number, since it is metadata about the invoice itself rather than about a line item.

Bottom of the invoice, near the total. Some layouts group the allocation number with the VAT summary, treating it as part of the financial summary section.

In a dedicated field within the invoice table. Certain invoice templates include an explicit labelled field (such as “Mispar Haktza’a” or “Allocation No.”) that appears either above the line item table or below the totals row.

In a text note or footer. Smaller businesses sometimes include the allocation number as a line of text in the notes section of the invoice, without any explicit field label.

This variability is the core challenge for automated extraction.

The Challenge: Why Standard Key-Value Extraction Misses It

Standard key-value extraction models work by identifying pairs of labels and values in the document. For example, they recognize “Invoice Date:” as a label and the adjacent date string as its value. This works very well for fields that appear consistently in the same position with the same label across invoices from major Israeli invoicing platforms.

The allocation number field, however, frequently lacks a consistent label. Some invoices label it “Mispar Haktza’a,” others use “Mispar Hakatza’a” (alternate transliteration), others use “Allocation No.,” others use “Auth. No.,” and some print the number without any label at all, relying on the reader’s familiarity with the format to recognize it.

When the label is absent or non-standard, key-value extraction does not create a pair for the field. The number exists in the extracted text but is not associated with a field name. A system that relies solely on key-value pairs for structured data extraction will simply not include the allocation number in its output for these invoices.

VirtuAc’s Solution: Post-Processing Regex Scan

VirtuAc’s pipeline includes a post-processing stage that runs after the AI engine completes its key-value extraction. This stage performs a full-text scan of all extracted text, including text that was not associated with any key-value pair, using a regex pattern designed to match the allocation number format.

The pattern matches:

• The canonical format: four groups of four digits separated by hyphens (\d{4}-\d{4}-\d{4}-\d{4})
• The space-separated variant: four groups of four digits separated by spaces
• The unseparated variant: exactly 16 consecutive digits that are not adjacent to other digits (to avoid matching 16-digit sequences embedded in longer numbers)

When the pattern finds a match in the full-text content, VirtuAc checks whether the key-value extraction already captured an allocation number field. If it did, the two values are compared. If they match, confidence in the allocation number is high. If they differ, both candidates are flagged for human review. If key-value extraction produced no allocation number but the regex finds a match, the regex result is used as the extracted value with a confidence label of “Pattern match (unverified)” to indicate that it was not confirmed by key-value pair analysis.

This approach ensures that invoices with non-standard layouts are handled correctly rather than silently missing the allocation number.

Handling Cases Where the Number Is Missing

When an invoice’s VAT component exceeds ILS 25,000 and no allocation number can be found through either key-value extraction or the regex scan, VirtuAc places the record in a “Needs Review” queue and sends a notification to the assigned accountant.

The notification includes the invoice details (supplier, date, amount) and the specific reason for the flag: “High-value invoice: no allocation number detected.” The accountant’s options are:

Enter the number manually. If the allocation number is visible on the document image but was not detected (perhaps because the image quality degraded that region of the document), the accountant can open the invoice preview and type the allocation number into the field. VirtuAc validates the format before accepting the value.

Request the number from the supplier. If the allocation number is genuinely absent from the invoice, the accountant should contact the supplier and request it. The supplier can look up the number they received from the Tax Authority when they prepared the invoice.

Mark the VAT as non-deductible. If the allocation number cannot be obtained and the accountant determines that the VAT on this transaction is therefore not deductible, the record can be marked as such in VirtuAc. It will be exported to Hashavshevet or the relevant ERP with a flag indicating that the VAT component should not be claimed as input tax credit.

Records in the “Needs Review” state for allocation number reasons are tracked separately in the VirtuAc dashboard, giving firm managers a clear view of open compliance issues.

Links to Relevant Tax Authority Documentation

The Israeli Tax Authority publishes guidance on the allocation number requirement through its official portal at the govil.gov.il domain. The relevant section covers the VAT authorization system (“Mispar Haktza’a LeHishmonot Ma’am”) and includes the technical specification for the online authorization request system. Accountants who process large volumes of high-value invoices should familiarize themselves with this documentation, as the rules regarding the threshold, the timeline for obtaining authorization (before the invoice is issued, not retrospectively), and the consequences of non-compliance are specified there.

Why Domain-Specific Post-Processing Matters

Generic invoice processing platforms built for international markets do not include an allocation number detection pipeline because the concept does not exist in most tax systems. A platform designed for Australian, British, or American accounting workflows has no reason to implement it.

VirtuAc was designed specifically for the Israeli accounting market. Every processing rule in the pipeline reflects an Israeli tax or regulatory requirement: the 9-digit Osek Murshe format for VAT registration numbers, the specific Hashavshevet field structure for export, the Israeli date conventions, and the allocation number detection and flagging logic described in this post.

The result is a system that does not just extract text from invoices but understands what the extracted data means in the context of Israeli VAT law, and flags the situations where compliance obligations are at risk.

To see the allocation number detection in action on your own invoices, sign up for a free VirtuAc trial and upload a set of high-value supplier invoices. The extraction results will show you exactly what was detected, with what confidence, and which records require attention. Visit the features page for a full overview of the compliance-oriented processing features in the VirtuAc pipeline.