A guest lifts a bottle of water off the shelf behind reception at ten past eleven at night, and in the next ninety seconds your hotel either records that properly or starts an argument it will lose in four days. Posting a charge is the smallest financial act in a hotel and the one most reliably done badly. It happens in a hurry. It gets done by whoever is nearest to the screen. It is almost never done by the person who will have to defend it at checkout. In a property management system the act itself takes a few taps, and every system on the market makes those taps easy. Making the result survive the night audit, the checkout conversation and the month-end reconciliation is a different skill, and almost nobody is taught it.
This is not really about the restaurant. A bar running its own point of sale system has already solved the problem with an interface. The drink gets rung up on a till, the guest is looked up once, the charge lands on the folio, and nobody retypes anything, assuming the posting interface between the two systems is configured properly. The gap is everywhere else in the building. It is the desk itself, the shelf of minibar stock behind it, the late checkout somebody agreed at nine in the morning, the corkage on a bottle a guest carried onto the terrace, the laundry bag handed over at seven. None of those have a till. They get posted by hand or they get lost, and the second happens far more often than most owners would like to know.
What a Posting Actually Is
A posting is a dated, coded claim on a guest's money. That is the whole definition, and every part of it does work.
It is a claim, which means it is not a note. Writing minibar, 4 euro on a pad by the keyboard is not a posting, and neither is telling the morning shift. Until a line exists on the folio, the hotel has given away stock and recorded nothing. It is coded, which means it carries a transaction code that decides which revenue account the money lands in, whether tax applies, and how it appears on the guest's bill. And it is dated, which is the part people forget, because the date determines which business day the revenue belongs to and therefore which night audit picks it up.
The folio is where it lands. A folio is the running bill attached to a stay, and it is the reason hotels can do something almost no other business does, which is let a guest accumulate charges across five days and four outlets and then settle once at the end. That convenience is built entirely on postings arriving correctly. Every one that goes to the wrong place, carries the wrong code or arrives on the wrong day is a small crack in a structure the whole property leans on.
Most systems then let a single stay carry more than one folio, or more than one window on the same folio, so that a company can be billed for the room while the guest pays for everything else. OPERA gives a reservation up to eight billing windows. That flexibility is genuinely useful and it is also the first place a charge gets lost, because a line posted to window two on a folio nobody prints at checkout will sit there quietly until somebody runs an aged report weeks later.
Four Fields, and All of Them Bite
Strip away the menu differences between systems and every posting asks for the same four things.
Who. Which folio the charge belongs to. Not which guest, which folio, and the distinction matters the moment a reservation carries two of them or a group has a master bill.
What. The transaction code. This is the field that looks like an administrative detail and is actually the most consequential thing on the screen.
How much. The amount, plus the quantity, plus whatever tax behaviour the code carries. Infor HMS exposes this most explicitly of the major systems, asking separately for unit price, quantity, currency and exchange rate, then showing the property-currency total before you commit.
When. The posting date. Almost every system defaults this to now and almost every user leaves it there, which is correct perhaps ninety-five per cent of the time and quietly wrong the rest.
Some systems add a fifth field for a reference or a comment, and it is worth more than it looks. RoomKey PMS pre-fills the reference with the transaction code description and lets you overwrite it, which is how you turn Laundry into Laundry, 3 shirts, and turn a checkout argument into a five-second conversation. A guest disputing a charge is almost never disputing that they bought something. They are disputing that they cannot remember buying it. A reference line fixes that at the moment of posting, for free, and nobody does it.
Transaction Codes Are the Chart of Accounts Wearing a Hat
Ask a receptionist what a transaction code is and you will usually get an answer about the dropdown. Ask the financial controller and you will get an answer about the profit and loss statement. They are describing the same object from opposite ends, and the receptionist is the one who decides which account gets the money.
Every code maps to a revenue account in your chart of accounts. When somebody posts a bottle of wine under a food code instead of a beverage code, the money still arrives, the folio still balances and the guest still pays. Nothing appears broken. But the beverage cost of sales now sits against understated beverage revenue, the food margin is flattered by revenue it did not earn, and the person analysing outlet performance at month end is reading fiction. Multiply that by a hundred small mispostings and you have a set of departmental numbers nobody can act on.
Tax behaviour is configured on the code too, which is why posting the right amount under the wrong code can still produce the wrong bill. A code set to add tax on top of the amount you type will produce a different total to one that treats your figure as tax-inclusive. Anyone who has watched a receptionist type the shelf price of a minibar item into a tax-exclusive code has watched a hotel undercharge itself by the tax rate, every single time, for as long as the mistake goes unnoticed.
The Miscellaneous Trap
Nearly every property has a code called Miscellaneous, or Sundry, or something similarly forgiving. It exists for genuine one-offs. It gets used for everything anybody cannot immediately find.
The reason is entirely human. It is a busy shift, the dropdown has four hundred entries, the guest is waiting, and Miscellaneous is right there and always works. So the charge goes on, the guest pays, and the shift ends without incident. What has actually happened is that a piece of revenue has been detached from the department that earned it. Nobody can tell whether the spa had a good month. The bar's numbers do not reconcile against its stock. And the general manager asking why beverage revenue is down gets an answer that is technically true and completely useless.
There are two fixes and they work together. Cut the code list down to what the property genuinely sells, because a list of four hundred codes is a list nobody reads. Then run a report on Miscellaneous postings once a month and look at what is in there. Whatever keeps appearing deserves its own code, and the person posting it deserves to have it near the top of the list.
The Long Way to Post a Charge
Here is what selling a four euro bottle of water looks like in a traditional PMS, written out in full, because writing it out is the argument.
Go to the front desk menu. Choose in-house guests. Type the room number, or the surname if the guest cannot remember their room number, which at eleven at night is common. Wait for the search. Pick the reservation out of the results. Open the actions menu. Choose billing. Wait for the billing screen, which loads the entire financial history of the stay because that is what it is built to do. Pick a billing window. Open the code lookup. Find the right code. Enter the price. Confirm the quantity. Apply the charge. Close the billing screen. Return to whatever you were doing before the guest walked up.
That is roughly a dozen interactions and two full page loads to record four euro. Oracle documents essentially this path for OPERA Cloud, Infor documents its own version through Guest Stay and the folio tab, and RoomKey documents a third. None of them is badly designed. They are all designed for a different job, which is managing the billing of an entire stay, and they are all perfectly good at that job.
The problem is that the desk does the small thing forty times a day and the big thing twice. When the tool for the common case costs a dozen interactions, people stop using it. They write on a pad and post everything at the end of the shift, from memory, which is where the wrong room numbers come from. Or they wait for the guest to mention it at checkout. Or, most often, they simply let the four euro go, because there is a queue and it is only four euro. Do that a dozen times a day in a sixty-room hotel and the annual number stops being trivial.
What Opera Calls Post It
The systems that have been around longest all grew a second, shorter route for exactly this reason, which is why an EPOS built into the PMS has become a normal shape for this. In OPERA the route is Post It, reached through cashiering rather than through a reservation. You pick articles from a list, build a small basket, choose who is paying and post it, without ever opening the guest's billing screen.
Prostay's version is Quick Charge, and it opens as a drawer over whatever page you already have on screen, from a receipt icon in the top bar or from the more-options panel on a calendar tile. You search by name, room or confirmation number, and in-house guests come back first, because at eleven at night the person in front of you is almost always staying tonight. You tap the item rather than hunting a code. Then you either put it on the room or take the money there and then.
Anyone moving off OPERA should test this workflow early in an evaluation, and most buyers do not. Demos concentrate on the reservation grid, the rate setup and the reporting, because those are the impressive parts. The desk team's actual daily experience is dominated by small repetitive acts like this one, and they will tell you within a week if it is missing.
The Wrong Room, and Why It Keeps Happening
The most common posting error in any hotel is putting the charge on the wrong guest, and it is worth being precise about why, because the usual explanation of carelessness is both unkind and wrong.
Room numbers are short, similar and spoken aloud in noisy places. Room 214 and room 240 sound almost identical across a desk when somebody is walking away. Guests move rooms and the person posting is often working from a number they were told at check-in two days ago. Groups arrive with six people sharing a surname. Common surnames collide constantly, and in a hotel with a coach group from one country you can easily have four reservations under variations of the same name. And a search screen that returns departed guests alongside in-house ones will eventually get one picked by mistake, because the eye reads the name and stops.
Good search design removes most of this without asking anybody to concentrate harder. Returning in-house guests first is the single highest-value decision, because it puts the statistically likely answer at the top. Limiting results to a handful rather than a long scroll forces a more specific search instead of an approximate pick. Refusing charges outright on cancelled reservations, no-shows and checked-out stays removes a category of error completely, which is what Prostay does, and the refusal is enforced on the server rather than only hidden in the interface.
A confirmation step earns its keep here too. Quick Charge does not post when you choose to charge the room. It shows a check step first, with the guest and the lines you are about to commit, and only the explicit action posts to the folio. That extra tap is the cheapest insurance in the building. It costs a second and it catches the wrong Müller before the wrong Müller becomes a conversation at checkout.
Undoing a Posting Without Lying About It
Every hotel needs to reverse charges. What separates a controlled property from a leaky one is having three distinct tools and knowing which is which.
A void says the posting should never have existed. Somebody double-tapped, or posted a test line, or charged a guest who was never given the item. The line comes off the guest's bill and stays in the audit trail, so the folio reads cleanly and you can still reconstruct what happened.
An adjustment says the event was real and the number was wrong. You posted forty for a bottle that costs thirty. The correct response is a second, offsetting line that both you and the guest can see, because the sale genuinely happened and pretending otherwise would misstate the outlet's revenue.
A transfer says everything was right except the destination. The charge belongs on a different folio, a different window, or a different account entirely. Nothing about the money changes, only where it sits. This is the correct tool for the wrong-room problem and it is the one people reach for least, mostly because it is buried deepest in the menus.
Then there is the fourth thing, the one that is not a tool at all: posting a negative line with a vague description to cancel something out. It clears the balance and leaves behind two entries nobody can explain, and at month end somebody will spend an afternoon working out what happened. If your team is doing this, it is nearly always because the real tools are permission-locked to a manager who is not on shift at eleven at night. Fix the permission, not the person.
Before the Night Audit, and After
The night audit draws a line across the day, and corrections behave differently on either side of it.
Before it runs, the business day is still open and most systems let you void freely. The posting has not yet been rolled into a closed day's revenue, so removing it is clean. After the audit, that day's numbers have been reported, and in many properties they have already gone to accounting or into a management report somebody has read. Systems reflect this by restricting voids once the day is closed, which leaves an adjustment as the only honest instrument.
The operational consequence is simple and worth putting on the wall. If you know a posting is wrong, fix it on the shift where it happened. A correction made at midnight is a non-event. The same correction made at ten the next morning is a conversation with the financial controller.
Late Charges and the Wall at Checkout
Checkout closes the folio, and closing is meant to be final. The guest has seen a total, agreed it, paid it and gone. That finality is exactly what makes the late charge such a persistent nuisance.
The classic version is the minibar. Housekeeping finds two beers gone at half past ten, and the guest checked out at half past eight. The room service tray discovered at eleven is the same problem. So is the bar tab from the previous night that nobody posted before the shift ended, which is really a posting-discipline failure wearing a late-charge costume.
Systems differ in how much they let you do about it. OPERA can permit post-stay charging as a controlled privilege for specific users. Prostay takes the stricter line and refuses charges on checked-out, cancelled and no-show reservations, with the block enforced server-side. The intended route for a genuine late charge is a house account, which is a folio that exists without anybody in a room and can be settled separately.
Both approaches are defensible and neither solves the real problem, which is commercial rather than technical. Collecting money from a guest who has already left is slow, awkward and frequently not worth the staff time it consumes. A card on file makes it possible. It does not make it pleasant, and a guest who finds an unexpected charge two days after departure is a chargeback risk regardless of how right you are. The properties that lose least here are the ones that shortened the gap: minibar checked before the guest reaches the desk on the morning of departure, bar tabs posted at close rather than at the end of a shift, and a departure list the desk actually looks at.
Posting to Somebody Who Is Not in a Room
A quiet assumption runs through everything above, which is that the person buying something is asleep upstairs. Plenty of them are not.
The meeting room booked by a company with no bedrooms attached. The wedding party paying for a bar tab on a day nobody stayed. Somebody from the town with a spa membership. A travel agency that owes you for a booking. Staff meals, if you charge for them. Each of these produces a real charge with real revenue behind it, and none of them has a reservation to post against.
The answer is a house account, which is simply a folio that exists without anybody in a room. It behaves like a guest folio in most respects, accumulating charges until somebody closes and settles it, and in Prostay it draws from the same grid of flagged items as the counter drawer, so the desk is not learning a second workflow to sell the same bottle of water to a non-resident.
Two cautions, both learned expensively by properties that got them wrong. A house account is not a parking space for charges you cannot be bothered to identify, and one that has been open for four months is not an account, it is an unrecorded loss. And a house account is not the same thing as your city ledger, though the two are constantly confused. The account is the live container while charges are still going on. The ledger is where the balance lands once it closes and becomes a receivable somebody has to chase. If the difference between those matters to your property, and it will the moment a company stops paying on time, the handoff between them is worth understanding properly.
The pseudo-room deserves a specific warning. Faced with a charge that has no reservation, a certain kind of resourceful receptionist creates a dummy booking in a room that does not exist, purely to have something to post against. It works. It also puts a fake reservation into your occupancy figures, which means your ADR, your occupancy and anything derived from them are now slightly wrong in a way that is genuinely difficult to trace back months later. If people at your property are doing this, house accounts are either switched off or nobody has shown them where they are.
Taking the Money in the Same Breath
So far this has been about charges, which are one half of the transaction. The other half is settlement, and a counter sale is the case where both happen at once.
Charging to the room is the simple path. The charge goes on the folio and the money gets collected later, at checkout, against whatever payment method the stay carries. Nothing else needs to happen now. But a walk-in buying a coffee has no folio, and a departing guest paying cash for a bottle of water on the way out does not want the charge posted to a bill they are about to close. In both cases you need the charge and the payment recorded together.
Prostay handles this by settling three ways from the same drawer. Charge to room posts to the folio after the confirmation step. Take cash opens a counting step. Take card records a payment you have already taken on the property's own card machine, and it is worth being blunt about what that means, because it is a genuine limitation rather than a feature. Nothing in that step talks to the terminal. You run the card on your own machine, then copy the approval number off the printed slip into the field that asks for it. Integrated capture, where the software drives the terminal directly, is what Prostay Pay and the outlet POS are for.
The Sale That Records Half of Itself
There is a specific failure that shows up in reconciliation and confuses everybody involved, and it is worth understanding because it is invisible while it happens.
Two things have to be recorded for a cash sale: the charge, and the payment that clears it. If those are two separate operations, there is a gap between them, and anything that interrupts the gap leaves the sale recorded as half of itself. A tab crashes. The network drops. Someone gets called away mid-flow. What survives is a charge with no payment, which leaves a balance sitting on a guest's folio that they will dispute at checkout because they already handed over a twenty euro note. Or, worse in a different way, a payment with no charge, which produces a credit nobody can explain.
The structural fix is to make the pair atomic, so that the charge and its settlement are committed in a single request that either fully succeeds or fully fails. Prostay does this for both cash and card, which is why a Quick Charge sale cannot end up half recorded. It is a small piece of engineering that nobody notices working, and it removes an entire category of reconciliation mystery from the night audit.
Cash at the Desk Is Still a Real Problem
Card penetration keeps climbing and every year somebody declares cash finished. Meanwhile the desk still has a drawer, and that drawer still has to balance at six in the morning.
Cash handling at a hotel front desk has its own discipline, separate from anything the PMS does. There is a float, counted at the start of a shift and counted again at the end. There is the arithmetic of making change under time pressure, which is where most honest errors come from. There is the over and short figure, which is the difference between what the drawer holds and what the system says it should, and which tells you more about your controls than almost any other number. A drawer that is exactly right every single day is not necessarily a well-run drawer. It can equally be a drawer somebody is balancing by adjusting the count.
Software helps most by removing the mental arithmetic. A settlement step that asks what the guest actually handed over and then calculates the change is doing the thing humans get wrong when a queue is forming. Prostay's cash step works this way, showing change as you enter the notes received, and it follows the property currency properly, including the zero-decimal ones. That last detail sounds like pedantry until you run a property in Tokyo or Seoul and watch a system built for two decimal places try to represent 1,200 yen.
The rest is procedure and no software will save you from getting it wrong. One person per drawer per shift. A count at handover, done by both people, not one. Over and short recorded every time rather than only when it is large, because the pattern is the signal and a single figure tells you nothing.
Not Everyone Should Be Able to Post
Most properties treat billing as one permission, and it is the wrong shape. The acts involved carry very different risks and belong behind different doors.
Posting a charge to a room creates a claim the guest can dispute at checkout. If it is wrong, somebody notices and it gets corrected, and the worst outcome is an awkward conversation. Taking cash creates a drawer that has to reconcile, which is a different kind of exposure and one that needs a named person attached to it. Voiding a posting can make revenue disappear, which is the act that gets looked at when the numbers do not add up. Posting the same charge to several rooms at once multiplies whatever mistake you just made by the number of rooms selected.
Prostay separates these into four rights: adding an item to a folio, posting from the counter drawer without opening the reservation, adding a payment, and charging several rooms in one action. The point of the split is that a receptionist on their first evening can sell a bottle of water without also being able to erase last night's bar revenue. Roll them into one permission and you face a choice between over-granting and paralysis, and most properties pick over-granting because the alternative stops the desk working.
Two practical notes on the multi-room right in particular. Charging several rooms posts the full amount to each folio separately, which is what you want for a conference where every delegate room takes the same fee. It is emphatically not a way to split one bill between rooms, which is a different feature entirely and lives on the folio. And when more than one room is selected, cash and card settlement stop making sense and disappear, because there is no single payer to hand over the money.
The Item List Is an Editorial Decision
A grid of tappable items only beats a code dropdown if somebody curates it, and this is the part properties skip.
The temptation on setup is to show everything. It feels safer and it takes no thought. What it produces is a grid with sixty tiles that is slower to use than the dropdown it replaced, because now you are scanning instead of typing. The whole value of a tile grid comes from it holding the twelve things the desk actually sells at eleven at night, in roughly the order they get sold.
Prostay makes this an explicit per-item flag, so an item appears on the counter grid only when somebody has ticked Show on the Quick Charge grid. Treat that tick as an editorial decision rather than a configuration step. Water, the local beer, late checkout, the parking fee, corkage, a luggage store charge, whatever your property genuinely sells at the desk. Then look at it again after a season, because the list drifts as the property changes and nobody ever reviews it unprompted.
A related trap is packages. When an item carries components, posting it should put those components on the folio as their own lines rather than one opaque total, so that the revenue splits correctly across departments and the guest can see what they bought. If your grid posts a package as a single line under a single code, you have recreated the Miscellaneous problem with better styling.
What the Night Audit Does With Your Day
Everything posted during the day meets the night audit, and understanding what it does explains most of the rules that seem arbitrary during a shift.
The audit closes the business day. It rolls the date forward, posts room and tax charges for the night, produces the day's revenue reports, and fixes the numbers that will be reported upward. Once it has run, that day is settled in the accounting sense, which is why voids stop being available and why a charge posted with yesterday's date after the audit has run causes a problem that reaches beyond the folio.
This is also the reason that a system posting everything dated now is a reasonable design choice rather than a limitation. Quick Charge always dates a posting to the moment it happens, with no date picker, and the tradeoff is deliberate. You lose the ability to backdate. You also lose an entire class of error where somebody backdates by accident and drops revenue into a closed day.
The place this bites is the shift that ends after midnight. A bar closing at one in the morning is selling into a business day that, as far as the PMS is concerned, has already turned over. Whether that is correct depends on how your property defines its day and when the audit runs, and it is worth agreeing explicitly with your financial controller rather than discovering the answer in a variance report. Properties with late outlets often run the audit later for exactly this reason.
A Posting Discipline That Survives a Full House
Rules that only work on a quiet Tuesday are not rules. Here is what survives a Saturday with a wedding in the ballroom.
Post it now, not later. The pad by the keyboard is where revenue goes to die. If posting takes twelve interactions your team will use the pad, so the honest fix is a faster route rather than a memo about discipline.
Say what it was. Use the reference field. Laundry, 3 shirts settles an argument that Laundry starts.
Check the name, not the number. Room numbers are the field most likely to be wrong and the one people verify least. Read the guest's name back from the screen before committing.
Correct on the shift that caused it. Before the audit a mistake is nothing. After it, it is a report.
Never invent a code. If nothing fits, use Miscellaneous and flag it, so the code list gets fixed. Do not quietly use whatever is closest.
Count the drawer with a second pair of eyes. Every handover, not just the ones where something feels off.
Six habits, none of them clever. Properties that follow them do not have a month-end posting problem, and the ones that do not spend an afternoon every month reconstructing what happened from memory.
The Charge Was Always the Easy Part
Every PMS on the market can post a charge to a folio. That has been solved for thirty years and no vendor differentiates on it. What varies, and what actually determines whether your revenue arrives intact, is everything around the act.
How many interactions it takes when there is a queue. Whether the search puts the in-house guest first or leaves you scrolling past last week's departures. Whether the system stops you charging a guest who left this morning. Whether a correction leaves a trail somebody can read in six weeks. Whether the person who can sell a bottle of water is automatically also the person who can erase a night's bar revenue. Whether a cash sale can end up recorded as half of itself.
None of that shows up in a feature comparison, because every row would say yes. It shows up on a Saturday night with a queue of four and a guest who wants a bottle of water, and it shows up again at month end when somebody asks why the beverage numbers do not reconcile. The four euro was never the point. The trail it leaves is.
