Where omnichannel money actually lands

Sell one thing today and you know exactly what happened. Sell four hundred things across four channels and you will not see the money for a fortnight, in pieces, from six different senders, none of which will tell you which sales they represent.

This is the part of omnichannel retail nobody warns you about. The stock problem is obvious and everyone talks about it. The money problem is quieter, arrives later, and is the reason the accounts take a week to close.

Six senders, six clocks

Walk through a single ordinary day in a retail business that sells in a shop and online.

Cash at the counter. Arrives instantly, in a drawer, and reaches the bank whenever somebody takes it there. The only takings you hold physically, and the only ones that can walk away.

Card at the counter. Batched by the terminal, settled by the acquirer a day or three later, net of a fee that is deducted before you see it.

Your own storefront. Paid through a gateway. In Malaysia that is often Billplz for online banking, GrabPay for wallet payments, Stripe for cards, and increasingly a buy-now-pay-later option like Atome or a cashback platform like ShopBack. Each settles on its own schedule with its own deduction.

The marketplaces. Shopee, TikTok Shop, Lazada each pay in batches, several days after the order, net of commission, transaction fees, service fees, seller-funded vouchers and whatever campaign you joined. One deposit covers many orders across several days.

Six senders. Six clocks. And every one of them nets its fees off before the money arrives, which is the detail that turns this from an administrative chore into an accounting problem.

Ending up with several gateways rather than one is the normal outcome rather than a mistake, for reasons set out in running more than one payment gateway.

Why the bank statement will not save you

The instinct is to work from the bank. Money came in, tick it off, done.

It does not work, for a specific reason: a deposit does not correspond to anything in your records. A marketplace payout of RM8,432.17 is not a sale. It is the residue of perhaps ninety sales, minus commission on each, minus a voucher you co-funded on some of them, minus a refund on two, plus an adjustment for something that happened last week.

You cannot match that to an order because it is not an order. You can only match it by decomposing it.

Which is why so many retailers end up doing the only thing that seems possible: treating the deposit as the revenue. That is the single most expensive mistake in multichannel retail. It quietly books your fees as though they never existed, understates your true sales, and makes it impossible to tell a channel with thin margins from a channel with fat ones.

What reconciliation actually means here

Not "does the bank balance". It means every deposit is broken back down into the orders it paid for, and every deduction is attached to the order that incurred it.

Done properly, three things become answerable that were not before.

What did this channel really earn? Gross sales minus the commission, transaction fee, service fee, voucher co-funding, absorbed shipping and returns that belong to those specific orders. That number is often startlingly different from the one on the seller centre dashboard.

Which deductions are legitimate? Most are. Some are not. A promotional campaign that ended in your head but not in the platform's settings will keep co-funding discounts for as long as you let it. A refund where the commission should have partly reversed and did not is a small amount on one order and a meaningful amount across a quarter.

Where is the money that has not arrived? Orders delivered three weeks ago with no payout against them. This is not usually theft or platform error. It is usually a hold, a dispute, or a settlement that failed quietly. But you only find it if something is watching for orders that were never paid.

Doing this by hand is possible and some businesses genuinely do it. It costs a few days a month and stops being possible somewhere around a few thousand orders.

The counter is the awkward one

Online money is messy but at least it is data. Counter takings are physical, and that makes them a different kind of problem.

Cash has to be counted, agreed at shift handover, and banked, and every one of those steps is a place where a difference can appear. Card takings at the counter settle in batches that rarely line up neatly with a trading day, so the terminal report and the day's sales disagree by whatever crossed the boundary at closing time.

Neither is an error. Both look like one at month-end if nobody has connected the till to the rest of the system. That is the practical argument for integrating a POS such as Xilnex rather than reconciling the shop separately: not so the till behaves differently, but so the counter's takings sit in the same ledger as everything else, and the differences that do appear are visible while somebody still remembers the day.

Where automation genuinely helps, and where it does not

Matching is repetitive, rule-shaped work, which is exactly what software is good at. A settlement file arrives, its lines are matched to orders, fees are attached, and the exceptions are put in front of a person.

The design target for that matching is 98%, not 100%, and the missing two per cent is deliberate rather than an admission of defeat. Platforms introduce new fee types, change how a campaign is reported, or settle something in a way nobody has seen before. A system that claimed to handle every case would be quietly guessing at the ones it did not recognise, and a wrong match is worse than an unmatched line, because it looks finished.

So the useful goal is not an empty exception queue. It is an exception queue short enough that a person can look at every item in it and long enough to be honest.

What automation does not do is decide what to do about a genuine shortfall. Whether to dispute a deduction, chase a missing payout, or accept a fee as the cost of the channel is a commercial judgement.

What changes when this works

The close stops being an investigation. Fees stop being a lump labelled "platform charges" and become a cost you can see per channel, per campaign, sometimes per product.

Channel decisions get made on margin instead of volume, which frequently reverses them. Retailers who reconcile properly for the first time often discover their busiest channel is not their most profitable one, and that a quiet storefront doing a fraction of the volume is carrying the business.

And the question of whether a marketplace has actually paid you what it owes becomes something you can answer, rather than something you assume.

A counter running alongside an online store adds several settlement worlds at once — cash with a banking lag, card through a terminal provider, wallet payments by whichever route was configured — each needing its own clearing account — see Shopify POS and your accounting.

Common questions

Why can I not just use the payout figure as my sales?

Because the payout is what is left after commission, transaction and service fees, voucher co-funding, absorbed shipping and refunds. Booking it as revenue understates your sales, hides your costs, and makes channels impossible to compare. The payout is an outcome. The sales are what produced it.

Do I need to reconcile every payment method separately?

They need to be reconciled against the same orders, but each sender has its own file, timing and fee structure, so in practice each is matched on its own terms and then brought together. The point is not that they are processed identically. It is that they end up in one ledger rather than six.

How do I handle cash from the shop in all this?

Cash is counted and agreed at the counter, then banked, and both steps should be recorded against the trading day they belong to. The differences worth investigating are the ones between what the till says was sold and what was counted, which is why connecting the POS matters more than any cash-handling rule.

What if a marketplace payout never arrives?

You will only notice if something is comparing delivered orders against payouts received. That comparison is the entire value of order-level reconciliation, and it is the reason the exercise pays for itself more often than people expect.

The gap between sold and banked

Every retailer knows what they sold. Most know what reached the bank. The business lives in the gap between those two numbers, and that gap is made of fees, timing, refunds and the occasional thing that went missing.

Six senders on six clocks is not a problem to be eliminated. It is the shape of selling in more than one place. It only becomes a problem when nobody is decomposing what they send.