Point of sale and hotel management system in one: why the integration is the source of almost every error

In most hotels, the restaurant has a point of sale and the front desk has a property management system, and between the two there is something the vendor calls an integration. It sounds as if the two systems talk to each other. In practice it is a courier: it takes the charge from the restaurant, carries it to the folio, and if anything along the way does not match, drops it in a log nobody reads. Almost everything that goes wrong between the restaurant and the front desk happens on that road.

Two systems, one link, and what lives in between

A point of sale knows about tables, orders, the kitchen and shift closes. A property management system knows about reservations, stays, folios and rates. Neither was designed with the other in mind, and each stores its information by its own rules. The link between them has to translate: the room number from the point of sale into a stay in the hotel system, the ticket total into a folio line, the revenue center name into a revenue code.

Every translation is a point of failure. And there is a consequence worse than the error: blindness. When a charge fails in the link, neither system knows for certain. The point of sale believes it sent it. The hotel system never received it. The consumption exists on a closed ticket and exists on no folio. It is discovered, if it is discovered, at guest check-out or in the month-end reconciliation.

The “almost every error” in the title is not rhetorical exaggeration. If you list the problems between a hotel’s restaurant and its front desk, almost none occur inside the point of sale or inside the hotel system. They occur on the trip between the two.

Anatomy of a charge traveling between systems

To see where consumption is lost, it helps to follow a single charge from the table to the folio. This is the typical route when there are two systems.

1. The guest says “to my room” and the server enters into the point of sale the number the guest gave.
2. The point of sale asks the link whether that room is occupied. Sometimes the question is asked; sometimes the number is simply accepted.
3. The link queries the hotel system and returns a name, or an error, or nothing if the line is slow.
4. The server closes the ticket with the payment method “room charge”. The point of sale marks it as paid.
5. The link picks up the closed ticket and sends it to the hotel system as a folio line, with a revenue code.
6. The hotel system accepts it if the room is still occupied, the folio is still open and the code exists. If anything fails, it rejects it or leaves it in a queue.
7. The front desk sees the charge on the folio when it opens the stay for check-out. If it never arrived, they see nothing, and neither does the guest.

Seven steps, five different systems or people, and the point of sale considered the consumption paid at step four. Everything from step five onward is invisible to the restaurant. That is the trap: the restaurant reports a sale the front desk may never have collected.

The typical link errors

Look at the “when” column. None of the errors is found at the moment it happens. All are found later, when fixing them is already expensive, and several are never found. The other places where consumption escapes in a hotel are covered in the article on the eight places where consumption is lost (The eight places where a hotel loses food and beverage revenue), and the link between systems shows up in more than one.

Why the link fails more than it seems

Versions

A link is built for one version of the point of sale and one version of the hotel system. When either one updates, the link may stop understanding what it receives. The point of sale vendor says the problem is the hotel system, and vice versa. Meanwhile, charges do not travel.

The end-of-day process

Hotel systems run a date roll at night, usually in the early hours. During that process, many do not accept charges. If the bar closes at one and the date roll runs at one thirty, the bar’s last tickets reach a system that does not want them, and they sit in a queue with the wrong date.

The guest who changes rooms

It is the most frequent case and the hardest for a link based on room number. The guest moves from 210 to 315 because of an air conditioning problem. That night they have dinner and say “to my room, 315”. The point of sale accepts 315 because it is occupied. But if the move was not reflected in time, or if the server remembered the previous number, the charge goes to 210, where someone else now sleeps and will complain in the morning.

The queue nobody reads

Every link has a place where it leaves what it could not deliver. It is called a queue, an error log or pending items. In almost every hotel, nobody has that place as a daily responsibility. It gets reviewed when the controller cannot balance the month, and by then the guests behind those charges are back home.

An illustrative example with numbers

The figures below are made up to show the calculation; they are not data from any hotel or from the industry. Picture a 100-room hotel whose revenue centers generate 900 room charges a month, with an average of 350 per charge. That is 900 × 350 = 315,000 a month traveling through the link.

