Why 1C-Bitrix counterparty exchange produces duplicates and discrepancies
Counterparty exchange between 1C and the website is almost never a simple two-way export.
The catalog in the accounting system and the website database live by different rules: in 1C, a record is changed retroactively, while on the website it is already linked to orders, invoices, and the personal account.
As soon as matching rules are not explicitly defined, the very first edit of details in one environment creates a new card in the other.
The most common cause of counterparty duplicates is an incomplete matching key.
If the exchange node searches for a record by name, then "Romashka LLC", "Romashka LLC" (different order) and "LLC "Romashka"" become three different companies with different order histories.
It is more reliable to link records by INN together with KPP, and keep the name, address, and contacts as overwritable fields rather than an identifier.
The second source of failures is the conflict of "who is in charge." Until a source-of-truth environment is assigned, exchange goes both ways and details overwrite each other: a manager corrected a contact person in 1C-Bitrix, and the next upload from the accounting system returned the old value.
This also causes catalog divergence — some cards were updated, some remained as they were, and no one can confirm which version is correct.
Double data entry appears as a consequence. Managers stop trusting automatic exchange and create a counterparty manually on the side where it is missing — this makes the databases diverge even faster and irreversibly.
Below we discuss how this is solved: matching key, field priority rules, discrepancy handling, and exchange log.
Result of setup: clean catalogs and less manual work
After setup, exchange goes both ways: a counterparty created in the accounting system appears in 1C-Bitrix along with details, contact persons, and a link to the deal, and card edits from the interface are returned back.
Records are matched by a key — tax number or external identifier — so one client does not turn into three duplicates after each upload.
A unified catalog reduces manual operations that usually consume a manager's and accountant's time: reconciling two databases, finding discrepancies, re-entering data.
We assign an owner for each field — some attributes are updated only from accounting, some only from the website interface — and automatic counterparty synchronization distributes them without conflicts, on a schedule or by event.
The exchange log stores what was transferred and when: if a record did not go through, it is clear at which step.
Up-to-date client data no longer depends on who last accessed the database.
The deal card has the same details as in the accounting system — the manager does not clarify them by phone or wait for an upload from accounting, and deal closing times become predictable: the pause for "we'll send the correct data now" disappears from the process.
We check the result on live scenarios: create a counterparty on each side, change details, see how field priorities and repeat exchange work. Setup is considered complete when after a control run discrepancies in the catalogs are zero and remain so without manual intervention.
Counterparty exchange modes: one-time, scheduled, event-driven
Three modes cover different tasks, and the choice between them is determined by how critical the catalog's lag behind the accounting system is.
One-time counterparty import is the initial load: one run when launching the website or after changing the accounting system, then the catalog lives on its own.
Scheduled exchange is a job that at a specified interval picks up changes and updates partner cards without creating a peak load on the database.
Event-driven export works differently: 1C transmits the counterparty at the moment of recording, so a new client appears in the personal account almost immediately, rather than after the job interval.
The price for this is external access to the database and protection against repeated transmission if the response did not arrive. Therefore, in practice, catalog synchronization modes are combined rather than choosing one.
| Mode | When suitable | Limitations |
|---|---|---|
| One-time import | Initial catalog filling, migration after changing the accounting system | Does not see edits after launch, repeat must be initiated manually |
| Scheduled exchange | Small flow of deals, lag for the job period is acceptable | Delay equals the launch interval, on large catalogs the pass duration grows |
| Event-driven export | Personal accounts and orders where immediate relevance is important | Requires network access to the database and duplicate cutoff on repeated sending |
The working scheme is usually like this: one-time import fills the catalog, event-driven export delivers new counterparties, and scheduled exchange picks up everything that did not go through by event.
Which set of modes is needed in your case depends on the document flow and where exactly divergence is acceptable.
Work order: from catalog audit to handover of regulations
Counterparty exchange breaks not at the setup stage but on the data: duplicates with different spellings, empty details, cards created manually in both systems at once. Therefore, we start with an inspection of the catalogs, not with the export. The work order is the same for one-way and two-way exchange — only the set of rules changes.
- Catalog audit. We take a snapshot from 1C and the website: how many records, where duplicates are, which details are not filled in, how legal entities and separate divisions relate. The output is a discrepancy map and a list of data that cannot be transferred automatically.
- Details matching rules. We agree on the attribute by which records are linked: source system identifier, tax number, combination of fields. We fix the master system, conflict resolution procedure, and what to do with a counterparty that exists only on one side.
- Exchange setup. We determine the direction and composition of fields: details, addresses, contact persons, group links. We configure the schedule, exchange log, and error notifications — a failure is visible immediately, not during reconciliation a month later.
- Testing on a test environment. A copy of the working database, a run of full and partial exchange, a separate scenario on "dirty" data and duplicates. We measure the pass time and behavior during a communication break.
- Integration acceptance. Checklist: reconciliation of record counts, selective reconciliation of details, repeat run without creating duplicates, correct rollback of a failed pass.
- Handover of exchange regulations. Description of matching rules, person responsible for the catalog, instructions for restarting and resolving conflicts, procedure for making changes to the schema.
After handover, exchange runs on schedule: new counterparties appear in both systems, discrepancies are localized in the log, and schema changes go through the test environment, not directly in the working database.
What remains with you: matching rules, settings, documentation
After launch, counterparty exchange lives not in correspondence or in the engineer's head, but in artifacts that are with you and available to the team without contacting us.
Below is a list of what is handed over based on the results of the work and remains a working support tool.
- Link map: which objects are matched between the accounting system and the website, the exchange direction for each, and launch triggers — event, schedule, manual launch.
- Details matching rules: by which fields a match is found (INN/UNP, counterparty code, service identifier), how duplicates, empty and changed values are handled, which fields are required to create a record.
- Selection and filter settings: which types and groups of counterparties are included in the exchange, which remain only in the accounting system, how service and test records are excluded.
- Access control to catalogs: employee roles on the website side, who edits the counterparty card, who launches exchange manually, and where these actions are recorded.
- Discrepancy regulations and employee instructions: what to do if a counterparty was not created, updated only in one system, or exchange hung — where to look and to whom to pass the task.
- Exchange log: where to view launch statistics, errors, and processing time to distinguish an integration failure from a data error.
Case study: how duplicates between the accounting system and the website were removed
The client is a wholesale supplier: the counterparty catalog lives in 1C, the catalog and personal account are on 1C-Bitrix. There was no exchange between the systems: data was transferred by a file prepared manually, and matching was done by the organization name as a string.
Any typo or change of legal name created a new record — duplicates accumulated on the website, linked to different users and orders.
What was changed
We configured scheduled exchange: matching is done by tax number and external key, not by name.
The catalog on the website became derived from the accounting one — new counterparties appear on their own, details and contact persons are updated within 15 minutes, and discrepancies go to the exchange log indicating exactly what did not match.
Before launch, we reconciled the history: we sorted out accumulated duplicates, merged orders and invoices linked to them, and recorded a map of correspondence between old records and new ones.
Metrics before and after
- share of duplicate records: from 18% to 0.4% — the remainder requires manual resolution for incomplete details;
- preparation of exports: 3–4 hours per week manually → 0, exchange runs in the background;
- manual counterparty edits: about 40 per week → 2–3 per month, and only for disputed cases;
- exchange implementation time: 3 weeks, of which one week was for reconciling historical data.
What to do if data is already entered differently in two systems?
When both systems are already filled, matching by name gives false pairs: one counterparty is entered as "Romashka", another as "Romashka LLC, Minsk", and next to it lies "Romashka TD" — that is already another legal entity.
Therefore, we start not with exchange but with inventory: we export both catalogs, normalize names, and match entities by hard attributes — tax number, then by the combination of "name + phone + address".
| Discrepancy class | How we detect | Solution |
|---|---|---|
| Duplicates within one database | grouping by number and name | merge into one card |
| Different details for a pair | field comparison, discrepancy log | value is taken from the leading system for the field |
| Record exists only on one side | full catalog matching | a pair is created, the link is recorded |
| Test and empty cards | filtering: no details and deals | not included in exchange |
The leading system is chosen not for the entire card but for each field: details, name according to documents, and contracts — from the accounting system; contact persons, segment, and source of contact — from the website.
A disputed value is not overwritten silently: the discrepancy goes to the log, where it is visible what was overwritten and on what basis.
Individual cases where the automation is not sure are handled by an operator: records are stitched manually, and the link is preserved as a stable correspondence that the exchange subsequently only uses.
Then a one-time alignment takes place — one pass according to the rules of the leading system, with change history preserved, so any step can be rolled back without losing data in either database.
Common technical concerns before starting work
Before starting counterparty exchange, the client's technical services check not "whether the integration works" but how it behaves during failures and what will happen to it in a year. Below are short answers to what most often comes up during approval.
Can you synchronize not all counterparties, but only a part?
Yes, the selection rule is set on the source side: group, attribute, additional detail. Records outside the rule do not enter the queue at all, so the transfer volume remains predictable.
The first run is additionally limited by modification date — history for past years is not exported.
What happens if one of the systems is unavailable?
Changes are not lost: they remain in the queue and are repeated on schedule until the receiving side confirms receipt. The repeat does not create duplicates — records are matched by external key, and discrepancies are collected in a report for review.
How does exchange affect load?
Only changed records are transferred, in portions, not the entire catalog. Peak load is moved to the night window; during the day, exchange does not prevent managers from working with cards.
Can changes be rolled back if a rule turns out to be erroneous?
Yes: the rule is disabled without breaking the link between systems. Before a mass run, we take a snapshot of the catalog to restore previous detail values, and the log shows which record changed and when.
Let's discuss the task: we will return with a work plan and estimate
To estimate counterparty exchange between 1C and the website, a full specification is not needed — initial inputs that show the scope and risks are enough. Send them in free form, and we will return with a work plan, list of modifications, and timelines by stage.
What helps to calculate faster:
- Which 1C configuration you have in use and how customized it is: standard or with modifications that cannot be lost during exchange.
- What is considered the source of truth for a counterparty: 1C writes to the website, the website sends data back, or exchange is two-way with priority rules.
- Volumes: how many counterparties now, how many are added per month, how often details and contracts change.
- How we link records between databases — by INN, UNP, or external code — and what to do with duplicates and cards without details.
- Composition of exchange: only the counterparty card or also contracts, contact persons, addresses, and links to invoices and orders.
- Access: 1C test environment, database copy or its structure, access to the website admin panel, and contact of your 1C specialist.
The first conversation is 30–40 minutes to the point: we discuss the scheme, failure points, and who is responsible for data at each section.
Based on the results, we send a work plan by stages, timeline estimate and risks, as well as the start order: first one-way exchange on a limited list of counterparties, then the full composition and exchange regulations. Describe the task — we will return with an estimate and plan.