Reconcile DoorDash, Uber Eats & Grubhub Payouts in QuickBooks

Reconcile DoorDash, Uber Eats & Grubhub payouts in QuickBooks or Xero: split fees, post the journal entry, handle facilitator tax, match the 1099-K.

Published
Updated
Reading Time
22 min
Topics:
Industry GuidesHospitalityUSQuickBooksXerothird-party deliverymarketplace facilitator1099-K

A delivery-platform payout is a bundled bank deposit that hides a gross-sales line, several fee categories (commission, marketing, delivery), customer refunds and error charges, platform-collected sales tax, and pass-through tips. To reconcile DoorDash, Uber Eats, and Grubhub payouts in QuickBooks correctly, book the gross sales as revenue and post each fee or adjustment to its own GL account so the P&L reads correctly and the year-end 1099-K reconciles. In states with marketplace facilitator laws, the platform remits the sales tax on platform-facilitated orders; the restaurant still owes sales tax on direct-channel orders.

Concretely: your POS reported $7,200 of delivery sales this week. DoorDash deposited $4,800. The $2,400 difference is real money — commission, marketing fees, customer refunds, sales tax DoorDash collected on the customer's behalf, tips that passed through to the Dasher — and every dollar of it has to land somewhere in the general ledger. Booked the wrong way (the $4,800 deposit posted as revenue), the fees vanish from the P&L, the platform's commission rate becomes invisible, and next January the 1099-K will report a gross figure that the books cannot explain. Booked the right way, the $7,200 credits Delivery Sales Income, the components of the $2,400 each debit their own account, and the deposit ties out to $4,800 with the gross preserved on the income statement.


Anatomy of a payout statement: DoorDash, Uber Eats, and Grubhub side by side

Each platform issues a weekly payout statement (PDF in the merchant portal, CSV via the report exporter) that breaks the deposit into roughly the same economic components. The labels move. The order moves. The level of granularity moves. The job is to translate every platform's vocabulary into a single internal taxonomy that maps cleanly to the GL accounts in the next section.

DoorDash Merchant Payouts

DoorDash's report is the most field-itemised of the three. Expect:

  • Gross sales — customer-paid food subtotal before tax and tip; becomes Delivery Sales Income on the journal entry.
  • Customer refunds — orders refunded to the customer for cancellations or non-delivery.
  • Commissions — DoorDash's percentage take on the marketplace order.
  • Marketing fees — restaurant-funded promotion charge-backs and DoorDash advertising charges. Platform-funded promotions don't hit this line.
  • Error charges — adjustments for missing items, wrong items, or quality issues.
  • Customer support adjustments and restaurant adjustments — one-off credits or debits originating with DoorDash for billing-dispute resolutions, equipment fees, back-credits, and similar.
  • Customer tax — sales tax customers paid on the platform-facilitated order. In marketplace facilitator states (the default in 2026), DoorDash remits this directly and the restaurant doesn't see it as a payable.
  • Restaurant tax — any tax DoorDash is passing through rather than remitting. This is where the post-July-2025 local-tax pass-through lands; treat it as a real liability the restaurant has to remit.
  • Tips — pass-through to the Dasher, not restaurant revenue.
  • Net payout — the bank-deposit figure.

Uber Eats Payment Reports

