By the end of a week a restaurant may have removed items before payment, given dishes at no charge and returned money to guests who had already paid. If those events end up in one adjustments total, nobody can tell what actually happened to the money, which refunds are finished and which are still open.
This guide reconciles service adjustments from event to evidence. It keeps three kinds of event apart, records each refund as one case with its full attempt history, and reports totals by category and state rather than as a single figure. It is not a point-of-sale tutorial, a fraud review or a way to rank staff. Every case and amount is an original fictional illustration.
Keep three events apart
Payment systems use different words for similar actions, so write local definitions and record the classification your source system actually shows beside them. In this guide, an unpaid void removes an item or ticket before any payment was taken. A prepayment comp gives an item at no charge before the bill is settled, so the guest is never asked to pay for it. A refund returns money from a payment that was already captured, and it always links back to that payment.
The first two change what the guest is asked to pay. Only the third involves sending money back. Mixing them hides whether money left the business and whether it reached the guest.
What the vendor references describe
Square's help article on comps and voids describes a comp as giving goods without asking for payment, with a reason recorded against the ticket, and a void as closing an open ticket without processing a payment, typically for incorrect entries or items not yet prepared. Both leave a record in the seller's dashboard.
Square's article on cancelling and refunding orders treats cancellation and refund as separate steps: after items are cancelled, the user can skip the refund or continue into a refund flow, and closed orders are refunded through their transaction. That separation is the useful point here. A cancelled order is not, by itself, evidence that any money was returned. This guide uses only these general distinctions; Square's specific workflows, permissions and time limits are not adopted.
Fix the window and the cutoff
Choose a window, such as one trading week, and an as-of cutoff for the review. The register covers adjustments initiated within the window and shows each case's state at the cutoff. A refund in the window may relate to a sale from an earlier week; keep the original order and payment reference so the link stays visible.
Reconcile against every expected source: the point-of-sale adjustment log, the payment or processor record and any manual refund log. An event you expected but cannot find is recorded as unknown, never as zero.
One row per logical case
Each refund case gets one row and a stable case ID. Record anonymous original order and payment references, amount and currency, current stage, reason, the permission or approval evidence, the source evidence, an owner and the next check date. Attempts sit in an attached history that is appended, never overwritten.
If a refund fails and is tried again, the retry is a second attempt under the same case, not a new case. Otherwise one guest's refund can be counted twice, once as failed and once as a fresh request.
Keep the case amount and its approved scope fixed while attempts are reconciled. If an amount is amended or only partly completed, retain the original request and reconcile the constituent amounts before using this simple one-amount, one-state template. Never label a whole request Confirmed because only part succeeded.
Worked example: one week's register
In this fictional week there is one unpaid void, V01, for INR 300, one prepayment comp, C01, for INR 200, and four refund cases. At the cutoff, R01 for INR 150 is Pending, R02 for INR 100 is Confirmed, R03 for INR 80 is Failed and R04 for INR 120 is Confirmed.
Refund requests total INR 450: INR 220 Confirmed, INR 150 Pending and INR 80 Failed. The void and comp stay in their own lines at INR 300 and INR 200. They are not added to the refunds, and there is no grand total or lost-profit figure, because the categories describe different things.
Here, Confirmed means the processor or payment record shows that refund as completed. It does not prove the amount has reached the guest's bank account, and it does not reconcile your own settlements or payouts. Pending and Failed are not completed returns of money.
| Fictional ID | Category | Amount (INR) | State at cutoff | Next action |
|---|---|---|---|---|
| V01 | Unpaid void | 300 | Recorded | Keep reason and source reference |
| C01 | Prepayment comp | 200 | Recorded | Keep reason and approval evidence |
| R01 | Refund | 150 | Pending | Owner checks processor record on next check date |
| R02 | Refund | 100 | Confirmed | Retain confirmation reference |
| R03 | Refund | 80 | Failed | Investigate; any retry is attempt 2 under R03 |
| R04 | Refund | 120 | Confirmed | Retain confirmation reference |
| Refund summary | Refund | Requested 450 | Confirmed 220 / Pending 150 / Failed 80 | No combined total with void or comp |
Before anyone acts on a case
The register does not authorise, process or limit refunds. Before any action, the person responsible checks the source system for earlier partial refunds and the remaining paid balance on the original payment, and follows the restaurant's existing approval route.
If the source and register disagree, investigate the evidence and identify the authorised correction. Preserve the earlier record and explain what changed; neither an export nor a manual entry is automatically correct.
Corrections, unknowns and privacy
Make every correction traceable: who changed what, when and why, with the earlier value kept. Unknown states stay visible until resolved. Keep guest names, contact details and card data out of the shared sheet; use anonymous references that point back to the restricted system where those details already live.
Patterns in the register, such as repeated failed refunds through one route, are questions for a process review, not conclusions about individuals.
This template uses one stated currency per review. Confirm that the case list is complete against the source records before reporting its totals. Unknown records remain visible with an owner. A confirmed-empty list can support zero totals; an unreviewed empty list cannot.
Put it into practice
Your action checklist
Your progress saves in this browser. No sign-up needed.
0 of 9 complete
From reading to doing
Service adjustment and refund reconciliation
The Service Adjustments worksheet records one stated currency, a review window and cutoff, one row per event or logical refund case, and a manual history of attempts and corrections. It keeps unpaid voids and prepayment comps separate from refund case amounts by Confirmed, Pending, Failed, Cancelled and Unknown state. All amounts must be positive numbers in the stated currency. Missing amounts, unknown categories, duplicate IDs, incompatible states or incomplete source reconciliation withhold summary amounts rather than silently dropping rows. Unknown refund states remain visible even when the amount is known. Manual records retain source classifications, original payment references, reasons, authority and follow-up. The sheet does not process refunds, verify evidence, reconcile partial attempts or calculate a combined loss.
Open the Service Adjustments tab in the launch workbook. Keep a copy for your own business.
Download the free workbook See what’s inside the toolkit →Sources & further reading
- Comp and void open tickets (Square Support Center) ↗
Retrieved 7 November 2026. Used only for the general distinction between a comp (goods given without payment, with a recorded reason) and a void (open ticket closed without processing payment). Square workflows, permissions and features are not adopted, and no integration is implied. All figures are original.
- Cancel and refund orders (Square Support Center) ↗
Retrieved 7 November 2026. Used only for the point that order cancellation and refund are separate steps. Refund time limits, provider-specific terms and workflows are not applied as general practice.
Published by Keystonne Grow. Product links connect to the Keystonne ecosystem; check the linked product or service for its current scope.