Restaurant POS Deposit Reconciliation: Toast, Clover, Square

Restaurant POS deposits rarely match the day's sales for five structural reasons: tips ride with card payments through the same merchant deposit, batches close on a per-meal-period or per-day cycle (lunch and dinner separately, not one flat daily total), weekend and holiday batches stack into Monday's deposit, processing fees come off before the bank credits the funds, and chargebacks reverse prior batches. The "bank is wrong" feeling restaurant operators describe is the symptom. The cause is that restaurant cash flow has more moving parts than typical retail.

The deposit decomposition is the same across vendors:

Card sales + card tips − card fees − refunds − chargebacks = net deposit.

Toast publishes this formula directly in its support documentation. The same decomposition applies on Clover, Square, and traditional-acquirer setups (Worldpay, Heartland, or Elavon as the acquirer with Aloha, Micros, or Revel as the POS). The vendor names change; the formula does not. Restaurant POS deposit reconciliation works back from the bank credit to the per-batch POS report, then isolates the variance line by line. Each term in the formula is a candidate for the variance, and the reconciliation has to identify which one.

How Tips Riding Through the Card Deposit Break the Reconciliation

When a guest leaves a tip on a credit card, the tip amount rides through the same merchant deposit as the underlying check. The acquirer doesn't separate sales from tips at settlement; both arrive together as a single net credit to the operating account, typically T+1 to T+3 after the batch closes. On the bank statement that money looks like the restaurant's revenue, but a chunk of it is owed to staff and will leave the account again on the next payroll run or the next nightly tip-out. Recognising this flow is the first move in the reconciliation. Treating the gross deposit as revenue overstates sales every day and produces a tip-pool liability that quietly disappears.

The split behaves differently per vendor, and the per-vendor difference is what makes a one-size workflow fail. Toast and Square for Restaurants both isolate tips in their reports and accounting feeds, so a bookkeeper can post tips directly to a "tips owed to staff" liability account on the same day the deposit lands. Clover and most traditional-acquirer-plus-third-party-POS setups mingle tips with sales in the deposit channel. The bookkeeper has to back the tip total out of the gross deposit using a separate POS tip report before the rest of the reconciliation begins. The reconciliation always has to split the gross deposit into card sales and card tips first; everything else (fees, refunds, chargebacks) comes off afterward.

The end-of-day journal entry has three legs at minimum: revenue net of tips, tip liability for the cash owed to staff, and a fee accrual or reduction for the processor's deduction. When tips are mingled at the source and not separated, the reconciliation drifts a little every day. The drift is invisible at the daily grain because the bank balance keeps changing for other reasons. It surfaces at the next pay period when the tip-out is paid and the liability account doesn't tie out, or at year-end when the books and the W-2s disagree on declared tips.

The tip mechanics also link out to payroll-tax obligations even when they look clean on the deposit side. Large food and beverage establishments owe tip reporting on Form 8027, and restaurants taking the FICA tip credit need declared tips and credit-card tips to reconcile to one another. A daily reconciliation that handles the deposit-side tip split correctly still has to feed the year-end tip reporting cleanly; for the deeper version of that workflow see Form 8027 tip reporting from POS and payroll data. The point for the reconciliation in front of you today: split tips out before you book revenue, and post them to a liability account that gets cleared on payroll.

Per-Vendor Report Inventory: Toast, Clover, Square, and Traditional Acquirers

Across every configuration, the reconciliation pulls the same three documents and works back from the bank credit to identify the variance: a per-batch POS report, a settlement or transfer report from the processor, and the bank statement. The vendor names and report names change; the structure is consistent. What follows is the entry-point report to start from for each major restaurant POS configuration.

Toast. The reconciliation entry point is the Settled Deposits Daily Breakdown, supplemented by the Reconciliation Report and the Sales Summary. Toast publishes the deposit formula directly in its support content and surfaces card sales, card tips, fees, refunds, chargebacks, and adjustments as named lines that map cleanly to the formula. For a fully-Toast restaurant this is the most-tractable configuration: the reports speak the reconciliation language, and the bookkeeper's job is to compare named line to named line. Most "Toast deposit doesn't match bank" cases trace to one of three things picked up by the daily breakdown: a Toast Capital deduction, a chargeback reversal landing in the current deposit, or weekend stacking. All three are itemised; the bookkeeper has to read the breakdown carefully rather than start from the bank balance.

