Verifying a Corporate Customer Before Extending Credit: A Companies Registry Workflow

The Israeli Companies Registry is published as an open dataset on data.gov.il and can be queried by company number for corporation status, corporation type, a violation flag and the last annual report year filed. It answers whether the customer exists and in what registration state - not whether they can pay.

Why is this a different check from a supplier check?

Different questions, different data, different timing. A supplier check asks "how much tax to withhold and where to send the money", and it runs before money leaves you. This check asks "should I hand over goods or work before being paid", and it runs before money is meant to arrive.

The practical difference:

The other side of that equation is covered in automated supplier verification in Israel, and there is no point duplicating it here - the two checks run at different points in the process and on different data.

What the dataset actually holds

In the query we ran against the companies file, the fields returned per record include:

• Company number and company name, plus an English name where one exists.
• Corporation type - for example an Israeli private company or a foreign private company.
• Corporation status - among the values we saw: active, voluntarily liquidated, in voluntary liquidation, liquidated by merger, struck off.
• Sub-status - empty in most records, and in some carrying values such as an order to open proceedings or an expedited voluntary liquidation.
• Violation flag - empty, or carrying the violation value.
• Last annual report year filed - a number, or empty.
• Limitation - limited, unlimited, or unknown.
• Incorporation date, address and country.
• Parallel code fields for several of the textual fields, such as a status code and a violation code.

Note the field that does not exist: there is no financial data of any kind. No turnover, no balances, no payment history, no rating. Anyone expecting a number to compare against a credit limit will find it is not there.

How do you pull a single company from the dataset?

Access is through the CKAN API rather than the dataset's HTML page. Three things measured in practice:

1. Find the resource. A package_show call with the dataset identifier returns the resource list, including the companies CSV and its resource id.
2. Free-text search works. A datastore_search call with the q parameter and a company number returned 200 and a single record when the number exists, and a total of 0 when it does not.
3. Filtering on a Hebrew field name did not. A datastore_search call whose filters key was in Hebrew returned, in our test, the site's error page with a 404 status, while the same call with the _id key returned 200.

A datastore_search_sql call also returned 404. The design conclusion: plan around q and around filters with ASCII keys, not around an SQL query or a filter keyed on a Hebrew field name. General working practices against the portal are covered in the data.gov.il API guide and in the Israeli company registry dataset.

From a trigger to a process, not to a score

The common mistake is trying to derive a score. What the dataset genuinely supports is marking when to stop and look:

• A status other than active - any other value takes the customer off the automatic path.
• A non-empty sub-status - a field that filled in is by definition an event.
• The violation flag - present and binary, so a rule attaches to it cleanly.
• An old annual report year - the gap between the recorded year and the current one is a measurable registration indicator.
• A change between checks - the change matters more than the state. A customer who was active last quarter and is not now is the event worth reacting to.

The rule that holds up over time: the system flags, a person decides, and the decision is recorded with a date and a reason. Connecting that flag to the customer's actual debt position is covered in updating customer debt from a Masav return file.

What actually breaks

• Matching by name. Names in the dataset sometimes appear in a different spelling, without gershayim or with a run-together form of the limited-company suffix. Matching has to be on the company number.
• A customer that is not a company. A customer who is not an incorporated entity will not be in the dataset at all, and that is an absence of relevance rather than a negative finding.
• Leading zeros. Company numbers stored as numbers rather than strings lose a digit on their way through a spreadsheet and come back as not found.
• A static dataset. An open file refreshes on its own schedule, so the fetch date has to be stored alongside the result.
• An empty field is not a "no". An empty violation field is not a statement that the company is fine; it is the absence of a flag. That distinction matters when the rule is written.
• A record that vanished. A company found in a previous check and absent now is not necessarily a company that closed. The file may have been replaced, the query may have changed, or the number may be stored differently. Record that outcome as "not checked" rather than "does not exist", because the two conclusions lead to very different actions toward the customer.

What to have ready before building

• A customer list with a clean company number per legal entity, stored as a string.
• A decision on what triggers a check: a new customer, a request for terms, a limit breach, or a fixed cycle.
• Somewhere to store the check result with its fetch date, not only the conclusion.
• A defined approver for an exception, and where the reason is recorded.
• A rule for customers that are not incorporated entities, for whom the dataset is irrelevant from the start.

Sources

• Companies dataset - Companies Registrar, data.gov.il (CKAN API)
• Corporation search - Corporations Authority, Ministry of Justice