Checking a counterparty before a deal usually looks like this: the rep copies the tax ID out of the CRM, goes to a verification service, looks at the status and revenue, comes back, and retells the result in a comment. That works while deals are few and everyone remembers that checks are required. The weak spot is the human factor: a contract with a liquidated legal entity gets signed exactly when "there was no time to check". Let's break down how to move the check inside Bitrix24 (Alaio) — into a business process that starts by itself and never forgets.

What a tax ID can tell you without leaving the CRM

The Company requisites by tax ID robot takes a single tax ID and returns data from the state business registry: the official name (short and full), the legal entity's status — active or liquidated, the director, the primary activity code, the legal address, and the registration date. The Company revenue by tax ID robot adds the financial dimension: annual revenue from official financial statements, with the reporting year attached — and writes it straight into the system "Annual revenue" field of the company card, or any other field of your choice. Together this covers basic scoring: is the company alive, who signs for it, and what is the scale of its business.

Scenario 1: a check when a company is created

A process on company creation takes three steps. First, Find company by tax ID searches for that tax ID among existing cards — if the counterparty already exists, a new one isn't created and the database doesn't sprout duplicates (why duplicates spread and how to clean them up — in the breakdown of duplicates). Then Company requisites by tax ID fills the card with registry data: the name as it appears in the state business registry, the address, the director — instead of whatever the rep managed to type in. How registry data relates to the card's requisites block is covered in the article on requisites. The finishing touch — Company revenue by tax ID fills in the revenue, and "large/medium/small" segmentation starts working from the card's first day.

Scenario 2: a stop-check at the contract stage

The main safety net goes on the "Contract" stage: the process requests the legal entity's status, and a condition splits the branches. Status "active" — the deal moves on. A liquidation or bankruptcy status — the process halts the deal, assigns a task to the lawyer, and adds the department supervisor as an observer on the deal (how observers work — in a separate breakdown). An extra condition uses revenue: a contract worth more than the counterparty's annual revenue is a reason for a manual review, and the process will say so honestly. This check doesn't depend on how busy the rep is: it fires on every deal that reaches the stage.

Scenario 3: readable activity codes and refreshing the database

The code "62.01" in a card field tells the rep nothing. The OKVED 2: decode by code robot turns the code from the activity code classifier (OKVED) into the name of the business activity — "Computer software development" — and the process writes it into a text field next to it. For an accumulated database, the same thing is done in bulk: a "check and backfill" process is run over a list of companies with a bulk workflow launch — statuses, revenue, and decoded activity codes get refreshed across the whole database in a single pass, with no manual clicking through cards.

Frequently asked questions

Where does the data come from? From state business registries and official financial statements via data services; the source is configured on the application's side — the portal only talks to the robot. How often should you refresh? A sensible minimum is at card creation and at the contract stage; for an active database, add a scheduled run once a quarter. Does this replace a full due-diligence check? No: lawsuits, pledges, and sanctions lists are a separate depth; the robots cover the first line — status, signatory, scale, and database hygiene. What about individuals' data? The robots work with legal entities by the tax ID from the company card.

In summary

Counterparty checking in Bitrix24 is a process, not a rep's habit: duplicate control and auto-fill at card creation, a stop condition on the legal status at the contract stage, revenue and a readable activity code for segmentation. All four robots are in the Roboteka catalog, free to install from Bitrix24 Market. If the scenario you need isn't there, describe the task and we'll build the robot for free.