Suppose the link fails on 2 % of charges for any of the causes in the table. That is 900 × 0.02 = 18 charges a month that do not reach the folio correctly, worth 18 × 350 = 6,300. If half are recovered through front desk and controller work and the other half are lost, the direct loss is 3,150 a month, or 37,800 a year.

Now the recovery work: each of the 18 charges takes about thirty minutes between finding the ticket, identifying the right guest, correcting the folio and, sometimes, making a call. That is 18 × 30 = 540 minutes, that is, 9 hours a month of qualified people repairing what the link broke. Over a year, 108 hours.

And there is what this arithmetic cannot measure: the guest in 210 who found someone else’s dinner on their bill, and the trust between front desk and restaurant that erodes with every case. Two percent sounds small until you multiply it by twelve months and put a name on every guest.

What “in one” really means

Many vendors say their system is integrated and actually sell two products with a link in between, sometimes built by a third party. “In one” means something more concrete: the server and the receptionist work on the same guest record, and the charge does not travel because it is born where it needs to be.

• The server looks up the guest by name or room and sees the real stay: name, departure date, whether there is an agreement and whether there is a credit limit. They do not type a number blind.
• The charge is posted to the folio the instant the ticket closes. There is no sending, no queue, no “it already went out”.
• If the guest changed rooms, the charge goes to the person, not the number. The room is an attribute of the stay, not the identifier of the charge.
• The front desk sees the consumption detail inside the folio: what was consumed, at what time, at which revenue center and who served it. Not a line that says “restaurant 350”.
• The restaurant close and the hotel report come from the same data. Reconciliation ceases to exist as a task.
• There is no date roll rejecting charges: the one in the morning consumption knows which business date it belongs to.

How that charge tied to the stay works, step by step from the server’s screen, is shown on the room charge page (Room charge).

What “in one” does not solve

It is worth being honest about the limits. Having the point of sale and the hotel system in one removes the link and its errors, but it does not remove process errors. A server can still charge the wrong person if they do not confirm the name out loud. The front desk can still run express check-outs without reviewing the folio. A badly entered corporate agreement still overcharges.

What changes is that those errors are visible at the moment, on the screen of whoever makes them, not days later in a queue. And the fix is an action in the system, not an investigation between two vendors. Process still matters; it just stops competing with the technology.

There is another limit: if the hotel already has a management system it will not change, the point of sale has to link to it anyway. In that case, what you can demand is a link with verification at the moment, a visible queue with an owner, and a log of every transmission. It is the second-best scenario, and it is far better than the blind link.

Questions for your vendor

Whether you are evaluating an all-in-one system or a link between two, these questions separate commercial answers from technical ones. Ask for them to be answered with a demonstration, not a slide deck.

• When the server enters a charge, what do they see about the guest on screen: name, departure date, agreement. If all they see is “room occupied”, the link is blind.
• What happens to a charge if the folio is already closed. Where it goes, who sees it and how they are notified.
• What happens if the guest changed rooms an hour ago. Show it with a real case in the demonstration.
• Where is the queue of charges that did not arrive, and who reviews it every day at the hotel. If the answer is “there is no queue because it never fails”, be suspicious.
• What happens when either system updates. Who gives notice and who fixes it.
• How the controller sees restaurant revenue inside the hotel report, and whether anything has to be reconciled by hand at month end.

What the controller needs from that report, and why manual reconciliation is the clearest sign of a blind link, is developed on the page for controllers (Controller).

What to do this week

1. Ask who reviews today the queue of charges that did not reach the hotel system. If nobody knows which queue that is, you already have your first finding.
2. Ask the controller how many hours went last month into reconciling the restaurant against folios, and how many charges were adjusted by hand.
3. Run a test: move a guest to another room in the afternoon and post a dinner under their name at night. See where the charge landed.
4. Check what time the hotel system’s date roll runs and what time the bar closes. If they overlap, there are charges with the wrong date.
5. Write down the six vendor questions and ask for a live demonstration with your own room-change case.

Inn Restaurant posts every hotel restaurant charge directly to the guest’s stay, with name, departure date and agreement in front of the server, with no link in between that could lose it. If you want to see the room-change test with your own eyes, a fifteen-minute demo (contact) runs it live.