The deposit becomes a liability, not a good month
Money taken in June against a gown delivered in September is owed, not earned. It posts to an append-only double-entry ledger and is recognized at delivery.
Where the deposit goes next →The answer, plainly
What does RingUps do at checkout?
RingUps runs the checkout a bridal store does in the ten minutes after a bride says yes. It records the deposit as a liability rather than as income, issues the contract from the store’s own template with her gown and her terms on it, files that contract against the order, and starts the must-arrive-by date counting backward from the wedding day.
The contract is the store’s own wording, not a generic form
Contract types are configured per store and per kind of order, so a bridesmaid order and a made-to-order gown do not go out under one set of terms edited at the counter.
Getting your templates out of the old system →The sale starts a chain of dates
The wedding date is the fixed point. RingUps computes backward from it to a must-arrive-by date, and the dye-lot guard blocks a mismatched lot when the purchase order is placed.
The deadline chain →The long-tail question
What does a bridal contract have to say that a general retail receipt does not?
A receipt records that something changed hands. A bridal contract has to describe something that does not exist yet. On the day she signs, the gown has not been cut, the designer has not been paid, and the only thing the store can promise is a process.
Cande Bridal Boutique in Kelowna, British Columbia ran twelve contract templates in Bridal Web Solutions to cover that. Four clauses do most of the work, and all four are the reason a general point of sale cannot be used for this sale.
| Clause | Why a bridal order needs it | What RingUps does with it |
|---|---|---|
| The deposit is non-refundable | The store places the order with the designer on the strength of that money. It is committed before there is anything to hand back. | Records the deposit against the order and holds it in the ledger as deferred revenue until the gown is delivered. |
| The gown is ordered to her measurements and cannot be returned | She is not buying the sample she tried on. She is buying a size the designer will make, chosen off a size chart against her measurements. | Records the size ordered on the order line with the style, the designer and the dye lot where one applies, so what was agreed is on the record rather than in a stylist’s memory. |
| The delivery window is an estimate from the designer | The store does not control the factory. A date given at the counter is a lead time, not a promise, and saying otherwise is what turns a late gown into a dispute. | Computes a must-arrive-by date backward from the wedding date with an alterations buffer, and tracks the order against that date rather than against the estimate. |
| Alterations are separate | Fitting a made-to-order gown is its own job. It is measured after the gown lands and priced then, and it is not included in the gown price. | Keeps alterations on the alterations record rather than in the gown balance, so the fitting charges never blur into what she owed for the gown. |
Ten minutes, five steps
How does a RingUps checkout run, step by step?
What the stylist does is on the left of each step. What the system does in response is the sentence after it. Nothing here waits for a back-office pass at the end of the day.
-
Start the order on her record
The stylist opens the bride and adds the gown: style, designer, size ordered, and the dye lot if a party has to match. RingUps creates the order and the line, and prices it against the store’s tax codes.
-
Take the deposit
She enters the amount and how it was paid. RingUps posts it to the append-only ledger as deferred revenue and shows the balance owing. The pilot store can run the card inside RingUps; every other store runs its own terminal and records the payment here.
-
Issue the contract
She picks the contract type for what was actually sold. RingUps fills the store’s own wording with the bride, the gown, the amounts and the dates, and files the contract against the order rather than in a folder on a back-office computer.
-
She signs
At Cande Bridal Boutique the contract prints and is signed at the counter. The contract record stays on the order either way, filed against it the moment it is issued.
-
The deadlines start running
Nobody does anything. The wedding date on her record drives a must-arrive-by date, and when the purchase order is placed the dye-lot guard blocks a mismatched lot at the write path with an override that has to be ticked deliberately.
The screen
One checkout, four kinds of order, four sets of terms
A bridesmaid order, a made-to-order gown, an alterations job and a payment plan are not the same sale and should not go out under the same terms. Switch the type and the terms panel changes with it.
Illustration, with sample data. The figures below are made up for the picture. Every figure elsewhere on this page is from the production database.
What the order does after checkout →Proof
What evidence is there that deposits are recorded properly?
Twenty years of Cande Bridal Boutique’s sales were reconciled on the way in. Reversals in Bridal Web Solutions had been recorded with both a negative quantity and a negative price, so they read back as positive charges: 93 lines across 59 orders, $141,807.75 wrong-signed, which made roughly 78% of an apparent $384,659.89 receivable an artefact of the export rather than money anyone owed.
The sales export carried no tax at all, so tax was rebuilt across all 1,391 orders, then 36 exception invoices were corrected against a second report, catching a $3,253.05 overstatement. 228 orders were skipped rather than fabricate a bride to attach them to, and 2,759 payments were skipped for carrying no order number.
Ask an owner to reconcile their current system against itself.
The import was not pristine and we do not tell it that way. Every imported order landed with status picked_up, and the tax on all 1,391 of them was backfilled after the fact. It is a migration-competence story, not a clean-data story.
Verified against production, 2026-08-04
- 2,341 payments, $2,161,190.44
- Migrated net of 43 refunds, every row idempotent on org, source and source reference, and reversible by batch id.
- 1,391 orders, $2,275,597.72
- The full historical order book, tax rebuilt line by line because the export shipped none.
- 228 orders skipped
- Rather than invent a bride to hang them on. The restraint is the proof point.
- 2,902 brides, 3,820 appointments
- Moved in the same batch, with 625 styles and 427 gown photographs rehosted off the vendor’s servers.
What it replaces
The contract file on the back-office computer
In most stores the contract is a document somebody duplicates, retypes the bride’s name into, and prints. The deposit is written on the paper file. The delivery date is on a wall calendar. Three records of one sale, none of which know about each other, and the version of the terms she signed is whichever copy was on the desktop that morning.
After checkout in RingUps there is one order carrying the contract, the payments and the dates. When a bride calls in March about a gown she bought in June, the answer is on one screen.
Your contract wording is the part that does not come out of the old system
Bridal Web Solutions ships 47 export files. None of them contain a contract body. The same is true of email template bodies, scheduled message rules, supplier lead times, size charts and the booking builder configuration: there is no export behind any of it and it ends with the subscription.
Cande’s twelve contract templates were transcribed by hand out of a live session, because that was the only way to get them. Your records can leave. Your configuration cannot, unless somebody sits down and copies it.
How the migration handles that →Where to go next
Payments and revenue
What happens to the deposit after checkout: deferred revenue, the double-entry ledger, and why you should not pay tax in June on a gown you deliver in September.
Special orders
The chain of deadlines this sale starts: the must-arrive-by date computed backward from the wedding, the purchase order, and the dye-lot guard.
Switching systems
How the contract bodies, templates, lead times and size charts that no export covers actually get moved, and how the orders behind them are reconciled first.
Questions we get asked
Checkout, contracts and deposits
What does a bridal contract have to say that a general retail receipt does not?
Four things. The deposit is non-refundable, because the gown is ordered after she signs. The gown is ordered to her measurements and cannot be returned. The delivery window is an estimate from the designer, not a date the store controls. Alterations are a separate job, measured and priced later.
What happens to the deposit in the books?
RingUps posts the deposit to an append-only double-entry ledger as deferred revenue. It is a liability the store owes a gown against, not income, and it is recognized as revenue at delivery rather than on the day it was taken. The full accounting treatment is on the payments and revenue page.
How does RingUps handle a refund on a deposit?
The refund is recorded in the ledger and it never touches Stripe. If the money went out on a card, someone refunds that card by hand in the Stripe dashboard. The migration brought across 2,341 payments totalling $2,161,190.44 net of 43 refunds, so refunded history reconciles, but the movement of money is a manual step.
Bring your current contract to the demo
We load your own terms into the templates and run a full checkout in front of you, deposit and deadlines included. Fifteen minutes, on your own data.