Automatic counterparty verification by TIN in Bitrix24 via DaData

Counterparty verification by INN: where the manual process breaks

A manager receives details from the client and enters them into the system manually: INN, KPP, name, legal address. Then comes the tax service tab, search, copying into the card.

One reconciliation takes 5–10 minutes, and it is done exactly until the first rush: when there are five deals a day, manual reconciliation of details turns into a formality — "the client is ours, we've worked together for a long time."

It is at this step that an error appears in the counterparty card. A typo in the INN, an address from before the move, a name from an old contract instead of the current one in the EGRUL.

Several cards for one legal entity settle in the database, and client reporting counts them as different companies. There is no one to notice the discrepancy: in the manager's eyes, a checksum does not exist.

The cost surfaces later, when the contract has already been signed. A deal with an inactive entity is not only a denial of a tax deduction.

It is documents on behalf of a liquidated or blocked company, stalled deliveries, and a dispute where the lawyer must prove that counterparty verification by INN was a regular procedure, not a one-off gesture for a deal.

The manual process leaves no trace: who reconciled, when, what exactly they saw — there is nothing to reconstruct it from. Next, we break down how this is covered by INN verification directly in the card, before the deal goes into work.

What changes after implementation: speed and completeness of data

Automatic verification by INN changes not a single operation but the entire cycle of working with a partner: data enters the card at the moment it is created, not after correspondence with accounting and legal. Below are the effects that are visible during intake as early as a month after launch.

• Request processing time. Verification takes seconds: instead of manual search across registries and reconciliation of extracts, the operator immediately gets the result and passes the request further on the same day, not in two or three days.
• Share of manual operations. Name, address, director, OKVED, and record status are pulled from DaData; a person enters only the INN and the reason for the request — the rest is filled in without copying and retyping.
• Completeness of partner data. The card retains details, signs of unreliability, and links to other legal entities, so fields do not stay empty because someone did not have time to complete them.
• Reconciliation history. Each request is recorded in the card history with the date and the service response: you can see how the counterparty's status changed between deals, and this is confirmed by a record, not by an employee's memory.
• Eliminated class of failures. Companies in liquidation, with an inactive address, or with a disqualified director are filtered out before the contract is signed — reviewing such cases after the fact no longer takes up the team's time.

The result is verifiable: compare the average time per request and the number of manual edits in the card before and after implementation — the difference is noticeable within the first hundred requests.

Connection options: one-time request, batch, continuous monitoring

The three modes differ not in the service's capabilities but in the point of integration into your process: where exactly in the deal flow verification is launched and what happens next with its result.

You should choose based on two parameters — the volume of incoming counterparties and who makes the decision: a manager or a predefined rule.

The modes are not mutually exclusive: automatic reconciliation when a deal is created covers the entry point, continuous monitoring of changes works on the already established database, and batch processing is needed once — during migration or reconciliation. In practice, they are layered on top of one another.

The common limitation for all options is the quality of input data: an INN with a typo will not be found in any mode.

Therefore, we immediately build normalization of details and a queue for manual review into the scheme, otherwise false positives will teach managers to ignore verification.

Implementation procedure: from process review to handover of regulations

The work proceeds so that counterparty verification by INN fits into the existing loop rather than requiring company and deal cards to be rewritten. First, we record where counterparties are checked now and which details are entered manually. Each step ends with an artifact that can be verified and handed over to the internal team.

1. Process review — interviews with sales, procurement, and accounting, an audit of the company and deal card fields. The output is a map: where verification is needed and where it creates unnecessary actions.
2. Verification scheme — we define the trigger event: company creation, change of details, deal moving to a stage. We separately describe behavior when the external service is unavailable — the request is not blocked but flagged for manual review.
3. Access rules setup — who sees the verification result, who can rerun it manually, who has access to fields with risk flags. Rights are distributed by roles and departments.
4. Connection and test run — access key, field mapping, writing the result to the card, call logging. We run scenarios: valid INN, nonexistent INN, checksum error, repeat request, service unavailability.
5. Verification on real data — launch on the production portal and reconciliation with what employees get manually. We refine the rules if data on branches, liquidation, or name changes diverges.
6. Handover of regulations — instructions on working with results, description of fields and risk flags, procedure for a disputed result. Plus setup documentation so the team can change rules without us.

What remains with the client: settings, rules, documents

We close each counterparty verification by INN project with the handover of a set of artifacts — not access to the service's personal account, but settings, schemes, and regulations according to which the client's team works without us.

The set is assembled so that a new employee can understand the reconciliation rules in a day, and a disputed card can be reviewed using the log rather than the contractor's memory.

• Reconciliation rule configuration: which card fields are filled from the service response, under which flag a deal goes to manual review, what to do when the name and INN do not match.
• Data flow scheme: where the request is sent from, where the result is stored, which copies are transferred to external systems, and how retries are configured when the service is unavailable.
• Access rights: role matrix — who launches batch reconciliation, who sees history, who changes the rule itself, who is blocked from manually editing the counterparty card.
• Employee instructions: a two-to-three-screen memo — how to launch verification for one INN, how to read the result, in which cases to contact support.
• Results log: who checked the counterparty and when, what response came back, who made the decision on a disputed card and on what basis.
• Procedure for reviewing disputed cases: a regulation with escalation — who is responsible, within what time frame an answer is given, how the discrepancy is recorded, and what goes into the rule after review.
• Control points: which failures the automation catches — external service failures, empty responses, duplicate counterparties — and who receives the notification.

