Finding the money the marketplaces never paid you — a modelled omnichannel scenario

The figures below are modelled, not measured. They come from an internal ROI model built on realistic Malaysian inputs — order volumes, hourly rates, channel mixes and invoice counts of the kind we see regularly. This is not a customer, not a case study and not a success story. No real business is described, and nothing here is quoted from anyone. What a business of this shape would actually get depends on its own data, its own processes and its own discipline afterwards.

With that said, this is the scenario worth working through in detail, because it is the one where finance automation stops arguing about time and starts producing a number. Not "we saved you hours" — "here are the orders you were paid for, and here are the ones you were not."

The business the model describes

A fashion retailer, mid-sized by Malaysian standards. Six physical outlets. A Shopify storefront of its own. Shopee. TikTok Shop.

Around RM30 million a year flows back to it as payouts and takings across those channels. Finance spends roughly 90 hours a month matching payouts to orders — and never quite finishes, which is the detail that matters more than the 90. On top of that, 600 supplier invoices a month arrive as PDFs, photos, WhatsApp images and the occasional paper original, and someone keys them.

That is the shape. Multiple channels, one product catalogue, one bank account, and no single place where money received is joined to goods sold.

The campaign month that starts it

In the model, nothing breaks on an ordinary month. Ordinary months are survivable — the reconciliation runs late, a few hundred orders never get matched, and the difference gets written off as "fees" because that is the least alarming available explanation.

The trigger is a campaign month. Volume spikes, discounts are co-funded, returns arrive weeks later against orders from a settlement period that has already closed, and at the end of it the numbers do not reconcile by a meaningful amount. Somebody asks the obvious question: is that shortfall fees, returns, or a platform error?

Nobody can answer. Not because they are careless, but because answering requires matching thousands of individual orders to individual settlement lines, and nobody has ever had the time. The honest position is "we think it is mostly fees", and mostly is doing a great deal of work in that sentence — as we argue in why your Shopee payout never matches your sales report.

What the model switches on

Four things, all of them unglamorous:

• A payout reconciliation workflow per channel, working from settlement detail rather than settlement summaries.
• Order-to-payout matching at the line level — every order tracked from sale, through the hold period, to the money that actually arrived against it.
• Document AI on supplier bills, so the 600 monthly invoices are read and coded rather than typed.
• An exception dashboard — the part that decides whether any of this works, because the output of automated matching is not a tick, it is a short list of things that did not match.

The model assumes around 100 hours of internal effort to get there: mapping how each channel's settlement data is structured, agreeing what counts as an acceptable variance, cleaning up the product and order references that need to be consistent across channels, and training the two or three people who will own the exceptions. That is real work by the client's own staff, and a model that leaves it out is lying to you.

The channel specifics are where most of that effort lands, and they differ more than people expect: Shopee, TikTok Shop and Shopify each have their own settlement structure, fee vocabulary and clock, and the outlets' till data — Xilnex in this model — has to arrive in a form that sits alongside them.

Why 90 hours a month never finishes the job

Worth pausing on the arithmetic, because it explains the whole scenario.

Ninety hours across a month is roughly four working days of one person's time. Against RM30 million of payouts spread over tens of thousands of orders in three online channels plus six tills, four days buys you summary-level checking. You can confirm that the payout total matches the platform's own report of the payout total. You cannot confirm that the payout contains every order it should.

So the work is not slow because the team is slow. It is slow because it is the wrong size for the method. Manual reconciliation at this volume does not produce a wrong answer — it produces no answer, and the gap gets filled with an assumption. That is the real cost, and it is invisible on any timesheet.

What the model produces on these inputs

Three outcomes, in descending order of how much anyone will care:

Leakage identified: around RM45,000. Short payments, fee calculations that do not match the stated rate, and refunds credited to the customer where the goods never came back. Money the business had already earned and was not paid.

Reconciliation effort: 90 hours a month down to 27. Not to zero. Twenty-seven hours is what it costs to review exceptions, chase the ones worth chasing, and sign off a month you can actually defend.

Supplier invoice handling: 100 hours a month down to 38. Six hundred invoices read, coded and queued for approval instead of keyed, with a human checking the ones the system is unsure about — the pattern we set out in AI in accounts payable.

Note what the model does not say. It does not say what any of this costs, because that depends entirely on scope — how many channels, how many entities, how many processes — and stating a figure in an article guarantees it goes stale. Whether it pays back on these numbers is a calculation you do against current pricing, not one we do for you here.

Why the leakage figure is set at 0.15% of payouts

RM45,000 sounds like a big number and is in fact a deliberately small one. On RM30 million of payouts it is 0.15%.

That rate was chosen to be defensible rather than impressive. Fifteen basis points of leakage across three marketplace channels, a campaign period, co-funded promotions and a returns tail is a conservative assumption — most of the deductions in a marketplace settlement are entirely legitimate, and the model does not pretend otherwise. It assumes the overwhelming majority of the RM30 million was correctly paid and correctly deducted, and that the recoverable portion is a thin sliver at the edges.

