Your Lightspeed daily sales total includes $800 in DoorDash orders that you won’t see in your bank for another 3–5 business days — and when you do, they arrive as roughly $600, net of a 25% commission, not the $800 Lightspeed shows. Add Uber Eats and Grubhub on their own schedules and your Lightspeed end-of-day will never match your bank, because the POS and the delivery platforms are measuring different things on different timelines.
One Lightspeed operator told us their team spent “hours manipulating reports” trying to reconcile a single week — and still weren’t confident the numbers were right. The “missing” money usually isn’t missing: it’s unreconciled platform commission, refund clawbacks, and promotional deductions nobody matched back to the original Lightspeed orders. This guide walks through exactly why your Lightspeed sales don’t match DoorDash, Uber Eats, and Grubhub payouts, how to reconcile them, and — secondarily — how to tame the Lightspeed EOD operational friction that makes it harder to see. For the broader cross-platform picture, see our guide to reconciling delivery platform payouts.
Why your Lightspeed sales don’t match your delivery payouts
Lightspeed integrates with DoorDash, Uber Eats, and Grubhub through third-party connectors, so delivery orders flow into your POS at full menu price. At end-of-day they appear as regular revenue, but the actual cash hits your bank on the delivery platform’s schedule (weekly for DoorDash and Uber Eats, separately for Grubhub) and at net-of-commission rates.
Full menu price in, net payout out. A $40 delivery order shows as $40 in Lightspeed but nets roughly $30 after a 25% commission, days later. Without separating direct revenue from delivery revenue, the daily cash-flow picture is permanently distorted.
Misaligned timelines. Lightspeed’s processor deposits in-house card sales in 1–2 days. DoorDash pays weekly. Uber Eats pays weekly. Grubhub pays on its own schedule. The gap between Lightspeed’s EOD total and your bank only closes weekly when each platform pays out — and often not cleanly even then.
Commission and refund opacity. Each platform deducts a different commission rate plus refunds, customer promotions, and delivery fees before paying. The difference between the platform-recorded order value and the platform payout is your effective commission rate — verifying it against your contracted rate catches overcharges.
Phantom revenue from refunds. When a delivery customer is refunded by the platform, the platform deducts it from your next payout but the order still sits in Lightspeed as a completed sale. Over months these accumulate into hundreds or thousands of dollars your POS reports but your bank never received.
How to reconcile Lightspeed against your delivery payouts (step by step)
- Record delivery orders separately at EOD. Add a column to your daily reconciliation for delivery platform revenue (DoorDash $X, Uber Eats $Y, Grubhub $Z). Don’t expect this money in tonight’s bank deposit — it’s owed by the platforms separately.
- Pull each platform’s payout report. Export the transaction-level payout report from each delivery platform’s merchant dashboard for the reconciliation period — per-order commission, refund adjustments, promotional charges, net payout.
- Match Lightspeed orders to platform payouts. For each platform, match payout line items to the Lightspeed delivery orders by order ID (or timestamp + amount). Verify commission rate (commission ÷ subtotal vs. contracted), refund deductions against your Lightspeed tickets, and that every Lightspeed delivery order appears on a payout.
- Match each payout to the bank deposit. DoorDash and Grubhub pay weekly; Uber Eats pays weekly. Match each platform’s net payout to the corresponding bank deposit, allowing 3–5 business days. Our DoorDash payout reconciliation guide covers the per-order process.
- Flag and dispute the gaps. Over-charged commission, refund clawbacks on correctly-fulfilled orders, missing orders, and unenrolled promo deductions are recoverable. Record order ID, expected vs. actual, and dispute through the platform’s merchant portal with the Lightspeed ticket as evidence.
See how much your Lightspeed restaurant may be losing to delivery commission errors, refund clawbacks, and missing payouts.
Run a Free ScanThe secondary issue: Lightspeed EOD operational friction
Delivery payouts are where the money actually leaks. Lightspeed’s own end-of-day process is a secondary, operational problem — it doesn’t lose you money so much as it makes the close-out tedious and obscures the delivery gap. It’s still worth fixing so EOD friction doesn’t mask the discrepancies above.
Why Lightspeed Restaurant end-of-day feels confusing
The core issue isn’t that Lightspeed’s numbers are wrong — it’s that the information required to close out a day is scattered across four different places.
Multi-report reconciliation. Lightspeed separates your EOD data across the daily sales summary, the cash management report, the tip declaration report, and the payment method breakdown. Each shows part of the close-out picture. None shows the complete reconciliation. A manager trying to verify “did today balance?” has to open all four reports, cross-reference numbers between them, and reconcile them in their head. This is why operators describe the reports as confusing — not because they’re inaccurate, but because they require reassembly work before they’re useful.
Revenue center complexity. If your restaurant runs separate revenue centers for bar, dining room, and takeout, Lightspeed makes you close each one individually before running the final close-out. For a three-revenue-center restaurant, that’s three separate close-out workflows plus the master close-out — four total passes through the EOD process. A single-revenue-center restaurant closes out in 10–15 minutes. A three-revenue-center restaurant takes 25–35 minutes if everything goes smoothly.
Verbose reporting. Lightspeed’s daily reports are comprehensive but dense. The full EOD report is often 4–6 pages of sales data, tax breakdowns, payment method splits, and inventory movement. The reconciliation-critical numbers (cash drawer expected vs. actual, tip totals, credit card batch totals) are buried among less-relevant data, which slows down managers who just need to verify the close-out balanced.
Delivery platform interaction. If you integrate DoorDash, Uber Eats, or Grubhub with Lightspeed, those orders appear in your sales report at full menu price. But the delivery platform pays you separately on its own schedule (typically weekly) and at net-of-commission rates. At EOD, delivery orders look like they’re part of today’s revenue, but the cash flow doesn’t arrive until days or weeks later.
The “can’t adjust after entry” problem
Lightspeed Restaurant locks reconciliation entries once they’re submitted. This is a common complaint from operators: “Lightspeed Restaurant reconciliation can’t adjust if entered wrong.” The design choice is intentional — locked entries preserve audit integrity and prevent accidental data changes — but it creates real operational friction.
What triggers the need to adjust:
- A manager enters a wrong cash count before fully counting the drawer
- A server declares tips incorrectly before the batch closes
- A late-night transaction comes in after the close-out was submitted
- A refund or void is processed after reconciliation but before batch settlement
- A credit card batch amount differs from what was expected due to processor timing
The workaround: Since you can’t edit the submitted entry, you create a correcting entry in the next day’s reconciliation with notes explaining the adjustment. The process:
- Document the original error. Screenshot the locked entry and note the exact amount that was wrong.
- Calculate the correction. Determine the adjustment amount (positive or negative).
- Enter the correction in tomorrow’s reconciliation. Use the adjustment field (if Lightspeed shows one) or add it as a line-item note in the cash variance section.
- Record the audit trail. Keep a separate log of all corrections with the original submission date, correction date, amount, reason, and manager name. This protects you during bookkeeping reviews and year-end audits.
- Escalate repeat errors. If the same type of error happens twice in a week, review the underlying process. The issue is usually training or a timing problem, not the software.
The friction of this workaround is real, but it’s manageable with consistent documentation. Where it becomes a problem is in restaurants that don’t maintain the audit log — over time, the gap between original submissions and bank deposits grows unexplained, and the correcting entries become impossible to reconcile backward.
Multi-revenue-center close-out workflow
For restaurants running separate bar, dining room, and takeout revenue centers, Lightspeed’s EOD process has a specific order of operations that minimizes errors:
- Close the bar first (usually earliest to finish service). Complete the bar revenue center’s close-out including tip declarations and cash drawer count. Document the numbers before submitting.
- Close takeout next (typically second to finish). Run through the same close-out for the takeout revenue center.
- Close the dining room last. This is usually the final revenue center to finish service. Complete the dining room close-out.
- Process the master close-out. Once all three revenue centers are closed, run the final restaurant-wide close-out. This consolidates all revenue center data.
- Verify the master total matches the sum of revenue centers. Add the three revenue center totals together and confirm they equal the master close-out total. If they don’t match, there’s a transaction that fell between centers — investigate before closing the batch.
- Close the credit card batch. Only after the master close-out is verified should the credit card batch be submitted. Closing the batch first locks the deposit before you’ve confirmed the numbers.
This sequence saves roughly 5–10 minutes compared to closing revenue centers in a random order because it minimizes the number of times you have to go back and fix cross-center transactions. The total for a well-trained multi-revenue-center operation should be 20–30 minutes, not 45+.
Common Lightspeed EOD discrepancies
Even when managers follow the right workflow, Lightspeed Restaurant EOD can fail to balance for specific reasons. The reference table below covers the symptoms operators report most often, what’s actually causing the gap, and the specific fix.
| Symptom you see | What’s actually causing it | How to fix |
|---|---|---|
| Credit card batch total doesn’t match POS card total | Tip declared after batch closed | Make tip declaration mandatory before close-out |
| Cash drawer consistently $2–$5 off every shift | Small variances accumulating, not investigated | Pull weekly cash variance report; coach drawer that’s consistently off |
| Today’s sales lower than expected, yesterday’s higher | Refund processed after yesterday’s close hit today’s totals | Track post-close refunds separately; reconcile weekly, not daily |
| POS daily total way higher than bank deposit | Delivery platform orders inflating gross at menu price | Separate delivery revenue from direct at EOD; reconcile platform payouts weekly |
| Daily summary missing EBT/SNAP totals | Default Lightspeed report excludes alternate payment types | Manually add EBT totals or build a custom report |
| Three different reports show three different sales totals | Closed-check, EOD, and processor settlement reports use different bases | Trust the processor settlement report when reconciling against bank |
| Reconciliation entry can’t be edited after entry | Lightspeed locks reconciliation records once submitted | Document the correction in a daily log; don’t try to overwrite |
| Multi-revenue-center totals don’t roll up cleanly | Cross-center transactions (drink moved from bar to dining room) double-count | Close revenue centers in fixed order: bar → dining → takeout → delivery |
Lightspeed EOD checklist (use every shift)
Run through these eight items in order at every close-out. Skipping any of them is the source of 80% of next-morning reconciliation problems.
- Confirm all servers have declared tips — before any batch closes.
- Close revenue centers in fixed order: bar → dining room → takeout → delivery.
- Settle the credit card batch and verify the “settled” status appears in the Lightspeed Payments dashboard.
- Count the cash drawer, subtract the starting bank, compare to POS cash total. Variance over $10 gets flagged in the daily log.
- Run the daily sales summary AND the processor settlement report. Note the totals from both.
- Record delivery platform totals separately (DoorDash $X, Uber Eats $Y, Grubhub $Z). Don’t reconcile these tonight.
- Note any post-close refunds, voids, or comps in the daily log so they can be applied to the correct day in weekly reconciliation.
- Lock the day in your daily log: gross sales, cash variance, batch total, delivery totals, voids/comps, and any anomalies.
The detailed discrepancy explanations below cover each symptom in the table in more depth.
Tips batched before declaration. Lightspeed processes tip amounts through the credit card batch. If a server forgets to declare a tip before the batch closes, the credit card batch includes the tip amount but the tip declaration report shows a lower total. This creates a variance that looks like missing money on one report and extra money on another. The fix is mandatory tip declaration before close-out — build it into the shift-end checklist.
Cash drawer variance accumulating. Small daily cash variances ($2 short here, $3 over there) accumulate into larger weekly problems if not investigated. Lightspeed’s cash management report shows daily variance but doesn’t aggregate it automatically. Pull a weekly cash variance summary every Monday and address any drawer that’s consistently off by more than $5/day.
Refunds processed post-close. A customer returns the next morning with a complaint, and the refund is processed after yesterday’s close-out. Lightspeed processes the refund against the current day’s sales, which makes today look lower than it should and yesterday look higher than it actually was. Track post-close refunds separately for cleaner weekly reconciliation.
Delivery platform orders creating phantom revenue. DoorDash or Uber Eats orders appear in Lightspeed’s daily sales at full menu price. They show up as revenue today, but the actual payout arrives days later at net-of-commission rates. This is why your Lightspeed daily total will almost never match your bank deposit when delivery platforms are active. Track delivery revenue separately from direct revenue at EOD.
Missing EBT or alternate payment method. If your restaurant accepts SNAP/EBT, food stamps, or other alternate payment methods, Lightspeed’s standard EOD flow may not include them in the daily summary. Operators report needing to manually add EBT totals to the close-out because the default report excludes them. Check if any payment types are missing from your summary report and add them to your close-out checklist.
Speeding up Lightspeed Restaurant EOD
Most Lightspeed close-out problems come from process, not software. Here are the changes that cut EOD time most effectively:
Standardize the shift-end checklist. Every shift manager should have a written checklist covering: final tip declarations, cash drawer count procedure, refund processing cutoff, credit card batch verification, and delivery platform order review. A standardized checklist reduces training time and prevents the most common errors.
Run reports in parallel where possible. While the master close-out is running, the closing manager can be counting the cash drawer, reviewing the tip declaration report, and checking the delivery platform order list. Many managers serialize these tasks when they could run them together.
Batch correcting entries weekly, not daily. If you’re using the “next-day correction” workaround for locked entries, batch the corrections at end-of-week rather than trying to remember each one. Keep a single running log during the week and process all corrections in one Monday reconciliation review.
Separate delivery revenue tracking. Add a column to your daily reconciliation spreadsheet for delivery platform revenue specifically. This prevents the phantom-revenue problem from contaminating your cash flow view. For the full multi-platform matching process, see our guide on reconciling DoorDash, Uber Eats, and Grubhub payouts.
Automate what Lightspeed can’t. Lightspeed’s locked-entry constraint and multi-report scattering are fundamental design choices that won’t change. The gap between “what Lightspeed produces” and “what a manager needs to actually close out” is where external reconciliation tools earn their keep.
This pattern of report-vs-payout disagreement isn’t unique to Lightspeed. Operators on other POS systems run into structurally identical delivery reconciliation gaps — see Clover sales not matching delivery payouts and Toast sales not matching delivery payouts. Different POS, same root cause: the POS records delivery at menu price while the platform pays net of commission on a different timeline.
How DeliverGuard helps Lightspeed restaurants
Manually reconciling Lightspeed against your bank while tracking delivery platform payouts on their own timelines is the kind of work that gets skipped once managers realize how much time it takes. One Lightspeed operator told us their team spent “hours manipulating reports” trying to reconcile a single week — and even then, they weren’t fully confident the numbers were right.
DeliverGuard automates the multi-source reconciliation that Lightspeed can’t do natively. Upload your Lightspeed payment reports, your delivery platform statements from DoorDash, Uber Eats, and Grubhub, and your bank transaction history. The system matches every transaction across all three data sources. Lightspeed processing fees, delivery platform commissions, refund adjustments, chargebacks, and timing delays are all categorized automatically.
For Lightspeed restaurants running delivery, this is the highest-value integration. Instead of needing Lightspeed’s four separate reports plus three platform reports plus your bank statement to book one week, you get one reconciled view after uploading each source once. Processing fee overcharges, commission variances, and missing payouts are all surfaced together with the transaction-level evidence needed to dispute them.
The “can’t adjust locked entries” problem becomes less painful when the reconciliation happens in an external system that can flag corrections without modifying Lightspeed’s audit record. You keep Lightspeed’s integrity, you get the reconciliation flexibility you actually need.
Stop spending an hour on Lightspeed close-out. Upload your reports, delivery platform data, and bank transactions to see the full reconciliation in minutes. Free scan, no credit card required.
Run a Free ScanFrequently Asked Questions
Lightspeed records every delivery order at full menu price in your end-of-day sales, but DoorDash, Uber Eats, and Grubhub collect the customer payment and pay you separately, days later, net of a 15–30% commission plus refund and promotional adjustments. Your Lightspeed daily total will include $800 in DoorDash orders that arrive 3–5 days later as roughly $600 after a 25% commission. The POS and the platforms are measuring different things on different timelines, so EOD will never balance against the bank when delivery is active.
After the platform’s commission (typically 25%) plus refund and promotional adjustments, $800 in menu-price delivery orders nets roughly $600, and it arrives on the platform’s weekly schedule rather than Lightspeed’s processing schedule. The ‘missing’ ~$200 is unreconciled commission, refund clawbacks, and promotional deductions that were never matched back to the original Lightspeed orders.
At end-of-day, record delivery platform orders separately from direct revenue. For each platform, pull the merchant payout report and match it order-by-order to the Lightspeed delivery orders for the period, accounting for commission, refund deductions, and payout timing. The gap between platform-recorded order value and platform payout is your effective commission rate — anything above your contracted rate, plus refund clawbacks on correctly-fulfilled orders and missing orders, is a recoverable discrepancy.
Separately from delivery, Lightspeed spreads EOD data across the daily sales summary, cash management, tip declaration, and payment breakdown reports, and it locks reconciliation entries once submitted. This operational friction is real but secondary — it makes close-out tedious, whereas the delivery payout gap is what actually leaves money unrecovered. The workaround for locked entries is a documented correcting entry in the next day’s reconciliation.
Lightspeed splits tip reconciliation into tip declaration (what servers report) and tip batch processing (what goes through credit card batches). Both must be completed before the batch closes or the amounts won’t match. If a server forgets to declare a tip before batch close, the credit card batch will include the tip amount but the tip declaration report will show a lower total, creating a gap that carries into the next day’s reconciliation.