A guest closes out a bar tab at checkout. The front desk pulls up the folio and the charge is not on it. Nobody did anything wrong. The bartender rang it correctly, the POS terminal said it went through, and somewhere between the two systems it simply did not arrive. The guest re-explains a purchase they already made, and the property either eats the charge or spends the next hour chasing it down after the guest has already left.
This happens more than owners realize, because when it works, it is invisible, and when it breaks, everyone assumes it was a one-off. It is rarely a one-off. It is usually a small piece of software that has been quietly running in the background since before most of the current staff started, and nobody has checked on it in years.
Everyone calls it "the integration." It is actually a program
Ask most GMs how restaurant charges get to the guest folio and they will say "it's integrated," as if that settles it. What that actually means, in almost any property running an on-premise or hybrid PMS, is that a small background service sits between the two systems. It watches for a transaction, checks whether the room is checked in and the guest's authorization covers the amount, and posts the charge to the folio if it does.
That program has a name, an install path, and a login it runs under, even if nobody at the property could tell you any of the three. It does real work every few minutes, all day, every day, and it has been doing it long enough that everyone stopped thinking of it as a thing that could stop.
It usually runs as a background service, and that detail matters
A properly configured background service runs without anyone logged in, restarts itself automatically if it crashes, and comes back on its own if the server reboots. That is the right way to run something like this. The problem is how many are not actually set up that way. They run under a specific person's personal login instead of a dedicated service account, because that was the fastest way to get it working the day it was installed, and nobody circled back to fix it once it was working.
Which means the day that person's password expires, or they leave the company, or IT locks the account during a routine cleanup, the service stops. Not with an alert. It just stops, and the first sign anyone gets is a guest at the front desk holding a receipt for a charge that does not exist anywhere in the PMS.
Nobody is watching whether it is alive
Compare this to almost anything else in a modern tech stack. The booking engine has uptime monitoring. The payment processor has a status page you can check. This program, sitting quietly at the center of every charge that touches a guest folio, usually has neither. The only monitoring most properties actually have is a guest complaint at checkout.
The failure mode has a name, and it is not dramatic
When this service fails, it rarely announces itself. What usually happens instead is what the hotel accounting side calls an orphaned charge: a transaction that posts cleanly on the POS side but never lands on the folio it was meant for, because by the time it tries, the connection is down or the room reference no longer matches an open folio.
The charge does not vanish. It sits in a suspense account or a batch report somewhere, waiting for someone to notice it does not belong to anyone yet and reconnect it to the guest who actually incurred it. On a slow week that is a five-minute fix. On a busy week with a hundred outlet transactions a day, it is exactly the kind of thing that gets written off because nobody has the time to trace it, and a write-off is just revenue you quietly decided not to collect.
The crash loop nobody sees
If the service crashes outright instead of just failing quietly, most are configured to restart on their own, usually within about sixty seconds. That number is worth remembering, because it is the difference between a blip nobody notices and an outage that runs for hours. A service that is genuinely configured correctly recovers in under a minute without anyone touching it. A service that is misconfigured, or depends on a login that no longer works, tries to restart, fails again, and repeats that cycle indefinitely. From the front desk, the symptom looks the same either way: charges quietly stop posting, and nothing in the interface explains why.
What it actually costs you
None of this shows up as a clean line item. It shows up as things that quietly never happened.
- Charges that never post get written off, not collected. Somewhere between a bar tab and a spa treatment sits real revenue nobody billed, because tracing an orphaned charge back to a checked-out guest takes longer than most teams have.
- Reconciliation becomes a person's job instead of a system's job. Someone on your team spends real hours every week manually matching POS batch totals against folio postings, and calls it normal, because it has always been that way.
- Guest trust takes a small hit every time it happens. Being asked to explain a charge that is not showing up is a small friction once. It adds up across a property that does it weekly without knowing it.
- Institutional knowledge lives in one person's head. If whoever set up that service, or knows which login it depends on, leaves without documenting it, the next outage takes days to diagnose instead of minutes.
A service like this is not a technical detail sitting somewhere below the P&L. It is the only thing standing between a POS transaction and the money that is supposed to follow it.
Five things worth checking this week
You do not need to be technical to ask these. You need someone on your team, or your IT contact, to be able to answer them without guessing.
- Ask what login the posting service runs under. If the honest answer is a specific person's name rather than a dedicated account, that is your single biggest point of failure, and it is usually fixable in an afternoon.
- Ask when it was last tested through an actual server reboot, not just a process restart. Those are not the same test, and a service that survives one does not automatically survive the other.
- Ask where its logs live, and whether anyone has looked at them in the last month. A service that has been quietly failing and retrying for weeks usually leaves a trail, if anyone thought to check it.
- Ask what happens on the accounting side when a charge does not post. If the answer is "we'd probably notice," that is not a process. That is a hope.
- Ask if more than one person could explain how this piece of the stack works if the person who set it up were unavailable tomorrow.
None of these require new software or a vendor call. They require someone spending twenty minutes asking questions that nobody has asked since the day this was installed.
Where to start this week
Pick one outlet, the bar or the restaurant, and pull a week of POS transaction totals against what actually landed on folios for that same week. If the numbers do not match exactly, you have just found your orphaned charges, and you now know they exist before a guest or an owner finds them for you.
Then ask the question that actually matters: if this stopped working tonight, how would anyone know before checkout tomorrow. If nobody has a confident answer, that is the real finding, not the charges themselves.