It is also worth being clear about what "identified" means. Identified is not recovered. Some of it gets credited back when raised with the platform. Some of it is a fee the business agreed to years ago and forgot. Some of it is a refund the customer will never return goods against, and knowing about it changes your policy rather than your bank balance. The model produces a number you can act on, not a cheque.

A discovered number is a different conversation from a saved hour

Here is why this scenario matters more than the hours in it.

Every automation pitch offers time back, and finance directors have learned to discount time-back claims, correctly, because released hours have a habit of quietly refilling with other work. Sixty-three hours a month across reconciliation and invoices is genuine capacity, but it is capacity — it becomes value only if someone deliberately spends it on something better than data entry.

RM45,000 of identified leakage is a different kind of claim. It is a list. Order by order, this is what you were paid and this is what you should have been paid. You can open it, disagree with individual lines, raise the ones that hold up, and change your process where they do not. It survives a sceptical reading in a way "we saved you time" does not.

That is also the honest reason reconciliation is the strongest starting point in a business like this one. It is high-volume, rule-based matching with a small tail of genuine judgement calls — the exact shape of work that automates well — and its output is evidence rather than a feeling. We have written about what that design target looks like in practice in what 98% automated reconciliation means; the 98% is a deliberate design target, not a measured result, and the missing 2% is the exception queue that a person still owns.

Six outlets and three channels on one set of numbers

The omnichannel part is not a bolt-on to this scenario. It is the reason it is hard.

Six outlets and three online channels mean the same garment has several identities — a SKU at the till, a listing ID on each marketplace, a variant in the storefront — and money arrives for it through several different mechanisms on several different clocks. Counter sales settle same-day through a payment gateway. Marketplace orders settle after a hold period, net of deductions, in batches that mix sales from different weeks. Storefront orders settle on the gateway's schedule.

Reconciling one channel well is useful. Reconciling all of them into a single position is what lets somebody finally answer "which channel is actually making us money", which most multi-channel retailers cannot state accurately. That question is worth more over a year than the RM45,000 — see reconciling sales across multiple marketplaces and building an omnichannel retail business for the operational side of it.

What would make this model wrong

Three ways this scenario fails to land, all of them worth saying out loud.

Nobody owns the exception queue. Automated matching converts a big undone job into a small, specific, undone job. If the 27 hours are not actually staffed, the exceptions pile up and you have bought a dashboard nobody reads. This is the most common failure and it has nothing to do with the software.

The leakage was already smaller than modelled. A retailer with tight channel management and a finance team that already spot-checks settlements at line level may have far less than 0.15% sitting there. The reconciliation still pays for itself in confidence and close speed, but the headline discovered number shrinks, and with it the easy business case.

The freed hours are not redeployed. Sixty-three hours a month is either analysis, faster close and better supplier terms, or it is the same team working slightly less hard at the same things. That choice is management's, not the system's, and the model cannot make it for you.

Common questions

Are these real customer results?

No. Every figure in this article is modelled. It comes from an internal ROI model using realistic Malaysian inputs — payout volumes, invoice counts, hourly rates and channel mixes typical of a mid-sized omnichannel retailer — and no real business, named or unnamed, is described. There is no client, no case study and no quotation from anybody. We publish it as a worked scenario because the arithmetic is useful to reason with, not because it happened.

How can reconciliation identify money that was never paid?

By matching at the order level rather than the payout level. A payout total will usually agree with the platform's own report of that payout total, which tells you nothing about whether every order that should have settled actually did. Order-level matching produces a list: orders sold but never settled, deductions that do not match the stated fee, refunds credited where goods never returned. Identified is not the same as recovered — some lines are legitimate fees you had forgotten agreeing to.

Why is the modelled leakage only 0.15% of payouts?

Because a conservative assumption is more useful than a flattering one. Most deductions in a marketplace settlement are entirely correct, and the model assumes the overwhelming majority of the RM30 million was properly paid and properly deducted. Fifteen basis points across three channels, a campaign period, co-funded promotions and a returns tail is a thin sliver at the edges. A business with tighter channel management may find considerably less, which is a good outcome and a weaker business case.

Does this work if we sell in physical outlets as well as online?

That is the harder version of the problem and the one this scenario describes. The same product has several identities — a SKU at the till, a listing on each marketplace, a variant in the storefront — and money arrives through different mechanisms on different clocks. The value is in joining them: one stock position, one ledger, one answer to which channel actually makes money. It also means more mapping work up front, which the modelled 100 hours of internal effort accounts for.

Whether a scenario like this holds for your business depends on things we cannot see from here: how much of your settlement data you can get at line level, how consistent your order references are across channels, and whether anyone will genuinely own the exceptions afterwards.

If you want to run the same arithmetic against your own volumes — including if the honest answer is that your leakage is too small to justify it — talk to us.

Related: why multichannel sellers lose track of money and one source of truth for multichannel sellers.