Checkout, receipts, refunds, and reconciliation

How to close a booking without losing the money trail

A successful charge is only one checkpoint. Staff still need to explain the final service total, deposit, add-ons, discount, declared tax input, tip, each tender, receipt, refund or credit, processor settlement, payout, and any mismatch—without doing the arithmetic from memory.

First checks

Freeze the completed booking
Name the customer obligation, service snapshot, billable duration or quantity, add-ons, discount, declared tax input, voluntary tip, currency, and authorized actor.
Bring forward prior value
Apply each deposit, prepayment, approved credit, refund, reversal, or dispute once, with a stable link to the original booking and transaction.
Collect the exact remainder
Keep single or split tender open until every successful amount equals the final balance; unknown results must enter recovery before retry.

Checkout closeout checker

Can the customer leave—and can staff close the ledger?

Use the fixed example or enter your own declared amounts. Then state whether the receipt exists, where processor settlement stands, whether payout records match, and whether a retry is safe.

Your result

The synthetic checkout reconciles

The synthetic bill, tenders, receipt, settlement, and payout record reconcile without an outstanding balance.

Calculated total: $151.50
Gross successful value: $151.50
Net collected: $151.50
Expected outstanding: $0.00
Customer state: paid and receipted
Staff state: reconciled

This planning aid performs deterministic arithmetic and state classification only. It stores nothing and cannot verify a card, transaction, refund, settlement, payout, bank, tax, accounting record, or product behavior.

Understand the customer-balance rule

Close the customer checkout and the staff ledger as two related, separate jobs.

Freeze the final bill

Keep service, quantity, add-ons, discount, declared tax, and tip visible as separate line items.

Apply value once

Carry deposits and each successful tender into one booking ledger without duplicate collection.

Issue an explainable receipt

Make customer and staff records agree about what was charged, returned, and still due.

Reconcile after payment

Track settlement, payout, fees, refunds, and mismatches without calling them the customer balance.

Customer payment and business reconciliation finish at different times.

A customer can be fully paid and receipted while the processor still shows pending funds, a payout has not reached the bank record, or a refund and fee have not reached the staff ledger. One vague paid state hides who must act next.

The customer-balance rule: Customer balance = final bill − net successful customer payments

A $151.50 final bill minus a $30 deposit leaves $121.50. Two final tenders of $70 and $51.50 close the customer balance, but settlement and payout matching remain separate staff states.

Follow the complete booking-closeout sequence

One stable booking identity should connect the final bill, prior value, each tender, receipt, returned value, settlement, payout, export, and recovery work without turning them into one vague paid state.

Freeze the completed booking
Name the customer obligation, service snapshot, billable duration or quantity, add-ons, discount, declared tax input, voluntary tip, currency, and authorized actor.
Bring forward prior value
Apply each deposit, prepayment, approved credit, refund, reversal, or dispute once, with a stable link to the original booking and transaction.
Collect the exact remainder
Keep single or split tender open until every successful amount equals the final balance; unknown results must enter recovery before retry.
Issue one reconciled receipt
Generate the receipt or invoice from the final booking and money ledger, not from an isolated success screen or staff memory.
Track processor settlement
Keep authorization, capture, settlement, available balance, payout, and bank match separate from the customer's paid state.
Close or assign recovery
Match fees, refunds, payout entries, exports, and staff records—or create one visible recovery item with an owner and reason.

Compare the five closeout models

Single tender, split tender, deposit handoff, later refunds, and payout batches create different recovery and evidence needs.

Single tender

One card, cash, bank, or other supported method pays the final balance.

Rule: Attach the result to the booking once and retain the method, amount, actor, source, and current state.
Watch for: A success screen can arrive before authoritative capture or settlement evidence.

Split tender

Part card and part cash close one final balance.

Rule: Record each tender separately and leave checkout open while any amount or result is unresolved.
Watch for: Timeout, reversal, or retry can duplicate one part while hiding the remaining balance.

Deposit plus final checkout

A scheduler collected $30 and a front desk collects the remainder.

Rule: Carry the net prior collection into final checkout through stable booking and payment references.
Watch for: Disconnected tools force manual lookup and make a full-price second charge easy.

Refund or credit after close

A later adjustment returns money or creates authorized future value.

Rule: Append the outcome to the original tender and recalculate net collected value without rewriting history.
Watch for: A booking edit or deletion can detach the refund, credit, receipt, and audit trail.

Processor payout reconciliation

Several charges, fees, and refunds become one payout batch.

Rule: Match provider entries to the payout and bank record separately from customer checkout.
Watch for: Paid, settled, available, paid out, and bank matched are not interchangeable.

Review checkout and settlement changes

Every adjustment needs a named actor, reason, amount, related record, current state, and safe recovery path.

Service, duration, or add-on changes

Rebuild the bill before collection

Preserve the original snapshot and authorized change, then show the new total and remaining balance before staff takes another tender.

The second tender fails

Keep the first success; reopen only the remainder

Resolve the failed or unknown attempt before retry and prevent the first successful part from being collected again.

A refund or credit appears later

Append the value outcome

Link the actor, reason, amount, original tender, processor state, receipt update, and current net balance.

Processor settlement changes

Do not rewrite customer payment

Update the processor and staff recovery states while preserving what the customer actually paid and received.

Payout and bank record disagree

Explain the batch difference

Trace charges, refunds, disputes, fees, timing, and payout entries instead of adjusting the customer balance to force a match.

Staff abandons checkout

Leave one visible recovery item

Keep the booking, bill, attempts, successful value, unknown value, owner, and safe next action available for another authorized staff member.

Look for warning signs in a software demo

Make a split tender fail and a payout mismatch. Watch the final bill, prior deposit, each tender, retry behavior, receipt, refund, settlement, payout, export, and recovery queue.

Make one split tender fail before comparing products.

The useful test is not whether a product has a checkout button. Follow the same invented booking through deposit, add-on, discount, declared tax, tip, split tender, receipt, refund copy, settlement, and payout reconciliation.

Start with a $120 service, $20 add-on, $10 discount, $6.50 declared tax input, $15 voluntary tip, and $30 prior deposit.
Collect invented tenders of $70 and $51.50, then repeat from fresh fixtures with the second tender failed, unknown, repeated, refunded, and abandoned.
Compare customer receipt, staff checkout, transaction history, processor settlement, payout report, bank-match field, export, recovery queue, and audit history.

Keep the test fair

Use only an authorized sandbox or test mode with synthetic customer and payment data.
Record the exact plan, device, currency, tax input, tender modes, processor, payout mode, versions, and checked date.
Treat documentation and this checker as preparation, never as transaction, tax, accounting, product, ranking, or recommendation evidence.