Automating Detailed VAT Reporting in Israel: What Can Be Automated and What Cannot

The detailed VAT report - the file known as PCN874 - is a reconciliation between the invoices you issued and the invoices you received, filed online to the Tax Authority's systems. And that is exactly why it hurts: it exposes every gap that exists in your data.

First: what is not decided here

Who is required to file a detailed report, from what turnover, and at what frequency, is set by the Tax Authority and gets updated.

So the figures deliberately do not appear in this article. The threshold, the effective date and the reporting frequency that applies to you should be taken from two sources only:

• The Tax Authority's own publication - the "detailed VAT reporting" service page and the notices to businesses on gov.il.
• Your accountant or tax adviser, who knows what applies to your specific business.

A technical article is not a source for a reporting obligation. What does belong here is what happens once you know what is required - how to build it so it does not fall over.

Why this is harder than an export

People imagine an "export report" button. In practice it is a two-sided reconciliation, and therefore twice the difficulty:

The design consequence: if someone offers to automate your reporting, the first question is what they do with supplier invoices. If the answer is vague, they automated the easy half.

The easy side: what you issued

If invoices are issued in an invoicing system or an ERP, the data already exists in the right shape - number, date, amount, VAT, customer.

Two things that break even here:

• Invoices issued outside the system. A manual receipt, an invoice someone produced from their own spreadsheet. What never entered the system will not enter the report, and the gap surfaces in the reconciliation.
• The allocation number. An invoice that required an allocation number and did not receive one is a problem discovered late. If issuing depends on an external service, it needs a queue and retry - not a synchronous call that fails quietly.

The hard side: what you received

This is where most of the effort sits, and most projects underestimate it.

1. The invoices arrive as images

A supplier emails a PDF, sometimes a scan, sometimes a phone photo. You need to extract from them: the supplier's VAT ID, invoice number, date, amount and VAT.

Automatic extraction works - but a scanned PDF is not a text PDF, and character recognition in Hebrew degrades more than in English. A digit misread in an amount or a VAT ID does not stand out in the output.

The rule: every amount entering the report gets human approval before filing. Extraction is interpretation, and here the interpretation reaches a tax authority.

2. The VAT ID is the key - not the name

This is the most important technical point in the article.

Hebrew supplier names are dirty: a double space, the company suffix with and without an apostrophe, the same supplier in two spellings, invisible directional characters that arrived via copy-paste.

The result: the same supplier gets counted as three different suppliers, and the reconciliation breaks - not because of tax, because of strings.

What works: the VAT ID as the sole key. The supplier name is display, not an identifier. And normalise it once on entry to the system - not repaired at every filing.

3. An invoice that arrived after you filed

A situation every business knows and almost no system handles correctly: a supplier sends last month's invoice after you already filed.

The system has to know which period an invoice belongs to and what happens to a late one - and that is an accounting decision to take from your accountant, not from the code. What the code must do is not lose it silently.

The four engineering rules

1. A unique key per filing: period plus business. If the process runs twice it does not produce two reports. The same consistency required in any financial process.
2. Keep the file that was actually filed. Do not regenerate it when someone asks. The evidence of what was filed is the file, not the ability to reconstruct it.
3. Record every failure, not only successes. An invoice that did not go through because of a missing field has to appear on a list a person sees - not in a log file.
4. A reconciliation check before filing. Total VAT in the file against total VAT in the books. If there is a gap, stop. A one-second check that prevents a wrong filing.

There is an official API - and this is what it covers

Yes, one exists. The Tax Authority publishes a document titled "Tax Authority Open API" on its SHAAM connection service page, and the list of services offered through the API explicitly includes periodic reporting and payment of VAT.

Alongside it the same list carries:

• The Israel Invoices model - the allocation number services
• Reporting and payment of income tax advances
• Withholding tax certificates from tax coordination and retirement systems
• Transferring donation receipt data

So this is not "it might be possible" - it is a documented service with a developer portal, a sandbox and technical support.

