Form 856: Producing It From Your Own Payment Data Instead of by Hand

Form 856 is Israel's annual report of tax withheld from payments to suppliers and service providers, filed online with the Tax Authority. Nothing in it is new data - it is a yearly aggregation of payment transactions you already hold, grouped per supplier and per identifier. The manual work almost always comes from identifiers that are not clean.

Where the numbers come from

The report summarises, per supplier, the amounts paid during the tax year and the tax withheld from them. In an average system that information sits in three different places, which is exactly why producing it hurts:

That last row is why supplier verification and 856 output are really the same project. If validity dates were never stored as fields, there is no way to explain retroactively why 5% was withheld in February and 0% in May. The groundwork for that is covered in automated supplier verification.

What the production process looks like when it is automated

1. Extract. Pull every payment transaction in the tax year with supplier identifier, value date, gross amount and amount withheld.
2. Normalise identifiers. Strip whitespace, cast to string, preserve leading zeros, and collapse duplicate supplier records onto one canonical identifier.
3. Aggregate. Sum by supplier identifier - not by name, not by record.
4. Reconcile. Compare aggregated withholding against the periodic filings transmitted during the year.
5. Exceptions report. Produce a list of everything that does not tie out, before generating any output.
6. Generate. Only once the exceptions list is empty or explicitly approved.

Step five is the one that decides whether this was worth building. A system that produces an 856 without an exceptions report has not saved work; it has moved the checking onto the accountant.

How do you handle a supplier with two records?

Collapse them onto one canonical identifier before aggregating, never after. Duplicate suppliers appear for three recurring reasons:

• Entered once with a hyphen in the number and once without.
• A new record opened when the supplier changed trading name.
• The same entity exists both as a supplier and as a one-off service provider on another record.

The fix is not deletion. Mark one record primary, point the others at it, and route every aggregation query through the primary identifier. Deleting a record breaks payment history and leaves orphan transactions that will not appear in the report at all.

What do you check before filing?

Five reconciliations catch nearly every error:

• Total withholding against periodic filings. If the annual figure does not tie to what was reported and paid during the year, there is a gap that needs explaining.
• Payments with no supplier identifier. Any transaction without a valid identifier is a line that will not appear in the report.
• A withheld rate that appears on no certificate. Signals a hand-typed rate or an expired certificate.
• Negative amounts. Credits and refunds recorded as negative payments distort the aggregate.
• Year-boundary transactions. A payment with a value date of 31 December and a posting date in January needs one consistent rule, applied the same way every year.

How does 856 relate to the 806 certificate the supplier receives?

They are two sides of the same fact. The 806 certificate is the annual confirmation you give the supplier of tax withheld from payments to them; Form 856 is the filing you submit to the Tax Authority covering those same deductions. If a supplier holds a certificate for one figure and the report carries another, the gap surfaces - because it is visible from both directions.

That is why both documents should be produced from the same aggregation query, in the same run. Generating them separately, weeks apart, is the reliable way to create a mismatch nobody can explain six months later.

What happens when a supplier changed legal entity mid-year

This is the case that breaks the most automated productions, because it looks like one supplier and behaves like two. A sole trader that incorporates receives a new company number, and payments before and after the change belong to two entirely separate entities - even though they came from the same contact and went to the same bank account.

• Payments before the change aggregate under the old identifier and payments after it under the new one. Merging them produces a wrong line.
• One withholding certificate does not cover both entities, and if somebody swapped the number on the record by hand, the validity dates did not travel with it.
• Where the entity number was "updated" in place instead of opening a new record, the entire history silently moved to the new identifier, and the output will look clean while being wrong.

The design rule is simple: a legal entity identifier is a field you never edit. An entity change opens a new record linked to the previous one, and the aggregation query respects the date the change took effect. The same problem, with the roles reversed, is covered in automated supplier verification.

What to keep so next year is easier

• A snapshot of the data the report was produced from, not only the output.
• Historical validity dates and withholding rates, stored as fields with a date range.
• The duplicate-to-primary identifier mapping, stored rather than recomputed each year.
• The exceptions report as it stood at production time, including what was manually approved and by whom.
• The version of the rules used, so a re-run gives the same result.

Related: checking a withholding certificate before paying a supplier, automating payment-to-invoice matching, Masav supplier payment files.

Sources

• Filing - transmitting 126 and 856 reports, Israel Tax Authority
• Filing confirmation system (126/856), Israel Tax Authority
• Annual withholding certificate (Form 806), Israel Tax Authority