09 Unit economics calculation and financial reporting for marketplace sales

Sales run on four marketplaces: Wildberries, Ozon, Lamoda and Detsky Mir. Each one hands back its data its own way: its own reports, its own timing, its own names for the same things. To understand how much the company earned, someone exported reports from all four, combined them into a spreadsheet, and reconciled it against what production was seeing.

The main difficulty wasn't the volume of work, it was that marketplace revenue is not what lands in the account. Between the storefront price and the company's money sit the platform's commission, logistics, storage, receiving, returns, penalties, and promotional discounts. Some of these deductions arrive after the sale itself, and tying them to a specific product in a spreadsheet by hand is nearly impossible.

The question of which SKU is losing money had no answer: the averaged calculation hid unprofitable products behind profitable ones.

So profit was calculated as an average, pooled across the whole assortment. And in a calculation like that, an unprofitable SKU is invisible: it hides behind profitable ones, keeps selling, and quietly eats into the margin of the rest. The question of which product is losing money had no answer, even though it was the most important one.

And 1C stood apart on its own. Cost of goods and accounting reports lived there, marketplace reporting lived in spreadsheets, and to bring the two together someone exported the 1C report and carried it over by hand at the end of every period.

A system that pulls the data itself. Connections to the Wildberries, Ozon, Lamoda and Detsky Mir APIs run on a schedule: orders, sales, returns, and settlement reports arrive in a shared database without human involvement and are normalized to a single shape, so that a SKU sold on every marketplace becomes one SKU with several sales channels.

Unit economics is calculated on top of that data. The system breaks down revenue across every platform deduction: commission, logistics, storage, receiving, returns, penalties, discounts. It then adds cost of goods and shows how much the company earns on a specific SKU. Not on average, and not by category, but by product.

A SKU sold on all four marketplaces became one SKU with several sales channels, and it gained its own economics instead of an averaged one.

Internal financial reporting sits on top of that: what used to be assembled by hand at the end of the period is now built from the same data at any moment. The report stopped being the result of someone's week and became a state of the system.

Syncing with the marketplaces is not a one-time button, it's a continuous background process, and it's built to survive failures. Marketplace APIs don't always respond: rate limits, timeouts, reports that don't generate instantly. That's why exports run as scheduled task queues: a task that fails on the first try goes back into the queue instead of getting lost silently.

This matters more than it seems. In a financial report, a quietly missing chunk of data is worse than an obvious error: the report looks complete, the numbers look plausible, and a decision gets made on an incomplete picture. A queue with retries is what turns "the data arrived complete" into a verifiable property instead of a hope.

Certain deductions arrive from the platform with a delay, after the sale itself. The system ties them to the sales they belong to and recalculates the SKU's economics, so the report for a period gets refined as data comes in, rather than staying a snapshot from the day it was exported.

1C remained the company's accounting system, and the marketplace system doesn't replace or duplicate it. It only reads what it needs from 1C and writes nothing back: accounting stays where accounting and production keep it.

What comes from 1C is what unit economics can't be calculated without: cost of goods and accounting reports. Without cost of goods, the marketplace-side calculation only shows how much the platform withheld, not whether the company actually earned anything.

As a result, carrying the 1C report into a spreadsheet by hand at the end of the period is gone from the process, and accounting and marketplace sales stopped being two separate versions of reality that someone reconciled once a month.

The company got an answer to a question it didn't have before: how much each SKU earns after every platform deduction. That changes not the reporting but the decisions: which product to push, which to reprice, which to drop from the assortment.

Putting the report together stopped being work. Data arrives on its own, deductions get broken down on their own, and the report is available whenever it's needed, not a week after the period ends.

And the calculation became reproducible. As long as economics is calculated in a spreadsheet, it depends on who assembled it and how; in the system, the same data always produces the same number, and that number can be traced back to the original line of the platform's report.