Automated Supplier Verification in Israel: Withholding Tax, Company Registry and Bank Details in One Check

Supplier verification in Israel is a repeating check against three separate sources before money leaves: the withholding-tax and bookkeeping certificate from the Tax Authority's certificate system, the entity's status in the Companies Registry, and the bank account the payment is routed to. Each goes stale on a different clock, so a one-time check at onboarding is worth very little.

What you are actually checking before money moves

The check is three genuinely different questions, and they are easy to conflate:

• How much tax to withhold. Determined by the withholding certificate that is valid for that supplier on the payment date, and the rate stated on it.
• Whether the entity is even active. A company whose registration status has changed, or that is flagged as in violation in the registry, is a commercial question before it is a technical one.
• Where the money goes. Bank, branch and account in the supplier's name. This is the field targeted by bank-detail substitution fraud, and the only one of the three with no public registry behind it.

The check belongs on the release of a payment, not on a manual task somebody remembers once a year.

Does the Israel Tax Authority publish an API for withholding certificates?

No public API specification is published for this service. The Tax Authority's online service is built for a manual query: you enter one identifier - a company number, VAT dealer number or ID number - and get back a withholding-tax and bookkeeping certificate as a document.

The design consequence is that you cannot build on a documented, guaranteed integration. Three approaches that do work in practice:

1. Anchor the process on the document. Store the certificate you received, together with its validity dates, as fields in the system - not as a file in somebody's mailbox.
2. Alert on the expiry date. The system marks a supplier unverified on the day validity lapses, not on the day somebody notices.
3. Block at release. A payment to a supplier without a valid certificate stops for approval instead of quietly going out at last year's rate.

If your supplier count makes manual work impossible, that is a question to take directly to the Tax Authority. There is no public technical answer you can build against.

The three sources and what each actually returns

The third row is the point. The first two can be checked against a third party; the third is verified only inside your own process - a callback to a known contact, an audit record of who changed the field and when, and a hold on the first payment after any bank-detail change.

Fitting the check into the payment run without stalling it

The pattern that works is a status on the supplier record, not a lookup fired at the moment somebody clicks "pay". The supplier record carries three fields: certificate expiry date, withholding rate, and the date bank details were last confirmed. A background process flags expiries, and the payment run screen shows them as an exceptions list before a payment file is built.

The practical result: no payment is delayed by a check, because the check already ran. The only things delayed are the suppliers that genuinely have something missing. The same principle drives the supplier invoice approval to Masav workflow, where the exceptions list is the deliverable and the file is just the output.

When do you re-check, rather than check once at onboarding?

The correct default is a check on every payment run, not on every supplier creation. Four events force a re-check even when no run is due:

• The stored certificate's validity date has passed.
• The supplier changed bank details, name or legal entity.
• Cumulative payments to that supplier this tax year crossed whatever threshold you set for a second look.
• The supplier told you their withholding rate changed - which is not a substitute for a certificate, only a reason to pull a fresh one.

What actually breaks

• Matching by name. Two suppliers with similar names, or one name spelled two ways, attach to the wrong certificate. Matching must be on the numeric identifier only.
• A scanned certificate saved with no date. The PDF sits in a folder and nobody knows when it lapsed.
• A supplier who is also a customer. Two records, two checks, and one certificate attached to only one of them.
• An entity change. A sole trader that incorporates gets a new company number, and the whole history stays attached to the old identifier.
• Leading zeros. Corporation and account numbers stored as numbers lose a digit the first time they pass through a spreadsheet.

That last one recurs in nearly every financial integration; it is covered at length in the context of bank account check digits and payment rejections.

What to have ready before building this

• A clean supplier list with one numeric identifier per legal entity and no duplicates.
• A decision on who owns the bank-details field and who may change it.
• Somewhere to store validity date and withholding rate as fields, not as free text.
• A defined behaviour when a supplier fails: a hard block, or a documented override.
• An audit log showing who approved an exception, when, and on what basis.

Related: checking a withholding certificate before paying a supplier, company registry checks for customer credit, producing Form 856 from payment data.

Sources

• Withholding tax and bookkeeping certificates - Israel Tax Authority
• Companies Registry dataset - data.gov.il (CKAN API)
• Corporation search - Corporations Authority, Ministry of Justice