Room charge: why a text field is not enough
Almost every point of sale claims to have room charge. Almost every one has a field where you type a number. The difference between the two is where the money is lost and where the meeting with IT is won.
Ask any point of sale vendor to show you their room charge. They will show you a payment screen with a button that says “room” and a field where the server types 241. That is not room charge. That is a text field. This article explains, with the precision an IT director cares about, what a real room charge has to do, and why it cannot be solved with an integration.
The question the text field does not answer
When the guest says “put it on my room”, the system has to answer, in that instant and without calling anyone, five questions: is anyone staying in that room right now? Is it this person? Does their company cover this item or only the lodging? Whose tax is it? And where does this money go, if it does not enter the restaurant drawer? A text field answers none of them. It accepts 241, prints a slip, and leaves all five questions for the front desk to answer tomorrow, with the guest already at the airport.
Requirement 1: stay verification
A real charge checks the room status at the very moment the server selects it. If the room is empty, it refuses. If it is occupied, it shows the guest’s name, the arrival and departure dates, and asks for a confirmation that is not typing the number again. The server sees “241, Ana López, departs Thursday” and the guest confirms she is Ana. A charge to a room that checked out an hour ago cannot exist, because there is no open folio to receive it.
This is only possible if the point of sale reads the same stay table as the front desk. Not a copy synced every five minutes: the same one. In an integration between two systems, the room move the front desk made at 8:05 reaches the point of sale at 8:10, and the charge posted at 8:07 went to the old room.
Requirement 2: the charge never touches the drawer
A room charge is a restaurant sale that is collected somewhere else and at another time: at the front desk, at check-out, together with the nights. That is why it cannot enter the restaurant drawer or affect its expected cash. It has to be recorded as a sale of the revenue center, with its server, time and detail, and at the same time create a charge on the guest folio, referencing the check that originated it.
Systems that do not distinguish between sale and payment fail here in two ways. Either they push the charge into the drawer as if it were cash, and the restaurant close shows a “shortage” that is really a charge pending at the front desk. Or they do not record it as a sale until the front desk collects it, and that day’s restaurant report is wrong by everything charged to rooms. An order is not a payment. When the system respects that, the charge exists as a sale from the first second and as money only when someone collects it.
Requirement 3: the agreement applies itself
If the guest is staying through a company, the charge has to consult the agreement at the moment of posting, not at month end. The agreement states, by category, what the company covers and what the guest pays. The system takes each line of the check, classifies it, and sends it to the right folio: food to the company folio, beer to the personal folio. If two rules collide, the most specific one wins, and that hierarchy is written in the agreement, not in the server’s memory.
This is where an integration becomes impossible in practice. The agreement lives in the hotel system. The check with its lines lives in the point of sale. To apply it at posting time, the point of sale would need to know the agreement rules, the hotel catalog categories and the open folios of that room. The moment it does, it is no longer an integrated point of sale: it is a partial copy of the hotel system, and it will drift from the original.
Requirement 4: tax is split
If a check is split between two folios, the tax is split with it, in the same proportion. The tax on the food goes to the company folio; the tax on the wine, to the guest folio. Each folio closes with its own taxable base, and each invoice shows what belongs to it. A system that sends the whole tax to one folio produces an incorrect corporate invoice and an incomplete personal one, and the company’s controller will notice.
This calculation has to happen on the server, not in the server’s browser. The price, the tax and the total that land on the folio are the ones the system calculated with the current version of the rules, not the ones showing on a tablet that has not reloaded in three days.
Requirement 5: a trail in both directions
From the restaurant check you have to be able to reach the folio where every line ended up. From the folio you have to be able to reach the check, the server, the table and the time it was served. When the guest at check-out asks “what is this 340 charge?”, the front desk opens the folio, taps the charge and sees the full check: table 4, two dishes, one bottle of water, served by Carlos, 21:12. Without that link, the answer is “let me call the restaurant”, and the check-out turns into a dispute.
The trail also serves the controller: to audit, they need to take any charge on any folio and reconstruct where it came from, with whom and why, without cross-referencing two reports from two systems by room number and approximate time.
Why an integration does not solve it
An integration is an agreement between two systems to exchange messages. It works for things that change rarely: a rate, a catalog. Room charge changes all the time and on both sides at once: the guest moves rooms, the agreement changes its cap, the check is split at the table, the front desk voids a charge. Every one of those events is a message that can arrive late, arrive twice or never arrive. And every lost message is a month-end difference someone will hunt for by hand. Two systems mean two versions of the truth. The best integration is the one you never need.
The one-minute test
When you evaluate a system, ask for this in the demo: post a check with food and alcohol to the room of a guest under a corporate agreement that does not cover alcohol. Then open that room’s folio. If in under a minute you see the food on the company folio, the beer on the guest folio, the tax split, and you can tap the charge and reach the table and the server, you have room charge. If you see one total charge on one folio with a reference number, you have a text field.
A real room charge verifies the stay in the instant, never touches the restaurant drawer, applies the agreement by category with a hierarchy, splits the tax between folios and leaves a trail from check to folio and from folio to check. None of that can be done with a text field or with an integration between two systems.
Inn Restaurant does not integrate with the hotel: it is the same system, which is why the charge meets all five requirements by design. See the detail on the room charge page (/cargo-a-la-habitacion) and the technical foundations on the technology page (/tecnologia). And the question for your next demo: if your system just lets you type a room number, do you have room charge, or do you have a text field?
Your restaurant already sells. Your system just does not know it.
Fifteen minutes, with your menu and your tables. Nothing to install.