A bridal deposit isn't income the day it's paid — it's a promise you haven't fulfilled. RingUps books it that way, and recognizes the revenue on the day the gown actually leaves.
Set a sale price and a deposit and watch what each system reports as income today.
Split a gown across three payments, take a card at the counter and a transfer next month, and see at a glance who's behind — with a reminder that goes out before you have to make the awkward call.
Track deposits and balances against every order using whichever processor you already have, at the rate you already negotiated. In-app card capture is on our roadmap — we'll say so here the day it ships, not before.
Every deposit is booked as two matching journal legs, and nothing in the ledger can be edited or deleted afterwards — the database refuses. Payments are the same: nobody, not a manager and not a stray script, can delete one or quietly change its amount. A mistake is voided with a reason and stays on file, struck through. Sales tax collected, AR aging, deferred sales by month, payment summary by method, voids and forfeits, credits on account, discounts and a daily summary all export as spreadsheets.
Accounting integrations →Because the deposit was never booked as income, a cancellation releases a liability instead of forcing a restatement — and staff choose the outcome explicitly: forfeit it, refund it, or keep it as store credit she can spend on another dress.
Most POS systems book a deposit as revenue the moment it's paid. That overstates income — and the tax you owe — on gowns that could still be months from delivery. Fixing it after the fact means restating your books, usually in the same week you're trying to close the year.
They'll have three questions. We'd rather answer them now than after you've switched.