Clover. The reconciliation entry point is the Deposits view in the Clover dashboard, paired with the closing report from the POS itself. Two specifics matter for Clover and they're the source of most operator complaints. Clover's batch-close cuts at 7 p.m. PST regardless of where the restaurant operates, which means a dinner shift on the East Coast straddles two batches. And Clover frequently combines multiple days into a single deposit (a typical pattern: Friday, Saturday, and Sunday rolled into Monday) without an obvious per-day breakdown in the deposits view. Operators routinely report that their Clover deposit doesn't add up to a single day's sales because the deposit isn't a single day. The reconciliation reassembles per-day sales from the closing reports rather than starting from the deposit total and asking why it's wrong.

Square (for Restaurants). The reconciliation entry point is the Transfer reports under Balance, with the Sales Summary and the Tips report as supporting detail. Square's native exports are usable: tips are isolated, fees are itemised by transaction, transfers tie to specific batch ranges. When the restaurant is fully on Square, the surface is straightforward and a clean daily reconciliation runs against the Transfer report directly.

Traditional acquirer plus third-party POS. This is the hardest configuration and the one where the manual workload concentrates. Worldpay, Heartland, or Elavon as the acquirer paired with Aloha, Micros, or Revel as the POS produces a genuinely three-document reconciliation: the daily POS report from Aloha or Micros or Revel for the sales and tip detail, the merchant statement from the acquirer for fees and chargebacks, and the bank statement for the actual credit. The processor statement is typically a multi-page PDF (Worldpay's MoneyMovement reports, Heartland's InfoCentral statements, Elavon's similar formats) running to hundreds of dense lines, not a clean per-batch breakdown that maps directly to the deposit formula. Before the per-batch reconciliation can start, the bookkeeper either keys the processor statement into a spreadsheet by hand or runs it through an extraction tool. For restaurants on Heartland in particular, a tighter walk of the statement and what to pull lives in Heartland merchant statement extraction for restaurants on traditional acquirers.

Multi-Batch Settlement: Lunch and Dinner, Weekend Stacks, and AMEX on a Different Cycle

Non-uniform settlement timing is the rule for restaurants, not the exception. A bookkeeper running a daily reconciliation has to reconcile batches, not days; once the per-batch grain is the unit of work, the patterns below stop looking like errors and start looking like the timetable they actually are.

The lunch-plus-dinner double batch is the baseline pattern for most full-service restaurants. A POS configured to capture at end of lunch (typically around 4 p.m.) and end of dinner (close of night) produces two separate captures per day, and each batch settles as its own deposit on T+1 to T+3 depending on processor rules and cutoff times. The bank credit on a given day reflects whichever batches happen to land that day, not whichever batches closed the day before. A fast-casual operator on a single end-of-day capture sees one batch per day; a fine-dining operator with three or four captures (lunch, between services, dinner, late-night) sees three or four. The reconciliation tracks per-batch and rolls up to per-day downstream, never the other way around.

Weekend stacking is the single most common cause of "the bank deposit doesn't match Friday's sales." Most acquirers do not settle on weekends, so Friday, Saturday, and Sunday batches frequently land together in Monday's deposit (sometimes Tuesday's, depending on processor and bank rules). The Monday deposit is the three-day stack, not Friday alone. Holiday weeks extend the pattern: a Thursday-Friday-Saturday-Sunday stack around Thanksgiving lands on Monday, and a four- or five-day stack around Christmas or New Year is normal. The reconciliation reassembles per-batch from the POS side and matches the consolidated Monday credit against the sum of those batches; the daily-grain reconciliation tab will show no Friday deposit at all, and that's correct.

American Express usually settles on a separate cadence from Visa and Mastercard, frequently landing one or two days later. A daily batch typically produces two deposits to the operating account: one for Visa, Mastercard, and Discover combined, and a second AMEX-only deposit a day or two behind. The reconciliation has to split card brands at the POS side so the AMEX-only portion of the batch matches the AMEX-only deposit. Restaurants on a single-MID setup with AMEX OptBlue see the brands consolidated into one deposit, which is one of the more useful reasons to consolidate; restaurants with a direct AMEX merchant agreement still see the two-stream pattern.

