Deposits and balances

Keep deposits and balances in agreement.

Compare what is owed, paid, and refunded with the balance attached to the same booking.

First checks

Define the money agreement
Record service price, tax, fees, discounts, deposit type, due timing, refund rule, currency, and which later events may change the obligation.
Create stable linked records
Give the booking, customer obligation, payment attempt, successful transaction, receipt, and refund their own identities and durable links.
Collect the deposit once
Confirm success from the payment system before marking value collected, and make retries safe so refreshing or repeating a callback cannot double charge.

A synthetic money workflow: a 120 dollar agreement minus a 30 dollar deposit leaves a 90 dollar balance. Later price changes, payments, and refunds update the same linked ledger instead of restarting checkout from 120 dollars. — **The balance is a calculation, not a second price.**Keep the current customer obligation and every successful payment, refund, and adjustment linked to the same booking.

Deposit ledger checker

Does the displayed balance match the recorded money?

Enter the current amount the customer should ultimately owe after any policy or price change, successful deposit and later payments, refunds already issued, and the balance shown by the system. The checker finds open, settled, refund-due, mismatch, and invalid states.

Your result

The balance remains open

$90.00 remains due. Collect only that amount against the same booking and payment ledger.

Current amount due: $120.00
Successful payments: $30.00
Refunds issued: $0.00
Net collected: $30.00
Expected outstanding: $90.00
System displays: $90.00

This planning aid performs arithmetic only. It does not verify transactions, payment settlement, tax, fees, disputes, refund eligibility, accounting treatment, security, legal obligations, or product behavior.

Understand the balance rule and example

A deposit is one payment against a customer obligation, not a separate price and not proof that the appointment is fully paid. The booking, customer receipt, staff checkout, payment record, refund history, and any connected point-of-sale system must agree about what was collected and what remains due.

Collect a deposit once, charge the correct remainder, and explain every later money state.

Show the full agreement

Display the current total, deposit rule, amount collected, and remaining balance before confirmation.

Record payment once

Attach each successful charge to the same booking and prevent retries from becoming duplicate deposits.

Recalculate after change

Price, tax, discount, cancellation, and refund events can all change the real amount due.

Reconcile every view

Customer, staff, gateway, receipt, export, and accounting handoff should tell the same money story.

The remaining balance must come from the ledger, not staff memory.

If a $120 booking takes a $30 deposit, the next collection should begin at $90. A price change, refund, failed payment, duplicate retry, cancellation, or separate checkout system can change that number. The system should preserve the events and calculate the current balance without manual subtraction.

The balance rule: Outstanding balance = current amount due − (successful payments − refunds)

A booking shows a $120 current total, a successful $30 deposit, no later payment, and no refund. The expected outstanding balance is $90—not $120, $30, or an unlabeled partially-paid state.

Follow the complete deposit-to-checkout sequence

The current customer obligation and the transaction history are different records. The remaining balance is calculated from both, then checked across every customer, staff, payment, and export view.

Define the money agreement
Record service price, tax, fees, discounts, deposit type, due timing, refund rule, currency, and which later events may change the obligation.
Create stable linked records
Give the booking, customer obligation, payment attempt, successful transaction, receipt, and refund their own identities and durable links.
Collect the deposit once
Confirm success from the payment system before marking value collected, and make retries safe so refreshing or repeating a callback cannot double charge.
Recalculate after every change
Update the current amount due when service, price, discount, tax, policy, cancellation, or refund state changes; preserve the earlier events rather than overwriting them.
Collect only the remainder
At checkout, subtract net successful payments from the current obligation and attach the final payment to the same booking ledger.
Close and reconcile the ledger
Match the customer receipt, staff view, payment provider, export, refund history, and outstanding balance before calling the booking settled.

Compare the five deposit and payment models

A fixed amount, percentage, full prepayment, card guarantee, and separate point-of-sale handoff create different collection and reconciliation risks.

Fixed deposit

Example: collect $30 now for a service whose current total is $120.

Rule: Store the collected amount as one successful payment and calculate the remaining balance from the current total.
Watch for: A fixed amount can exceed a discounted or shortened service unless the rule is revalidated when the price changes.

Percentage deposit

Example: collect 25% of the price confirmed at booking time.

Rule: Record the price basis, percentage, rounding rule, and resulting currency amount—not only the percentage label.
Watch for: Later price changes and currency rounding can make staff and customer balances disagree if the original calculation is not preserved.

Full prepayment

Example: collect the complete current total before confirming the appointment.

Rule: Mark the obligation paid only after confirmed collection, while keeping refund and dispute states separate.
Watch for: Full payment is not a deposit; describing it as one can make cancellation and refund explanations misleading.

Card hold or guarantee

Example: store an authorized method or place a temporary authorization without capturing the service price.

Rule: Distinguish authorized, captured, voided, expired, and failed states from money actually collected.
Watch for: A card on file or authorization can appear as paid even though no settled payment exists.

Booking plus separate checkout

Example: the scheduler collects the deposit and a point-of-sale system collects the remainder.

Rule: Carry a stable booking and payment reference across systems and reconcile before charging the final balance.
Watch for: Staff may re-enter amounts, miss a refund, or charge the full total when the systems do not share reliable payment state.

Review changes and failure recovery

Every edit needs an explicit money consequence. Preserve what happened, calculate what is true now, and keep customer, staff, receipt, gateway, and export states aligned.

Price, discount, tax, or fee changes

Change the obligation, not the payment history

Recalculate the current amount due, preserve what was already collected, and explain any new remainder or overpayment before checkout.

The appointment is rescheduled

Carry money forward deliberately

Keep or transfer the deposit only under the declared rule, preserve its transaction identity, and prevent a second deposit from being requested accidentally.

The customer cancels or does not attend

Apply the policy as a new ledger event

Set the resulting obligation, retained amount, refund, credit, and receipt explicitly instead of deleting the deposit or leaving the booking ambiguously paid.

The business cancels

Release the obligation and reconcile collected money

Record the cancellation reason, refund or approved alternative, notification, and final balance without relying on staff to remember a separate payment.

Final payment fails or repeats

Separate attempts from successful collection

Leave the correct balance open after failure, prevent duplicate capture on retry, and reconcile delayed success callbacks before another charge.

A refund or dispute appears later

Reopen the financial state without rewriting history

Attach the event to the original payment, recalculate net collected value, update the customer and staff views, and preserve the audit trail.

Look for warning signs in a software demo

Force the money story to change. Watch the customer receipt, staff checkout, payment history, outstanding balance, and export after a price edit, failed payment, cancellation, refund, and retry.

Follow a $30 deposit through final payment, cancellation, and refund.

A deposit setting or payment-provider logo proves little. Give every shortlisted system the same synthetic money story and compare the customer, staff, transaction, and export records after each event.

Create a synthetic $120 booking with a fixed $30 deposit and record the full agreement, amount requested, customer receipt, and staff-side balance.
Collect a synthetic $90 final payment, then repeat from fresh bookings with a price change, failed payment, cancellation, and refund while preserving every ledger event.
Compare the customer view, staff checkout, payment history, receipt, and export; record any manual arithmetic, duplicate risk, unexplained state, or unavailable evidence.

Keep the test fair

Use only a documented sandbox or explicitly authorized test account with synthetic customer and payment data.
Record the exact plan, currency, deposit rule, policy, price basis, payment mode, and checked date.
Treat this checker and documentation as preparation, not evidence that a product collects or reconciles money correctly.