Bitrix24 and Kontur.Focus integration: automating counterparty verification

Why Bitrix24 integration with Kontur.Focus breaks on manual verification

A typical failure looks mundane: a manager opens a counterparty card, goes to a third-party service, manually searches for the company by name, copies the details, and transfers them into the deal fields.

One counterparty takes from fifteen minutes, and with a flow of several dozen checks per week, that is already a full working day crossed out of sales. Worse, the company data in the deal card remains a snapshot at the time of copying, not an up-to-date extract.

Manual counterparty verification accumulates errors during counterparty checks: a typo in the INN, an old name after re-registration, a missed record of liquidation or enforcement proceedings.

The error does not stay inside the system — it travels into the contract, invoice, and closing documents, and surfaces during reconciliation with accounting, when the deal is effectively closed.

The delay of a deal due to verification is structured the same way: approval does not start until the card has complete details, while accounting keeps its own database separately and reconciles manually.

The same company lives in several versions, no one knows which one is correct, and nowhere is it noted when the data was last reconciled.

Bitrix24 integration with Kontur.Focus closes exactly this gap: details are pulled by INN into the card fields, verification is launched from the deal or on a schedule, and the result and reconciliation date remain in the history.

Let's break down how this is closed and what breaks when trying to assemble verification "quickly and with scripts."

Automation effect: speed, data completeness, less manual work

Verification ceases to be a separate operation in someone else's window: counterparty data lives in the deal card and is updated on a schedule. Below is a checklist of what is visible in the first weeks after launching integration with Kontur.Focus. For each item, you can verify the fact rather than take it on faith.

• Verification time — minutes instead of half an hour of manual search. The manager no longer gathers information piece by piece: details, status, director, and risk indicators come to the card in a single response.
• Details in the card are filled automatically. By INN, the name, address, OGRN, and codes are pulled — manual input remains only for fields that are not in the registry.
• Some checks pass without human involvement. Typical cases close themselves; a specialist gets involved where a risk indicator has triggered or a discrepancy has been found.
• A class of rejections for inactive counterparties is gone. A deal does not go into work if the company is liquidated, undergoing bankruptcy, or has suspended activity.
• A single source of counterparty data. The question "what do we have on this company" is resolved in the card, not by searching through email, chats, and exports.
• Up-to-date company data is maintained by a regulation. Updates happen on a schedule and upon significant events, not at the moment when the contract has already been signed.

Compare the list with your process: where time is currently lost, how many fields are entered manually, which checks can be handed to the system without losing control.

Counterparty verification options: manual or automatic

The choice here is not between "we check" and "we don't check," but between who initiates the request to Kontur.Focus and what happens to the response next. This affects both the team's labor costs and how complete the data in the counterparty card will be.

In practice, there are three modes — from a manual-entry regulation to full data exchange. Each has honest limitations, and partial automation often turns out to be a workable compromise: it removes routine but does not require rebuilding the process entirely.

It is worth comparing the options by flow volume and by the point where verification sticks to the process: if it happens outside the card, half the result is lost.

That is why we usually start with partial automation and connect full exchange when the regulation and field mapping have already been worked out.

Implementation stages: from exchange schema to handover to support

The integration implementation stages are arranged sequentially: at each step it is visible what already works and what does not yet. This removes the main risk — when the exchange is configured but employees continue to enter data manually because the deal card has not changed.

1. Audit of the verification process. We break down at which step the manager requests counterparty data, which fields get into the card manually, and where information about related companies is lost. The outcome is a list of discrepancies between the current and target verification.
2. Design of the data exchange schema. We determine the matching key (usually INN), the composition of transferred fields, and the moment of the request — when a deal is created, a stage changes, or on a schedule. Separately, we describe what to do if there is no data or several matches are found.
3. Setup. We transfer the agreed schema into cards and entities and assign rights by roles. We immediately include a log of calls to the external service — it is later used to investigate disputed cases.
4. Testing the integration. We run a sample from the live database: large companies, recently registered ones, ones in liquidation, ones with a name change. We compare the data in the card with manual verification and analyze discrepancies.
5. Handling failures. We look at behavior when the service is unavailable, with a partial response, and with a repeated request for the same counterparty: data must not be duplicated or overwrite already verified data.
6. Training and handover to support. We show managers the new procedure in the deal card: where data comes from and when verification is still performed manually. Then we hand over the regulation, a description of fields and typical errors, accesses, and the monitoring procedure — further changes go through the regular support cycle, not one-off edits.

Handover of results: exchange settings, access rights, regulations

After launch, the customer's team retains not only working scenarios but also integration documentation — with it, the exchange can be handed over to another engineer or extended without us. We list exactly what we record and hand over at acceptance.

