A delivery order is five numbers. One of them reaches the bank.

The guest paid $1,000 this week. DoorDash deposited $698. Book the $698 as sales — which is what almost every restaurant file does — and revenue is understated by 30%, $302 of cost is invisible, and food cost reads 43% on a kitchen running at 30%. Here is the anatomy of a payout, the entry that keeps the ratios honest, and the proof that catches what the platform took out quietly.

LedgerInbox · September 2026 · corrections@ledgerinbox.com

What is actually inside a payout

A third-party deposit is a net figure with at least five components collapsed into it, and the platform's own statement is the only place they are itemised.

The entry

One journal entry per payout, per platform. Every line is a fact the platform statement already states — you are un-collapsing the deposit, not estimating anything.

The account codes are from the chart of accounts — if the client has no 5200, the commission ends up in whatever expense line is nearest and the channel's real margin can never be read.

Why the shortcut costs so much

Booking the deposit as revenue looks harmless because the bank still reconciles. What it does is arithmetic:

Thirteen points of food cost, invented by a bookkeeping choice. The chef gets asked why the kitchen is out of control, the answer is that it isn't, and the $250 that actually left — the number worth negotiating, or worth deciding the channel is unprofitable — never appears anywhere.

Two things that are not yours

Sales tax, under marketplace facilitator law

Most US states now treat the delivery platform as the marketplace facilitator: it collects the sales tax on those orders and remits it directly. That tax is not the restaurant's liability and must not land in 2100 — if it does, the client remits it a second time. The reconciliation that matters is the one against the sales tax return: taxable sales on the return should exclude marketplace orders the platform already remitted.

Driver tips

A tip added in the DoorDash app goes to the Dasher. It is not restaurant revenue and it is not restaurant tip liability — it never enters the file. This is the opposite of a charged tip on an in-house check, which is the restaurant holding someone else's money until payroll: tip liability, and the rollforward that proves it.

The three numbers that have to agree

Reconciling delivery means putting three independent sources beside each other, per platform, per payout period:

When gross minus the itemised deductions does not equal the deposit, the difference is almost always one of four things: a refund processed after the period closed, an “error charge” for a missing item, a promotion the restaurant funded rather than the platform, or a tablet/equipment fee. Each is small. A year of them is not.

The monthly proof

Per platform: opening receivable, plus gross sales in the month, minus commissions and fees, minus refunds, minus deposits received, equals closing receivable — and the closing figure should be the orders that traded near month end and have not paid out yet. If it is anything else, a payout is unrecorded or a deduction was never booked.

This sits inside the wider close, at step 7 — the month-end close, in the order that proves things.

Doing it weekly, not monthly

Payouts are weekly and the statements are only conveniently available for a while. A month of three platforms is twelve payouts, forty-plus deduction lines and at least one refund nobody remembers — reconstructed on the 5th from downloads. Done the day the deposit lands, each one is a five-minute comparison against a statement that is still in front of you, and the anomalies are still recent enough that a manager can explain them.