Toast Capital deducts loan repayments from each deposit before the bank credit. A restaurant on a Toast Capital advance sees every deposit come in by a fixed dollar amount or a fixed percentage less than the underlying batch, and the variance is not invisible: it's a named line in the Settled Deposits detail on the Toast side. It is invisible if the bookkeeper reconciles from the bank statement back without pulling the Toast-side report, which is what makes it worth flagging. The pattern repeats for other POS-financed advance products on Square Capital, Clover Capital, and similar; the structural rule is that any merchant-cash-advance-style product takes its repayment at the deposit level, and the bank statement won't tell you why.

Holdbacks and Chargebacks: Tracing Today's Variance to a Dispute From Weeks Ago

A chargeback reverses a prior transaction. When a cardholder disputes a charge, the issuer pulls the funds back from the acquirer; the acquirer deducts the disputed amount from a future deposit to the merchant. The deposit that lands light today can reflect a meal a guest disputed three weeks ago, and the variance won't show up anywhere in today's batch totals because the original transaction was never in today's batch.

The structural cause of the long lookback is in federal billing-error rules, not in any individual processor's policy. Under federal credit-card billing-error rules, cardholders must send a written dispute notice to the card issuer within 60 calendar days after the charge appears on their statement. Combined with statement-cycle timing, that 60-day window means a meal eaten in early March can produce a chargeback that hits the merchant's deposit in mid-May. The 60-day floor isn't a quirk of how chargebacks happen to work; it's the federal floor that defines how far back the reconciliation has to be willing to look. Internal acquirer timelines for processing the dispute add more days on top.

Holdbacks (sometimes called reserves) are the second mechanism that decouples today's deposit from today's sales. Acquirers protect themselves against future chargebacks by holding back a percentage of each deposit, particularly for restaurants that have crossed risk thresholds: a high chargeback ratio, a long average ticket, large reservation deposits taken in advance of service, or seasonal exposure. The held-back amount appears as a reduction in the current deposit and is released later, sometimes weeks later, sometimes only at contract anniversary. A restaurant on a holdback sees every deposit come in light by a consistent percentage, and the reconciliation has to recognise the pattern and book the held-back amount as a receivable rather than chase it as missing revenue.

A worked example tightens the picture. A guest disputes a $180 dinner check from three weeks ago. Today's deposit lands $182.43 short of the computed net based on the formula at the start of this article. The reconciliation traces the variance: $180 chargeback principal plus a $2.43 chargeback fee, both itemised on the merchant statement under the original transaction reference. The variance reason field on the daily reconciliation row gets "chargeback, original transaction [date], reason code [code], representment in progress" and the bookkeeper queues the dispute paperwork on the operations side. Without the multi-week lookback the variance reads as missing revenue and never resolves.

The dispute lifecycle has stages worth knowing because each one can move money in or out of a deposit. A retrieval request is a request for documentation; the funds aren't pulled yet but the merchant has to respond. The first chargeback pulls the funds. Representment is the merchant's rebuttal with evidence (the signed receipt, the contemporaneous communication, the delivery confirmation), and a successful representment puts the funds back in a future deposit. A second chargeback (also called pre-arbitration) pulls them again if the cardholder counters. Visa and Mastercard each publish chargeback reason codes that identify why the cardholder disputed, and a competent reconciliation captures the reason code alongside the original transaction reference so the trace is reproducible later.

The Daily Reconciliation Spreadsheet Schema

Every restaurant bookkeeper running the daily close cycle on cash and card needs a column structure for the reconciliation sheet, and the structure that handles the patterns covered in the prior sections is consistent across vendors. The daily reconciliation row carries these columns, in this order:

