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.
What follows is the workflow end to end: payout-statement anatomy across all three platforms with a normalisation table, the QuickBooks Online and Xero journal entries with the actual debits and credits, the marketplace facilitator framework (including the post-July-2025 DoorDash local-tax pass-through change tripping operators in 2026), and the 1099-K reconciliation worksheet a CPA can use directly at filing.
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 category | DoorDash field | Uber Eats field | Grubhub field |
|---|---|---|---|
| Gross Food Sales | Gross sales | Order Earnings + Service Fee (derived) | Gross order subtotals |
| Customer Refunds | Customer refunds | Adjustments (refund portion) | Refunds and adjustments (refund portion) |
| Platform Commission | Commissions | Service Fee | Marketing commission + delivery commission + processing fees |
| Marketing & Promotions Charged Back | Marketing fees | Promotions (restaurant-funded only) | Promotional charges where itemised |
| Error Charges & Adjustments | Error charges + customer support adjustments + restaurant adjustments | Adjustments (error and quality portion) | Refunds and adjustments (adjustment portion) |
| Sales Tax Collected (marketplace-facilitated) | Customer tax | Taxes (collected-and-remitted portion) | Marketplace facilitator tax |
| Pass-Through Tips | Tips | Tips | Tips |
| Net Bank Deposit | Net payout | Total Payout | Net 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.
The bundled-deposit shape isn't unique to restaurant delivery — the same payout-to-deposit pattern in hotel OTA commission reconciliation runs on the booking platforms a hotel uses, with the same gross-vs-net principle. 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:
| Account | Debit | Credit |
|---|---|---|
| Bank — Operating (DoorDash deposit) | 4,800 | |
| Delivery Platform Commissions | 2,000 | |
| Delivery Platform Marketing & Promotions | 200 | |
| Delivery Platform Error Charges | 100 | |
| Customer Refunds & Adjustments | 100 | |
| Delivery Sales Income — DoorDash | 7,200 | |
| Totals | 7,200 | 7,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.
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, marketing fees, error charges, and customer refunds: the categorisation traps
Four line categories on the payout statement get mis-coded more than any other. None are arithmetically large enough to break the bank match — the deposit still ties — but each one quietly distorts the P&L and breaks the 1099-K reconciliation if posted to the wrong account.
Restaurant-funded promotions belong in marketing expense
When DoorDash or Uber Eats charges back a "$10 off orders $30+" promotion, the restaurant is paying for visibility on the platform. The customer paid the platform the discounted total; the platform paid the restaurant the discounted total; the difference between the menu-listed gross and the platform-paid amount is a marketing cost the restaurant absorbed in exchange for the order existing. Book it as marketing expense. Two things break under the wrong treatment: marketing spend is understated, and the apparent commission ratio gets noisier because what is really a discrete marketing decision shows up as a fluctuating dent in revenue. The third break is the 1099-K reconciliation, which expects marketing-expense as a bridge between menu gross and recorded revenue.
A subset of promotions is platform-funded — Uber Eats or DoorDash absorbs the discount as their own customer-acquisition spend. These don't appear as a charge on the restaurant's payout. The trap is reading the report carefully enough to tell which is which: on Uber Eats, the Promotions field generally splits restaurant-funded and platform-funded explicitly; on DoorDash, the Marketing fees line typically captures restaurant-funded only. A bookkeeper who treats every "Promotion" line as a restaurant cost absorbs phantom marketing spend the restaurant never owed.
Error charges and customer refunds are refunds of revenue, not commission
When a customer reports a missing item, the platform refunds the customer and charges the restaurant back. The economic event is a refund of revenue. The right home is either the Customer Refunds & Adjustments contra-revenue account or a separate Delivery Platform Error Charges expense if the operator wants kitchen-error volume tracked discretely. It is not commission — mis-classifying as commission inflates the apparent take-rate and hides a fixable kitchen problem (wrong items going out at 6pm Friday, missing dipping sauces, a new line cook who hasn't internalised the modifiers).
The same logic covers customer-initiated refunds (cancelled order, never received) and platform-initiated quality adjustments (credit issued because delivery was 45 minutes late). A single Customer Refunds & Adjustments contra-revenue account that absorbs both is fine for monthly reporting; the per-event detail lives in the line memo. The principle: refunds and adjustments reduce revenue, they don't inflate expense. The P&L should show gross sales and a separate refund-and-adjustment line just below it.
Restaurant adjustments need a memo, not a new account
The Restaurant adjustments line (and equivalents on Uber Eats and Grubhub) is the platform's catch-all: a billing-dispute resolution, an equipment fee, a back-credit for an over-deduction, a rounding correction. Read the description, post to the most specific account possible (commission expense for a commission true-up, marketing for a promotion adjustment, contra-revenue for a delayed refund), and capture the underlying event in the journal-entry memo. The memo is the audit trail; without it, a year-end review is reading numbers without the why. Resist opening a new GL account for every adjustment type — the chart of accounts gets noisy fast and the memo carries per-event detail more efficiently than account proliferation does.
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 — makes payout reconciliation work. Every line maps to exactly one GL account; never let an unclassified line settle into a generic "delivery expense" bucket.
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. Toast's and Square's own merchant resources document the integration-specific layouts.
Pass-through tips, restaurant-retained tips, and the Form 8027 line
Tips on a delivery payout look like restaurant tip income at a glance — they're labelled "Tips" on the statement and they sometimes pass through the restaurant's bank account on the way somewhere else. The categorisation that matters at year-end is whether they belonged to a restaurant employee or to a third-party driver, because Form 8027 only cares about the first.
The rule
Tips collected through DoorDash, Uber Eats, or Grubhub on a marketplace order go to the delivery driver. The driver isn't a restaurant employee. The tip isn't restaurant revenue, isn't restaurant tip income, and doesn't belong on Form 8027. Where the platform pays the driver directly without routing the cash through the restaurant's bank (the typical case), there's no journal entry to make. Where the platform deposits the tip with the payout and the restaurant remits it onward, the booking treatment is a Pass-Through Tips clearing or liability account that nets to zero — credited when the tip arrives, debited when the driver-payment leg settles. Either way, tips never recognise as either income or expense to the restaurant.
Booking pass-through delivery tips as restaurant tip income inflates the Form 8027 gross receipts denominator and the reportable tip income figure. Because Form 8027's allocation mechanism compares reported tips to a percentage of gross receipts, an inflated denominator can force the restaurant to allocate additional tips to its tipped employees — creating a tax liability that the employees don't actually owe and a reporting headache that takes hours to unwind. None of it is real; it's a categorisation artefact created by treating driver tips as server tips.
The hybrid case
When a restaurant runs its own ordering channel (its own website, Toast Online Ordering, ChowNow) with delivery fulfilled by Toast Delivery Services, DoorDash Drive, or another driver-as-a-service provider, the answer turns on who employs the driver. If the driver is a restaurant employee on a hybrid in-house and delivery rota, the tip is restaurant tip income, belongs on Form 8027, and is allocated through payroll like a server's tip. If the driver is contracted through the third-party network, the tip is pass-through and treated as a marketplace tip would be. Read the contract and the platform's tip-flow documentation; the answer per channel determines the journal-entry account, and the journal-entry account determines the Form 8027 figure at year-end.
A restaurant running both in-house dining and platform delivery should keep the two tip streams in separate accounts from day one. Mixing them creates a year-end untangling problem; separated, the aggregation is automatic. The broader Form 8027 workflow lives in a companion piece on Form 8027 tip reporting from POS and payroll data.
Direct-channel orders and ghost-kitchen brand splits
Two operating shapes don't fit the standard marketplace-payout journal entry without an adjustment.
Direct-channel orders with third-party delivery
When the restaurant takes the order through its own website, its own phone line, Toast Online Ordering, ChowNow, or another first-party channel — even if the delivery is fulfilled by Toast Delivery Services, DoorDash Drive, or Uber Direct — the restaurant is the merchant. Three things change.
The restaurant collects and remits the sales tax. Marketplace facilitator law doesn't apply because no marketplace was involved in the transaction; the customer found the restaurant, the restaurant priced the order, the restaurant captured the payment. The driver-fulfilment cost is a discrete expense line, not a marketplace commission — the right account is Driver Fulfilment Cost or Third-Party Delivery, distinct from Delivery Platform Commissions, because the platform is selling driver capacity at a per-order rate rather than taking a marketing percentage. And revenue recognition is direct: gross food sales credit Direct Online Sales Income (a separate income account from Delivery Sales Income), the merchant processor fee debits payment-processing expense, the driver-fulfilment cost debits the Third-Party Delivery account, and customer-paid sales tax credits Sales Tax Payable for the state filing. The two channels should never share an income account.
Ghost kitchens and virtual brands
A single physical kitchen running two or three virtual brands on Uber Eats produces one bank deposit covering all brands. The platform statement can split orders by brand or storefront in the order-detail report, but the journal entry has to allocate the gross to each brand-level revenue line. Without that, brand-level P&L visibility is gone and the operator can't tell which virtual brand is profitable.
Set up a sales-class (QuickBooks Online) or tracking-category (Xero) per brand — or per brand-platform combination if the operator wants finer detail. Pull the brand or storefront column from the platform's order-detail report, aggregate gross sales, refunds, and platform-attributable fees per brand, and post the journal entry against the brand-tagged income lines. The ghost kitchen virtual brand delivery payout split lives or dies on the order-detail report being pulled weekly. Operators who skip it discover at month-end that aggregate revenue is right but they have no idea which brand earned what — and at that point they're rebuilding the per-brand allocation from raw report data anyway, just under quarterly-close pressure rather than weekly. The same allocation approach extends to a hotel F&B department or a catering operator running platform orders alongside its primary channel.
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 is what bridges the gap and what answers an IRS notice if one ever arrives.
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:
| Line | Amount |
|---|---|
| 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 amount | 515,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
The threshold for a 1099-K being issued has moved several times. Under the original American Rescue Plan, it was scheduled to drop to $600 in gross transactions with no minimum count. The IRS phased the transition with intermediate thresholds — $5,000 for tax year 2024, $2,500 for 2025 — and the 2025 One Big Beautiful Bill Act reset the trajectory back toward the older $20,000 / 200-transaction threshold. Verify the current-year threshold against current IRS guidance; this has changed mid-year before. Operationally the threshold question matters less than it sounds — every restaurant with material delivery volume now receives 1099-Ks from each platform regardless of where the threshold lands, because the volumes clear any of the proposed thresholds easily.
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.
That is the kind of structured-extraction job that pays back its setup quickly. Every weekly DoorDash, Uber Eats, and Grubhub statement is the same shape as the one before it, and the GL posting is built from the same set of fields each time. 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) plus per-platform identifiers, with output as a per-week or per-order Excel or CSV that drops directly into the journal-entry template. The same prompt — saved once — runs on every subsequent week's statements; the structured output drops into the normalisation table without re-typing, and the journal entry writes itself from there. For a multi-platform multi-location operator, that's the difference between the workflow being a daily friction and being a fifteen-minute Friday morning step.
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.
Related Articles
Explore adjacent guides and reference articles on this topic.
Foodservice Wholesaler Invoice to Weekly Purchase Log
Turn Sysco, Brakes, or Bidfood invoices into a weekly purchase log spreadsheet with line items, short-delivery tracking, and QuickBooks/Xero-ready totals.
Alcohol Distributor Invoice Recordkeeping for Restaurants
How US restaurants and bars should keep alcohol distributor invoices for TTB and state ABC audits, including fields, retention files, COD, and keg deposits.
Bar Pour Cost From Spirits and Beer Invoices
Calculate bar pour cost from spirits, beer, and mixer invoices. Build a spreadsheet for bottle yield, keg cost, cocktail recipes, pricing, and variance.