Why Bitrix24 and 1C deal sync breaks
Deal synchronization between Bitrix24 and 1C breaks not at the "no connection" stage, but at data matching.
Item, counterparty, and warehouse catalogs live in two systems by their own rules: a new counterparty appears in 1C — in the client card it arrives as a string without being linked to an existing record.
If matching is done by name, and not by an immutable identifier, any edit to the name breaks the link between documents.
The second typical place is repeated export. The exchange session is interrupted in the middle, the schedule starts the next exchange, and some deals are posted to accounting a second time.
This is how duplicate deals appear: the manager sees one entity, accounting sees two, and invoices and shipments for them diverge.
The third is status mismatch during rollback. If the exchange transfers a deal stage into an order state without passing it back, then cancellation or return to the previous stage in 1C does not reach Bitrix24. The manager works from an outdated stage, while a closed order sits in accounting.
The cost of these failures is manual data transfer. Someone reconciles exports line by line, restores links between cards, manually returns lost statuses — and repeats this after every failure. Sales and accounting begin living by different numbers.
We break down how this is closed: matching by stable identifiers, protection against reprocessing the same record, and an exchange log that shows exactly where the link broke.
What changes after setup: measurable effect
After setup, the effect is visible in values that are checked at acceptance: duplicate share, delay before a deal appears in accounting, number of manual manager operations, and the class of failures that disappears entirely.
Below are benchmarks against which we jointly verify the result, rather than a subjective "it became more convenient."
Eliminating duplicates is the first thing accounting notices. The matching key (counterparty code, attribute, external record identifier) is fixed once, and a repeated export from the CRM updates the existing deal instead of creating a second one.
The share of duplicates in the register falls to isolated cases, and disputed records go into a discrepancy report rather than into interdepartmental correspondence.
Deal synchronization time is measured from a stage change in the CRM to the appearance of the document in accounting, not "generally fast." With event-driven exchange this is tens of seconds; with a scheduled run it is the schedule interval; in both cases the value is predictable and does not depend on whether the manager has the card open.
Manual manager operations in typical scenarios disappear completely: creating a deal, changing a stage, issuing an invoice, closing. These are the very actions that used to be duplicated manually and on which typos in amounts and items accumulated.
Deal data integrity is checked by end-to-end matching: amount, line items, counterparty, responsible person, and stage match in both systems. A whole class of failures disappears — discrepancies during partial payment and double invoices.
A record that could not be matched goes into an error queue with a reason, while the exchange itself continues to run, so one problematic deal does not stop the flow.
Synchronization modes: event-driven, scheduled, manual
Synchronization mode is the answer to the question of when a deal goes into the accounting system. It determines the delay between editing a card and posting, the peak load on both systems, and which changes will even make it into the export. Below are three working options with their real boundaries.
Comparison of modes
| Mode | When it fits | Mode limitations |
|---|---|---|
| Event-driven exchange | Deals change all day; accounting needs status and amount immediately | Every edit creates a queue entry; mass field changes require batch processing or event suppression |
| Scheduled exchange | Hourly or nightly exports; reporting does not require online data | Between runs data diverges; overlapping runs cause duplicates — locking and selection by modification date are needed |
| Manual export launch | One-off reconciliations, period closing, sorting out discrepancies after a failure | No predictability: a forgotten run leaves deals unexported |
In practice, modes are combined: event-driven covers statuses and amounts, the schedule acts as insurance against missed events, and manual launch is for reconciliations and repeated export after a failure.
The limitation common to all three is catalog matching: if a counterparty or item is not matched, the deal will enter the queue with an error, and the mode has nothing to do with it.
That is why we choose after analyzing the volume: how many deals pass per day, how often attributes change, and how critical the delay is.
Setup stages: from audit to handover to support
Exchange is rarely set up from scratch: some data between Bitrix24 and 1C already flows, but with discrepancies and manual fine-tuning.
Therefore we start by capturing the actual picture — which entities are transferred and in which direction, by which events, and where duplicates appear. Setting up on top of an unclear scheme breaks an already working area.
- Integration audit — we examine handlers, the exchange log, and discrepancies: deals without a document in 1C, documents without a deal, duplicated counterparties.
- Field mapping scheme — we bring together deal attributes and the 1C document into a table: field, source, direction, transformation rule, behavior when the value is empty.
- Catalogs — we separately describe the matching of counterparties, items, and statuses: most errors occur there.
- Trigger rules — we define trigger events (stage change, payment, closing), queue order, and idempotency rules so that a repeated run does not create a second deal.
- Test environment — we deploy a copy of the production database with a slice of real data and run the scenarios end to end: creation, modification, cancellation, repeated synchronization.
- Handover to support — we train the customer's team and provide documentation and a verification procedure after changes to attributes.
After that, the exchange lives without a developer: typical failures are resolved according to the instructions, and schema changes go through the test environment.
What you retain after handover: configurations and procedures
Exchange handover is not the moment when deals first went to 1C, but a set of artifacts by which another engineer can maintain the link.
Without them, knowledge remains in the implementer's head: when the responsible person changes or the configuration is updated, the exchange quietly breaks, and no one can say which field should have gone where. Therefore handover includes:
- Field mapping map — a table "1C attribute ↔ deal field" with types, requiredness, default values, and transformation rules: how a deal line is assembled from items, what to do with an empty counterparty.
- Exchange rules and schedule: which entities are synchronized, in which direction, with what frequency, by what criterion a record is considered modified, and how a conflicting edit is resolved.
- Access matrix: who can see exchange settings, who can change them, who only reads the log; separately — the service user on whose behalf the export runs, and its permissions.
- Integration documentation: data flow diagram, list of external identifiers by which a deal finds its document after reinstallation or restoration from a copy.
- Instructions for managers: which fields are required when working with a deal, where to view export status, and what to do if a deal did not go through.
- Incident procedure: diagnostic order — exchange log, unprocessed items, repeated export — and the escalation point with contacts.
- Checklist of acceptance scenarios with test data, so that after any exchange change verification takes minutes, not half a day.
Each item is a working document, not a description of "how everything is arranged": they are edited when the business process changes, they are used to onboard a new employee, and they are also used to restore the exchange after an incident.
Case: how synchronization stopped falling apart
Project — a wholesale supplier: the pipeline lives in Bitrix24, accounting and shipment — in 1C. The exchange was set up in batches every two hours: all cards modified during the period were exported, and record matching was done by counterparty name.
On such a scheme, 60 to 80 deals per month were lost. Some never reached the accounting system; some were overwritten by a counter-record when the card was edited in both systems in time.
Pipeline stage discrepancies showed 12% of deals, and the operator spent 6–7 hours per week manually merging the two lists.
The exchange was moved to an event-driven scheme: every card edit generates an event with a unique identifier, enters the queue, and is retried on failure instead of disappearing silently.
Catalog matching — items, counterparties, responsible persons — was moved into a separate mapping table; conflicts are resolved by the rule of the last confirmed change. Every event leaves a log entry: deal identifier, direction, delivery result.
After a quarter of observation, the numbers are as follows:
- lost deals — zero with 6–8 thousand events per month;
- delay between a pipeline edit and an accounting record — 15–30 seconds instead of "up to two hours";
- stage discrepancy — 0.4% instead of 12%, and each one is visible in the log with a reason;
- manual merging eliminated, freeing up 6 hours per week for the operator.
Stability rests not on a "good exchange," but on the fact that delivery failure stopped being invisible: an undelivered event is visible in the log and is delivered again without manually restarting the export.
How does event-driven exchange differ from scheduled exchange?
The choice between schemes is determined by two things: how long data can "age" without harm, and what load the accounting system can handle.
The event-driven scheme initiates transfer at the moment an object changes — a deal, invoice, or payment status goes to 1C immediately. Batch transfer accumulates changes over an interval and sends them as one set on a schedule.
The downside of events is the load on the accounting system. A group stage change, mass lead upload, or price recalculation generates a stream of calls, 1C starts hitting locks, and some records are duplicated.
Therefore, only those entities where data freshness affects work are moved to events: money, reserves, shipment statuses.
Batch transfer is cheaper to maintain: load is predictable, the exchange is easy to restart and reconcile by checksums. The price is freshness: until the next pass, the manager sees an outdated stock balance or status in the card. For items, catalogs, and warehouse this is acceptable; for payments it is not.
A working compromise is a combined mode. An event does not pull data immediately but marks the object as modified; a scheduled job processes the accumulated changes in batches with a size limit.
Freshness remains close to event-driven, while peak load on the accounting system is limited by the batch size.
The selection criterion is simple: entities with a high cost of delay — event-driven; mass and rarely changing — scheduled. If the exchange is already running and "drifts" under load, it is usually enough to separate the flows and add duplicate protection by key.
Common technical doubts before starting
Deal exchange between Bitrix24 and 1C is not a "synchronize" button, but a background process with an event queue, log, and retries. Before starting, people ask not about features, but about behavior during failures and responsibility for data.
What happens if one of the systems is unavailable?
Events are not lost: they accumulate in the queue and are read after communication is restored — by timestamp and the identifier of the last successful exchange. Retries occur with increasing delay, and writing by external key prevents creating a duplicate deal.
If the queue does not drain longer than a specified threshold, a notification is sent to the responsible person.
Will employees have to stop work during setup?
No. The initial export runs outside working hours in portions, and catalogs are synchronized before deals so that links do not break. We enable writing after the field map is approved and verification in the test environment is complete — work processes are not blocked.
What if some deals are not exported?
Selection rules are fixed explicitly: pipeline, stages, type, modification date, responsible person. Anything not included in the filter remains in the source system and is not deleted: partial export is an intentional setting, not a loss.
The exchange log shows the reason for skipping for each record, and reconciling the number of deals by stage reveals discrepancies in advance.
Who is responsible for the correctness of fields in a deal?
The field mapping map — source, target, transformation rule, default value — is included in the project documentation and versioned. The meaning and completeness of data remain with the customer; we take responsibility for transformation correctness and error handling. New fields go through the same map rather than being edited manually in two systems.
Let's discuss the task and come back with an estimate and plan
A project starts not with edits in the configuration, but with an analysis of the current exchange scheme.
To come back with a work estimate rather than general words, we need to see how synchronization is currently arranged: which entities are transferred, what is already configured, and what is still done manually.
What to send for preliminary analysis:
- an export of exchange rules and a list of objects involved in deal synchronization;
- the log of recent runs: when they ran, where they were interrupted, which records went into errors;
- a description of catalogs and attributes by which deals, counterparties, and items are matched;
- a list of modifications already made to the exchange module, and who maintains them;
- a couple of "problematic" deals — they make it faster to reproduce the failure and avoid guessing the cause.
On the call we clarify the exchange procedure and allowable window, transfer directions, who is responsible for changes in the accounting system, and how conflicts are resolved when data diverges.
Then we come back with an implementation plan: stages, scope of work, timelines, responsibility areas, and a rollback procedure if the previous scheme needs to be restored after launch.
Describe the task — we will come back with an estimate and a plan.