ERP integration with a website: where data exchange breaks
Exchange between a website and an accounting system almost always runs in batches: catalog exported at night, orders accepted during the day, stock reconciled in the evening.
Between these points, the storefront and the warehouse live on different data, and an item sold in retail or on a marketplace is still listed as available on the website — the customer places an order for stock that no longer exists.
The flip side is orders that reach the accounting system twice: a repeated send when a response did not arrive on time, plus parallel transfer from an export and a record from the customer portal produce duplicate orders that managers then sort out.
Prices and terms for counterparties follow the same queue: if the exchange stops, the storefront sells at the old price list, and the customer's discount group is not pulled in.
Stock discrepancies and outdated prices are usually noticed not in the exchange log but through returns, cancellations, and calls asking to "check availability."
The cost of such a scheme grows quietly: manual reconciliations turn from an emergency procedure into routine work — the warehouse and support spend hours on them every week, and discrepancies accumulate faster than they can be closed.
Below we break down how this is closed: an exchange queue with delivery confirmation, a resend key on the order side, and a log that shows exactly where an item was lost.
A unified data loop: orders, products, and customers without manual reconciliations
The source of truth remains in the accounting system: 1С:ERP and the web application exchange not files by email but structured messages — event-based and scheduled.
Item master data, warehouse stock, prices, and shipping terms arrive on the website without an operator, so the product card stops diverging from accounting. A single data source removes the main cause of manual reconciliations — desynchronization of the two databases.
| Data flow | Direction | Frequency | What it eliminates |
|---|---|---|---|
| Item master data relevance, prices | accounting → website | on change | sale of a discontinued item |
| Warehouse stock synchronization | accounting → website | scheduled, minutes | rejection of an item that is out of stock |
| Orders and payment statuses | website → accounting | on event | lost or duplicated order |
| Customers, contracts, details | bidirectional | on change | manual data entry into an invoice |
The share of operations previously done by a human goes into automatic order export: the cart turns into a document with a number, status, and customer link.
Order processing time drops from manual passes to minutes, and the class of failures "sold something that is not in stock" is closed at the level of exchange rules, not manager vigilance.
We build the exchange idempotently: each message has a key, repeated delivery does not create a duplicate, a discrepancy goes into the exchange log and is handled from it.
Reducing manual operations here is not a slogan but a measurable value — you can see how many messages passed without edits and how many required intervention in a week.
Ways to integrate ERP with a website: comparing exchange modes
The exchange mode is chosen by two parameters: how often data changes and what delay between the accounting system and the storefront the business considers acceptable. Batch synchronization transfers a snapshot on a schedule, event-based exchange sends each change immediately.
The connection scheme then decides something else: who is responsible for delivery — a direct connection or an intermediary link.
The four schemes below are real options to choose between at the start; each covers its own class of tasks and requires its own customization.
| Exchange mode | When it fits | Limitations and what to customize |
|---|---|---|
| Scheduled batch synchronization | Catalog and stock with thousands of items, updated every few hours | Delay between sale and write-off; conflict resolution rules are needed if runs overlap |
| Event-based exchange | Orders, payments, reservations — sequence and minimal delay matter | Resend and duplicate protection are mandatory, otherwise an order will be duplicated on failure |
| Direct website connection to ERP | One sales channel, moderate load, simple exchange logic | The accounting system is exposed to the outside, and a failure of either side stops the exchange entirely |
| Through an intermediary link | Multiple sales channels, peak load, side decoupling needed | Takes longer to implement: queue, resend, and monitoring of undelivered messages are configured |
A common mistake at the start is to take a direct connection "while the volume is small": migrating to an intermediary link later affects both the website and the accounting system.
Implementation stages: from exchange audit to handover to support
Integration never starts with configuring the exchange — first we analyze how an order, product, and customer move between systems today. If this step is skipped, matching of item master data and statuses will surface in production: duplicate orders, diverged stock, lost items. That is why the first two stages take more time than the configuration itself.
- Exchange audit. We look at which flows already work, what operators transfer by hand, at what frequency and volume. We record weak points: where orders are lost, where stock diverges from actuals.
- Data map. We break entities into fields: order, line item, counterparty, price, warehouse, status. For each field we define the source system — otherwise a counter write will overwrite correct data.
- Matching rules. We agree on linking keys: SKU, barcode, external identifier. Separately we close units of measure, tax rates, and the order status reference — typical causes of desynchronization.
- Scheme and configuration. We assemble the exchange in a test loop: queue, retry on failure, operation log, responsible person notification. In 1С this is configured with standard exchange tools, without modifying the core.
- Testing on real orders. We run sales history and live scenarios: new order, cancellation, partial shipment, return. We reconcile amounts, stock, and statuses before and after — a discrepancy in at least one line item means going back to the data map.
- Handover to support. We provide regulations, flow diagram, instructions for operators, and a list of typical errors with responses to them. After that, support can be handled in-house or by our team.
Flow diagrams, matching rules, and support regulations
Exchange with ERP does not live in chat threads or in the developer's head.
After delivery, the customer is left with a set of artifacts by which the exchange can be modified, extended, and handed to another team — including troubleshooting any discrepancy in orders, prices, or stock. What exactly is included in the set:
- Data flow diagram — which entities and in which direction move between ERP and the website, where the point of truth is for price, stock, and order status, which events trigger the exchange immediately and which run on a schedule.
- Item matching rules — by which key a product and an item in the accounting system are linked (SKU, barcode, external identifier), how duplicates, analogues, and new categories are handled, what happens when a supplier changes the SKU.
- Access policies — which accounts and rights the exchange needs on both sides, what limits access to customer personal data, how keys are issued, rotated, and revoked, where secrets are stored.
- Exchange log — what is recorded for each operation: time, entity, identifier, result, error text. It is used to find a specific order and repeat the operation without a full catalog re-export.
- Failure regulations — system behavior when ERP is unavailable, accumulation of unsent orders, notification recipient, and the procedure for manually fixing disputed line items.
- Exchange documentation — description of fields and formats, a map of status and reference correspondence, instructions for the customer's manager, and the procedure for changing rules without stopping sales.
The set is assembled for your configuration, not from a standard template: when a warehouse or a new sales channel is added, it is extended rather than rewritten from scratch. Our engineers hand over the documentation together with a walkthrough for your team.
Case study: synchronizing orders and stock instead of manual exports
Starting point
The store and the accounting system 1С:Управление торговлей lived separately: stock was exported manually once an hour, orders were transferred by managers via copy-paste.
During sales, the export could not keep up — storefront still had items that were no longer in the warehouse, and some orders had to be canceled or reassembled.
The share of such cancellations reached every fifth per day, and an order reached accounting on average after 40–90 minutes.
What was rebuilt
The exchange was moved to a separate service: order events leave the store immediately, stock is updated based on actual warehouse movements rather than a schedule.
Each record carries an idempotency key — repeated delivery does not create a duplicate, and a failure on the accounting side does not lose the order: it stays in the queue and is retried with increasing delay.
Discrepancies are additionally reconciled by a nightly protocol so that the stock difference is visible before the shift opens, not after a customer complaint.
After that, an order reaches accounting in seconds instead of hours, and processing no longer depends on manual operations. Cancellations due to zero stock fell within the margin of error, and duplicate orders disappeared.
After that, the exchange lives on support: we monitor queue depth, event delivery delay, and the number of retries — a deviation notification arrives before a customer notices it.
How batch exchange differs from event-based exchange
Batch exchange runs on a schedule: the integration layer, at a set interval, selects records changed since the previous run from the accounting system and transfers them to the website in one portion.
Event-based exchange flips the scheme: the accounting system publishes an event at the moment of change — an order was created, stock changed — and it reaches the website almost instantly.
Hence the first difference — data delay: with batch exchange, stock and statuses are current as of the last run, and the discrepancy window grows with the interval.
Event mode reduces it to seconds but requires maintaining event order for a single entity and discarding duplicates so that repeated delivery does not overwrite a fresh state with an old one.
The load on the accounting system falls differently. A batch produces infrequent but heavy queries: the larger the catalog, the longer the run and the higher the risk of colliding with operational work during peak hours, while stretching the interval increases the delay.
A stream of events spreads the load but adds many small requests, so a buffer is placed in front of the accounting system — otherwise a burst of activity hits the database directly.
Support differs as well. Batch is simpler: a failure is fixed by re-running, the state levels out on its own because the source of truth is the accounting system. An event scheme needs retries, duplicate suppression, and queue lag monitoring.
The choice of mode comes down to what data delay the business actually notices. Orders, reservations, and stock on which a sale depends are more profitably run on events; item master data and characteristics that change rarely — in batches.
The working configuration is usually hybrid: an event loop for the critical parts, an hourly batch for the rest, and daily checksum reconciliation.
Common technical doubts before implementing exchange
Exchange with an accounting system is rarely turned on with a single switch — it is introduced so that the storefront continues to accept orders. Doubts before the start come down to five topics: downtime, item matching, access, load, and data protection.
Will the website need to be stopped during implementation?
We connect the exchange as a second loop: the storefront runs on the current catalog, and the new source is first populated and reconciled in test mode. Switching takes minutes and happens outside peak hours, and rolling back to the previous source is one setting.
What if product codes do not match?
We build a mapping table: accounting system SKU → website card identifier. Matching is done by SKU, barcode, or a "name + characteristic" combination; ambiguous items go into a report and are resolved before the exchange is enabled.
What access is needed to the accounting system?
A separate service account with minimal rights: reading item master data, prices, and stock; writing — only to orders and counterparties. There are no administrator rights, keys are stored in a secure vault and do not get into the code.
Will the load on the storefront increase?
The exchange runs in portions and transfers only changed records; the catalog is served from cache. The public part does not access the accounting system directly, so the product card response does not depend on its load.
How is customer data protected?
Transfer is over a secure channel, access by IP allowlist and tokens, personal data is not duplicated in unnecessary places. Every exchange is written to the log: you can see what was synchronized and when.
Let's discuss your exchange scheme and come back with an estimate and plan
Setting the task begins with what moves and in which direction. It is enough to list the entities — products, stock, prices, orders, customers — and indicate which system is considered the source of truth for each of them.
If an exchange scheme already exists, send it as is: even a one-page draft removes a round of clarifications.
To come back with an estimate of the work and a stage plan, we need the initial exchange data:
- list of entities and flow direction: what ERP gives to the website and what it receives back;
- access method: file export (CSV, XML), REST exchange, webhooks, or an intermediate table;
- frequency and volumes: how many items and orders per day, what data lag is acceptable;
- reference data and matching rules: by what attribute a product, order, and customer are linked, what to do with new items;
- failure behavior: resend, duplicate protection, exchange log, responsible person notifications;
- access: test loop, accounts, restrictions on ERP load;
- constraints on your side: maintenance windows, IT service regulations, who accepts the result.
Then we fix the exchange scheme, estimate the work for each block separately, and assemble a stage plan with checkpoints. Describe your situation in free form — we will come back with an estimate and a timeline proposal.
