Cardinal

What a folio actually is, and why the balance is not one number

Six different numbers hide inside the one a desk reads out loud. Which one answers 'can this guest leave', what breaks when a company pays for the room, and why an edit button is the feature that costs you the most.

8 min read

A guest at the desk asks what they owe. Somebody looks at a screen and reads a number out loud.

That number is a summary of about six other numbers, and depending on which one the software chose to display, it can be wrong in either direction on a stay where anything unusual happened. Not wrong as in a bug. Wrong as in "the software answered a different question than the one the guest asked."

Understanding a folio properly is the difference between a desk that can answer confidently and one that quietly guesses.

A folio is an account, not a bill

An invoice is a document produced at a moment. A folio is a running account attached to a stay, and it exists from the moment the reservation is made until long after the guest has gone.

Things post to it as they happen: the room charge for each night, the activity they booked, the bottle of wine, the deposit they paid in March, the card payment at check-out, the correction posted three days later when somebody noticed a mistake. It is a ledger for one stay, and like any ledger, its meaning comes from the entries and not from the total at the bottom.

That is why the total at the bottom is the least interesting thing on it.

The six numbers hiding inside "the balance"

Here is what a desk is actually working with on any stay in progress.

Charged so far. Everything posted to date. On the third night of a seven night stay, this includes three room nights, not seven.

Still to post. The four nights that have not happened yet. Real money, contractually committed, and not yet a charge. A system that shows only "charged so far" makes a week-long stay look like it owes very little on Tuesday.

Paid. What has actually been collected, including the deposit taken months ago.

Held but not earned. The deposit again, seen from the other side. Cash you are holding against a service you have not yet delivered. It reduces what the guest will pay at the end; it does not mean you have earned it.

Guaranteed but not collected. A card on file, a company guarantee, a purchase order. Somebody has promised this will be paid. Nothing has moved.

Owing right now. Charged minus paid. The only one of the six that answers "can this person walk out the door".

Ask "what is the balance" and any of those six is a defensible answer. The question the desk actually needs answered depends entirely on why they are asking, and there are only three reasons.

The three questions a desk actually asks

"Can this guest leave?" Charged minus paid, right now. Nothing about future nights.

"What do I collect from them at this moment?" Usually the same number, minus anything guaranteed by somebody else, minus anything they are settling separately.

"What will this stay be worth?" Everything, including nights not yet posted. This is the forecast question and it belongs in the forecast, not on the check-out screen.

A folio that shows one number without saying which of these it is answering will eventually cause somebody to chase a guest for money that a company had guaranteed, or wave a guest out of the door who genuinely owed for a mini-bar.

Then it gets more interesting

Three ordinary situations break the single-number model completely.

The bill is split

A company pays for the room, the guest pays for everything else. This is one stay, one guest, one arrival, and two separate settlements against the same folio. "The balance" is now genuinely two numbers, and neither of them is the sum.

Systems that cannot model this end up faking it, usually by making a second reservation. Then the room count is wrong, the occupancy is wrong, and the two halves of one guest's stay can be checked out on different days.

The guest moves rooms mid-stay

A radiator fails on night two. They move. Was that one stay or two?

For the guest it is obviously one. For the books it has to be one continuous folio, or their bill arrives in two pieces with two check-in dates and neither of them describes what happened. The room changed. The account did not.

A charge was posted to the wrong folio

Two guests with the same surname. It happens weekly. The fix is not to delete the charge from one and type it into the other, because that erases the evidence of what happened and leaves two folios that no longer explain themselves. The fix is a transfer: the charge leaves one account and arrives on the other, and both sides record that it did.

Why "just edit it" is the wrong instinct

The most requested feature in accounting software is an edit button, and it is the one that quietly destroys the thing you bought the software for.

If a posted transaction can be changed, then your folio only tells you its current state. It cannot tell you what it said last Tuesday, which is exactly what somebody will ask when a guest disputes a charge, when a card issuer sends a chargeback, or when an accountant is reconciling a month that has already been filed.

A folio that corrects by reversal costs a few seconds more on the day. In exchange, every version of the truth remains readable, and "what did this account say on the 14th" has an answer.

The same logic explains why a discount, a void, a refund and a reversal are four different things rather than four labels on one thing. They describe genuinely different events, and collapsing them into "edit" loses the distinction permanently.

What to look for when you are evaluating

Six questions. All of them answerable in ten minutes of a demo.

  1. Show me a folio where a company pays the room and the guest pays extras. Watch whether it stays one reservation.
  2. Move a guest to a different room mid-stay, then show me their bill. One document, one stay, or two?
  3. Post a charge to the wrong guest, then fix it. Is the fix a transfer with a trail, or a deletion?
  4. On the third night of a seven night stay, what does the folio say is owed? Then ask what the stay is worth. If those are the same number, one of them is wrong.
  5. Take a deposit, then show me it in the revenue report. It should not be there. It should be a liability until the stay happens.
  6. Correct a posted transaction. Then ask what the folio said before the correction, and see whether the system can still answer.

None of these are edge cases. Every one of them will happen in your first month.


In Cardinal a folio is an append-only account, not a balance field. A mid-stay move keeps one continuous folio. A folio can be split so a company settles the room while the guest settles their extras, on one reservation. Charges transfer between folios with both sides recorded. Postings are immutable, corrections are manager-authorized reversals written into the ledger, and accommodation charges accrue per night, so "owed now" and "what the stay is worth" are two numbers the system keeps separately because they are two different questions.

One email when the next guide is ready

We publish a guide or a tool every few weeks about Canadian small-property operations, tax and the desk. Nothing else, and no sequence.

No sequence, no sales emails, and nothing sold to anybody. Unsubscribe in one click.

See it working

Watch the report build itself.

Thirty minutes on a real property. Bring the edge case you are worried about.