System integration: ways to connect 1C, CRM and the warehouse — and the cost of ownership

System integration is a configured data exchange between programs, in which an event in one system travels on its own to every other system that needs it. In practice the choice comes down to five schemes: scheduled file exports, direct point-to-point links over an API, a message broker or data bus, off-the-shelf connectors and intermediary platforms, and a nightly ETL into a warehouse for analytics. All five work; they differ in cost of ownership and in how they behave when something fails. Three quantities decide the choice: how many systems are in the loop, how many documents pass through per day, and how much one duplicated or lost document costs.

Below is each scheme on its own: the volume it holds up at and where it hits its ceiling. After that — how an exchange breaks in production, what the cost of ownership consists of once the project is handed over, and what the company has to prepare before the start. Why systems should be connected at all and which link to begin with, we covered in a zoo of services: how to connect 1C, CRM, your bank and Telegram into one loop — that article assembles a specific loop around 1C, the accounting and ERP platform most Russian companies run on. This one is about choosing the exchange method and what it costs to run.

What methods of system integration are there?

There are five schemes, and the order of the list is at once the order of increasing reliability and increasing cost. The more systems in the loop and the more expensive an error in a document, the sooner you have to move from files and direct links to an exchange with queues and a log.

Tools of this class are already mainstream in Russian companies. In the Nexign survey, 71% of organizations use integration tools: ETL systems are in place at 62%, data buses (ESB) at 44%, ELT at 26%, and comprehensive platforms at 17% (summary on CNews, July 14, 2026). The sample size and survey period are not disclosed in the publication, so the figures show the balance of forces rather than an exact market share.

The fifth row stands apart, even though it is the most widespread of the five. ETL and replication solve a reporting problem: collect data from 1C, from CRM and from the warehouse system into one place so that the owner's dashboard can be calculated from it. The “order — reservation — shipment — payment” loop is not built on them: there you need freshness measured in minutes and a write-back into the systems. Companies often run both layers at once, and confusing them is an expensive mistake at the start of a project.

A hybrid is the normal state of a mature loop. The standard link between the website and CRM runs on a connector, the flow that is critical to the money goes through a broker with an exchange log, and reporting is collected by a nightly ETL.

When is a file exchange on a schedule enough?

A file exchange holds up while there are two or three systems, the data is needed once a day, and a delay of a few hours breaks nothing. A nightly transfer of stock levels to an online store, an export of sales documents to accounting, sending a price list to dealers — these are scenarios where a file is still cheaper than any other solution.

For Russian accounting this is a standard method. The EnterpriseData format, through which standard 1C solutions exchange data with each other, works over four channels: web services, a file in a folder, FTP and email. The applications keep track of the messages sent and received, so each session carries only the changes since the last one (the format description on v8.1c.ru).

The ceiling arrives at three points:

1. Delay. The salesperson sees the morning's stock and sells something that was shipped out overnight. The customer gets an apology instead of goods.
2. Fragility of the format. A column is added to the export and parsing fails on the receiving side. Worse still when it reads the data with an offset and silently writes nonsense.
3. Reruns. The operator restarted the exchange because “it didn't go through”, and half the documents were duplicated. Without an identifier on every row, a repeat is impossible to tell apart.

Keeping a file as the main channel makes sense until staff start checking its results by hand. Once a daily “did everything arrive?” reconciliation appears, the exchange already costs more than it looks in the estimate.

When do you need a direct point-to-point integration over an API?

A direct API link is the default method for two to four systems where the data is needed within minutes. One system calls the other in a strictly defined form and gets an answer immediately: a request from the website lands in CRM, a payment from the bank closes an invoice in accounting, an order status goes to the warehouse.

The ground for this is already prepared in the Russian stack. The automatic REST interface appeared in the 1C:Enterprise platform in version 8.3.5.1068. The application is published on a web server, and from then on an external system reads data, changes it, creates and deletes objects over the OData protocol (a post on the 1C:Zazerkalye blog, the REST interface description on v8.1c.ru). CRM systems, banks and marketplaces have APIs too.

A direct link breaks on three things:

1. An avalanche of links. Every new system pulls a bridge to every existing one. Five systems can require up to ten such bridges, eight systems up to twenty-eight. Each one lives its own life and needs its own support.
2. Someone else's API limits. Bitrix24, a Russian CRM and collaboration suite, caps request intensity with a Leaky Bucket algorithm. On most plans the counter drains at two requests per second with a bucket size of fifty requests; on Enterprise it is five requests per second and a bucket of two hundred and fifty. Exceed it and the next request comes back with status 503 and the code QUERY_LIMIT_EXCEEDED (Bitrix24 REST API limits).
3. No buffer. The receiver is unavailable for fifteen minutes, and the data from those fifteen minutes arrives nowhere. Exactly what was lost is known only to the log, which a direct link usually does not have.