Uber Eats reports against a different schema and frequently leads with net rather than gross — read carefully or the gross figure goes unrecorded.

  • Order Earnings — net of the Uber Service Fee per order. To recover gross food sales, add the Service Fee back.
  • Promotions — splits into restaurant-funded (a real marketing cost) and platform-funded (Uber's own customer-acquisition spend, no charge to the restaurant). Only the restaurant-funded portion belongs in marketing expense.
  • Adjustments — customer refunds and error charges, reported as a negative against earnings.
  • Service Fee — Uber's commission on the marketplace order; added back to Order Earnings to derive gross.
  • Delivery Fee — only relevant on Uber Direct (driver-as-a-service) for direct-channel orders; on a pure marketplace order the customer pays it to Uber and it doesn't flow through.
  • Taxes — split into collected-and-remitted (Uber handles) and passed-through (restaurant has to remit), mirroring DoorDash's structure with different field names.
  • Tips — pass-through to the driver.
  • Total Payout — the bank-deposit figure.

Grubhub Statements

Grubhub uses broader categories but the underlying components are the same:

  • Gross order subtotals — customer-paid food before tax and tip; the income line.
  • Marketing commission — visibility-tier percentage take.
  • Delivery commission — driver-fulfilment percentage take.
  • Processing fees — payment-processing charges, sometimes itemised, sometimes folded into commission.
  • Refunds and adjustments — combined refund and adjustment line, often without DoorDash's per-event detail. Pull the order-detail report if a specific refund needs investigation.
  • Marketplace facilitator tax — sales tax Grubhub collected and remitted on platform-facilitated orders.
  • Local pass-through tax — where applicable in jurisdictions Grubhub doesn't cover at the local level.
  • Tips — pass-through to the driver.
  • Net payout — the bank-deposit figure.

The normalisation table

Every line on every statement maps to one of eight standard categories. Build the journal entry from the standard categories, not from the platform-specific names, and the same template runs on all three platforms.

Standard categoryDoorDash fieldUber Eats fieldGrubhub field
Gross Food SalesGross salesOrder Earnings + Service Fee (derived)Gross order subtotals
Customer RefundsCustomer refundsAdjustments (refund portion)Refunds and adjustments (refund portion)
Platform CommissionCommissionsService FeeMarketing commission + delivery commission + processing fees
Marketing & Promotions Charged BackMarketing feesPromotions (restaurant-funded only)Promotional charges where itemised
Error Charges & AdjustmentsError charges + customer support adjustments + restaurant adjustmentsAdjustments (error and quality portion)Refunds and adjustments (adjustment portion)
Sales Tax Collected (marketplace-facilitated)Customer taxTaxes (collected-and-remitted portion)Marketplace facilitator tax
Pass-Through TipsTipsTipsTips
Net Bank DepositNet payoutTotal PayoutNet payout

A ninth row earns its place when the platform passes local taxes through rather than remitting them — typically DoorDash's Restaurant tax line in affected states from July 2025 onward, and the equivalent on Uber Eats and Grubhub where applicable. That row maps to a Sales Tax Payable account because the restaurant collected the tax on the customer's behalf and owes it to the local jurisdiction.

Verify any normalisation against the current DoorDash Merchant Help, Uber Eats Restaurant Help, and Grubhub for Restaurants documentation when a field doesn't match what's on the statement; the categories above are the durable structure but the labels move from quarter to quarter.


Posting the payout in QuickBooks Online and Xero

The journal entry runs on a small, stable chart of accounts. Set it up once and every weekly payout posts against the same lines.

The account list

  • Delivery Sales Income (income) — gross food sales, optionally broken by platform with sub-accounts or with classes / tracking categories.
  • Customer Refunds & Adjustments (contra-revenue) — sits just under Delivery Sales Income on the P&L; keeps the gross visible rather than netting silently into revenue.
  • Delivery Platform Commissions (expense) — the platform's percentage take.
  • Delivery Platform Marketing & Promotions (expense) — restaurant-funded promotional charges and platform advertising.
  • Delivery Platform Error Charges (expense) — error and adjustment charges, separated from generic commission so the kitchen-error trend is visible.
  • Sales Tax Payable (liability) — credited only when the platform passes the tax through.
  • Pass-Through Tips (clearing or liability) — used when tips actually land in the restaurant's bank rather than being paid directly to the driver by the platform.
  • Bank — Operating (asset) — debited for the net deposit so the journal entry matches the bank feed.

The QuickBooks Online entry

Take the running example. Customer-paid food gross is $7,200. DoorDash deducts commission $2,000, marketing $200, error charges $100, and refunds the customer $100 on a single problem order. DoorDash also collected $576 in customer sales tax (8%) on the platform-facilitated orders and remitted that directly to the state — the restaurant never sees it as cash. Tips of $720 went straight from the customer to the Dasher and never touched the restaurant's bank. The net deposit is $4,800.

Post it in QuickBooks Online either as a Sales Receipt with line items (preserves invoice-style detail) or as a manual Journal Entry (cleaner for a weekly batch). Both produce the same result; pick whichever fits the firm's workflow. The journal-entry form:

AccountDebitCredit
Bank — Operating (DoorDash deposit)4,800
Delivery Platform Commissions2,000
Delivery Platform Marketing & Promotions200
Delivery Platform Error Charges100
Customer Refunds & Adjustments100
Delivery Sales Income — DoorDash7,200
Totals7,2007,200

Customer-remitted sales tax and pass-through tips don't appear in the entry — neither item moved through the restaurant's bank, so neither has a debit or credit to record. The platform-statement lines for them are informational and confirm the gross arithmetic; they're not GL entries on this payout.

When the platform passes a local tax through (the post-July-2025 DoorDash situation in affected jurisdictions), an additional pair lands in the same entry: debit Bank — Operating for the local-tax amount that was actually deposited with the payout, credit Sales Tax Payable — local meals for the same. The deposit total grows by that amount; the income line and fee lines don't change.

If delivery-driver tips do pass through the restaurant bank account, use a Pass-Through Tips clearing or liability account that nets to zero. Driver tips are not restaurant revenue, not employee tip income, and not Form 8027 tip income; the broader employee-tip workflow belongs in Form 8027 tip reporting from POS and payroll data.

The same posting in Xero

Xero produces an identical economic result with two mechanical wrinkles. The first: the Receive Money transaction on the bank-reconciliation rule can post the deposit and split it across the relevant income, expense, and contra-revenue accounts in one step — the closest Xero equivalent to QuickBooks Online's Sales Receipt with line items. The second: per-platform tracking is generally done with tracking categories (a "Channel" tracking category with values DoorDash, Uber Eats, Grubhub) rather than sub-accounts, because Xero discourages chart-of-account proliferation. The journal-entry form runs identically when posted as a Manual Journal — same accounts, same debits and credits, same totals.

A bookkeeper handling third-party delivery accounting across QuickBooks and Xero clients should see the same line categories on every payout posting. The platform-specific labels stay in the normalisation table; the GL stays consistent across systems.

Per-platform tracking is not optional

A class (QuickBooks Online) or tracking category (Xero) per platform turns three insights on at once: the per-platform P&L, the effective take-rate trend (commission as a percentage of gross, watched month over month), and the marketing-spend trend (whether the restaurant is absorbing more of the discount over time). Without per-platform tracking, the three platforms blur into a single "delivery" line and none of those signals surface until something breaks.

Reconciling the bank feed

When a deposit lands in the bank feed and the journal entry has already been posted, the matching transaction is the journal entry's debit to Bank — Operating for the net amount — one line, one match. The fee debits and the income credit are part of that journal entry; they don't show up as separate bank-feed items because they were never separate cash movements. This is the most-asked question on the QuickBooks Community: why doesn't the bank deposit equal what was posted as revenue? Because the deposit isn't revenue — it's the net residue after the journal entry has done its job. The same logic applies whether the platform is DoorDash, Uber Eats booked into QuickBooks Online, or Grubhub: one journal entry per payout per platform, the bank deposit matches the asset-side debit, the per-platform breakdown lives inside the entry.


Promotions, error charges, and refunds: the coding traps

Four line categories quietly distort the P&L and the 1099-K bridge when they are posted to the wrong account:

  • Restaurant-funded promotions belong in marketing expense. Platform-funded promotions do not hit the restaurant's books; check whether the report separates the two before posting a promotion line as a cost.
  • Customer refunds and error charges reduce revenue or sit in a discrete error-charge expense account. Do not bury them in commission expense, where they hide kitchen or service problems.
  • Restaurant adjustments need a memo and a specific account, not a new GL account for every label. A commission true-up goes to commission, a delayed refund goes to contra-revenue, and a back-credit follows the item it reverses.

The same coding discipline that makes GL coding for restaurant supplier invoices work on the AP side — code by the underlying economic event, not by the document label — makes payout reconciliation work.


Marketplace facilitator sales tax and the DoorDash local-tax pass-through

Every payout statement carries a sales-tax line. Whether that line is a real liability depends on a state-level rule that's now in effect across most of the United States, and on a 2025 DoorDash policy change that quietly moved certain local taxes back onto the restaurant's plate.

The framework

As of 2026, marketplace facilitator laws are in effect in 45-plus US states. In those states, DoorDash, Uber Eats, and Grubhub are responsible for collecting and remitting state sales tax on orders placed through their platforms. The restaurant doesn't remit that tax, doesn't accrue it as a payable, and doesn't include the marketplace-facilitated revenue in the figure on which it calculates state sales-tax owed. The restaurant does still owe sales tax on direct-channel orders — its own website, its own phone-in orders, walk-in dine-in or take-out, catering booked direct, anything not transacted through a marketplace platform.

The canonical reference point is California. California's Marketplace Facilitator Act took effect on October 1, 2019, making marketplace facilitators generally responsible for collecting, reporting, and paying sales tax on retail sales made through their marketplace. Most other states followed similar patterns over the next two years, with effective dates clustered between 2019 and 2021.

The typical state filing pattern

Most state DORs still want the restaurant to report gross taxable sales on its periodic sales-tax return — including the marketplace-facilitated portion — and then claim a deduction for the marketplace-facilitated amount, leaving only the direct-channel portion subject to remittance. The deduction line is usually labelled close to "Marketplace facilitator sales" or "Sales for which the marketplace facilitator collected the tax." A handful of states want no reporting at all for marketplace orders; a few want the marketplace portion broken out by platform on the return; some require reporting by location for multi-unit operators.

For pattern recognition, look at California, New York, Texas, Florida, Illinois, Washington, and Massachusetts as representative — they cover most of the variation a multi-state operator will encounter. They are not a substitute for the actual state DOR guidance for the jurisdictions a specific restaurant files in; both the return form and the deduction-line treatment have been amended several times since the original facilitator laws took effect. For multi-state operators, economic nexus tracking for multi-state sellers covers the broader registration and threshold framework that sits underneath the facilitator question, and state-by-state sales tax invoice requirements covers the documentation side.

The post-July-2025 DoorDash local-tax pass-through

Starting July 1, 2025, in certain marketplace facilitator states, DoorDash began including specific local food-and-beverage taxes — typically meals taxes or restaurant taxes administered separately from the state sales tax — in payouts to non-integrated restaurants, instead of remitting them directly. The restaurant has to remit these local taxes on its own filing, as it always did before marketplace facilitator law existed.

The booking treatment: the local-tax amount appears on the payout (typically on a Restaurant tax line, sometimes split out as a separate row in the CSV), credits Sales Tax Payable — local meals on the journal entry, and gets remitted on the local meals-tax filing the jurisdiction requires. Because it's a passed-through liability and not income or expense, the entry doesn't touch the P&L; it moves through the balance sheet only.

Restaurants that booked the entire DoorDash payout as net revenue without splitting out the new pass-through line are now under-remitting local meals tax. The state-level facilitator collection still happens in the background, so the state portion is fine; the local portion is silently accumulating an unfiled liability with interest and penalty exposure. Verify on a current DoorDash payout statement whether the affected jurisdiction is involved, then go back through 2025 statements from July 1 onward and remit any missed amounts with a self-assessment. Read merchant communications carefully when any platform changes its tax-handling policy mid-year — the booking practice has to change with the policy, not after the next filing notice arrives.

For restaurants on a deeply integrated POS (Toast, Square, Clover with the platform's API integration), the line layout is different because the deposit reconciliation runs inside the integration rather than against a downloaded statement. The principles are identical; the field locations move — and the parallel exercise of tying Toast, Clover, and Square daily settlement deposits back to the bank (tips through deposit, multi-batch settlement, holdbacks, chargeback trace) sits alongside the marketplace-payout workflow on the same weekly close calendar. Toast's and Square's own merchant resources document the integration-specific layouts.


Exceptions: direct-channel orders and virtual brands

Direct-channel delivery is not a marketplace payout. When the restaurant takes the order through its own website, phone line, Toast Online Ordering, ChowNow, or another first-party channel, the restaurant is the merchant: it records direct sales, remits the sales tax, and books the driver-fulfilment charge as a separate delivery expense rather than a marketplace commission.

Virtual brands need one extra split before the weekly journal entry is posted. Pull the brand or storefront column from the order-detail report, aggregate gross sales, refunds, and platform-attributable fees per brand, and post the entry against brand-level classes in QuickBooks Online or tracking categories in Xero. For virtual brands, the split only works if the order-detail report is pulled weekly.


The 1099-K reconciliation worksheet

A 1099-K from any of the three platforms will report a number larger than what the books recorded as delivery revenue. That is the expected state; the worksheet below bridges the gap and answers an IRS notice if one ever arrives. For a broader year-end workpaper, use the dedicated workflow to reconcile 1099-Ks to the books.

Why the 1099-K is larger

The 1099-K reports the gross transaction amount the platform processed on the restaurant's behalf, including every dollar that touched the customer's payment regardless of where the dollar ultimately landed. Specifically:

  • Customer-paid sales tax — even when the platform remitted it as a marketplace facilitator. The customer paid the tax; the platform processed the transaction including the tax; the 1099-K reports the gross including the tax.
  • Customer-paid tips that passed through to the driver. The customer paid the tip; the platform processed it; the 1099-K reports it.
  • The platform's commissions, marketing fees, delivery fees, and error charges — every fee the platform netted out before depositing the residue. The customer's payment funded those fees; the 1099-K reports the gross before they were netted.

The books recorded delivery revenue as gross food sales — the customer-paid food subtotal before tax and tip. That figure is correctly smaller than the 1099-K gross because it excludes the tax, tip, and fee components that the 1099-K does include.

The worksheet

Build it per platform per year. Take the running example expanded to a year — a restaurant doing roughly $7,200 of weekly DoorDash gross food sales runs to about $374,400 of annual gross. The fee mix scales the same way the weekly entry did:

LineAmount
Books Delivery Revenue — DoorDash (annual gross food sales)374,400
Plus: Platform-collected sales tax (DoorDash remitted to states under marketplace facilitator law)24,960
Plus: Pass-through tips (Dasher tips through the payout)37,440
Plus: Platform-deducted fees (commission, marketing, error charges netted from deposits)78,624
Equals: Gross transaction amount515,424
1099-K Box 1a (per the form)515,424

Match. The arithmetic runs identically on Uber Eats and Grubhub with each platform's equivalent line categories — the components vary in size but the bridge structure doesn't change. A restaurant running all three platforms ends the year with three worksheets and three matching 1099-Ks; keep them in the year-end work-paper file alongside the platform-by-platform booked revenue summary.

The 1099-K threshold context

For federal third-party network reporting, the IRS says the One Big Beautiful Bill reinstated the pre-ARPA Form 1099-K threshold: more than $20,000 in gross reportable payments and more than 200 transactions. Restaurants should still build the worksheet, because material delivery volume can clear the threshold, payment-card reporting follows different rules, and state reporting thresholds may be lower.

The CP2000 mechanic

The IRS's Automated Underreporter program matches 1099-K totals against gross receipts on the return. If the books show $180,000 of delivery revenue and the 1099-Ks total $240,000 with no reconciling explanation, the system generates a CP2000 notice proposing additional tax (and interest) on the difference. The notice doesn't accuse fraud; it asks for an explanation. The reconciliation worksheet, kept on file, is the explanation — attach it, show the line-by-line bridge from booked revenue to 1099-K gross, and the underreporter case closes.

CP2000s on delivery 1099-Ks arrive 18 to 24 months after the return was filed, which means the bridge has to be documented at filing time. Reconstructing it two years later from primary platform statements is hours of work the contemporaneous worksheet avoids entirely. For restaurants with multiple legal entities or multiple EINs running on the same platform, also reconcile against the EIN on the 1099-K — if the form is on the wrong EIN, request a corrected one before filing rather than apportioning revenue across entities on the return.

The DoorDash 1099-K reconciliation, and the equivalent on Uber Eats and Grubhub, ultimately reduces to the same one-page exercise: book the gross, track the tax, tip, and fee components all year, run the bridge at year-end, file the result. Done weekly with the right journal-entry structure, it requires no extra work at tax time — the bridge is just an aggregation of figures already living in their own GL accounts.


The reconciliation cadence and where the platform statement starts

The workflow runs on a calendar. Every step has a natural frequency, and the labour stays manageable when each piece of work happens at the cadence that matches its purpose rather than backing up to month-end or year-end.

Weekly. Pull each platform's payout report. Translate each line through the normalisation table. Build the journal entry — gross to Delivery Sales Income, fees to their expense lines, refunds to Customer Refunds & Adjustments, pass-through tax to Sales Tax Payable where applicable. Post in QuickBooks Online or Xero. Match the bank deposit to the asset-side debit. Time per platform per location, once the chart of accounts is set up: minutes.

Monthly. Roll up each platform's gross sales, commissions, marketing, and net deposit; reconcile total platform deposits to the bank; run the per-platform P&L to spot trend changes — a creeping commission ratio, a rising error-charge rate, marketing absorbing more of gross.

Quarterly. Prepare the marketplace-facilitator deduction or report for each state DOR filing using the per-state, per-platform revenue split.

Annually. Open the 1099-Ks. Run the reconciliation worksheet per platform per year. File alongside the return.

A parallel AP-side cadence runs on the supplier statements coming in from food and beverage vendors — supplier-side statement reconciliation for restaurants covers the equivalent rhythm on that side, and feeding Sysco and Brakes invoices into a weekly purchase log sits on the same weekly close calendar a bookkeeper is already running.

Where the data has to come from

Every step on the calendar runs on the platform's payout statement — a PDF in the merchant portal or a CSV from the report exporter. For an operator on three platforms with four locations, that's twelve statements a week, six hundred plus a year. The line categories are stable but each statement still needs a per-statement parse to extract the figures the journal entry needs. The journal entry itself is a couple of minutes of work; the upstream parsing is the bulk of the labour.

The extraction setup pays back when the same DoorDash, Uber Eats, and Grubhub fields feed the weekly journal-entry template. A bookkeeper can extract delivery-platform payout statements into structured per-order data by uploading the week's PDFs or CSVs and prompting for the standard normalised fields: gross food sales, customer refunds, platform commission, marketing and promotions, error charges, sales tax collected, pass-through tips, net bank deposit, and per-platform identifiers. The saved prompt runs on each week's statements and drops the output into the normalisation table without re-typing.

Book the gross. Split every fee line. Get the marketplace facilitator and 1099-K overlays right. The books match the bank, the state DOR, and the IRS form without surprises — at month-end, at quarter-end, and a year later when the 1099-K shows up.

Extract invoice data to Excel with natural language prompts

Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.

Exceptional accuracy on financial documents
1–8 seconds per page with parallel processing
50 free pages every month — no subscription
Any document layout, language, or scan quality
Native Excel types — numbers, dates, currencies
Files encrypted and auto-deleted within 24 hours
Continue Reading