Back to blog
Food Delivery Reconciliation: How F&B Operators Stop Losing Money to Grab, foodpanda & Deliveroo

Food Delivery Reconciliation: How F&B Operators Stop Losing Money to Grab, foodpanda & Deliveroo

6 min read

You sold S$48,000 through the delivery apps last month. The platforms paid you S$31,000-ish. Somewhere in that gap sits commission, delivery fees, packaging charges, promo co-funding, refunds, chargebacks, and adjustments you've never been able to fully explain.

That gap is normal. What's not normal is having no idea whether the number you were paid is the number you were owed.

This is food delivery reconciliation: matching what each platform says it sold, against what your POS recorded, against what actually landed in your bank. Most F&B operators don't do it properly. Not because they're lazy — because the platforms make it genuinely hard, and the manual version is miserable. So they eyeball the payout, assume it's roughly right, and move on.

On a 10% net margin, "roughly right" is an expensive habit.

Why delivery reconciliation is so painful

A single GrabFood or foodpanda order isn't one number. It's a stack of deductions, and every platform stacks them differently.

Commission is the big one — typically somewhere between 15% and 30% per order depending on the platform, your location, and your contract. But underneath it sits a longer list: delivery fees, small-order fees, packaging charges, payment-processing fees, promotional discounts you agreed to, promotional discounts you're co-funding without quite realising, customer refunds, driver-cancelled orders, and end-of-cycle adjustments that show up with no order attached to them at all.

Then there's timing. Each platform settles on its own clock, in its own format, with its own reference numbers. Grab pays on one cadence, foodpanda on another, often with longer settlement windows where a disputed payment can take weeks to resolve. Your POS, meanwhile, recorded the order the moment it came in — at a different value, under a different ID.

So reconciliation isn't "did the money arrive." It's "does this payout statement, with its forty line items, reconcile to the eighty orders my POS thinks went out on those days, net of every deduction the platform is entitled to take — and not a cent more."

Do that across three platforms and four outlets, every week, in a spreadsheet, and you'll understand why most people don't.

The three things reconciliation should actually catch

When you reconcile delivery payouts properly, you're hunting for three specific failures.

Missing orders. Orders your POS recorded that never appeared on a payout statement. A dropped order is pure lost revenue — you made the food, paid for the ingredients and labour, and were never paid for it. These slip through constantly because nobody is checking order-by-order.

Over-charged deductions. Commission applied at the wrong rate. Promo co-funding deducted on orders that weren't part of the promo. Packaging fees that don't match your agreement. Each one is small. Across thousands of orders a month, the small ones are the whole story.

Refunds and chargebacks you can't trace. A customer complains, the platform refunds them, and the cost lands on you — sometimes correctly, often without enough detail to know whether the complaint was even real. If you can't tie each refund back to a specific order, you can't dispute the ones that are wrong.

None of these is visible from the payout total. You only see them when you go line by line.

Why the spreadsheet version breaks

Most operators start the same way: download the platform statement, export the POS report, paste both into a sheet, and try to match them with VLOOKUP and willpower.

It works until it doesn't, which is usually around the second outlet. The order IDs don't match between systems. The platform statement groups things differently each cycle. Someone formats a date column wrong and 200 orders silently stop matching. The person who built the sheet goes on leave, and reconciliation just... stops happening that month.

The deeper problem is that a spreadsheet is a snapshot, and reconciliation is a process. You're not doing this once. You're doing it every settlement cycle, forever, across every platform you're on. A one-off artefact can't carry a recurring obligation. So the work either consumes a person — five-plus hours a week of soul-destroying matching — or it quietly lapses, and the leakage goes back to being invisible.

This is the same trap that swallows prep lists, scheduling, and every other ops workflow held together by manual effort: the tool was never built to hold the process, so the process leans on a human instead.

What good delivery reconciliation looks like

A reconciliation system that actually holds does a few things the spreadsheet can't.

It pulls automatically from every source — each delivery platform's payout data, your POS, and your bank feed — so nobody is exporting and pasting. It matches order-by-order, not total-to-total, so a missing order or a mis-applied fee surfaces by name instead of disappearing into an aggregate. It normalises the different ID schemes and statement formats so Grab, foodpanda and Deliveroo can be compared on the same terms. And it flags only the exceptions: the orders that didn't match, the deductions that look wrong, the refunds with no trace. You review the 30 things that need a human, not the 3,000 that reconciled cleanly.

The output you want is a single, boring sentence you can trust every cycle: every order is accounted for, every deduction is explained, and the bank matches the statement. When it doesn't, you get a specific list of discrepancies to chase — with enough detail to actually dispute them before the platform's claim window closes.

That last part matters. Most platform disputes have a deadline. Reconciliation that runs weeks late is reconciliation that can't recover the money it finds.

Where this fits in your month-end

Delivery reconciliation isn't a standalone chore. It's one feed into a clean month-end close. The same matched, normalised order data that catches a dropped payout is also what tells you true revenue by channel, real COGS after delivery commissions, and which platform is actually profitable once you net out everything it takes.

Operators who only look at gross delivery sales routinely discover that their "busiest" channel is their least profitable one. You can't see that until the deductions are reconciled at the order level.

The honest version

If you're on one platform, at one outlet, with low volume — a careful spreadsheet and a disciplined hour each week is fine. Don't over-build this.

But if you're running multiple outlets across two or three delivery platforms, reconciling by hand is a losing game. The volume is too high to check properly, the deductions are too varied to eyeball, and the cost of not checking is buried exactly where you'll never casually notice it.

This is squarely the kind of problem Hippo Labs builds for: a reconciliation layer that pulls from your POS, your delivery platforms and your bank, matches every order, and hands you the exceptions — built around the platforms and outlets you actually run, not a generic template. Worth a conversation if your delivery payouts have become a number you accept rather than a number you check.

The short version

Delivery reconciliation is matching every payout to every order, net of every deduction. Done by hand, it either eats a person or quietly stops. Done properly, it catches the missing orders, the over-charged fees, and the untraceable refunds that no payout total will ever show you — and it tells you which channel is actually making you money.

On F&B margins, that's not bookkeeping hygiene. It's the difference between knowing your numbers and hoping they're close.

Jarvin

Jarvin

Finance × Operations × Software. I build operations platforms for F&B businesses — for people who’d rather be running their business than building their tools.

Fig. 01 / BriefRev. A

Want to talk shop?

Tell us what’s slowing you down.