What is the city ledger in a hotel?
Every hotel folio ends up in one of two places. Either the guest settles it in full at check-out — cash, card, or a payment already on file — and it drops off your books, or it does not, and it becomes a receivable. The city ledger is that second bucket: the sum of every folio balance the hotel is owed by someone other than the guest who stayed in the room.
The name is old hotel-industry shorthand — 'city' as opposed to 'guest', because the debtor is out in the city rather than standing at your front desk. In a modern PMS it is simply your accounts receivable (A/R) sub-ledger, and it should tie to a control account in the general ledger.
Typical debtors on a city ledger:
- Corporate accounts — a company that books rooms for staff and settles by invoice, often monthly.
- Travel agents and tour operators (TAs/TOs) — commissionable bookings, often on net rates, sometimes with the agent or the guest owing different pieces of the same folio.
- Airlines and crew accounts — recurring room-and-meal arrangements with fixed terms.
- Government and event billing — a conference, wedding or long-stay group billed as one master account after the event.
How does a folio get transferred to the city ledger?
The transfer happens at check-out, and it is a bookkeeping move, not a discount. The guest folio is credited (closed to zero) and the same amount is debited to a company or agent account — the balance has not disappeared, it has changed who owes it.
- Confirm which charges are billable to the account before check-out — room and tax almost always are; minibar, spa or restaurant extras may or may not be, depending on the contract.
- Split the folio if only part of it is billable — the company covers room and breakfast, the guest pays incidentals on their own card.
- Transfer the billable balance to the company/agent (A/R) account, referencing the reservation and folio number so the line can be traced back later.
- Close the guest folio at zero and issue the guest their copy showing what was transferred and to whom.
- Leave the A/R account open until a statement is produced and payment is received or applied.
This is exactly the kind of transfer a city ledger module needs to get right every time — the reference back to the source folio is what makes a statement or an aging report auditable months later, instead of a pile of numbers nobody can explain.
How do credit limits protect the hotel?
A credit limit is the maximum outstanding balance the hotel will let a company or agent account carry before requiring payment or a manager override. Without one, a slow-paying corporate account can quietly run up a balance for months while rooms keep going out under its name.
A workable credit-limit setup needs three things:
- A limit set per account at onboarding, based on expected monthly volume and payment history — not a single house-wide number.
- A live running balance the front desk can see at check-in and check-out, not a number finance checks once a week.
- A block or warning when a new charge would push the account over its limit, with a defined override path (who can approve it, and that the approval is logged).
What should a city ledger statement include?
A statement is what you send the debtor to get paid, so it has to stand on its own without anyone calling the hotel to ask what a line means. At minimum:
| Field | Why it matters |
|---|---|
| Guest name & folio number | Lets the client match the charge to their own traveler records |
| Arrival / departure dates | Confirms the stay actually happened on those nights |
| Room + tax vs. other charges | Separates what the contract covers from incidentals the guest may owe personally |
| Transfer date & reference | Ties the statement line back to the original folio for audit |
| Running account balance | Shows the debtor exactly what they owe as of the statement date |
This is also where mid-size hotels most often lose track: a statement built by hand in a spreadsheet drifts from the folios behind it within a month or two. A PMS that generates the statement straight from the same folio transfers used for the ledger keeps the two permanently in sync — this is one of the jobs Mukeem's accounting module does automatically, since the statement and the ledger read the same transactions rather than being reconciled after the fact.
How do you read a 30/60/90 aging report?
Aging buckets each open balance by how long it has been outstanding since the transfer (or invoice) date, so you can see risk building before it becomes a write-off.
| Bucket | What it usually means |
|---|---|
| 0–30 days | Normal — most corporate terms are net-30; nothing to act on yet |
| 31–60 days | Overdue for most contracts — send a reminder, check for a disputed line |
| 61–90 days | Serious — involve a manager, consider pausing new billing to that account |
| 90+ days | Collection risk — evaluate whether it should move toward write-off or legal follow-up |
Run the aging report weekly, not just at month-end. A balance that just crossed into the 61–90 bucket is far easier to collect than the same balance discovered for the first time at year-end close.
How do you collect and apply city ledger payments correctly?
Collection itself is simple once the statement is right: a bank transfer, a cheque, or occasionally a card payment against the account rather than a specific folio. Applying it correctly is where mistakes happen.
- Match the payment amount to the statement it is settling, not just to the account balance — a partial payment against a specific invoice should be applied to that invoice, not spread evenly across everything open.
- Record the payment against the A/R account with a reference to the statement or invoice number, never as a generic deposit.
- If the payment includes a deduction the client is claiming (a disputed charge, a commission not yet netted), flag that amount separately rather than writing off the difference silently.
- Reconcile the account balance after posting — it should equal the sum of unpaid statement lines, not an approximate figure.
A common leak here is a payment applied to the wrong invoice, which makes one statement look paid and another look overdue when neither is quite true. This is why the A/R ledger and the folio transfers behind it need to be the same system of record, not two spreadsheets someone reconciles by hand at month-end.
What are the most common city ledger leaks?
Most city ledger losses are not fraud — they are process gaps that compound quietly:
- Charges transferred to the wrong account (a similar company name, or a shared corporate code used for two different clients).
- No credit limit enforced, so a struggling account keeps billing until the balance is unrecoverable.
- Statements sent late or inconsistently, so the client has no fixed cycle to plan payment around.
- Commission or net-rate agreements applied inconsistently between reservations, so the agent and the hotel disagree on what is actually owed.
- Write-offs approved without a paper trail, so nobody can later explain why a balance disappeared.
- The city ledger balance in the PMS not matching the control account in the general ledger, because transfers and postings happened in different systems.
Each of these is fixable with a process, but the fastest fix is removing the manual handoff between front-office folios and the finance ledger. When check-out transfers, statements, aging and payment application all read from the same set of transactions — which is how Mukeem's cashier and accounting modules are built to work together — most of this list stops being a monthly firefight.