Case study: how the procurement department eliminated manual reconciliation

In the procurement department that came to us, four people handled about 60 requests per week, and each began with manual reconciliation: the INN was entered into the search on the tax website, details were transferred to the card, and the arbitration case file and unreliable information records were checked separately.

One request took from 25 to 40 minutes, the share of manual operations in the flow was 100%, and a discrepancy in one digit of the INN surfaced only at contract signing, when the payer did not match the counterparty.

What we changed

A deal in Bitrix24 was linked to the DaData service: based on the entered INN, the card is assembled automatically — name, address, director, type of activity, organization status, and risk flags.

The request is sent in the background, with retries: if the external service is unavailable, the request is not lost but returned for processing, so the procurement flow does not depend on someone else's availability.

We also added duplicate checking — a repeated INN is now highlighted at the moment a deal is created, rather than found during contract reconciliation.

What the result was

The processing time for one request decreased to 2–4 minutes: time goes to reading the risk card and making a decision, not to collecting data from three sources.

The share of manual operations fell to about 10% — only confirmation of disputed cases remains manual, when the counterparty has signs of unreliability or a recent change of director.

The department's throughput increased by about 8 times without expanding staff: requests stopped piling up by the end of the week, and rejections of unreliable suppliers became visible before signing, not after.

How does a one-time request differ from continuous monitoring?

A one-time request is verification initiated by a person: the operator opens the company card in Bitrix24, clicks a button, and gets a snapshot of details as of the current date.

The request goes to the verification service — for example, DaData — and the result is simply written into the card fields. Everything that happens to the counterparty afterward is no longer reflected in the deal: the address, director, and status remain as they were seen once.

Continuous monitoring works on a different trigger. Background scheduled jobs traverse the counterparty database, compare the checksum of details with the last saved snapshot, and on discrepancy create an activity or task for the responsible person.

Verification is launched not by a person but by a calendar or an event: a change in deal stage, contract signing, loading a new batch of counterparties.

The difference shows not in the accuracy of the response but in the moment of discrepancy. The one-time mode stays silent when a partner changes address or gets a new status — and this comes to light during document approval.

Continuous monitoring closes this gap but requires accounting for the verification service's limitations: without a queue, retries, and a reasonable traversal interval, requests hit limits.

In practice, the modes are not opposed. A one-time request is placed at the entrance to the funnel so as not to create an obviously problematic counterparty, while continuous monitoring is placed on active contracts.

Manual launch by button remains: an engineer can recheck an individual card without waiting for the scheduled traversal.

What is clarified before connection: addressing doubts

Before connecting INN verification, four things are clarified: where the data comes from, what happens when the source is unavailable, how this affects the load, and who provides support after launch. Below are short answers for each point.

What happens if the verification service is unavailable?

The call goes into a queue with retries and does not block saving the card. While there is no response, the field is marked as unfilled — verification can be rerun manually, including in batch across a list of deals. We save a partial response and leave the rest for retry.

How will this affect the load?

The request is executed by event — deal creation, INN change, scheduled reconciliation — not when the card is opened. Responses are kept in a local cache for a specified period, so repeated requests to the same counterparty do not create new calls.

Who gets access and how is it restricted?

We create a separate service user with minimal rights: reading details and writing to agreed fields. The access key is stored in protected settings, not in code or a template; all calls are logged.

What is included in support after launch?

We monitor errors and changes in field format and update mapping rules when your business processes change. The integration logic and settings are documented, so they can be handed over to the internal team.

Let's discuss the task: what is needed to start work

To make the scope estimate accurate and the stage plan workable, we need initial input from you. Describe the task in free form: what is already set up in Bitrix24, what counterparty directory you maintain, and what should happen after the INN is entered.

This is enough for us to come back with an estimate and sequence of work, without a long back-and-forth.

• How counterparties are checked now: manually in external services, via an export from 1C, or not checked at all.
• Where the data comes from: a deal, an invoice, a company card, a website request, or a feedback form.
• Which fields are needed in the end: name, status, address, director, risk flag.
• What to do on discrepancy: block saving, highlight the field, create a task for the responsible person.
• Who works with the result: managers, accounting, security service — and what rights they have.
• Whether there is an existing DaData access or a new one is needed, and who owns the account.
• Limitations: change log, data retention periods, requirements for duplicates in the directory.

Based on the review, we send a stage plan: setting up integration and the directory, rules for filling fields, handling errors and duplicates, a run on a copy of your database, and handover of instructions to the team.

The start order is simple: you approve the scope of work and the sequence of stages — we begin with verification rules and the directory, then connect scenarios in cards and requests, and finally fix the regulation for employees. Describe the task — we will come back with a scope estimate and plan.