Common PCN874 Import Errors and How to Prevent Them Before You Transmit

Most PCN874 rejections are not accounting mistakes but breaches of structural rules: a field that was not zero-padded, an identifier that is not nine valid digits, a date in the wrong format, or an amount sent with a minus instead of through the sign field. Every one of them is catchable in a pre-transmission check.

Where the intake actually fails

There are two completely different outcomes, and they are easy to confuse. In the first, the whole file is not accepted and a general message explains why. In the second, the file is accepted but the percentage of transactions accepted is below 100% - meaning some rows were quietly refused while the rest went through. The second is the dangerous one, because the screen shows that something succeeded.

In the transmission view you can drill into the transaction count and get a breakdown of the failed transactions, where each one carries a note explaining the nature of the error. That is the starting point for a fix, which is why it needs to be captured - not just the general message.

The field-level rule table

Why is "invalid dealer number" the most common error?

Because it is created somewhere entirely different from where it surfaces. The identifier comes from the customer or supplier master record, sometimes created years earlier by someone who had no idea the field would ever be reported. The three recurring cases:

• A number with fewer than nine digits stored without leading zeros, because the system stored it as a number rather than as text.
• A number with an invalid check digit - one mistyped keystroke that then flows through every document that follows.
• A customer who is not an Israeli dealer at all, entered into a field designed for an Israeli number.

The specification actually recommends that the software advise when there is a problem with the check digit while still allowing other values to be entered - a tourist, for example. In other words, the warning is meant to fire when the master record is created, not at month end. The same class of problem shows up on the payments side, described in bank account check digits and payment rejections.

Three categories that break a file that looks fine

Padding and data types. A system that stores identifiers and reference numbers in a numeric column will strip leading zeros the moment it writes them. The simple rule: every field that goes into the file is a fixed-length string, even when its content looks like a number.

Dates. The document date is eight characters in YYYYMMDD. Every conversion on the way out - a spreadsheet export, a regional encoding, a date column stored as free text in an old system - is a place where the format changes without anyone noticing.

Signs. This is the category that produces the silent gap. A row accepted with an inverted sign does not fail; it just moves the total. The specification's value table is explicit: sale to the customer plus, cancellation or credit to the customer minus, purchase from supplier plus, cancellation or credit from supplier minus, and a zero-value field takes plus.

How do you correct an invoice that has already been reported?

Not by editing it. The specification defines a two-step procedure: the incorrect invoice is cancelled - reported with an opposite sign, with all other details identical to what was reported - and then the invoice is reported again with the correct details. Both steps are required, and this applies both to a correction inside a current report and to one already submitted.

The implication for anyone building a system: you have to retain what was actually sent, not only what is correct today. Without a snapshot of the row as reported, you cannot construct the identical cancelling row.

Checks worth running before transmission

1. Compare the sales and input record counts in the header against the real counts in the transaction set.
2. Validate the check digit on every counterparty identifier, with a list of approved exceptions.
3. Verify every date field is exactly eight digits and falls inside the reported month.
4. Confirm no amount field carries a negative value.
5. Compare the header totals to your internal report for the same period.
6. Keep a copy of the file that was transmitted, alongside the response output.

The first five run in seconds and prevent most rejections. The sixth is what lets you answer "what exactly did we send" two months later.

What to record when a file is refused

The exact wording of the message, the percentage of transactions accepted, the breakdown of failed transactions with their notes, the period, and the version of the system that generated it. Without the first four you cannot tell a structural error from a data error, and that is the difference between a fix in code and a fix on a customer record.

The structure of the file itself, from which these checks derive, is described in generating PCN874 automatically, and the wider reporting process in automating VAT reporting in Israel.

This is a technical description of a file structure and of validation rules, not tax advice. What an incorrect submission means and what action it requires should be established with your accountant and against the official source.

Sources

• PCN874 file structure - Appendices A, B and C, Israel Tax Authority
• Information for software houses and information-system producers - Israel Tax Authority