The Quiet Loop
Example · Hospitality01 of 06

Night audit reconciliation between a PMS and the ledger

Illustrative scenario, not a client engagement.

Revenue posted in the property system, payments settled through the terminal and deposits held against future stays each close on a different basis, so the day balances in one system and not the other.

The night audit is the moment a property closes its trading day: charges are posted to rooms, open folios roll forward, payment batches settle, and a set of totals is produced that everyone downstream treats as fact.

Those totals then have to agree with three other things — the payment processor’s settlement, the bank, and the accounting ledger. They frequently do not, and the reasons are structural rather than careless.

The process

Charges accrue against a folio throughout a guest’s stay. Some are posted automatically by interfaces — telephone, food and beverage, spa — and some by hand. At the audit, the day’s revenue is summarised by department and posted; payments taken during the day are batched to the processor; and the folios of guests still in-house roll forward with an open balance.

Separately, deposits taken against future stays sit somewhere as a liability rather than as revenue, because the stay has not happened.

Where it breaks

Revenue and cash close on different bases. Revenue is recognised on the night it is earned; payment is taken whenever the guest chooses to settle, which may be several nights later or several weeks earlier. Comparing a night’s posted revenue to a night’s settled payments is comparing two different quantities, and the difference is not an error.

Deposits are recognised early or twice. A deposit taken for a future stay is a liability. If it is posted as revenue on receipt and again when the stay is charged, the same money is counted twice — and because both entries are individually reasonable, the duplication only appears as an unexplained variance months later.

Settlement batches do not align to the audit boundary. A processor’s batch cut-off is unlikely to be the property’s audit time. Transactions taken close to the boundary land in the adjacent batch, so a night’s payments and a night’s settlement disagree by whatever crossed it. The difference reverses the following day, which is why the variance is real but never accumulates — and why it is so often dismissed rather than explained.

Adjustments and voids post asymmetrically. A correction made after the audit adjusts one system on the day it was made and the other on the day it applied.

Channel commission is netted or gross. Where a booking arrives through an intermediary that deducts commission before remitting, the revenue and the cash differ by the commission, and whether the ledger expects gross revenue with a separate expense or a net figure changes the answer entirely.

How we would build it

Not as a single comparison but as three reconciliations that each answer one question, because a single variance figure combining all of the above tells nobody anything.

  1. Posted revenue against the property system’s own audit report. Does the extract agree with the source? This catches interface failures and posting errors, and it is the only one of the three that should ever be zero.
  2. Payments against processor settlement, matched on transaction reference rather than on date, with boundary-crossing items identified and reported as timing rather than difference.
  3. Settlement against the bank, matched on batch, with fees separated so the deposit reconciles gross.

Deposits are tracked as their own balance: taken, applied, refunded, forfeited. The balance carried forward must equal the sum of deposits on unarrived reservations, which is checkable against the booking system independently and is the single most effective control against double-recognised revenue.

Commission handling is fixed per channel in configuration, not inferred per transaction, and the choice is stated on the report.

What the system proves about itself

The output is not a variance figure. It is a dated exception list where each item names the transaction, the two figures that disagree, and the reason category — timing, missing, duplicated, or genuinely unreconciled. Timing items carry the date they are expected to clear, and the next night’s run confirms whether they did.

A night with no exceptions says something meaningful. A night with a variance and no explanation says only that somebody will have to work it out later, from worse information than is available now.

Run before the figures reach the ledger, this turns a monthly investigation into a nightly five-minute review — and, more usefully, means the person who can explain an anomaly is asked on the day it happened rather than at period end.

Send us the problem

Send us the problemThe files, or a sample. We reply in writing within one working day.