• Date. Calendar date of the batch, not the deposit date.
• Meal period. Lunch, dinner, brunch, late-night, or all-day depending on the restaurant's batch configuration.
• Batch identifier. The acquirer's or POS's batch number for traceability back to the source.
• Gross card sales. From the per-batch POS report, before tips.
• Gross card tips. From the POS report, separated explicitly so the tip-pool liability can be booked downstream.
• Refunds. Refunds processed against this batch.
• Chargebacks. Chargebacks landing in this batch's deposit, regardless of when the original transaction occurred.
• Processing fees. From the merchant statement, allocated to the batch.
• Net deposit (computed). Card sales + card tips − card fees − refunds − chargebacks.
• Actual deposit. From the bank statement, matched to the batch by the cadence (T+1 to T+3) and card brand.
• Variance. Actual deposit minus computed net deposit.
• Variance reason. The bookkeeper's annotation after the trace, populated only when variance is non-zero (chargeback from prior batch, holdback, Toast Capital deduction, AMEX cycle offset, missing tip total, fee accrual error, and so on).

Every column has a single source. Card sales, card tips, and refunds come from the POS report. Fees and chargebacks come from the processor statement. The actual deposit comes from the bank. The variance reason is the only judgment column; everything else ties back to a document.

A summary tab aggregates the per-batch rows by week and by month. The weekly rollup is what handles weekend stacking cleanly: Friday, Saturday, and Sunday batches that land in Monday's deposit collapse into a single weekly view where the sum of three POS-side batches equals the consolidated Monday bank credit. The daily-grain tab will show no Friday deposit at all and that's correct; the weekly rollup is what reconciles. Month-end produces the per-MID and per-location summary that feeds general-ledger posting.

Tip-split conventions live in a sibling column or a sibling tab depending on preference. Some bookkeepers add a "tips owed to staff liability" column that mirrors gross card tips and posts to a balance-sheet liability instead of revenue. Others post tips through a tip-pool clearing account that zeroes out at each pay-period tip-out. The schema accommodates either; the column structure stays the same and only the posting destination changes. The point is that gross card tips never flow to revenue, only to a liability or clearing account that gets paid out.

The close-cycle discipline is what makes the schema useful rather than an artifact. The daily reconciliation runs against current-day batches with whatever has cleared the bank by morning; the weekly rollup runs at the end of each operating week; month-end produces the per-MID and per-location summary. Variances that don't resolve same-day go into an aging queue, which is where the chargeback trace from the prior section lives: a $182.43 variance today might sit in the queue for three weeks before the chargeback paperwork closes. A clean restaurant runs with most variances resolved within seven days and an aging queue that's bounded by chargeback-cycle length. The same close-cycle discipline runs against the AP side of the books too, where supplier invoices are coded and posted on a parallel schedule; the close-cycle pattern for restaurant supplier invoice coding for the AP companion workflow is its own discipline but moves on the same monthly calendar.

One scope boundary the schema does not cover: third-party delivery payouts. DoorDash, Uber Eats, and Grubhub each settle on their own cycle outside the POS deposit channel, even when those orders also appeared in the POS sales total at face value. The deposit-reconciliation sheet handles card-deposit settlement only; a parallel sheet handles delivery payouts and the commission, marketing-fee, and adjustment lines those platforms deduct before paying out. For the column structure of that sheet see third-party delivery payout reconciliation for restaurants.

Multi-Unit and Franchise: Aggregating the Close Across Locations

Multi-unit restaurant deposit reconciliation is the same per-batch discipline applied across more locations, but the consolidation step is where most groups break down. A multi-unit operator typically holds one Merchant Identifier (MID) per location, sometimes per concept-and-location combination when a single building runs two concepts under different EINs. Each MID produces its own deposits, fees, and chargebacks, and the consolidated reconciliation rolls per-MID totals into a group view. The schema from the previous section extends with a location column and a MID column; the per-batch grain stays the same.

The franchise instance has its own structure. In a franchise model the franchisor often consolidates merchant processing centrally (one acquirer relationship, one fee schedule across the system) but each franchisee operates as its own MID for settlement purposes. The franchisor sees aggregated processing volume and rebate accounting; the franchisee sees per-location deposits and the same per-MID reconciliation any independent operator runs. Fee aggregation and rebate accounting at the franchisor level is its own sub-discipline that surfaces in a multi-MID view of the same statements; for the deeper version see multi-location franchise merchant fee aggregation across MIDs. The point for the franchisee's bookkeeper is that the per-location close still runs against the same per-MID schema regardless of how the franchisor handles the parent agreement.

