How SellerHub Found Revenue Discrepancies in Large Catalogs

10,000+ SKUs on a single marketplace — that was the scale at which SellerHub’s financial reconciliation started behaving differently than it did on test catalogs.

The task sounded straightforward: compare the seller’s expected revenue with the actual revenue on the marketplace and show the discrepancies. In practice, those two numbers sat on top of commissions, penalties, logistics, and each marketplace’s own rules. The same order event could appear in the report as different line items, with different dates and levels of detail.

For a small seller, you can still work through that by hand. On a large catalog, the report turns into a set of related charges and deductions, where an error in one category looks like “revenue doesn’t match.”

How we noticed the problem

The first discrepancies looked like a formula bug. The expected amount in SellerHub differed from the actual amount in the marketplace report. And the difference was not stable: on some data sets everything matched, while on others there were leftovers in commissions, penalties, or logistics.

We started with the obvious: checked how we calculate revenue, which deductions we subtract, and which charges we add back. We looked at commissions separately, logistics separately, and penalties separately. This was the part of the investigation where it is easy to get stuck: every marketplace has its own calculation model, and you want to reduce everything to one neat scheme.

A practical detail: we were not arguing about where to add another if, but about whether to treat the discrepancy as a bug or as a normal consequence of report granularity. For the seller, the answer is simple: if the expected and actual revenue numbers differ, they need a clear report, not an explanation of marketplace quirks.

Where we looked in the wrong place

At first we focused on the math. It seemed like the problem was in the rules: the wrong commission rate, logistics assigned to the wrong place, penalties handled incorrectly.

But some of the discrepancies could not be explained by formulas. The same rules worked on small volumes, but with large sellers there were missing items and an incomplete picture. That was an important signal: if the business logic is the same but the result depends on catalog size, you need to look not only at the calculation, but also at how you fetch the data.

For large sellers, each marketplace can have 10,000+ SKUs. Reconciliation at that scale runs into external integrations: reports have to be fetched in batches, pages have to be traversed correctly, rows must not be lost between requests, and everything must not be processed as a single array.

What turned out to be the cause

The cause was not one universal bug. The problem had two layers.

The first layer was the different rules used by marketplaces. Commissions, penalties, and logistics are not the same entities across all platforms. In some places they arrive as separate line items; in others they affect the final amount already in the marketplace report. That meant reconciliation could not be just a comparison of “expected X, got Y” without explanation.

The second layer was volume. For sellers with large catalogs, batch processing and pagination became critical. If the integration does not fetch the full report or tries to process a large set in one pass, the final reconciliation becomes unreliable. From the outside, this looks like a financial discrepancy, even though part of the cause lies in how the data is delivered before calculation.

We separated these things. A discrepancy caused by marketplace rules is one thing. An incomplete sample caused by pagination or overly large processing is another. In the seller-facing report, they should not be mixed together.

What we changed in reconciliation

We rebuilt reconciliation around automatic discrepancy detection and a report that shows the seller exactly where expected revenue differs from actual revenue.

For large sellers, we focused on handling volume:

• data is fetched page by page, so it does not depend on report size;
• calculation runs in batches, not in one large pass;
• commissions, penalties, and logistics are treated as separate discrepancy categories;
• the final report is generated after the integration has collected all required pieces of data.

This did not eliminate differences between marketplaces. Those still have to be handled separately. But it became easier to separate financial logic from transport issues: if revenue does not match, we can see whether it is a commission, a penalty, logistics, or an incomplete data set from the external integration.

The next step for problems like this is always the same: do not trust a single final number. First check that all report pages arrived and that the batches were processed, and only then argue with the formulas.