RingUps records a bridal deposit as deferred revenue: a liability the store owes the bride, not income. The sale is recognized on the day the gown is picked up. Every payment posts to an append-only double-entry ledger, so no row is ever edited in place and the balance on any past date can still be proved.
2,341 payments totalling $2,161,190.44, net of 43 refunds, migrated out of one store's twenty years of history.
A bride orders a gown in March and pays sixty percent down. The money is in the bank that afternoon. The gown, however, does not exist yet. It is cut in the designer's factory months later, shipped, checked in, altered and finally handed over in November. Until she walks out with it, the deposit is not something the store has earned. It is money the store owes back in the form of a gown.
Accountants call that a contract liability, or deferred revenue. Owners usually call it the deposit money they are not allowed to spend. Both are describing the same thing: cash on the balance sheet with an obligation attached to it.
It matters for three ordinary, unglamorous reasons.
RingUps posts the deposit to deferred revenue at the moment it is taken, and recognizes the revenue when the order is marked picked up. There is no month-end journal for a bookkeeper to remember, because recognition is an event in the ledger rather than an adjustment sitting on top of it.
Follow one order all the way through. Four entries, written in order, none of them ever edited afterwards.
| Date | What happens at the counter | Legs posted to the ledger | Deferred revenue | Revenue recognized |
|---|---|---|---|---|
| 14 Mar | She signs the order for a $6,400 gown and pays a sixty percent deposit of $3,840. | Cash in $3,840 Deferred revenue $3,840 |
$3,840 | $0 |
| Apr to Oct | The gown is placed with the designer, arrives, is checked in and waits on the rail. | Nothing. The ledger does not move because the gown moved. | $3,840 | $0 |
| 8 Nov | She pays the $2,560 balance at the counter. | Cash in $2,560 Deferred revenue $2,560 |
$6,400 | $0 |
| 8 Nov | The gown leaves with her. Staff mark the order picked up. | Deferred revenue released $6,400 Revenue $6,400 |
$0 | $6,400 |
The March row still reads exactly as it was written in March. Nothing went back and changed it. If the bride cancels in July instead, the March row is not deleted either: staff choose forfeit, refund or store credit, and the outcome is written as a further entry that releases the liability and says which of the three it was.
Append-only means a row is written once and never changed. A payment keyed wrong is not corrected by editing it. It is voided with a reason, and both the original and the void stay on file. RingUps enforces this in the database rather than in the application: payments cannot be deleted and ledger entries cannot be rewritten, so a manager, a support engineer or a stray script cannot change what a row said.
Because entries are only ever added, the deferred-revenue balance on 31 December is the sum of everything posted up to 31 December. It is reconstructed from the ledger, not remembered by it. Ask a system that overwrites rows what it was holding last December and the honest answer is that it can only tell you what it holds now.
Where rows can be edited, or filtered out of a report by changing a date range, a liability can shrink with nothing on file to say who shrank it. In an append-only ledger the only way to reduce deferred revenue is to post an entry that reduces it, and that entry carries an author, a timestamp and a reason.
Five rows for one order, and the wrong one is still there. That is the point: an auditor can see the mistake, the correction, who made it and when.
Staff: record the amount and the method against the order. RingUps: posts two matching legs and attaches them to that order, not to a day's takings, so the money is always answerable to a gown.
Staff: place the purchase order and check the gown in when it lands. RingUps: leaves the ledger alone. Receiving stock is not a revenue event, however long the wait has been.
Staff: take the balance and mark the order picked up. RingUps: releases the liability and recognizes the revenue on the pickup date, in one entry that references the order.
Staff: choose forfeit, refund or store credit. RingUps: writes the chosen outcome as its own entry. Nothing is reversed by deletion, and the reports for voids, forfeits and credits on account read from those same rows.
In-app card payments are built and running. A Stripe Checkout Session, a signature-verified webhook, and a recording function that writes the ledger legs when the webhook confirms the money. It shipped on 17 July 2026 and it is in use at the pilot store, Cande Bridal Boutique in Kelowna, British Columbia.
And it cannot be sold to a second store yet. The Stripe client in RingUps is single-org: it throws an error for any organization other than the pilot store. Unlocking it needs Stripe Connect, and Stripe Connect needs a legal entity that does not exist yet. That is a company-formation problem, not an engineering one, and we will say here the day it changes.
Until then a new store keeps the processor and the rate it already has, takes the card on its own terminal, and records the payment against the order in RingUps. The deferred-revenue accounting is identical either way, because the ledger cares about the order and the pickup date rather than about who moved the money.
Ask an owner to reconcile their current system against itself.
When Cande Bridal Boutique moved off Bridal Web Solutions, 2,341 payments totalling $2,161,190.44 came across, net of 43 refunds, against 1,391 orders totalling $2,275,597.72. Those are migration figures verified against the production database on 4 August 2026. The store has been trading since, so today's totals are larger, and we do not present one as the other.
We found it, we refused to guess at it, and we told the owner not to collect on it. That is the same discipline the ledger enforces afterwards: an entry is made because something happened, and it stays made.
A second set of books kept because the first set could not answer the question. It is accurate until the day someone is off sick.
An accountant reconstructing deferred revenue by hand from a printed list of open orders, once a year, for a fee, from data nobody can check afterwards.
Whoever knows which deposits are refundable, which were part-forfeited and which bride was promised something at the counter in a quiet moment.
The deposit on this page is created at checkout. That page covers the order, the terms the bride signs and the cancellation policy the forfeit entry refers back to.
Read about checkoutWhere the ledger surfaces: the end-of-day close, month-end deferred revenue, AR aging, payment summary by method, voids and forfeits, and credits on account.
See the reportsThe database-level guards that make append-only real rather than a promise, plus what RingUps has not certified yet, stated plainly.
See what is enforcedA deposit is a liability until the gown is handed over, not income on the day it is paid. The store has been paid for something it has not delivered yet. RingUps records the deposit as deferred revenue at the moment it is taken and recognizes the sale as revenue on the pickup date, so the books follow the gown rather than the cash.
Not unless you are the pilot store. In-app card payments are wired end to end with a Stripe Checkout Session, a signature-verified webhook and ledger legs, and they shipped on 17 July 2026 for Cande Bridal Boutique. The Stripe client is single-org and throws an error for any other organization, because opening it up requires Stripe Connect, which requires a legal entity that does not exist yet. Every other store runs its own processor and records the payment in RingUps.
It means a ledger row is written once and never updated in place. A mistake is corrected by voiding the row with a reason and posting a new one, so both stay on file. That is what lets RingUps prove what the deferred-revenue balance was on any past date, and it is why nobody can quietly zero a liability: the only way to reduce one is to post an entry that carries an author, a timestamp and a reason.
Because the deposit was never booked as income, a cancellation releases a liability instead of forcing a restatement. Staff choose the outcome explicitly: forfeit the deposit, refund it, or hold it as store credit. The refund is written to the ledger only. If the original payment was a card, the card refund itself is done by hand in the Stripe dashboard.
They will have three questions about recognition, three about the audit trail, and one about what happens when a bride cancels. We would rather answer them now than after you have switched.