How money moves

Money in Stay N Host passes through three distinct stages, and the boundaries between them explain most of what you see on the payment screens.

Stage 1 - a claim

When a guest says they’ve paid - by uploading a transfer screenshot on their quote link, or by an operator attaching the proof for them - nothing has happened to your books yet. The payment record moves from not_received to proof_received: it is a claim, an assertion waiting for a human. A guest never even states an amount; the figures come from your side of the funnel. Recording the proof is also what takes the unit hold: the nights are locked against other sales while the claim is examined (by default for 120 minutes - the “Listing hold” setting in your workspace’s Operations tab).

Stage 2 - human verification

Only an Account Manager can verify or reject a payment - that’s a deliberate role boundary, not a convenience. Verifying is the moment the claim becomes fact: the inquiry converts to a booking, the held nights become booked, and the ledger entries post. Rejecting releases the hold and sends the inquiry back through the funnel. Every verification writes an audit row with who decided and when.

Stage 3 - balanced ledger entries

Verification posts double-entry journal entries, and every entry must balance: debits equal credits, per currency and in your base currency, to the exact minor unit. This is enforced twice - once in code when the entry is constructed, and again by a database trigger. An unbalanced entry cannot be stored, which is why the books always reconcile to zero: not discipline, arithmetic.

When revenue counts: per night stayed

Getting paid and earning the money are different events. Revenue is recognized night by night, over the half-open range [check-in, check-out) - the check-in night counts, the check-out night doesn’t.

A concrete example: a guest books March 30 → April 2 and pays the full amount in February.

Night	Recognized in
March 30	March
March 31	March
April 1	April
April 2 (check-out day)	- not a night

March’s reports show two nights of this booking’s revenue; April’s show one. The February cash sits as a liability (money held, not yet earned) until each night passes. This is why a payment received today doesn’t move today’s revenue figure - and why month-end numbers don’t jump when a guest pays early or late.

The oversell guard

Each booked night is a row, and the database enforces one row per listing per night (UNIQUE(listing_id, night)). Two bookings can never hold the same night of the same unit - the second write is refused at the lowest possible level, whatever screen or automation attempted it. Same-day turnover works naturally: departure day is not the departing guest’s night, so it can be the arriving guest’s first.

Whose revenue it is

Recognition says when a night’s money counts; the property’s operating model says whose it is. A managed unit’s gross is the owner’s money passing through your hands - a liability, never your profit; your fee is your only income there. The full picture is in Whose money is whose.