The limits deserve a closer look, because this is where estimates go wrong most often. Thirty thousand product items sent one at a time at two requests per second is more than four hours of continuous work. A batch call helps halfway: it holds up to fifty commands and spends the request budget as a single one, but the nested calls are checked against a separate execution-time limit with the code 429 and OPERATION_TIME_LIMIT. The conclusion is simple: a large catalog is not pushed through REST in its entirety. You transfer only the changes since the last session, or move that part of the exchange to a file channel.

Direct links are good where there are few of them and they are simple. As soon as there are more than four, it is cheaper to build a central node once than to maintain a cobweb.

Why do you need a message broker or a data bus?

A message broker turns a failure into a delay. A message does not disappear until the receiver has acknowledged it, and it is redelivered once service is restored. A bus adds routing: all systems are connected to a single node that knows where each document goes and writes an exchange log.

The price of that reliability is mandatory protection against repeats. The RabbitMQ documentation puts it plainly: acknowledgements give “at least once” delivery, a message may arrive again, and the consumer must either deduplicate or process messages idempotently (the delivery reliability guide). In business terms this means: order number 4417 is created once, no matter how many copies of the message arrive.

A bus is justified with four or more systems, thousands of documents a day and a high cost per error — where a duplicated shipment or a lost payment costs real money. Below that threshold it is excessive: design, queues and monitoring eat up more than they save.

In Russian companies this class is widespread: in the same Nexign survey, ESBs are in place at 44% of organizations. The most frequent use case for integration tools is transferring data between systems (63%), followed by synchronizing reference data (44%) and end-to-end business processes (43%).

Should you take an off-the-shelf connector or an intermediary platform?

An off-the-shelf connector is worth taking when your scenario matches the standard one and you need the result this week. Exchange between the website and CRM, pushing deals into a messenger, exporting marketplace orders into accounting — here the vendor's template works, and building your own solution would be overpaying.

Three places where a connector hits its ceiling:

1. Exceptions in the process. Your own discount scheme, reservations against pre-orders, a separate procedure for branches and consignment goods. The template moves the fields its author provided for, and strictly in the direction he built in.
2. The route the data takes. With intermediary platforms, a copy of the data physically passes through the platform's cloud, often a foreign one. For requests containing names and phone numbers, that is already the territory of Federal Law 152-FZ, Russia's personal data protection law, and the question “where will the copy end up?” is settled before you connect anything.
3. Subscription economics. The plan is priced by transaction volume and grows along with the business. On a small exchange the subscription is cheaper than development; on a flow of thousands of documents the balance flips.

A sensible arrangement is a mixed one: the standard stays on a connector, what is critical to the money is built to fit. And the conversation is more useful when it is about flows rather than tools: which flow are you willing to hand over to someone else's template, and which one not.

How does an integration break in production?

Each scheme has its own typical failure, and all four are visible in advance — if you ask the right questions about the exchange before the work starts. Below is one failure per method, with the tell-tale sign by which it is recognized in a live company.

1. Duplicates from redelivery — the disease of queues and reruns. The message went out twice, the receiver created two orders, the warehouse reserved the goods twice. The sign: someone cleans up duplicates by hand every morning. Cured by an operation identifier and a receiver that remembers what it has already processed.
2. Reference data drift — the disease of any exchange without a data owner. Products and counterparties are entered independently in two systems, and six months later “Romashka LLC” exists in three spellings while one product has two part numbers. It is no accident that synchronizing reference data is the second most frequent scenario in the Nexign survey.
3. Silent failure — the disease of file exports and direct links. The exchange stopped overnight, nobody saw the error, documents pile up and the reports look plausible. It is discovered a month later through a discrepancy in the money, and the whole period has to be untangled at once.
4. Arguments over who owns a record — the disease of connectors with two-way synchronization. The price was changed in CRM and it is different in accounting; the delivery address was edited in two places. Until an owner system is assigned for each type of data, conflicts are resolved manually, case by case.

The scale of the task is visible in global statistics too. The tenth annual MuleSoft report was prepared together with Vanson Bourne and Deloitte Digital: 1,050 IT leaders were surveyed in October and November 2024. The average organization there runs 897 applications, of which 29% are integrated. 95% of respondents run into difficulties connecting data between systems (report announcement, Salesforce, January 29, 2025). Connectivity comes hard even where budgets and dedicated teams are allocated to it.

What makes up the cost of owning an integration?

