What is tender reconciliation — reconciling takings by tender type?

What does tender reconciliation prove, and why not just agree the total?

It proves, one payment method at a time, that the takings the sales system shows for each tender match an independent record of that tender for the same period. A total that agrees proves much less, because differences between tenders cancel out, as in these two cases:

• A tender keyed wrongly. A $45 card sale rung up as cash leaves cash $45 short and cards $45 over.
• A refund paid the wrong way. A card sale refunded in cash but recorded as a card refund leaves cash short and cards over by the same amount.

In both, the total still agrees. Working per tender also makes a difference traceable, because a shortfall on one tender points to one record. And it stops keying errors being left in place because the total agrees, which would make every later per-tender proof start from a wrong split.

Which tenders does your business need to separate?

A tender is a method a customer uses to pay. List every one you accept before the first run, because each gets its own line and its own record. The usual classes are:

• Cash. Notes and coins form one tender.
• Checks. Checks form another, kept apart from cash.
• Card and digital payments. Each processor or payment app that settles payments to you is a separate tender, because each sends its own settlement record.
• Gift cards and store credit. Balances you issued become a tender when redeemed.
• Vouchers. Your own gift certificates, and vouchers a third party issues, are separate tenders.
• House accounts. Sales charged to a customer's account and invoiced later are a tender too.

Square's undated U.S. help article on sales summary and payment methods reports describes a payment methods report covering the total collected and any associated fees from credit, debit, gift cards, and other tender types. A report like that is where the routine starts.

If your sales system records only a total, the routine cannot run until each sale carries its tender: set up a payment key or type for each tender, or note the tender against every sale on a handwritten daily sheet. Until then, a difference shows only in total and cannot be traced. Recording cash sales when nothing produces a receipt is a separate question.

What independent record is each tender compared against?

Each tender is compared with something the sales system did not produce. For cash and checks, that is the count of what was taken, with the float removed: the money itself. Counting the drawer is its own routine; here the count is simply the cash tender's figure. For card and digital payments, it is the processor's record of the payments it processed in the period, which reflects what was actually charged, not which key a cashier pressed.

For gift cards, store credit, vouchers and house accounts, no money arrives at the sale, so the record is a balance: the gift card program's redemption record, your register of vouchers issued, a third-party issuer's redemption statement, or the customer account ledger. The agreement proves a movement in that balance, not an incoming amount.

These records are independent only if kept apart from the takings, by a separate program or issuer or by someone other than the cashier. OpenStax's Principles of Accounting, in its section on internal controls, says separation of assets from custody ensures that the person who controls an asset cannot also keep the accounting records, and that prenumbered documents provide assurance that all sales are recorded, so number vouchers and house-account charge slips. If your gift card program or account ledger runs inside the sales system, agreeing its report with the takings shows only that the system's reports are consistent.

OpenStax's Principles of Accounting, in its section on current liabilities, lists gift cards among its examples of unearned revenue and says that until the customer is provided an obligated product or service, a liability exists and the amount paid in advance is recognized in the Unearned Revenue account; once it is provided, the value is then recognized as earned revenue. So a gift card agreement proves that redemptions cut what you owe cardholders by the takings recorded. The book's section on revenue recognition defines accounts receivable as an outstanding customer debt on a credit sale, so a house account agreement proves that every charge reached a customer's balance. For third-party vouchers, the agreement shows that every redemption you recorded appears on the issuer's statement; what the issuer pays for each, and when, is set by your agreement with it.

Those are accrual-basis descriptions. Whatever basis your books use, the gift card program and the account ledger still exist, and the comparison against them is the same. What becomes of balances never redeemed is a separate question.

How do you run the routine each period?

Run these steps every period, in this order:

1. Fix the period to the sales system's business-day cut-off, and take the count and every tender's record to that same cut-off. Toast's platform guide page on refunds and voids says Toast support configures each restaurant's business-day cutoff, typically 4:00 AM.
2. Produce the sales system's takings for that period by tender as the total collected, including sales tax and tips, before any fees.
3. Obtain each tender's independent record for the same period. For cards, use the processor's list of payments rather than its transfers, which follow its own cut-off: Square's undated U.S. help article on missing transfers says that payments accepted after the day's cutoff time will be sent in your next transfer.
4. If the only card record you have is a net payout, add back every deduction the processor shows between gross and net (fees and any other withholdings), so the record is gross.
5. Compare each pair separately and write down every tender's difference, including zero.
6. Find each difference's cause before recording anything.
7. Record what each cause requires, sign the sheet and pass it to the reviewer.

As a checklist, with a row added whenever you start accepting a new tender, the routine looks like this:

How do you handle fees deducted before settlement?

A processor that pays you net has already taken its fees. Square's undated U.S. help article on its fees says payment processing fees are taken out of the total amount of each transaction, including tax and tip, and are deducted before funds are transferred to your linked bank account. Square's undated article on sales summary and payment methods reports defines the net total as total collected minus fees minus other withholdings, so the add-back covers any other withholdings too.

Comparing a net figure with gross takings makes the fee look like a shortage, which understates takings and keeps the cost out of its own account. Add the fees back, compare the gross with the tender's takings, and record the fees as their own cost. If your processor pays gross and bills its charges separately, compare its settlement directly with gross takings and record the charges from its bill.

