Auto-filling details by INN in CRM: where it breaks
A manager creates a counterparty in Bitrix24 manually: they enter the name from memory, copy the number from an email, and fill in the address and bank details however they can.
Auto-filling details by INN is connected in the system, but the card is saved half-empty, and the deal moves on with an error in the client data.
The cost of such a failure does not appear immediately. Empty fields in the card do not block the deal's progress — the invoice goes out with incorrect details, the contract is printed for the wrong legal entity, and in reports one client appears as two or three records.
Accounting and support have to sort this out after shipment, when suppliers and amounts are already fixed.
Usually more than one node breaks.
Searching for a counterparty by number returns data, but part of it is lost when matched with the card fields; for individual entrepreneurs, some details are not filled because their set of details is different; a separate case is an exhausted request limit to an external verification service, and then the form silently returns emptiness instead of a suggestion. Plus, no one forbids manual counterparty entry, so a workaround will always be found.
Below we analyze where exactly data is lost and how this is closed — from choosing a source to the rules under which the card will not be saved until the required details are confirmed.
The effect of automatic filling of counterparty cards
While a counterparty card is assembled manually, the manager copies the name, OGRN, KPP, and address from an email or website, and some fields remain empty.
Verification is postponed, so the database contains both “Romashka LLC” and “Romashka” LLC with different INNs, and deal processing stretches over days.
Auto-filling details by INN changes the entry point: the manager enters one number, the system queries the source and distributes the name, OGRN, KPP, legal address, status, and contacts across the card fields.
The share of filled fields no longer depends on employee discipline — everything the source returns is inserted.
At the same time, a whole class of errors disappears: a typo in the INN or a mixed-up KPP breaks the invoice, contract, and reporting; an incorrect address affects delivery and correspondence with legal consequences.
Details come from the primary source, the number is verified by checksum, and a repeat request before the deal shows a status change.
A unified card format has a side effect: duplicates almost do not appear, because an INN match is visible before saving, and deals are tied to one card instead of three. Reducing manual operations frees up time for talking with the client instead of copying lines from an email.
The effect can be measured across four cuts: deal processing time, share of filled fields, number of card edits, and duplicates by INN.
The first two shift immediately; duplicates do not go away instantly — we collapse the existing database in a separate pass, otherwise the quality of the client base will remain the same.
Ways to fill details: comparison of options
All four methods solve one task — getting counterparty details into the card without manual errors — but each involves different operating modes and different support costs.
The choice depends on how many counterparties are created per month and whether the company has an accounting system that already maintains a reliable details directory.
We compare by three criteria: how quickly a record appears, where the source of truth for the data comes from, and what happens when a counterparty's details change.
| Option | When it fits | Limitations |
|---|---|---|
| Manual entry | One-off deals, a few new counterparties per month | Typos in INN and KPP, duplicate cards, client data updated only manually |
| Importing counterparties from a file | Initial database population, mass transfer from spreadsheets after migration | Data is fixed at upload time, column parsing has to be maintained with every export change |
| Online request to a counterparty verification service | The card is created by INN right at the deal moment, current details and company status are needed | Dependence on an external service, limits on the number of requests, some fields are returned incompletely |
| Integration with an accounting system | The accounting system already maintains a details directory, deals and invoices live in one environment | Exchange setup and matching rules are needed, accounting system errors are transferred to cards |
In practice, a combination is more stable: initial population by import, new counterparties by online verification, and changes to details of already created clients by exchange with the accounting system.
Then auto-filling details by INN covers both the first entry and subsequent discrepancies. Below we analyze how this is assembled into one scenario.
Setup order: from field audit to testing on deals
We start with an audit of the card fields: we check which details are actually needed in the deal, company, and contact — INN, KPP, OGRN, address, name, status in the register.
Extra fields confuse managers, and duplicates break filling rules, so we fix the set before setup, not after launch.
Then we describe the data exchange scheme: at what moment the request goes to the counterparty verification service, what is cached in the card, how “company not found,” a name change, and source unavailability are handled.
Separately, we specify which fields the manager edits manually and which are protected from manual editing.
- Card field audit. Inventory of details in the deal, company, and contact, search for duplicates, determination of required fields for specific pipelines.
- Filling rules. What is overwritten automatically, what is only supplemented, at what moment data is considered outdated and requires a repeat request.
- Data exchange scheme. Service call points, error and limit handling, cache by INN so repeat requests do not create extra queries.
- Test environment. We assemble a set of INNs — active, liquidated, with typos — and run the logic on a copy of the portal before enabling it in production.
- Testing on real deals. On a live flow, we look at the share of cards with correct details, response speed, and the volume of manual edits by managers.
- Handover to the process owner. Instructions for managers, a map of fields and rules, and the procedure for when the service is unavailable and directories are updated.
What you keep: settings, schemes, and policies
Auto-filling details by INN in Bitrix24 saves the manager's time only when the setup is transparent and can be handed over to another administrator.
Therefore, along with the working logic, we provide artifacts that let the system live without us: rules, the scheme, permissions, instructions, and the procedure for reviewing disputed cards.
- Configured filling rules — it is fixed which card field is filled with what: name, address, management, codes are pulled by INN, and disputed details remain for manual editing.
- Data exchange scheme — where the response comes from, what the card shows when the source is unavailable, and where the latest received values are stored so the manager does not wait for a response.
- Field access matrix — described by role, who sees and changes details: manager, department head, accounting. Editing pulled values — only with confirmation.
- Instructions for managers — a short one-page scenario: where to start filling, how to verify the result, and what to do if the INN is entered with an error.
- Policy for working with the directory — frequency of reconciliation, procedure for manual correction of records, and the person responsible for discrepancies between source data and actual data.
- Dispute review log — how to see which requests were sent and what they responded with, to review conflict cards based on facts, not memory.
All this is handed over in your environment, with assigned responsible people and testing on test deals. We return with an estimate and plan after you describe the task.
Case study: how manual card filling was reduced threefold
A wholesale company with a database of several thousand counterparties: before implementation, the card was filled manually, and details were copied from correspondence and from 1C. Fields alone — INN, KPP, legal address, bank accounts — took 8–10 minutes per deal.
About 14% of fields remained empty, and accounting returned the deal for completion after terms had already been agreed.
What we did
The INN field in the card was linked to the directory and auto-filling of details by INN was configured: the number pulls in the name, address, KPP, and bank data.
Values are written to the same fields that the manager filled manually, so reports and export to the accounting system did not change. If directory data differs from what is already saved in the card, it is flagged, and the responsible person receives a verification task.
Metrics before and after
Deal processing time decreased from 8–10 to 3 minutes — measured across 200 deals per month before and after. The number of edits in the card dropped from 9 to 3: the manager no longer rewrites the address and accounts after a call.
The share of empty fields decreased from 14% to 4% — only those that the client physically did not provide on first contact remained.
A separate effect is data consistency: previously details in CRM and in the accounting system diverged, now both systems read the same INN. Checking for duplicates and non-existent numbers filters out garbage at entry rather than surfacing at the closing documents stage.
What to do if a counterparty is already created with an error in the details?
It is worth starting not with editing cards, but with checking the existing database. We export counterparties with INNs and names, normalize the names, and match records by INN with checksum verification.
This immediately reveals typos in the number — they were exactly why auto-filling created a new card instead of inserting into an existing one.
Then we review counterparty duplicates and discrepancies in cards: the same INN appears in several records, the details in them differ, and deals are distributed among them. The rule is simple — INN is unique, so one card remains the master, and the rest are consolidated into it.
Merging cards transfers deals, tasks, emails, and comments to the main record, so history is not lost. We take as the base the card to which historical deals are linked: this way connections remain intact rather than being rebuilt from scratch.
Closed deals remain in their periods and pipelines, amounts and stages are not recalculated — reporting does not fall apart. Cards must not be hard-deleted: deletion breaks connections and zeroes out history, whereas merging preserves both amounts and correspondence.
We perform mass correction on a copy of the database, take a backup before it and keep a change log, and afterward compare pipeline totals before and after.
Separately, we further configure auto-filling of details by INN: when a number is entered, the system should suggest the found counterparty rather than create a new card.
Common doubts about setting up data exchange
Exchange with external sources of details almost always runs not into the data transfer itself, but into how it fits into an already working environment.
Below are the doubts most often voiced before the start: access rights, existing business processes, impact on department work, and system behavior when the external service is unavailable.
Will auto-filling break access rights and current business processes?
Data exchange setup is performed from a separate technical user with the minimum required rights: reading directories and writing only to detail fields.
Existing business processes and robots are not rewritten — insertion happens when the card is created, before your rules trigger, so the logic of approvals and stages remains the same.
Before publishing, we run the scenario on a copy of the environment and verify that stages, responsible people, and notifications work as before.
What happens if the external service is unavailable?
Department work is not blocked: the card is created as usual, fields remain empty and are filled manually. The request is repeated on a schedule, and the received response is added to the card after saving.
The error log shows which INNs received no response and on which attempt — this is visible without contacting support.
Can the setup be rolled back and return to manual entry?
Yes. The logic is separated and does not affect the core: it is disabled with one switch, after which fields are filled manually again, and already inserted details are preserved. The procedure, accesses, and rollback points are recorded in instructions for your team.
Let's discuss the task: what is needed to start work
To return with an estimate and work plan rather than clarifying questions, a short description of the task is enough for us.
Tell us how counterparty details currently get into the card — manually, by import, or through a third-party service — and what exactly does not suit you in this process. This will be enough to understand the scope of improvements and propose a solution for your case.
- Description of the current process: who fills in the details and at what stage, how much time it takes, and where errors most often occur.
- Source of information: official data by INN or a record from your accounting system — what should be considered reliable.
- List of card fields that should be filled automatically, and the rules for verifying them before saving.
- How your Bitrix24 is set up today: a cloud portal or one installed on your own servers, which sections are already used.
- Access for review: a test portal or database copy, an account with extended rights, and the contact of the person responsible for CRM.
- Integration with 1C: how the exchange is configured, which directories are involved, and who makes changes on the accounting side.
- Limitations: security service requirements for external requests and rules for storing counterparty data.
The first step is not development, but analysis: we look at the card and directories, reproduce the current filling scenario, and record where data is lost. After that we agree on the auto-filling scheme, the procedure for verifying details, and the implementation stages.
Describe the task in a request — we will return with an estimate and plan so that work starts without stopping sales.