Syncing stock between 1C, Wildberries and Ozon: why the numbers drift apart and how to line them up

Take a home goods online shop as an example: 280 orders a day, selling on its own website, Wildberries and Ozon at the same time, a team of 14. Stock levels in four places (the website, Wildberries, Ozon and 1C) don't match. A manager reconciles them by hand three times a day, and the shop still sells goods it doesn't have in the warehouse.

A gap of a few percent looks harmless until you look at the consequences. Each such sale means a cancellation that is the seller's fault: a marketplace penalty, a refund and an exchange of messages with support. On top of that, someone spends hours on work that produces nothing: reconciling four sources three times a day, only for them to drift apart again by evening.

The example comes from a ready-made solution: a process audit for an online shop. I've worked it out in full but haven't set it up for a client yet. So the shop in this article is hypothetical, and every figure about it is an estimate. Where I refer to projects that are already running, I name them.

Often a sync between the systems is already in place, and stock still drifts apart. The cause lies in the quantities themselves, the numbers it copies from one system to another:

• 1. Different codes. The same product has one code in 1C, another on Wildberries, another on Ozon and another on the website. Until something records that these are one product, the systems treat them as four.
• 2. Different units of measure. One system counts the product in pieces, another in sets or packs. The number “12” means a different quantity of goods in each, and the sync copies it as it is.
• 3. Different stock registers. Which number do you send to the marketplace: what is physically in the warehouse, or what is still free after the orders you've already accepted? In 1C these are different quantities. Until someone decides which one is needed, the sync will keep mixing them up.

Switching from a daily export to an hourly one doesn't remove any of these three causes: it only changes how often the sync runs. Infrequent syncing does add a fourth problem, though: a whole day of sales passes between two daily exports, and at 280 orders a day that is a noticeable volume.

The first step is to bring every code for a product into one table: the 1C code, the website SKU, the Wildberries listing number, the Ozon number and the unit of measure. It's tedious work, and you can't hand it to a program: the decision that two codes mean the same product is made by a person who knows the range.

Until that table exists, any integration diligently matches the wrong products. It does so silently, with a green sync status, while the discrepancy in the warehouse keeps growing.

A requirement I always set: the operator edits the mapping table themselves, without a developer. That's how it works in my project syncing orders with the warehouse's working spreadsheets: each spreadsheet has its own list of product names, and adding a line to it takes no code change. Otherwise every new product would turn into a request for development work.

The second decision takes five minutes, and nothing works without it: one system has to be named the main one. In the example it's 1C. It holds the stock figure, and the website, Wildberries and Ozon receive it. Orders from all channels come together in one window in RetailCRM, an order management system.

The test is simple. If your staff answer the question “where is the correct stock figure?” with “it depends”, you've found the cause of the discrepancy and can stop looking. When several systems have an equal say, sooner or later the sync produces a number that exists in none of them.

A caveat: the main system must be the one people actually work in. If the real records are kept in RetailCRM or a spreadsheet, and 1C is filled in once a week after the fact, a sync led by 1C will argue with your staff every day. In that case you move the record-keeping first and build the sync second. Those are two separate projects.

In the ready-made solution the sync runs in n8n, a workflow builder, on the shop's own server in Russia, so the data never leaves the country. Every 15 minutes the workflow polls 1C, the website, Wildberries and Ozon, matches the data through the mapping table, then recalculates stock on the website and updates the listings on both marketplaces.

The interval depends on order volume: at 280 orders a day, only a handful of orders arrive in 15 minutes. In my project syncing orders with the warehouse's working spreadsheets, the flow is different: the sync runs every 30 minutes, and that is enough. First count how many orders fall within one interval, then choose the interval.

Similar connections with 1C, Bitrix24 and amoCRM are described in the services catalogue.

Promising zero would be dishonest. There is always a gap between the moment a marketplace accepts an order and the moment the write-off goes through in 1C. During that gap the marketplace shows slightly more stock than there really is. A small residual discrepancy builds up during exactly that time.

