PCN874: Generating the Israeli Online VAT File Automatically From Your Own System

PCN874.TXT is a fixed-structure text file built from three layers: a single header record of type O, one transaction record per document, and a closing record of type X. Automating it means every field is derived from a query over your own data instead of being retyped at the end of the month.

The file in three layers

One header record. It opens with a one-character entry-type field holding the fixed value O. Then the licensed dealer number in nine characters, the reported month in six characters as YYYYMM, the report type, and the file generation date. The second half of the header is totals: total taxable sales excluding VAT, total VAT on taxable sales, total zero-value and exempt sales, total VAT on other inputs, total VAT on equipment inputs, and the VAT to pay or receive for the period. Each total has its own separate sign field.

Transaction records. One per document, holding: the entry-type letter, the nine-character VAT identification number of the other side - the customer on sales, the supplier on inputs - the document date as YYYYMMDD, a four-character reference group, a nine-character reference number, the VAT amount on the invoice, a sign field for credits, and the invoice total excluding VAT in ten characters. Both amount fields are always submitted as positive values; what makes it a charge or a credit is the sign field.

One closing record. Entry type X followed by the dealer number of whoever is submitting.

The entry-type code table

This is the field that decides which section of the report a document lands in, and it is the source of most mapping mistakes:

Where each field comes from in your own data

• The entry-type letter derives from the transaction type and the account card, not from the document type alone.
• The counterparty number comes from the customer or supplier master record, which is why reporting quality is decided by master-data quality.
• The reference number is taken as the first nine positions from the right, so a long internal numbering scheme is truncated predictably.
• The reference group attributes a document to a branch or series, and may be filled with zeros.
• The VAT amount is rounded to the nearest whole shekel.

For a mixed transaction carrying both a taxable component and an exempt or zero-rated one, the specification allows two treatments: count and summarise it as a taxable invoice, or report it twice - once at the normal rate and once at zero, with the same document type, customer, date and reference number. Either treatment has to be agreed with whoever maintains the books, because it changes what the report shows.

How do you turn this into a monthly process rather than a manual task?

1. Pull every document in the reported month, including cancellations and credits.
2. Classify each one to an entry-type letter using explicit mapping rules held as configuration, not in code.
3. Run an exceptions report - documents with no counterparty identifier, dates outside the month, empty references.
4. Compute the header totals and record counts from the very same collection of transactions that gets written to the file.
5. Write the file in the fixed structure with zero padding, and keep a timestamped copy.
6. Compare the header totals to your internal report before transmitting.

Step four is the whole thing. The header must be derived from the transactions, never computed separately. Compute it from a second query and any small difference in filtering produces a gap that looks exactly like a data error.

What has to reconcile between the header and the transactions?

The header declares the count of sales records and the count of input records, along with the accumulated totals. These are control values: they exist to be compared against what was actually accepted. So generation has to be one atomic operation - the transaction set is built once, and both the lines and the counters come out of it.

Special documents that break that assumption: on an export entry the counterparty field carries the export entry number, and for exported services or intangible goods it is 999999999. On a self invoice the supplier number goes into the counterparty field. On a petty-cash entry the reference field carries the number of invoices included in the record rather than a document number.

The wider monthly picture is covered in automating VAT reporting in Israel, and what happens when the file is refused is in common PCN874 import errors.

What stays manual even after automation

• Deciding how to classify an unusual document that no existing mapping rule covers.
• Signing off the totals with bookkeeping before transmission.
• Handling a correction to a month already reported.
• Tracking parameter changes, since the specification says explicitly that parameter values may change from time to time and are published in guidance.

Automation shortens the repetitive part. It does not replace judgement, and it is not supposed to.

This is a technical description of a file structure, not tax advice. The obligations that apply to a specific business, and the deadlines, must be checked against the official source and with whoever maintains the books.

Sources

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