Month-end across the group surfaces two recurring period-boundary issues: a chargeback that crossed the month (original transaction in the prior month, chargeback landing in a current-month deposit), and a multi-day batch stack that straddled the month-end weekend (a Friday batch from the last day of the prior month settling on the first business day of the current month). Both are handled by the per-batch grain in the daily schema; the period-boundary entries get manual flags and a reclass at close.

The year-end picture follows directly. Each acquirer issues a 1099-K to each MID reporting gross processed volume per month, before tips were split out, before fees were deducted, before chargebacks reversed prior transactions; a group that has run a clean per-batch reconciliation all year produces a 1099-K that ties to the books to within a few dollars, and a group that hasn't, doesn't. The deeper walk of 1099-K reconciliation against the books at year-end covers the form itself.

A note on revenue-share arrangements that show up in some franchise relationships: certain franchisors take royalty or marketing-fund deductions at the merchant level rather than billing the franchisee separately. Where this happens, the deduction lands as a reduction in the deposit and looks structurally similar to a Toast Capital pattern. Treat it as a separate ledger line in the variance reason rather than burying it inside processing fees, because it isn't a processing cost and doesn't belong in the same posting bucket.

Where Tooling Reaches and Where Manual Extraction Persists

For a fully-Toast restaurant, Toast's Reconciliation Report combined with the Settled Deposits Daily Breakdown handles the bulk of the daily reconciliation directly. Tips are isolated, fees are itemised, chargebacks appear as named lines, and Toast Capital deductions are visible in the breakdown. The bookkeeper still posts the journal entries and resolves variances, but the data is delivered in reconciliation-ready form. Worth saying plainly: this is the most-tractable configuration. A single-vendor Toast operator running the Reconciliation Report against a per-batch spreadsheet schema has the path of least resistance.

Accounting platforms layer on top. QuickBooks Online, Restaurant365, and Compeat each integrate with Toast, Square, and Clover to varying depths; Restaurant365 in particular targets restaurant operators with a deeper close model than generic SMB accounting handles, and it pulls per-batch detail in a form that makes the daily reconciliation largely a posting and review exercise. The integrations cover day-to-day journal posting and reduce manual entry meaningfully when the restaurant runs on a vendor the integration supports. None of them, in the current state of the market, fully reconciles a multi-vendor or traditional-acquirer setup end-to-end without supplementary work.

The manual-extraction step persists most for traditional-acquirer-plus-third-party-POS configurations. The reconciliation pulls from a multi-page PDF processor statement (often hundreds of dense lines), a separate POS daily report, and the bank statement, and no native integration reads all three. The bookkeeper either keys the processor statement by hand into the reconciliation spreadsheet, or runs it through AI extraction for restaurant POS reports and merchant statements to produce the structured rows the schema needs. The extraction step is the same prompt-based workflow that handles invoices: upload the statement (multi-page PDFs are supported up to several thousand pages, and a month's worth of statements across multiple MIDs can run as a single batch), describe the columns the reconciliation needs, and download an Excel or CSV file shaped to the schema in the previous section. The manual or extracted rows feed the same per-batch reconciliation; only the front-end of the workflow changes.

The same variance discipline runs against any merchant business reconciling card deposits to the bank, not only restaurants; the timing patterns (weekend stacking, multi-cycle settlement, processor holdbacks) are common across processors. For the broader version of the workflow that doesn't carry the restaurant-specific tip-flow split, multi-batch settlement, or per-meal-period grain, see generic merchant card deposit reconciliation at month-end. What this article covers that the generic version doesn't are the three load-bearing complications that define restaurant reconciliation: tips through the deposit, lunch-and-dinner double batches with weekend stacks on top, and chargeback or holdback trace across multiple weeks.

The operational read depends on the configuration the restaurant runs. Single-vendor on Toast, Square, or Clover: native reports plus a clean daily schema, with the integration covering most posting. Traditional acquirer plus Aloha, Micros, or Revel: extraction-then-schema, and the extraction step is where the time goes. Multi-unit across vendors: the same per-MID schema replicated per location, with month-end consolidation as the pinch point.