PMS audit logs: who changed what, and how to read the record each month

A PMS audit trail is the system's own record of every change: which user account made it, when, on which reservation, folio or rate, and what the value was before and after. Hotels read it monthly by filtering a small set of entry types, rate overrides, voids, complimentary rooms, reinstated check-outs and after-hours changes, then asking about patterns.

The month closes, the income report balances, and nobody opens the log. Somewhere in it sits a rate changed at 02:40 and the same folio voided twice by one account. Neither entry appears in any total, because neither changes the month's outcome on its own. After reading this page you will know where the record lives, which five entry types to read every month, how to ask about an entry without accusing anyone, and how to keep the review alive past the first month.

What does a PMS audit log record, and where do you find it?#

It records every change made inside the system: the account, the action, the time, the record touched, and in good systems the values before and after. A PMS (property management system) is the hotel's reservations, front desk and billing software. The log is also called an audit trail or a user activity record; the three names mean the same thing.

Four fields are the minimum for an entry to be useful: the user account, a timestamp, the action type, and the target record, such as a reservation number, a folio, a rate code or a room number. Better systems add the old and new value, and a reason code the user must type. An entry that says a charge was voided is weaker evidence than one that says which charge, for how much, and why.

Log, trail, activity record: the same thing#

Whatever the vendor calls it, the content decides its value. Ask one design question early: can an administrator edit or delete log rows? A record that can be quietly rewritten is a control weakness, whatever the report looks like. Logs record actions, not intent. An entry proves a void happened and who was logged in; it does not prove why, and it does not prove the person at the keyboard was the account holder.

Why the export matters more than the screen#

You find the record in three places: a report in the reports menu, a history tab on each reservation and folio, and an export file. Ask the vendor for the export, not a screenshot; a screenshot cannot be filtered or counted. The log is not the night audit report. Night audit closes the business day and produces totals; the log records individual actions. They answer different questions, and they are read together with what the day audit checks after night audit.

Which five entries should you read every month?#

Five entry types cover most of what goes wrong at the front desk: rate overrides, voids, complimentary rooms, reinstated check-outs and changes made outside the shift. Filter by entry type instead of reading the whole month. A busy hotel produces far more rows than one person can read line by line, and a full read is abandoned by the second month.

Keep the same five filters every month so that months can be compared. The number that matters is the change from last month, not the number itself. Count per user as well as per type: one account with five voids and ten accounts with none is a different picture from five voids spread across the team.

Read the entry next to the document it touched: open the folio, the reservation or the rate code. The log tells you where to look; the document tells you what happened. Note entries with no reason code where the system asks for one. A blank reason field is a process gap before it is anything else. For how a single charge should be corrected correctly, see how a void should appear on a folio without breaking the trail.

Which patterns are worth a question?#

A pattern is worth a question when the same account repeats an unusual action, when an amount sits just under an approval limit, or when the timing does not match the shift. For example, the same account voiding three charges on the same night shift, three weeks running. One void is routine; the repetition is the signal.

For example, discounts that land just under the figure that needs a manager's approval. A cluster at the boundary is worth checking against the approval rules, which are a policy question before they are a software one: discount limits and override rules for hotel staff. For example, a check-out reinstated after night audit closed the day, followed by a charge added to the reopened folio. For example, a rate changed and changed back within the same night, which leaves two entries and no net difference in the report.

Compare against a base before drawing a conclusion: voids per user, per shift and per month. Without a base, every number looks either normal or alarming. Write the question down and check the document. A single entry is never a finding; a repeated entry with a document behind it is.

How do you ask about a log entry without accusing anyone?#

Start from the document, not the person: open the folio, ask the person to walk you through it, and let the record carry the question. Ask in private, with the record open on the screen. Ask for the story before offering a theory; the order changes the answer you get.

Use neutral wording: "help me understand this entry", rather than "why did you void this". The first invites an explanation, the second invites a defence. Expect the ordinary answers first: a mis-keyed charge, a guest who changed their mind, a trainee who was not shown the right path, or a workaround because an approval took too long. If the answer is a workaround, fix the process. A slow approval step produces exactly the entries you are reading, and blaming the person leaves the cause in place.

Write the answer next to the entry on the monthly sheet. A second occurrence then becomes a different conversation, with a record behind it. Have two people review sensitive entries, for example the income auditor and the general manager, so that no single person decides what an entry means. If the explanation does not fit the record, follow the hotel's written procedure and take advice before any step that concerns the employee.

What hides the name: shared logins and missing reason codes#

A shared reception account, or a terminal left logged in at handover, turns the log into a list of actions with no name attached. A shared reception account is a common reason a log review ends without an answer. Every action reads "reception", and reception is four people.

Individual accounts are a setup task, not a purchase: one account per person, named, with a role limited to what the job needs. Roles come next. A receptionist who can change a rate, void a charge and reopen a folio has no limit to test against, and the log shows only that the account was allowed to do it. The setup order is covered in detail in PMS user roles and permissions: a setup checklist.

Reason codes come last, and the list must be short. A short list gets used; a long one gets skipped. Make the code mandatory for voids, discounts and complimentary rooms. Log out at shift handover and note who holds the terminal; a session left open is a shared login with extra steps. A manager's account used by a receptionist is the same problem with a wider blast radius, because it carries the approvals too.

Do the work in that order: accounts, then roles, then reason codes. Reversing it produces codes nobody fills in and a log that still cannot name anyone.

Who should read the log, and what must staff be told?#

The income auditor reads it monthly, the general manager reads the exceptions, and the owner reads a one-page summary; staff should be told plainly that the record exists and what is reviewed. Separate the reader from the entries where staffing allows. The person whose rate changes appear in the log should not be the only person who reads them.

Tell staff at induction and in writing: the system records actions, these entry types are reviewed, and this person reviews them. A known review deters more than a surprise one. Apply the same review to managers and to the owner's own account; a control that stops at the manager's login is a control on the least powerful people in the building. Keep the review to work inside the system: entries, documents, approvals. Personal devices and messaging are outside the scope of a PMS log review.

An audit log contains personal data, because account names and working times belong to people. Reviewing it is ordinary business control, but informing employees, proportionality and how long records are kept are legal questions for your adviser, not for a blog. Do not rely on published fine amounts for any of this. They are re-valued and amended; ask an accountant or legal adviser about your own case.

What goes on a one-page monthly review sheet?#

One page, the same columns every month, signed and dated, so that next month can be compared with this one. The sheet is the control; the log is the evidence. Without the sheet, each month starts from zero and the review quietly stops. It fits on one page because it holds counts and questions, not rows of log entries.

File the export next to the sheet so that a question raised in March can still be answered in September. The general manager signs the exceptions, the owner reads the summary line, and the income auditor keeps the file.

What to do next#

Pick a date, export last month's log, run the five filters once, and put the one-page sheet in front of the general manager. The log, the roles behind it and the monthly sheet are one control: the entries tell you where to look, the accounts tell you who to ask, and the sheet is what makes the review survive past the first month.

One design choice matters more than the rest: whether the system allows financial records to be deleted at all. In our own hotel operating system (built and working, ahead of launch), financial records are never deleted: corrections are voided and reversed, and night audit closes the business day. If you want to see how that record is built, request a briefing.