The cost of ownership is four recurring expense items after handover, none of which appears in the development estimate. Comparing exchange methods by project price is pointless until those four lines have been calculated over a one-year horizon.

The return, meanwhile, is measurable. Among the effects of integration tools in the Nexign survey, about half of respondents name a reduction in routine operations, better data availability and reliability of the exchange; the exact shares for these three effects are not disclosed in the summary. Next come a lower total cost of ownership at 31% and faster time to market at 25%. Someone else's survey shows the direction; your own economics are calculated from your own documents and hours.

What has to be prepared before an integration starts?

Before the first line of code, the company closes six questions. Not one of them can be settled on the contractor's side, and they are exactly what determines whether the project reaches its effect or stalls halfway.

1. A documented process. Where the document is born, who changes it, how its journey ends. A process that lives only in people's heads has nothing to automate: the exchange will cast in code something nobody ever agreed on.
2. An owner system for each type of data. Accounting owns the money, CRM owns the customers, the warehouse owns the stock. The other systems read, but do not rewrite what is not theirs.
3. Access and separation of rights. Separate accounts for the exchange, a defined set of objects exposed outward, read and write rights granted separately. An exchange running with administrator rights is the most common hole in this kind of project.
4. Someone responsible for reference data. A real person who enters new items by the rules and sorts out duplicates. Without them, shared identifiers drift apart within a single season.
5. An agreement on monitoring. Who sees a failure, how quickly they respond, what they do with stuck documents. An unattended exchange works exactly until the first nighttime error.
6. A “before” measurement. How many documents a month are moved by hand, how many minutes each one takes, what an hour of an employee's time costs. Without those three numbers, there is nothing to show the finance director as the effect.

The first four points require no development budget and remove most of the risk. They also explain why the price of an integration cannot be quoted over the phone: the figure is assembled from the number of systems, the quality of the data and the number of exceptions in the process. If half the bookkeeping still lives in spreadsheets, the place to start is not the exchange but that part of the picture — we collected seven signs of that moment in when a business should move out of Excel.

Which to choose: a boxed exchange or a system built around your process?

A ready-made exchange covers the standard movement of documents, and for standard movement it is enough. The fork in the road runs through the exceptions: reference data, internal regulations, access rights and conflict resolution rules are different in every company, and they are precisely what determines which document goes where and who is entitled to change it. A boxed connector moves fields according to someone else's logic. When your logic differs from it, people make up the difference by hand, and the savings disappear.

The second reason to look beyond the box is the time horizon. An exchange lives as long as the business process does: the product range changes, a warehouse is added, a new marketplace arrives. A method chosen for today's volume has to withstand the volume two years from now — otherwise, in two years, the whole project is repeated from scratch. We covered the choice between a ready-made solution and a system built around your process separately — your own system or a boxed one. Two related topics sit nearby: how to choose a CRM system, if the sales side of the loop is not yet settled, and a WMS system, if the warehouse is still tracked on paper.

An integration loop can also be built as custom development — with queues and protection against duplicates, an exchange log, separated rights and failure monitoring, on your infrastructure or on servers in Russia. We work under contract, the data stays within the Russian perimeter, and support is discussed together with the project. If you are measuring this against your own loop, tell us about the task: we will go through the document flows, name a suitable exchange method for each and calculate the cost of ownership a year ahead.

Sources

• CNews, July 14, 2026: the Nexign survey on integration tools — 71% of organizations use integration tools, ETL at 62%, ESB at 44%, ELT at 26%, comprehensive platforms at 17%; use cases and effects of adoption. The sample size and survey period are not disclosed in the publication
• Salesforce, January 29, 2025: announcement of the tenth MuleSoft Connectivity Benchmark report — a survey of 1,050 IT leaders (Vanson Bourne and Deloitte Digital, October–November 2024), 897 applications per organization, 29% integrated, 95% run into integration difficulties
• RabbitMQ, delivery reliability guide — “at least once” delivery, redelivery of messages and the requirement that the consumer be idempotent
• Bitrix24, REST API limits — the Leaky Bucket algorithm, two requests per second and a bucket of 50 on most plans, error 503 QUERY_LIMIT_EXCEEDED, up to 50 commands in a batch call, a separate execution-time limit
• 1C:Zazerkalye: the automatic REST interface of applications — implemented in version 8.3.5.1068, the OData protocol, publication on a web server and the set of available objects
• 1C: description of the platform's REST interface — reading, changing, creating and deleting data, verification of user rights
• 1C: the EnterpriseData exchange format — a business-oriented format, exchange channels (web services, file, FTP, email), message tracking and transfer of changes only