OpenStax's Principles of Accounting, in its section on revenue recognition, records a card sale at the original sales amount, with the fee as Credit Card Expense and the rest as a receivable from the card company. For card payments of $3,905.00 gross with $112.40 of fees, the accrual-basis entry at the sale is:

If the sales system has already posted the card takings, post only the fee: debit card processing fees $112.40 and credit the account the card takings were posted to. The full entry is for books in which takings are posted from this sheet. When the $3,792.60 arrives, debit the bank account and credit the amount due from the processor. If you keep cash-basis books, when card takings are recorded depends on your accounting method; whichever date applies, the takings reach sales once, at gross, and the fee reaches expense once. The entry assumes no sales tax or card tips: OpenStax's section on current liabilities holds sales tax in the Sales Tax Payable account, and Square's sales summary article lists tips apart from net sales.

What causes a per-tender difference, and how do you tell the causes apart?

Each class of cause leaves its own pattern:

Cash has no settlement delay, so once the count and the sales report share one cut-off, timing cannot explain a cash difference. For a tender that settles later or in batches, check the next period's record before treating a difference as an error.

Toast's undated platform guide overview of closing out the day says the Toast platform automatically processes credit and debit card payments at the closeout hour, so a cut-off before that hour can catch card payments not yet processed. Toast's undated platform guide page on refunds and voids says you can void items in an order until a payment is captured, and that after the payment is captured, you must refund the payment on the items. A void leaves no card payment behind; a refund is its own transaction and can land in a later period than the sale.

What does a takings-by-tender comparison look like?

Here is one day at a shop that takes cash, cards through one processor, its own gift cards and house accounts:

The total agrees, yet two tenders do not. Cash is $45 short and cards $45 over: equal and opposite, the pattern of a tender keyed wrongly. The processor's list shows a $45 card payment at 2:12 p.m. with no card sale at that time, and the sales system shows a $45 cash sale at 2:12 p.m. The fix is to correct the tender on that one sale, with the reviewer's approval. Takings stay at $5,670.00, and cash then agrees at $1,195.00 and cards at $3,905.00.

Comparing the card takings with the $3,792.60 actually paid would have shown a $67.40 shortfall, which is really $112.40 of fees less the $45 keying error.

How is a difference recorded, and which account carries it?

A difference whose cause is found is dealt with at that cause, as the table of causes shows, not booked as a difference. Never adjust the sales total to agree with a settlement figure: the books then agree with a difference nobody has explained, and its cause carries on. OpenStax's Principles of Accounting, in its section on internal controls, says that in most cases a manager must review a mistake involving cash, such as a cash register error, and clear it before any adjustments are made; apply that to every correction.

Only a difference left after the search is recorded as one. OpenStax's Principles of Accounting, in its petty cash section, records a cash shortage as a debit that has the same effect as an expense, and an overage as a credit to the cash over and short account. Had the corrected count in the example been $1,183.00 against cash takings of $1,195.00, with nothing explaining the $12, the day's cash entry would be:

If your sales system already posts the day's takings to your books, post only the difference: debit cash over and short $12.00 and credit the account the cash takings were posted to $12.00.

Sales stay at what customers were charged; only the cash is lower. The cash is in hand when the entry is made, so the entry is the same on the cash and accrual bases. OpenStax's over and short treatment is for cash. For another tender, use the same account only after an item-by-item match against the processor's or program's record has failed and the reviewer approves. The other side is the balance the takings were posted to: for a card shortfall on the accrual basis, debit cash over and short and credit the amount due from the processor; for gift cards, the gift card liability, so the books agree with the program's balance; for house accounts, the customer's account. A recurring over or short on one tender, terminal or shift is itself a finding to investigate.

Card payments in transit at a cut-off are carried, not written off: accrual-basis books keep them in the amount due from the processor, and on either basis they are listed on the sheet as in transit. Writing one off understates this period and, once it settles, overstates the next.

What changes when several sites or terminals settle into one deposit?

An aggregated settlement matches no single takings record, so a difference in it cannot be attributed. Break it down before investigating anything: list its individual payments, assign each to the site or terminal it belongs to, then compare per site and per tender. Square's undated U.S. help article on missing transfers says a transfer's details include the individual card payments included in the transfer. A processor report run per location or terminal, where one is available, does the same job.

What does the routine produce, and who reviews it?

Each run produces one sheet for the period showing, for every tender, the sales system's takings, the independent record and its source, any add-back, the difference, its cause and any correction or entry. The preparer signs it; someone who did not prepare it reviews and signs it, checking each cause and that last period's timing items arrived. OpenStax's Principles of Accounting, in its section on internal controls, describes one employee who should close out and reconcile the cash drawer using prenumbered forms in pen, and a different employee who would recount the money. Where one person runs the business, that person still completes the sheet each period and checks next period that each timing item cleared.

Run it every period, not only when something looks wrong: a matching total is exactly when offsetting differences go unnoticed. Keep the sheet with the reports behind it. The IRS page on what kind of records to keep says you should keep supporting documents that show the amounts and sources of your gross receipts.

How does it sit alongside the other reconciliations you run?

Tender reconciliation has its own object: a period's takings, tender by tender. The bank reconciliation proves the bank account against the bank statement; a deposit there mixes tenders, days and fees, so it cannot explain a per-tender difference. The cash-drawer count is one input here, not the whole job. Tying a processor's payouts to its sales, fees and refunds, and reconciling a processor's Form 1099-K to recorded sales, are separate routines.