Friday night, three outlets, full covers. The POS says you sold HK$412,000 across the group. Then the money starts arriving, and none of it looks like HK$412,000.

KeeTa settles net of commission; foodpanda nets a different commission on a different schedule. Octopus arrives as a batch, minus a handling fee. AlipayHK lands as a daily lump sum with fees and refunds already netted out. WeChat Pay HK arrives on whatever cycle the acquirer or aggregator you signed with runs. The card acquirer batches Visa and Mastercard together, minus merchant discount. Cash is whatever made it to the safe. By Monday, finance is staring at a dozen deposits that don't add up to what the POS said, and someone inevitably opens a spreadsheet to work out why.

And that's... where the trouble starts. Not because the person building it is careless, but because the reconciliation is being done backwards: reverse-engineering deposits into sales, instead of posting sales and clearing deposits against them.

The duopoly settles on its own terms

Hong Kong's delivery market got simpler and harder at the same time. Deliveroo left Hong Kong in April 2025 after nine years, selling some of its assets to foodpanda on the way out.

What's left is a duopoly of sorts.

Meituan's KeeTa, which took the order-volume lead within ten months of launching and is now widely described as the market leader, with foodpanda, now the number two, but still on every restaurant's counter. If you run restaurants in Hong Kong, you're often on both. There is sadly no third option with volume today. The nearest thing on the horizon is corporate: Uber agreed in July 2026 to buy foodpanda's parent, Delivery Hero, in a deal slated to close in the second half of 2027.

Both platforms pay you the same way: gross order value, minus commission, minus refunds and adjustments, equals the payout. Your revenue is the gross figure. Your deposit is the net one. The gap between them is a real cost of sale that belongs in your P&L as a visible line.

Plenty of operators book the deposit as the revenue because it's faster. The books balance, but two things quietly go wrong:

1. Reported sales understate what the kitchen actually produced.
2. Platform commission disappears. One of the largest and fastest-moving costs in the business falls into a netting entry nobody reviews.

When commission terms change, or refund rates creep up on one platform, the P&L has no line that moves. You find out at year-end. IF you find out.

Then multiply by the wallet stack

Delivery is two counterparties. The dine-in tender stack is worse.

A typical Hong Kong restaurant accepts a range of payments options: Octopus, AlipayHK, WeChat Pay HK, cards through an acquirer, FPS transfers, and cash. Each tender settles on its own cadence with its own fee mechanics: Octopus merchants pay a handling fee on batch settlements, AlipayHK nets fees and refunds before the daily lump sum arrives, and the card acquirer's statement bundles every scheme into a single merchant-discount deduction. FPS is the opposite problem: no batching and no netting, just dozens of individual real-time credits with no batch reference at all. Six tender types means six different answers to the question "when does the money arrive, and how much of it?"

Six tenders. Six arrival times.

When a Friday-night sale actually reaches the bank, by tender type. Same moment of sale — different arrival times, different shapes, different amounts.

Same Friday-night sale: FPS is in the account before the customer leaves. Cards and Octopus wait out the weekend and pile up Monday. Delivery money arrives weeks later — net of everything. That’s why the POS total never matches the bank.

Sources: HKICL (FPS), Octopus merchant FAQ, AlipayHK merchant FAQ, BOCHK acquiring schedules, Hang Seng merchant services, foodpanda partner terms. Card and WeChat Pay timing vary by acquirer; Octopus T+1 runs from transaction-data upload; delivery payout cycles per platform agreement. Delivery commissions reported at 28–35% (The Collective HK; Unwire, Mar 2025); KeeTa cadence not published.

Now multiply by outlets. A group running eight restaurants, often as separate legal entities, is reconciling six tenders times eight outlets against bank accounts that may sit at more than one bank. That's the real shape of the problem: not one hard reconciliation, but forty-eight small ones, every day, forever.

What clean looks like

The structure that works is a bit old-fashioned and unglamorous: clearing accounts, one per tender, per outlet.

The POS posts a daily sales journal at gross: sales by outlet and category, with the day's takings sitting in tender-level clearing accounts, one balance for KeeTa, one for Octopus, one for AlipayHK, and so on. When the settlement lands, it clears against that balance. Commission and fees post as their own expense lines at the same moment. Whatever doesn't clear stays visible as a residue in the clearing account, which is exactly what you want: an unmatched HK$3,000 in the WeChat Pay clearing account is a question someone can answer on Tuesday, instead of a mystery buried in a net revenue figure discovered in the audit.

In NetSuite, this runs as imported bank statements matched against the clearing accounts with reconciliation rules doing the bulk of the matching. The clearing-account structure is implementation design; we build it during the project rather than flipping a switch. One honest caveat for Hong Kong: NetSuite's live bank-feed connections don't currently cover Hong Kong banks, so statements come in as files, MT940 or camt.053 from HSBCnet and its peers, imported on a schedule rather than streamed. In practice that means a daily import routine. The matching, the clearing structure, and the visibility are where the work actually gets saved.

The payoff compounds at month-end. When every tender has cleared all month, the close isn't a reconstruction. Sales are already gross, commissions are already visible, and the variance accounts already tell you where the leaks are, outlet by outlet.

Where to start

If your group's number for "what did we sell last week" still requires a spreadsheet and a half-day of someone's time, the problem is the direction of the work: deposits are being turned back into sales by hand, when the sales should have been posted first and the deposits cleared against them.

We've written up how NetSuite handles the individual settlement formats: Octopus, AlipayHK, WeChat Pay, and the HSBC statement round-trip. And our NetSuite implementation page covers how a project starts, including the discovery phase that comes before any build; mapping your tender stack is the first thing discovery does.

The platforms aren't going to simplify their settlements for you. The wallets aren't either. The only variable you control is whether your books absorb that complexity by design, or whether someone rebuilds it in a spreadsheet every Monday.