Financing at the Register: What a Second Look Actually Does

A customer has already picked the sofa. They've walked the floor, sat in it twice, and told the RSA which delivery week works for them. Then the financing application comes back declined, and the shape of the sale changes in about four seconds — while the customer is still standing at the desk.

That moment isn't really about which provider said yes. It's an operational design problem: what's already on the RSA's screen, whether the customer has to repeat information they already gave once, and whether the order that eventually gets signed matches what actually got funded.

This isn't a lender comparison, and it shouldn't be. It's about the store's own process — the waterfall, the re-key, the split tender, and the reconciliation that happens days or weeks later, usually by hand.

What happens in the seconds after a decline?

Most furniture stores work with a primary financing provider and one or more secondary providers for applicants the primary doesn't approve. The operational question isn't whether that waterfall exists — it's whether the next step is already on the RSA's screen, or whether the RSA has to go build it.

In practice, that means one of two things happens. Either the RSA stays at the same terminal, on the same order, and moves to the next option without breaking stride — or they open a second portal, log in separately, and start explaining the process again to a customer who's now wondering if something went wrong. The second version is where deals stall.

None of this is about approval odds, and a store should never coach a customer on how to improve theirs. It's about what the point of sale puts in front of the RSA the moment a decision comes back.

Why does re-keying an application cost more than it looks like?

Every time an RSA re-enters a name, an address, an income figure, or a purchase amount into a second portal, that's a chance to mistype a number, lose momentum with the customer, or create a mismatch between what the lender actually funded and what the order says. None of those costs show up right away.

The mistake usually surfaces later — when the funded amount doesn't match the ticket, when a delivery gets held because a number doesn't reconcile, or when someone in the office spends an afternoon figuring out why. A payments process that carries the application forward instead of restarting it removes the step where that error gets introduced in the first place.

Are split tenders the exception, or the normal case?

On a furniture ticket, a single tender type is the exception. A deposit on a card, a financed balance, a gift card, a trade allowance, and a balance due on delivery are all routine on the same order — and if the register can't represent that natively, someone reconciles the difference by hand later.

That's not a minor inconvenience. Every tender type carries its own timing and its own record-keeping requirement, and a point-of-sale system that treats an order as one payment instead of a set of them pushes that complexity onto whoever closes the books at the end of the month.

Where does the real time go on a financed sale?

Not at the register — after it. Funded amounts that don't match the ticket, chargebacks, refunds on orders that were financed, and deposits held against business that's written but not yet delivered all need to be tracked against the same order, or someone ends up chasing them in a spreadsheet.

This is why the accounting side of financing is where the real time goes, and why it belongs on the same system as the sale. An order that lives in one place, with its payments, its financing record, and its fulfillment status attached, is the difference between a five-minute reconciliation and a half-day one. When accounting has to reconstruct that history out of three disconnected tools, the tail gets longer every month the store grows.

When is a deposit actually revenue?

Not when it's collected. Money taken on written business — an order placed but not yet delivered — is generally a liability on the books, not revenue, until the goods go out the door. Stores that book deposits as income at the time they're taken can end up overstating a period's performance.

What should you check in your own process this week?

Start with how the financing conversation actually moves through your building, not how it's supposed to move on paper. A short walk-through with one RSA, from application to signed contract, will surface most of what's described above faster than a policy review will.

• How many screens does an RSA touch to take a financed sale, from decline to signed contract?
• Who reconciles funded amounts against tickets, and how often does that happen?
• What happens to a financed order that gets returned or cancelled after delivery?
• Are deposits on undelivered orders sitting in a revenue account or a liability account?
• Can your register represent a split tender natively, or does someone rebuild it after the fact?

None of this requires a different financing provider. It requires a system that treats the sale, the payment, and the paperwork as one record instead of three.