I ran into the same thing when I reconciled revenue across three sources. Traced order by order, almost all of the 8.4% gap came from cancellations and partial refunds. The remaining 0.33% came from orders placed near midnight.

For stock, this leads to one conclusion. If a fast-selling product sells out faster than one sync cycle, you can't give the marketplace all of the free stock: part of it is held back as a reserve. How much to hold back is the owner's call, a choice between the risk of selling too little and the risk of cancellations. Decide this before launch.

A sync runs unattended, so it needs safeguards. Here are seven requirements you can hand to any contractor as a list. For each one, the answer should be “yes, and here's where you can see it”:

• 1. A schedule. The sync starts by itself, and you know how often.
• 2. A daily reconciliation. Once a day the system compares stock across all sources and produces a list of discrepancies.
• 3. A check that the sync is alive. A separate “the sync is running” signal. Silence can't be taken to mean all is well: a stopped sync is just as quiet as a healthy one.
• 4. A nightly backup. And at least one tested restore from it: a backup nobody has ever restored from is only a hope.
• 5. Failure alerts. A message to a person, retries, and re-sending of records that didn't get through.
• 6. Honest behaviour on failure. If a marketplace doesn't respond, that shows up as “no connection”. Otherwise incomplete data is silently passed off as complete, and someone makes a decision based on it.
• 7. A safe switch-over. The move to live data happens in parallel: for a while the sync writes both to the working system and to a reference copy. The daily reconciliation catches any differences. To roll back, you turn off one schedule. No big switch-over on a Monday morning.

How this works in my projects: eight scheduled jobs with monitoring in the project syncing orders with the warehouse's working spreadsheets; a separate failure signal from each data source in the internal CRM for an operations team.

And the order of work that saves the most money: first measure the discrepancy, then fix it. Without a figure for “how many percent right now”, you can't choose what to fix first or prove that anything improved.

For a shop like this, the ready-made solution has three fixes: the stock sync, AI for first-line support, and documents from 1C. By my estimate, together they free up 142 hours a month: almost one full-time role on a 40-hour week, or ₽89k a month in payroll savings. The investment is ₽600k: ₽380k for the in-depth audit and ₽220k for the implementation.

Check the calculation yourself: ₽600k divided by ₽89k a month means the investment comes back in about 7 months from payroll savings alone. Savings on marketplace penalties for cancellations aren't included: they depend on the shop.

One caveat, so the numbers above aren't misread: the stock sync is only one of the three fixes. The 142 hours are the total for all three, and crediting them to the sync alone would be wrong.

There is one clear way to choose: count how many non-standard rules you have. If you have none, buy a ready-made module. It's installed without development work, and its maker looks after support. Ordering a custom sync to get the same result makes no sense, and I'll tell you so straight away.

Non-standard rules include: bundles that are separate items in 1C but sell as one product; mixed units of measure; stock in several warehouses with different shipping times; your own reserve rules for product groups; manual corrections that must not be overwritten. A ready-made module can usually handle one or two such rules. With five, you'll be working around its limits by hand, which is exactly the work you wanted to get rid of.

And three situations when you don't need a sync at all:

• · Your volume is small. If one person does all the reconciliation in half an hour a day and no orders get lost, a sync won't pay off. Do the maths for your own warehouse.
• · The product catalogue is a mess. Duplicate items, products without codes, temporary entries in the warehouse. Automation will lock that mess in and repeat it four times an hour.
• · Nobody is responsible for 1C. If right now nobody understands your accounting system, a sync adds one more system without an owner. Find that person first.

Some figures, so you don't have to guess. The audit costs ₽5,000 and counts toward the first project. A pilot costs from ₽60,000 and takes 1–2 weeks: one marketplace, one sync scenario. A full setup costs considerably more: in the example above, the in-depth audit and the three fixes come to an estimated ₽600k. One-off and monthly costs and the expected payback are on the pricing page, in the process automation section. I break down what goes into a quote for different tasks in What AI implementation costs.