The client's accountant calls the sales rep: "You invoiced the LLP, we asked for the sole proprietor." The rep opens the CRM and finds three records: Alfa LLP, "Alfa" and "ТОО Альфа". One holds the director's phone number, another three deals from last year, the third nothing but a name. Nobody knows which one is real — the system included.
This is not about sales discipline or a bad CRM. In Kazakhstan a client almost always operates several legal entities, and every system that feeds data into the CRM creates records in its own way. Below: where duplicates come from, what stock Bitrix24 can do about them, which data model still holds a year later, and what we actually do when we clean a base of two or three thousand companies.
Why a client has three legal entities
The typical picture: an LLP on the general tax regime for large buyers, a sole proprietor on the simplified regime for retail, a separate LLP for a new line of business or a tender, a branch in another city with its own BIN. Sometimes an "old" LLP with history plus a "new" one after a change of founders. Since 2026 the mandatory VAT registration threshold is 10,000 MCI — 43.25 million tenge a year — so the "one entity with VAT, one without" pairing is even more common among small businesses.
As integrators we do not care why it is structured that way. What matters is this: the invoice, the contract and the e-invoice go to a specific BIN, while the person who calls, negotiates and decides is the same. The CRM asks "which company?", and the honest answer is "one client, three payers". If the data model ignores that, the rep solves it the only way available — by creating another record.
Five doors the mess comes through
- Excel import. Every rep keeps their own spreadsheet, and the same client appears as "Alfa LLP", "Alfa" and "ТОО Альфа". On import, duplicate control only fires if it is enabled and a phone or e-mail matches. How to prepare the file is covered in a separate article.
- Website and messenger requests. The lead is created before anyone looks at the base. The client writes from a new number — new contact; the lead gets converted — new company.
- Manual creation. Search found nothing because the name was spelled differently, so the rep created a new record in five seconds. This is the most common source of duplicates with people's names in them: "Alfa (Ivan)", "Alfa warehouse".
- 1C sync. In 1C a counterparty is a legal entity. The standard exchange brings every LLP of a client in as a separate company, and three entities become three records. How the exchange works is in the 1C integration article.
- Telephony. An inbound call from an unknown number spawns a nameless contact — "Incoming 16.09". The client calls back from another number — one more.
None of these channels checks with the others. In our experience a base of two to three thousand companies carries 10–15% duplicates, and roughly half of them are empty shells: a name and nothing else.
What breaks while duplicates live
- History is torn apart. Calls in one record, deals in another, documents in a third. The rep sees a "new client" and cold-calls a regular.
- Reports lie. Three records mean three clients. LTV, repeat sales, the new-versus-returning ratio — all computed on the wrong base.
- Two reps, one client. The records have different owners and both call. The client is annoyed; internally, an argument about whose deal it is.
- Invoice to the wrong entity. The client's accountants send it back, the e-invoice is redone, payment slips by a week.
- Double messaging. A WhatsApp campaign hits one number from two records — a complaint and a ban risk for the number. How to avoid that is in the messaging article.
- Access rights stop working. A rep sees "their" companies, but the same client also sits in somebody else's record. The role model we covered separately protects the base, not its copies.
What stock Bitrix24 can do
The tool is called duplicate control and is enabled under CRM → Settings → Duplicate control. It works in two modes: when a record is created, and across the base you already have.
- On creation of a lead, contact or company the system checks the selected fields against the base and shows the matches — you can open the existing record instead of spawning a new one.
- Fields checked. For companies — name, phone, e-mail and requisites: in the Kazakhstan template that is the BIN and the bank account. For contacts — full name, phone, e-mail. A match on any one selected field counts as a duplicate.
- Scanning the base. Runs manually or on a schedule, once a day by default. Records where every field matches, the owner is the same and — for leads — the stage is the same are merged automatically. The rest land in a list for manual review.
- Merging moves fields, activities, history and links into one record. If field values conflict, the system asks which one to keep. It requires edit and delete rights.
The other half of the toolkit is requisites. One company can hold several sets of requisites, there is a Kazakhstan template with BIN and IIN, and the data is pulled in automatically by BIN from the "Search requisites" field. When issuing an invoice you choose which requisites it goes to. Finally, links: a contact can be attached to several companies via "Add participant", and a deal can have several contacts but only one company — which is itself a hint at how to build the model.
| Situation | Stock | What to do |
|---|---|---|
| Two contacts with the same phone | Yes | Find duplicates → merge |
| One company under three names | Partly | Found by phone and e-mail; by name only on an exact match — "Alfa" and "Alfa LLP" will not meet |
| One client, three BINs | Yes | One company, three requisite sets, requisite chosen on the invoice |
| A person works for two companies | Yes | In the contact record → "Add participant" |
| 1C sends three counterparties | No | Mapping is configured during implementation or customised |
| Empty shells from telephony | No | Filter "no activities, no deals" → check → delete |
The model that holds: a company is a client
The rule we lay down on every implementation: a company in the CRM is a business client — the party you have a relationship with, not a row from a register of legal entities. Legal entities are requisite sets inside the record. People are contacts with roles: director, accountant, buyer. There is one owner per client. A deal is linked to the company and picks the right requisite set when the invoice is issued.
Sometimes two records are justified after all: the entities have different decision-makers, different contracts and terms, different cities and reps. Then it is two companies with a shared contact and a "Group of companies" field that reports are built on. The simple test: one director — one record.
1C is a separate conversation. The standard exchange transfers counterparties as companies one-to-one, and the "one record, three requisite sets" model does not fit it. For three counterparties to converge into one company, the mapping is configured during implementation, not afterwards. It is one of the first questions we ask whenever a project involves 1C.
Names: agree on how to write them
Half of the "duplicates by name" are not duplicates at all — they are one client written four ways. Stock search only counts an exact spelling as a match, so a naming rule matters more than any automation.
| How it gets written | Correct form | Why |
|---|---|---|
| Alfa LLP | Alfa | The legal form belongs in requisites, not in the name |
| Alfa, LLP / LLP Alfa | Alfa | Word order breaks search |
| ТОО Альфа | Alfa | One spelling per record; the other script goes in an "Also known as" field |
| Alfa (Ivan) | Alfa + contact Ivan | People live in contacts |
| Alfa warehouse / Alfa office | Alfa + addresses in requisites | Sites are not companies |
Cleaning the base: an order that works
- Export and back up. Companies and contacts to Excel; on self-hosted, a database copy. Date and time in the file name.
- Enable duplicate control by phone and e-mail for contacts and companies. These are reliable signals: two different clients sharing a number is almost unheard of.
- Run the base scan. Exact matches merge on their own; the rest come back as a list.
- Work the list by phone and e-mail first: this is where errors are rarest.
- Names — through normalisation. Export to Excel, strip LLP/IE/quotes, bring transliterations to one spelling, compare. In our experience this step finds the most.
- Multi-entity clients — into requisites. For each group of records belonging to one client: keep one, move the other BINs into requisite sets, bring deals and contacts over by merging.
- Empty shells. Filter "no activities, no deals, no phone" → check that no lead hangs on the record → delete.
- Write the rule down (below) — otherwise it all repeats within a quarter.
How long it takes: a base of 2,500 companies takes the two of us three to four working days. A day goes to automation and name normalisation; the rest is manual review of disputed pairs together with the reps, because only they know whether "this is one client or two".
What the button does not solve
- Telephony keeps spawning shells. Configure unknown numbers to create a lead rather than a contact, and have a robot delete leads with no activity after a few days.
- WhatsApp numbers are personal. One employee of the client writing from two phones is two contacts until someone merges them by hand.
- Merging does not merge deals. Two open deals for one client stay two; closing the extra one is the rep's call.
- After a merge there is one owner. The other rep loses the client from "theirs". Discuss it before the clean-up, not after — or you get quiet sabotage.
- 1C will keep sending counterparties its own way until the mapping is configured.
A five-point rule
- Before creating a company — search by phone and BIN, not by name.
- Company name — no legal form, no quotes, no people's names; the other script goes in "Also known as".
- A client's new legal entity is a new requisite set, not a new record.
- Only the head of sales may delete and merge.
- Once a month — run the duplicate scan and work the list; the result is logged.
