Payout reconciliation should not feel like detective work
Direct online ordering gives restaurants more control, but it also gives the owner a very practical finance question: "Which orders made up this bank deposit?"
That question usually shows up after the first few real payouts. The ordering page is working. Customers are paying. Tickets are moving through the kitchen. Then a deposit lands in the bank account, and somebody has to match it against the day's sales, refunds, and payment processing fees.
With OmNom, the restaurant-side model stays simple: zero OmNom commission and zero monthly platform fees. Standard Stripe processing still applies. That means the payout trail should be easier to explain than a commission-heavy marketplace statement, but it still needs a routine.
The goal is not to turn every restaurant into an accounting department. The goal is to make reconciliation boring enough that a manager can answer the common questions without guessing.
Start with the difference between orders, charges, and deposits
Restaurant teams often use one word, "payment," for several different steps.
For reconciliation, it helps to separate them:
- The order is the food ticket the restaurant fulfilled.
- The charge or payment is the customer's card or wallet transaction.
- The fee is the payment-processing cost attached to that transaction.
- The refund or adjustment is money moving back or changing after the original sale.
- The payout is the bank deposit from the payment balance.
Those pieces do not always collapse into one neat line. A single payout can include many transactions. A refund may belong to an order from a previous day. Stripe fees reduce the net amount before funds become available. A failed or delayed payout can create another status to check.
Stripe's payout reconciliation documentation explains that automatic payouts can include funds from multiple transactions, and that Stripe provides ways to review the transactions included in a payout. That is the core idea restaurant owners should remember: reconcile the deposit as a batch, not as one mystery number.
Build the routine around payout IDs, not only calendar dates
Calendar dates are useful for sales reporting, but payouts are their own object.
If a restaurant only asks, "What did we sell on Tuesday?" it may still be confused by the deposit that arrives later. The better reconciliation habit starts with the payout itself:
- What payout appeared in the bank account?
- What payout ID or statement reference is connected to it?
- Which transactions were included in that payout batch?
- Which fees, refunds, or adjustments changed the net amount?
- Are any recent orders still pending and not yet available for payout?
Stripe documents that payout details can be reviewed in the Dashboard, through payout reconciliation reports, or through the API. For most restaurants, the Dashboard and downloadable reports are the practical starting point.
The point is not that an owner needs to memorize Stripe object names. The point is that the deposit should have a trail. When the trail starts from the payout, the restaurant is less likely to force every order date, service date, and bank date into one flat spreadsheet.
Keep gross sales, fees, refunds, and net deposits in separate columns
One of the easiest ways to make restaurant payouts confusing is to compare gross order sales directly to a bank deposit.
Those numbers are not supposed to match.
Gross sales are the customer-facing order totals before payment-processing fees and later money movements. Net deposits are what lands after the applicable fees, refunds, and payout timing rules. Treating the bank deposit as "sales" makes the system look wrong even when it is doing exactly what it should.
A simple restaurant reconciliation sheet can stay small:
- payout arrival date
- payout ID or bank reference
- gross online order sales included
- Stripe processing fees
- refunds or partial refunds
- disputes or unusual adjustments, if any
- net payout amount
- notes for anything that needs review
Stripe's reporting docs describe balance transactions as the recommended starting point for reporting account balance activity because they are created for funds moving into or out of the Stripe balance. They also separate activity such as charges, refunds, Stripe fees, and payouts into transaction types.
That structure is useful for restaurants because it mirrors the questions owners actually ask. Did we get paid for the order? Was there a refund? What did processing cost? What deposited to the bank?
Reconcile refunds by order, not by memory
Refunds are where casual payout tracking usually breaks.
Imagine a customer places an online order on Friday, the restaurant issues a partial refund on Saturday, and the related payout changes on a later deposit. If the team only remembers "Friday was busy," the refund can feel like a missing sale.
Do not rely on memory. Tie refunds back to the order reason:
- missing item
- canceled order
- duplicate charge concern
- kitchen delay
- wrong modifier or menu setup issue
- delivery or handoff problem
Then record whether the refund was full or partial, who approved it, and where the customer conversation lives. That gives the finance side and the operations side the same source of truth.
This is one of the quiet advantages of direct ordering. A known order, a known guest issue, and a known refund record are easier to trace than a platform adjustment that appears later with limited context. Direct ordering does not eliminate mistakes. It makes the after-the-fact review easier to own.
Train one person to check payout status before service gets busy
Payout reconciliation should have an owner.
That does not mean only one person can understand it. It means the restaurant should know who checks the payment trail when a question comes up. If every manager assumes someone else understands payouts, nobody checks until the owner is already frustrated.
A weekly payout check can be simple:
- Review new bank deposits from online ordering.
- Open the matching payout record or report.
- Confirm the expected gross, fee, refund, and net amounts.
- Flag any failed payout, large refund, dispute, or unexplained adjustment.
- Share the one-line status with whoever handles bookkeeping.
For restaurants with frequent online orders, this may become a daily rhythm. For lower-volume restaurants, weekly may be enough. The important part is consistency.
If a restaurant is still in its first week of direct online ordering, pair this habit with the broader launch review in Restaurant Online Ordering First Week: What to Watch After Launch.
Compare this with marketplace statements before choosing where repeat orders go
Marketplace orders can still have a place in a restaurant's channel mix, especially when they bring discovery from customers who were not already looking for the restaurant.
But payout clarity is part of the comparison.
When a repeat customer already knows the restaurant, a direct ordering path gives the business a cleaner line between the order, the charge, the refund record, and the payout. The restaurant is not trying to decode a marketplace commission statement, promotion adjustment, refund policy, and customer support workflow all at the same time.
That matters because finance confusion has an operating cost. Owners spend time reviewing deposits. Managers answer refund questions. Staff explain totals. Bookkeepers chase missing context. The simpler the model, the easier those jobs become.
OmNom's restaurant-side pricing is built around that simplicity: no OmNom commission and no monthly OmNom platform fee, while standard Stripe processing still applies. Stripe's public pricing explains the payment-processing side. OmNom's role is to avoid adding another restaurant-side commission layer on top of it.
If you are comparing the broader economics, read Zero-Commission Online Ordering vs Marketplace Commissions.
Where OmNom fits
OmNom is built for restaurants that want direct online ordering they can understand operationally, not just a checkout link that works when everything is perfect.
That means fast setup, free menu help, a direct ordering page, and a restaurant-side cost structure that stays clear: zero OmNom commission, zero monthly platform fees, and standard Stripe processing. Once orders start flowing, payout reconciliation is one of the habits that helps the system stay trusted.
Keep the routine plain. Start from the payout. Match the included transactions. Separate gross sales, processing fees, refunds, and net deposits. Then use anything unusual as an operations signal, not just an accounting headache.
If you are ready to make direct ordering easier to launch and easier to explain, start from OmNom or open the restaurant app.