A walkthrough from a live project: why the same SKU shows different numbers in four systems, what to fix in what order, and when you should not build a sync at all
Short answer: they don't match because in four systems it is effectively four different products. The same item carries different identifiers, different units of measure and different stock registers — and a once-a-day export fixes none of the three, it only changes the cadence. Below is what to do, step by step, based on a shop where drift went from 7.4% to 0.3%, plus the cases where you don't need a sync at all.
A home-goods online shop: 280 orders a day, 12 SKU categories, selling on its own site, Wildberries and Ozon at the same time, a team of 14. Stock levels across four places — site, Wildberries, Ozon and 1C — differed by 7.4%. A manager reconciled them by hand three times a day, and the shop still sold items it did not have and ran into cash-flow gaps.
The percentage looks harmless right up until you translate it into consequences. Selling an item you don't have means a seller-fault cancellation: a marketplace penalty, a refund and a support conversation. On top of that sits a person doing work that creates nothing — reconciling four sources three times a day so they drift apart again by the evening.
The inventory numbers come from one project: online shop process audit. No industry averages — only what was measured in one warehouse. Where I lean on a neighbouring project, I name it.
When I dug in, it turned out the drift was not caused by a "bad sync". There was a sync. What differed were the quantities it was adding up:
None of the three is fixed by moving from a daily export to an hourly one. Cadence answers "how often"; what drifts is what gets reconciled. Cadence does add a fourth problem of its own: a full day of sales fits between two daily exports, and at 280 orders a day that is a meaningful volume.
The first thing we built was one mapping table holding every code for a given item: the 1C code, the site SKU, the Wildberries listing id, the Ozon id, the unit of measure. Boring work that cannot be delegated to software: the decision "this is the same product" is made by a human who knows the catalogue.
Without that table, any integration carefully reconciles the wrong thing with the wrong thing — silently, with a green sync status. The more expensive the connector, the less visible the error: it reports success while drift grows in the warehouse.
A requirement I now insist on: the mapping is edited by the operator, without touching code. In a neighbouring project — syncing paid orders into live warehouse spreadsheets — the name maps are per-workbook for exactly this reason. Otherwise every new item turns into a development ticket.
The second decision takes five minutes to make and nothing works without it: name one system as the master. Here that was 1C — it owns the stock number, while the site, Wildberries and Ozon receive it. Orders from all channels land in a single window in RetailCRM.
The test is simple. If the answer to "where is your correct stock number" is "well, it depends", you have found the cause of the drift and can stop looking. Three equal systems will always negotiate their way to a fourth number that exists in none of them.
A caveat: the master must be the system people actually work in, whatever it cost. If real bookkeeping lives in RetailCRM or in a spreadsheet while 1C is backfilled once a week, a sync mastered on 1C will argue with your staff every day. Then you move the bookkeeping first and build the sync second — two different projects.
The sync runs on n8n hosted on the client's own server, so all processing stays inside the Russian perimeter. Every 15 minutes the workflow polls 1C, the site, Wildberries and Ozon, reconciles what it gets through the mapping table, then recalculates stock on the site and updates the listings on both marketplaces.
The interval comes from order volume: at 280 orders a day, a 15-minute window holds a handful of orders rather than a day's revenue. In a neighbouring project — paid orders into live warehouse spreadsheets — the flow is different, the interval is 30 minutes, and that is enough. First count how many orders fit into an interval, then pick the interval.
I deliver this kind of work as a standalone service — integrations with 1C, Bitrix24 and amoCRM.
Promising zero would be dishonest. There is always a window between the moment a marketplace accepts an order and the moment the write-off lands in 1C: inside it, the marketplace stock is slightly higher than the real one. The remaining 0.3% is the size of that window.
One consequence: if a fast-moving item sells out quicker than one sync cycle, you cannot publish the entire free stock — part of it is held back as a buffer. That is an owner's decision about which is more expensive, underselling or cancelling. Make it before the sync goes live.
A sync runs unattended, so it needs an operations layer around it. In the warehouse spreadsheet project that layer is six scheduled jobs: the exchange every 30 minutes, a daily snapshot export, a healthcheck, a nightly reconciliation, a nightly backup and a test run against the real environment. Plus Telegram alerts, retries on failure and self-healing for records that did not make it through.
The second mandatory property is honest degradation. If a marketplace is not responding, that has to be visible rather than look like "no stock". In the internal CRM for an operations team I count failures per source and pass them up. Otherwise incomplete data is silently presented as complete, and someone makes a decision on it.
Third: how you switch it on. I migrate onto live data as a parallel track — the sync writes to the production system and to a reference copy at the same time, the nightly reconciliation catches divergence, and rollback is turning off one schedule. No big-bang cutover on a Monday morning.
And the sequencing that saves the most money: drift is measured first and fixed second. Without a number for "how many percent right now", you cannot choose what to fix first or prove anything improved.
Inventory drift: 7.4% before, 0.3% after — a 25× improvement, and selling non-existent stock all but disappeared. 142 hours a month were freed up, roughly 1.1 FTE, or about ₽89k a month in estimated payroll savings. Total invested: ₽600k — ₽380k audit + ₽220k implementation.
Do the division with me, on the one figure you can check: ₽600k over ₽89k is the investment back in about 7 months on payroll alone. The case page states 4.2× over 12 months: that adds avoided penalties for selling out-of-stock items on top of payroll, and I don't publish the penalty figure — so this article sticks to what you can recompute.
Now the honest part, without which the numbers above read wrong. Gains from faster support and more accurate purchasing were not counted at all. And of the three automation points, inventory was one: support response going from 47 minutes to 6, and month-end close from 9 days to 2, came from the other two. Attributing those to the inventory sync would be a lie.
There is exactly one sensible selection criterion: how many non-standard rules you have. If the answer is zero, buy the box. It is cheaper, faster to install and someone else maintains it. Paying for a custom sync to get the same result is a bad trade, and I say so up front.
Non-standard means: bundles that sit in 1C as separate items but sell as one; mixed units of measure; stock across several warehouses with different lead times; per-category buffer rules; manual corrections that must not be overwritten. One or two such rules a packaged product usually survives. Five, and you will work around its limits by hand — precisely the work the project was supposed to remove.
And three situations where you should not build a sync at all:
My rates for this work are public: business process automation — one-off cost, monthly cost and expected payback period.
Six questions, each with a one-sentence answer. No answer, or one that sounds like "well, it varies", and you have found where the money leaks.
If you confidently close only one or two of the six, the place to start is not buying a connector — it is measuring. A ₽9,900 audit: where exactly your numbers diverge, how big the drift is today and what pays back fastest. You get a prioritised list with a payback estimate per item, and you decide. Sometimes the honest answer is that you don't need this yet, and I will say so.
If this was useful, forward it to whoever reconciles stock by hand every morning. That person will tell you most precisely how much time it actually costs.
— Vyacheslav Chukhaldin, Kaliningrad, 2026-08-06
I'll tell you what to deploy in your business first, what the payback looks like, and whether you need AI for the task at all (sometimes you don't).
Or just send your question — I reply within 2 hours