Who can connect, and what that means for you

The service page defines three target audiences, and the distinction between them is the whole answer:

In one line: the API route is the software house route. An ordinary business wanting a file in and out gets that through the safes system or through its representative, not through an API.

And what if you are a developer building for your own business? There is an explicit procedure for granting permission to register a software house on behalf of the business owner or corporation - the business authorises the software house. What registration requires is not hidden: a software house connection procedure, a signed undertaking to use the API services, a data security appendix, and a digital application form.

This is a registration, not a sign-up. There are signatures and an information-security undertaking. Whether your specific case qualifies is decided by that procedure and by the Authority's service desk, not by an article.

How the connection actually works

The official document describes the process in full. In brief, so you know what is ahead:

1. Register the software house in the Authority's registration system, and receive confirmation by email.
2. Developer portal - create an Organization. Each organization requires its own registration request and its own admin, and developers are invited by link.
3. Create an app and receive a Client ID and Client Secret. The secret is not recoverable - only reproducible, so it is stored separately and securely.
4. Subscribe the app to the specific service. You cannot generate a token for a service you did not subscribe to.
5. Sandbox first, and only then a production Client ID, after confirmation.

And every API call requires two things together: a Client ID identifying the software house's application, and a valid token identifying the user authorised to act on behalf of the business.

Authentication is OAuth2 in two steps: an authorize call in the browser which returns an identification code in the URL, then a token request from the server using the Client ID and Secret. The response carries a Bearer access_token, an expires_in, and a refresh_token.

And the point that will break your production if you miss it: the refresh token is single-use. After using it a new one is issued, and it must be stored for next time. Whoever does not save the new one ends up back at user identification.

What this forces in the design

• The business-side permission has a limited duration. Someone in the business authorises digital operations, and that authorisation expires. Build a reminder before it does - otherwise reporting stops on the least convenient day.
• Authorise more than one employee. That is the Authority's own explicit recommendation in the document, and anyone who authorised a single person discovers what it means the day that person is on holiday.
• Treat a 401 as a normal path rather than a fault - an expired token is part of the flow.
• The secret is not recoverable. Losing it means reproducing it.
• Work in the sandbox first. There is no reason to discover problems against a live tax authority system.

One caveat, and it matters: the official API deck carries a date, and addresses and flow details change. Take the exact addresses, the service list and which token type each service requires from the developer portal and the documents on the Authority's site - not from an article, including this one. The Authority also runs a dedicated API support centre and a service desk for software houses.

What stays with a person

Even where automatic transmission is available to you, three things do not move into code:

• The decision on what gets reported - expense classification, what is recognised and what is not. A question for an accountant.
• The final approval before sending. Extraction from an invoice is interpretation, and here the interpretation reaches a tax authority.
• Handling exceptions - whatever the system flagged and could not decide.

Put precisely: the preparation automates fully; transmission depends on which access route is open to you; accountability for what is filed stays human. And the preparation is what takes days anyway.

What the automation genuinely gives

Worth being precise about the expectation:

• The report is ready on the first of the month rather than in the last week.
• Gaps are visible throughout the month rather than on filing day - and that is the real change. A missing supplier invoice found on the 3rd is a small problem; the same invoice on filing day is pressure.
• The double-checking disappears. Nobody keys amounts by hand twice.

What it does not give: certainty that the filing is correct. It produces an accurate report from the data it received - and an invoice that never entered the system will not appear.

Before starting

1. Establish what applies to you - from the Tax Authority and from your accountant. Not from an article.
2. Check what your invoicing system already does. Some systems already generate the file, and some also transmit it - worth checking before building.
3. Map where supplier invoices come from. That is the hard half, and it sets the budget.
4. Normalise VAT ID numbers before anything else.
5. Plan the exceptions - a late invoice, an unreadable amount, a new supplier.

And the question that precedes everything: do the systems you need to connect have an interface? Without that, the project is not a reporting project - it is a connection project.