What Israeli Tax Compliance Actually Asks of Your Software

Ask a vendor whether their system is compliant with Israeli tax requirements and you will not get a “no”. It is not a lie, exactly. It usually means the data is in there somewhere and a competent bookkeeper can assemble what the authorities want.

The more useful question is narrower: which obligations does the software produce, and which ones still end with a person copying figures into a government form? Here is what that list actually contains, and why some of it is harder than it looks.

The monthly VAT return is a file, not a form

The PCN874 return is a structured file, generated for a specific year and month, in which every transaction has been classified into the right category — domestic sales, exports, inputs, transactions with a special status. It is submitted as that file.

Which means the real work happens long before month end. Classification has to be decided when each document is created, not reconstructed afterwards by someone looking at a list of invoices and remembering what they were for. A system that stores VAT as a single amount rather than as a coded treatment can produce a total that reconciles perfectly and a return that is wrong in its detail.

You cannot classify a year of transactions in the last week of the month. Either it happened at the point of entry or it is being guessed.

Fixed-width formats punish you quietly

This deserves its own warning because it catches everyone once. Statutory files are position-based: each field occupies an exact number of characters. Put a value in that is one character too long and it is truncated — not rejected, not flagged, truncated. What comes out is a well-formed file containing an identifier that matches nothing.

The same is true of dates written in the wrong order and of amounts whose sign convention is inverted. All of these produce a file that opens cleanly. You discover the problem when somebody asks why a figure does not reconcile, usually several months later.

Withholding runs in two directions

Withholding tax is the obligation people most often underestimate, because there are two of them and they behave differently.

Tax withheld from your suppliers makes you a collector: you pay them less, you owe the difference to the authority, and you must be able to state the period total. Tax withheld by your customers makes you the subject: you received less than you invoiced, and that difference is an advance against your own liability that has to be offset rather than written off as a shortfall.

Both feed the monthly Form 102 return, alongside national insurance from payroll. If your payroll and your ledger are separate systems, that return is assembled by hand every month — which is one of the clearer arguments for them not being separate systems.

Allocation numbers changed the architecture

This is the requirement that most changed what accounting software has to be. Above a threshold, a tax invoice needs a number allocated by the Tax Authority before it is valid — requested over an API, at the moment of issuing.

Every other obligation on this list is a report produced after the fact, and a report can be re-run. This one sits in the middle of a business process and depends on somebody else’s service answering. That forces three design decisions that a monthly report never does:

• An applicability rule. Not every document needs one, and deciding at issuance whether this one does has to be automatic — if it depends on the user remembering the current threshold, it will be wrong.
• A retry queue. The API will be unavailable at some point. Failing the invoice is unacceptable; pretending it succeeded is worse. The request has to be able to be outstanding, and to be retried without a person watching it.
• A rule for what “not yet allocated” means. Can the document be printed, sent, or posted while the number is pending? Somebody has to answer that, and the answer belongs in the system rather than in each user’s judgement.

If you are evaluating software, this is a good area to probe. “Yes, we support allocation numbers” and “yes, and here is what happens when the API is down at 4pm on the last day of the month” are different answers.

The uniform file structure, and why it matters twice

The uniform file structure — an INI file plus a data file, made up of typed records for the business, its documents, its lines and its ledger — is what an auditor can ask for. It is also, less obviously, the most valuable thing about a system you are leaving.

Because it is a defined format, your previous system’s uniform file is a complete, structured history of your business: documents, customers, suppliers, journal entries, all in a shape another system can read. Migration is usually the ugliest part of changing accounting software, and this is the one case where the industry has already agreed on an interchange format. A system that can read one can bring your history with you rather than starting you at zero with a spreadsheet of opening balances.

It also explains a rule that seems pedantic until you see the file: document numbering must be gapless. A number issued and then abandoned leaves a hole with no document to account for it, and that hole is visible to anyone reading the file. Which is why numbers should be assigned when a document is issued, not when somebody opens a draft they might close again.

Rates have dates, and history must not move

The last one is short but load-bearing. VAT rates change. When they do, every document already issued must keep the rate that applied on its own date — not the current rate, and not the rate in force when you happen to re-run the report.

That means a rate cannot be a setting. It has to be a dated record, so that reprinting last year’s invoice or regenerating an old return produces what it produced the first time. A system that stores “the VAT rate” as a single number will quietly rewrite its own history the day that number changes.

Where Capitán fits

Capitán’s financial accounting produces the files rather than the raw material for them. The PCN874 VAT return and the Form 102 withholding and national insurance return are both generated for a given year and month from the classified transactions themselves. Withholding is tracked in both directions, with period totals and the advance offset handled as an offset rather than a loss.

Allocation numbers are requested from the Tax Authority with an applicability rule that decides per document, and outstanding requests are retried on a schedule instead of waiting for someone to notice. Documents are signed with a per-company certificate from a configured cutover date. VAT rates are dated records, so a document is always valued at the rate that applied to it.

Capitán also reads a uniform file — preview it, import it, clean up what the import found, and backfill the keys — which is how history comes across from a previous system. Note the direction: this is the migration path in, and it is a different thing from producing a file for an audit.

And because payroll lives in the same system, the national insurance and withholding figures on the monthly return come from the payroll runs that produced them rather than from a spreadsheet that reconciles to them. If you want a straight answer about a specific obligation, name it and ask us — “which of these do you generate, and which do we still do by hand” is a fair question and deserves a specific reply.

The short version

Compliance is not a checkbox, it is a list of files. Ask which ones the software generates, what happens when a fixed-width field overflows, what happens when the allocation API is down, and whether last year’s invoice still shows last year’s VAT rate. Those four answers tell you more than any feature list.