• Exchange configuration — schedule and call points, error handling, retries, and notifications: it indicates which parameter is responsible for what and where to change it.
• Field mapping — which source detail goes into which field of the company or contact card, how type discrepancies are handled, and how to add a new field without changing code.
• Access rights in Bitrix24 by roles — who can see the full verification conclusion, who sees only its status, who launches verification manually, and who sees the request history.
• Counterparty verification regulation — at which deal stage verification is mandatory, under which indicators a repeat one is launched, and who makes the decision on a disputed result.
• Instructions for managers — how to read the report: what each indicator means, what actions follow it, and in which cases the matter goes to approval.
• Failure investigation procedure — who is responsible for response, within what time the exchange is restored, and how partially loaded data is rolled back.
• Acceptance checklist — a set of checks by which the customer independently confirms that the exchange, accesses, and notifications work after each change.

Implementation example: counterparty verification directly in the deal

The customer is a wholesale trade company, five managers, about 40 new deals per month.

Counterparty verification lived separately from sales: the manager sent the INN to a lawyer, the lawyer exported a report from Kontur.Focus and transferred the conclusions into an email — one check took from 25 minutes, and with a heavy load it stretched to the next day.

Some deals started before the response, and along the way it turned out that the buyer had a record of unreliable information in EGRUL or a liquidation procedure had begun.

What was changed

The scenario was assembled in the deal card: on the creation event, a robot takes the INN from the company field, calls the external service, and parses the response — risk score, signs of bankruptcy and liquidation, enforcement proceedings, arbitration, mass address, unreliable information.

The parsed values are written to the card fields and the deal feed, so counterparty verification automation ceased to be a separate action for the manager.

Next — rules by risk threshold. At a medium score, a task is created for the lawyer, and the deal moves on; at critical indicators, the transition to the next stage is blocked until approval.

The request and response are logged, so the verification conclusion is reconstructed from the deal history.

Metrics before and after implementation: counterparty verification time — 15–20 seconds instead of 25–40 minutes, the share of deals without manual verification — about nine out of ten, and the lawyer gets involved only in disputed cases.

Over the quarter, not a single deal went into work with a counterparty showing signs of liquidation; previously two or three such deals would pass.

What to do if counterparty verification is already underway, but manually?

Partial automation is a normal state, not a sign of an unsuccessful implementation.

Some checks already run on a schedule — for example, for companies in the procurement funnel — while somewhere the manager enters counterparty data by hand: INN, status, director, signs of bankruptcy.

The problem is not that there is too little automation, but that the manual and automatic paths live in different fields and gradually diverge.

We break down which operations remain manual. Usually these are the initial filling of the company card, updating details before a deal, and verification before payment.

Each point can be closed separately: integration with Kontur.Focus by INN pulls data into the card and the related smart process, while the risk decision remains with the employee — automation prepares the inputs, the person confirms.

Phased implementation goes from one point to the others. First, verification is enabled in the most frequent scenario and for some time works in parallel with manual input: the employee acts as usual, but the results are compared.

When there are no discrepancies, the manual path is disabled for a specific scenario, not for the entire system at once.

A transition without stopping work rests on two rules: new data does not silently overwrite existing fields but is written next to a source and time mark; manual mode remains available as a rollback at any stage.

The department continues to verify counterparties, but with each connected scenario the share of manual operations falls.

To assemble such a plan for your processes, we need to see where manual entry of counterparty data currently happens and which statuses it changes — then we will return with an estimate and the order of stages.

Common technical questions about exchange and access rights

Questions about the exchange appear not during connection but in operation: the verification service is unavailable, the counterparty card has been duplicated, a manager has an extra access open.

Below are the things engineers and managers most often clarify before launching Bitrix24 integration with Kontur.Focus.

How does the integration avoid creating duplicate counterparties?

Before creating a record, the system searches for a match by INN and links the verification to the existing card. Changed details are updated in the same card rather than created as a new row — the reference book remains suitable for reporting.

How are accesses and roles differentiated?

Mass checks run from a service user with limited rights, while a manager sees only the result for their own counterparty. Exchange, schedule, and field mapping settings are available to the administrator — other roles do not change them.

What is recorded in the verification log?

Who and when launched the verification, for which counterparty, with what result, and when a repeat is needed. The log is stored in the system and can be exported — it shows the history of decisions and recheck timelines.

Let's discuss the task: what is needed for an estimate and work plan

To return with an estimate and a work plan, rather than general considerations, we need inputs on your scope: how counterparties are verified now and exactly where automatic verification should be placed.

The more specific the input data for the estimate, the more accurate the schema will be and the faster the integration work will start.

• How you currently verify counterparties: manually in a browser, via exports, by lawyers — and how much time one company takes.
• Volume: how many new counterparties appear per month and how many are already accumulated in the database — this determines whether a one-time mass verification of history is needed.
• Trigger point: verification when a company card is created, when a deal is moved to a stage, when an invoice is issued, or before signing a contract.
• Set of fields in the card: status, risks, related persons, court cases, changes over a period — and which of these we make mandatory.
• Reaction rules: what to do when a risk triggers — block the stage transition, create a task for the responsible person, send a notification, or only mark it with a record.
• Accesses and roles: production portal, test environment for debugging, settings rights, and the person responsible for data quality on your side.
• Priorities: which funnels and stages we cover first, how long we store verification history, and what we show in reports for management.

Describe the task in this scope — we will return with an estimate, a data exchange schema, and a stage-by-stage plan, and after approval we will schedule the start of integration work.