After a customer pays a deposit, staff need the agreed total, the amount received and the date the balance is due. If the group size changes, the updated amount must remain connected to the original booking.
Build that record before opening sales for a retreat, private event or training programme.
Make outstanding payments visible
Treating future payments as notes on an order leads to missed balances and confusing refunds. Use distinct states for a proposed plan, a paid deposit and a late balance.
| State | Meaning | Typical next action |
|---|---|---|
| Draft | Terms not accepted | Review total and schedule |
| Deposit due | Place not secured yet | Pay before deadline |
| Active | Deposit paid, future amount due | Monitor scheduled payments |
| Past due | Expected payment failed or is late | Retry, contact, or apply policy |
| Paid | Full agreed amount collected | Deliver experience |
| Changed | Scope or dates altered | Recalculate with audit trail |
| Cancelled/refunded | Obligation ended | Reconcile retained and returned amounts |
Two sample schedules
For a $1,500 booking, a 25% deposit is $375 and leaves $1,125. That balance could be due once or split into three payments of $375.
For a $4,800 private event, a fixed $1,000 deposit leaves $3,800. If the final balance changes with headcount, the quote should state the calculation and the date when the count becomes binding.
These figures illustrate arithmetic only. Deposit size, cancellation terms, taxes, credit rules, and payment authorization require policies appropriate to the business and jurisdiction.
What the software must do
Preserve the agreed terms
Store the original total, schedule, policy version, and acceptance. Changes should create a visible adjustment rather than overwrite history.
Make failures actionable
A failed charge should have a reason category, next retry, customer notice, and human owner when automation cannot resolve it.
Reconcile money precisely
Finance should trace each payment, refund, fee, dispute, and net payout back to the booking and plan.
Protect customer trust
Before payment, show amount and timing. After payment, send a clear receipt and remaining balance. Do not hide material instalment terms behind a generic checkout label.
Check the payment workflow in Gomry
Gomry supports ticket classes and approval-required tickets. Those features alone do not establish a deposit ledger, a card-hold-to-deposit conversion or an automatic instalment schedule. Demonstrate the complete workflow before offering it to customers.
If you use separate ticket classes for a deposit and balance, keep the agreed total, prior payments and due date attached to a clear booking reference. Test whether customers can accidentally buy the balance without the deposit and how staff reconcile the two payments. A second payment link still needs an owner and a record.
For corporate purchase orders or invoices with payment terms, retain the accounting workflow that produces the invoice. The private-booking guide covers the handoff from quote to confirmed event; the retreat guide adds room allocation and participant details.
Frequently asked questions
Is a deposit refundable?
That depends on the agreed policy and applicable law. The software should represent the rule accurately, not decide it.
Should cards be charged automatically?
Only with valid authorization, clear notice, appropriate payment setup, and a compliant process for the relevant market.
What happens when the total changes?
Issue an adjustment that shows the new total, payments already made, amount remaining, and reason. Preserve the prior agreement.
How should overdue balances be handled?
Define retry timing, communication, grace period, escalation, and the effect on the reservation before launching the plan.
Use one upcoming booking to test the agreed total, deposit, changed headcount and final balance. Confirm how each step will be recorded before sending the customer a payment schedule.