Why Data Diverges: Bitrix24 and 1C Integration
A typical failure looks like this: a customer places an order on the website, a manager confirms it in the portal, but the order is not in the accounting system — it remains in the exchange queue.
At the same time, the catalog shows an old price, the stock balance for the item is already zero, and the discrepancy between 1C and portal stock balances grows with every export. No one can say which version is correct.
Then manual mode kicks in. Nomenclature is reconciled by names because items in the database and on the website were created by different people as different entries, and disputed matches are corrected manually.
Payment statuses are not updated, so shipment is approved based on a bank statement, and deadlines slip by days. Exchange errors during export settle in the log and surface only when a customer calls and asks where their order is.
The reason is not a "broken module" but the absence of exchange rules. Export runs on a schedule, item matching relies on the name rather than the SKU; on resend, the order is duplicated; on connection loss, it is lost.
Double order entry becomes the norm: the portal and 1C live as two independent systems instead of one circuit.
What Bitrix24 Integration with the Accounting System Delivers
The first effect is visible already at checkout: an order from the website goes into the accounting system on its own, without re-entry by a manager.
Exchange runs by event and is backed up by a schedule, failed sessions are retried from the queue, and the order number serves as the matching key — so one order remains one order, not two diverging documents.
A unified nomenclature catalog removes the main cause of discrepancies: items are linked by SKU and internal identifier, not by name.
Stock balances are pulled into the portal by the time a customer calls — the manager confirms availability based on actual warehouse data, not yesterday's export, and does not promise what is not there.
Automatic payment statuses remove another manual layer. Receipt of funds changes the order state simultaneously in the accounting system and the portal: accounting does not reconcile the statement line by line, and the manager sees payment without a request to accounting.
Next, classes of failures that used to surface at the end of the month are closed: stock discrepancy, lost item, order without an invoice.
The exchange catches the error at the matching step and leaves a specific entry in the log, so investigation takes minutes rather than a day of reconciliation.
In total, the reduction in manual operations is measured by an order of magnitude: instead of transferring data between systems, employees work on orders and customers.
The longer the circuit operates, the fewer discrepancies remain — the effect accumulates rather than dissipates.
Exchange Formats: Scheduled, Event-Driven, Streaming
In Bitrix24 integration with a website, the choice of mode is dictated not by development convenience but by the nature of the data. The catalog changes in batches — it makes sense to export it on a schedule.
Order status changes pointwise and is important immediately — here event-driven exchange works. Stock balances sit between them: they cannot be sent in full, so batch transfer is used.
| Format | When It Fits | Limitations |
|---|---|---|
| Scheduled exchange | Export of catalog, sections, prices, and reference data; nightly scheduled jobs | Delay until the next run; on large catalogs the window stretches and hits database load |
| Event-driven exchange | Reverse export of order statuses, payments, reserves, and website requests | Requires a queue with redelivery: if one side is unavailable, the event is lost |
| Streaming, batch data transfer | Stock balances and large catalogs: tens of thousands of items that cannot be transferred in full | Debugging is more complex — checkpoints are needed to resume from the point of failure rather than from the beginning |
Each mode separately produces its own class of failures: schedule — discrepancy during the time between runs; events — loss of individual changes; streaming — a stuck batch.
Therefore, exchange is built in a combined way and a log is added: it shows what and when went in both directions, and a discrepancy is found in minutes rather than from a customer complaint.
Implementation Stages: From Audit to Handover of Regulations
We carry out the work so that not a single catalog desynchronization reaches the production system. First, an exchange audit: which nodes are already connected, at what frequency sessions run, what accumulates in the queue, and where nomenclature items are duplicated.
Based on the results, we produce a catalog mapping — a document that records which portal object is linked to which accounting system object and by what attribute records are matched.
- Exchange audit. We review session logs, accumulated conflicts, and manual edits in catalogs — we record what is currently blocking the exchange.
- Catalog mapping. We consolidate nomenclature, counterparties, warehouses, prices, and order statuses: what is matched by code, what by external key, and what requires a separate rule.
- Flow diagram and rules. We define the exchange direction, session frequency, behavior for edits on both sides, and the procedure for marking deleted items.
- Test circuit. We spin up copies of the Bitrix24 portal and the accounting system, configure the exchange, and deliberately interrupt a session — we watch how the queue recovers.
- Testing on real data. We run an export from the working database, reconcile stock balances, prices, and order history; we resolve discrepancies to zero, not to "roughly matches."
- Transfer to the production environment. We enable the exchange in a closed window: first catalogs, then documents, with queue control at every step.
- Handover of regulations. Catalog mapping, flow diagram, instructions for conflict resolution, and a checklist for desynchronization.
What the Customer Keeps: Configurations, Diagrams, Regulations
We hand over the integration not as "an exchange that works somewhere" but as a package that your administrator can use to maintain it without us. Everything listed is stored in the project repository, versioned, and updated along with changes to the exchange logic.
- Data flow diagram — which entities go to the accounting system and what comes back: nomenclature, prices, stock balances, orders, statuses. With direction, frequency, and an indication of what runs by event and what runs on a schedule.
- Access rights matrix — which roles and accounts read and change what, and where access is read-only. Service exchange users and fields that are overwritten and must not be edited manually are marked separately.
- Attribute mapping — mapping of catalogs and fields between systems. It shows where to add a property so that it reaches the website instead of being lost midway.
- Exchange error log — where to look for failures, how a one-time failure in an entry differs from a systemic problem, and for what period history is stored.
- Administrator instructions — typical operations: restarting the exchange, re-exporting a document, manual stock reconciliation, actions before updating configurations.
- Discrepancy investigation regulations — procedure for a price, stock, or status discrepancy: what is checked first, when a discrepancy is acceptable, and to whom it is escalated.
Such a package removes dependence on a specific contractor: any engineer familiar with the platform can maintain the Bitrix24 integration, not only the author of the solution.
Case Study: Warehouse and Portal Diverged — What Changed
An online store and a portal on Bitrix24 lived for years on their own copy of the catalog: stock balances and prices were transferred in full by a nightly export, and a manager manually reconciled disputed items before confirming an order.
Reconciliation took about three hours per shift, and almost every evening there were orders confirmed for goods that were no longer in the warehouse.
What We Changed
We separated the flows: the warehouse remained the single source of truth for quantity and price, and the website and portal receive not the full file but only changed items — by event, as edits occur.
A conflict between two edits is resolved by modification time, and anything that does not match goes into a discrepancy report rather than silently dissolving.
The reverse flow — order statuses and reserves — follows the same route, so the manager sees one picture both in the portal and in the accounting circuit.
Result in Numbers
Manual reconciliations went from 40–60 per shift to 2–3 per week — and even those only for items from the report. Average order processing time dropped from 22 minutes to 4: the manager confirms the order instead of finding out whether the item is on the shelf.
A separate class of failures — confirmation for missing stock and negative balances after recalculation — stopped recurring: over a month of observation, not a single case versus three or four dozen before implementation.
What to Do If 1C Is Already Connected to the Portal with Custom Scripts?
Custom exchange is not a death sentence, and it does not need to be rewritten entirely, nor should sales be stopped for a migration. The order is the opposite: first an audit of customizations, then a gradual transfer to a managed scheme.
The audit answers one question — which exchange rules actually work in the production circuit, and which remain as a legacy from previous contractors and are no longer controlled by anyone.
The practice is almost always the same.
Orders come from several sources, the matching key is sometimes the order number, sometimes the combination "date and counterparty," and duplicates appear at the junction: the same order is closed twice, stock balances diverge, and the manager manually merges cards.
Part of the logic lives not in code but in status settings and events known to one person — when they leave, the exchange stops.
Exchange migration is built as a parallel circuit: the new exchange writes data alongside the old one, and key-based reconciliation shows discrepancies before the old one is disabled.
For each entity, a matching rule and protection against duplicate writes are fixed — a repeatedly received order updates the existing one instead of creating a second. Switching happens in groups: first catalogs, then orders, then payments and statuses.
Moving to standard rules covers most of the custom logic: matching nomenclature, counterparties, prices, and statuses is configured with built-in tools rather than scripts. What is not covered by the standard remains, but as an extension on top, with versioning and an error log. After that, the exchange updates together with the platform instead of breaking with every update.
Doubts at the Start: Exchange, Conflicts, Access Rights
Before the exchange starts, engineers and managers usually have the same questions — not "can you" but "what will happen to what already works." Below are direct answers on the bottlenecks that most often come up during approval: data discrepancies, access, load on the accounting system, and the fate of current customizations.
An object was changed in two systems — whose version wins?
A data version conflict is resolved not by "last write wins" but by assigning the source of truth to a specific attribute: the name is pulled from the accounting system, the description from the website.
Matching is done by external key, and discrepancies that cannot be resolved automatically go into an investigation queue with both versions and the author of the edit.
Does the exchange run under an administrator?
No. A service account with minimally sufficient rights is created for the exchange: separately for reading and writing, only for the necessary catalogs and documents.
Keys are rotated, requests are restricted by address, actions are written to the log — a leaked password does not open the entire accounting system.
Will the accounting system go down during export?
The exchange runs in batches on a schedule, outside peak windows, with a limit on parallel threads. If the accounting system is unavailable, changes are not lost: they remain in the queue and go out on the next pass. Users continue working during this time — document posting is not blocked.
What will happen to our current customizations?
First, an inventory: event handlers, custom fields, scripts on the website and portal side. Then, for each one, a decision: migrate as is, adapt to the new exchange scheme, or disable. Extension points are recorded in the diagram so that a core update does not silently break them.
How are errors investigated after launch?
Using the exchange log: record identifier, direction, request body, and response. The error is reproduced on a copy and classified by priority — data loss, attribute discrepancy, delay.
The regulations set the response time and escalation, so the dispute "it did not update for us" turns into a specific log entry.
Let's Discuss Your Exchange Scheme and Come Back with a Plan
To come back with a scope estimate, a data flow diagram, and a launch sequence, we only need your description of the task — a deep dive into the code is not needed at this stage.
Below is a list of source data that covers almost all questions about exchange between the website, portal, and accounting system.
- Which objects participate in the exchange and in which direction: nomenclature and prices, stock balances by warehouse, orders and invoices, counterparties, payment and shipment statuses.
- Composition of the accounting system: configuration, edition, platform branch, presence of customizations in the standard exchange and external processing routines.
- Required frequency and volume: a schedule once a day or near-online, how many items and orders pass at peak.
- Where data diverges now: duplicate counterparties, manual price edits, orders placed bypassing accounting.
- Circuit limitations: access to databases, update window, logging requirements, role separation, and write permissions.
- Who on your side confirms the catalog matching rules and accepts discrepancies after reconciliation.
From this, we assemble a work plan for the exchange: a flow diagram, a launch sequence from catalogs to documents, a test run on a copy of the database with real orders and discrepancy investigation.
We put the exchange into the production circuit only after reconciliation matches. Describe the task in this format — we will come back with an estimate and a plan.
