Withholding Tax Certificates: Checking a Supplier Automatically Before You Pay

The value you need before paying is the supplier's withholding rate in force on the payment date, together with the state of their bookkeeping certificate. The Israel Tax Authority publishes it three ways - a single online query, a file exchange through System 1000, and Mivzak for large organisations. The difference between them is volume, not content.

What you are actually checking before paying

Not "does this supplier have a certificate" as a yes-or-no question, but three separate values:

• The withholding rate in force for that supplier - a percentage or an exemption.
• The validity window of the certificate, because one that was valid when the invoice was approved can expire before the payment goes out.
• The bookkeeping certificate status, which is a separate value and arrives alongside the first.

That is also why a one-off check when the supplier record is created is not enough. This is a value with validity dates, so it has to live on the record with those dates rather than as a yes-or-no flag.

The three ways to get the value

According to software-vendor documentation, a System 1000 exchange returns two files: one of valid records carrying each supplier's withholding percentage and bookkeeping certificate, and one of failed records with an error description. The same sources state that since August 2019 the system is aimed at organisations with up to 3,000 suppliers. Verify the exact threshold and the enrolment rules against the Tax Authority service page, because they have changed.

Is there an API for checking a withholding certificate?

Not as a documented public interface any developer can consume. What exists is an on-screen query and file-exchange mechanisms. The design consequence: do not plan a synchronous call at the moment somebody clicks "pay". Plan a refresh cycle - a file sent and loaded on a fixed cadence - and a local check against the loaded data at payment time.

In practice that is also the better design. A gate that depends on an external service being up fails when it is down, whereas a check against a local value with a validity date keeps working and can say "this value is seven days old" instead of failing silently.

What to store on the supplier record

• The withholding rate as received, as a number rather than free text.
• The validity start date and the validity end date.
• The bookkeeping certificate status.
• The last update timestamp and its source - a System 1000 file, a manual query, or a document the supplier sent.
• The supplier identifier as sent in the file, so the response row can be matched back.

That last field is what prevents the most common failure in a repeat load: a response file that cannot be attributed to a supplier with certainty, because the identifier you sent and the identifier that came back are not the same field.

How this fits into the payment run

1. An invoice is approved and becomes a payment candidate.
2. Before the payment batch is built, the system checks for each supplier whether a value exists and is valid for the planned payment date.
3. A supplier with a valid value passes. A supplier with none, or with an expired one, is flagged for handling.
4. The batch is built with the rate in force at that moment, and the rate is stored on the transaction.
5. After execution, the rate and its source stay on the payment as a record.

Step four is what makes it auditable: not "what is this supplier's rate today" but "what was the rate when the payment went out". Downstream, the batch itself becomes a Masav file, and the full approval chain is described in from supplier invoice approval to a Masav file.

What happens when a certificate expires between approval and payment?

That is precisely the case the check exists for, and why it sits before the payment rather than at invoice intake. An invoice approved at the start of the month can be paid weeks later, and the validity date can pass in between.

A system holding validity dates can see this coming: it knows which certificates expire within thirty days and which suppliers are scheduled for payment inside that window. That list can be produced before it becomes a problem, in the same spirit as the other supplier checks described in automated supplier verification in Israel.

What comes up when you wire this into an existing system

The first collision is almost always an identifier. The file you send is built around the supplier's file number or identifier as the Authority knows it, while the purchasing system identifies a supplier by an internal key of its own. With no field joining the two, the response file arrives and cannot be loaded.

Three decisions to make before development starts, preferably in writing:

• Which field holds the identifier that gets sent, and who owns its accuracy.
• What happens to a row returned in the failed-records file - does it block the supplier for payment or only flag them.
• Who receives the list of certificates about to expire, and how often.

Without the third, the mechanism runs and nobody acts on it. That is the same point made in the pre-integration checklist: the question is not who writes the code, but who receives the alert.

The link to annual reporting

What was actually withheld from supplier payments across the year is the basis for annual withholding reporting. If the rate is stored on every payment transaction along with the source of the value, producing that is a query. If the rate was applied by hand and never stored, it is a document reconstruction exercise at year end. Building it from payment data is covered in producing form 856 from your payment data.

This is a technical description of data sources and process, not tax advice. The withholding obligations, rates and timing that apply to a specific payment are determined with your accountant and against the official source.

Sources

• Information on withholding tax and bookkeeping certificates - Israel Tax Authority
• Information on withholding rates and bookkeeping (System 1000) - Israel Tax Authority