Corporate credit in the hotel restaurant: limits, terms and who signs off
Extending credit to a company is easy. Collecting it is not. Here is the corporate guest receivable explained from the hotel restaurant: the limit, the payment term, the signature that approves and the alarms that keep an account from becoming uncollectible.
In your hotel restaurant there is a table that almost never pays when the meal ends. It is the business traveler: dinner, a signature, "to my room, please", and the check goes to the folio, and from the folio to an account the company will pay in thirty days. That path is normal in hospitality. What is not normal is walking it with no limit, no written term and no record of who said yes.
What corporate credit really is
When a company has an agreement with your hotel, its travelers do not pay at the table. The restaurant check is posted to the room, the room is tied to a folio, and at check-out the folio is not settled by card: it is transferred to a receivable in the company’s name. You already delivered the dinner, the wine and the breakfast. The money arrives later, if it arrives.
That means every room charge from a corporate guest is a small loan your hotel makes to the company. Added together, those loans are the receivable portfolio. And a portfolio is managed with three things a restaurant without a hotel almost never has to think about: a limit, a term and a signature.
The good news is that the restaurant does not have to invent anything. The front desk and the controller already manage credit for lodging. What is missing is for food and beverage consumption to enter the same set of rules instead of living in a notebook with the company name written by hand, as explained on the company accounts page (Master accounts and agreements).
Three numbers the agreement needs before the first dinner
An agreement without numbers is a promise of a dispute. Before the first traveler sits down in the restaurant, the agreement needs these three values defined, and the system needs to know them, not only the sales manager’s file.
- The credit limit: the maximum balance the company can owe the hotel at any moment, lodging and consumption combined. When the balance reaches it, new charges are no longer approved on their own.
- The payment term: the days the company has to pay each statement from the date it is issued. Thirty days is common, but what matters is that it is written down and that the system counts the days from the right date.
- The per-meal cap: how much a traveler can post per meal, per day or per stay. It is the rule that keeps a working dinner with six guests from landing in your receivable without anyone approving it.
A fourth value, optional but very useful, is which consumption the agreement covers. Food yes, alcohol no, room service until a certain hour. When the rule lives in the system, the server does not have to remember it: the charge that does not qualify is split to a personal check and the guest pays it at the table.
Who approves and who does not
The most expensive mistake in corporate credit is not a badly calculated limit. It is informal approval: the server who accepts a charge because "that company always comes", the receptionist who raises the limit over the phone, the duty manager who signs without looking at the balance. Each of those decisions is reasonable in the moment and disastrous in aggregate.
| Decision | Who makes it | What they need to see first |
|---|---|---|
| Accept a room charge within the agreement | The system, automatically | Active stay, valid agreement, balance under the limit |
| Accept a charge above the per-meal cap | The restaurant manager | The amount, the cap and the guest’s name |
| Accept a charge when the company has hit its limit | The controller or the general manager | The company’s full aging report |
| Raise the credit limit | The general manager with the controller | Payment history for the last six months |
| Suspend credit | The controller, no further signatures needed | Any balance more than ninety days past due |
Look at the first row: the most frequent approval is not made by a person. The system makes it, because it has the three facts at hand. People step in only for exceptions, and the exceptions are recorded with a name and a time. That way the controller does not chase signatures: the controller reads them.
The aging report: the one that announces the uncollectible account
The aging report classifies what you are owed by how long it has been past due. It is the most boring report in the hotel and the one that protects the most money. A thirty-day balance is normal. A sixty-day balance calls for a phone call. A ninety-day balance calls for a decision. Anything past one hundred twenty days almost always ends in an accounting reserve and an uncomfortable conversation with the owner.
What the restaurant contributes to that report is half the problem and, often, the messier half. Lodging is invoiced at check-out and has a clear date. Restaurant consumption arrives in many small checks, sometimes across several revenue centers, and if it is not tied to the guest folio nobody knows for certain which statement it belongs to.
How to read it
Each column is an age bracket and each row is a company. You read from right to left: the oldest first, because that is what is at risk. Then you compare the total balance against the credit limit: if a company with a past-due balance still has credit available, you have a rules problem, not a collections problem.
An illustrative example with numbers
The figures below are invented to show the calculation. They are not from any hotel or any company. They exist only so you can follow the reasoning with a calculator in hand.
An example company has an agreement with your hotel: a credit limit of 60,000, a thirty-day term and a cap of 450 per dinner. It sends three travelers every week, four nights each, and all of them have dinner in the hotel restaurant. Weekly food consumption is 3 × 4 × 450 = 5,400. In a four-week month, 21,600 in the restaurant alone, not counting lodging.
| Bracket | Balance (illustrative example) | What it means |
|---|---|---|
| 0 to 30 days | 21,600 | The current month, within the term |
| 31 to 60 days | 18,000 | One statement past due, still collectible |
| 61 to 90 days | 9,000 | Two statements past due: the controller calls |
| More than 90 days | 4,500 | Balance at risk: credit is suspended |
| Total | 53,100 | Against a limit of 60,000: 6,900 still available |
Look at what the table says. The company still has 6,900 of available credit, so the system would keep accepting charges if the only rule were the limit. But it has 4,500 more than ninety days past due, and that condition alone should switch credit off even though the limit has not been reached. At 5,400 per week, in little more than a week the company would also exceed the limit. Two different alarms, and the aging one sounds first.
The alarms that should sound on their own
A controller who reviews the receivable once a month learns about problems once a month. Alarms exist so the system warns before new consumption is added to old balances. These are the ones worth switching on from the very first agreement.
- Balance at eighty percent of the limit: notice to the sales manager to talk with the company before credit closes at the table.
- Balance at the limit: new charges require the controller’s approval. The guest can pay at the table by card; nobody is denied dinner.
- Statement more than sixty days past due: notice to the controller with the lodging and consumption breakdown.
- Balance more than ninety days past due: credit suspended automatically; that company’s travelers pay directly until the account is current.
- Charge above the per-meal cap: it stops at the point of sale and asks for the restaurant manager’s signature, with a reason.
- Agreement fifteen days from expiry: notice to sales to renew it or let it expire on a date, not through forgetfulness.
None of these alarms punishes the guest. The corporate traveler keeps having dinner; the only thing that changes is how the check is paid. What is protected is the relationship between the hotel and the company, which is the one that is worth something.
How it shows up in the shift close and on the statement
In the restaurant’s shift close, consumption posted to a corporate guest’s room is neither cash nor card: it is a third column, "room charge", and it must match to the cent what the front desk received in the folios. If the restaurant close says 5,400 and the folios say 5,150, there is 250 that someone ate and nobody will pay. That daily reconciliation is the receivable’s first line of defense.
On the statement the company receives, every consumption line should carry the date, the revenue center, the traveler’s name and the room number. A company that receives a total without detail questions it, holds it and pays late. A company that receives the breakdown approves it the same day, because its own controller can match it against expense reports. Detail is not courtesy: it is collections.
And for the hotel controller, restaurant revenue that went to credit is still restaurant revenue under USALI. What changes is the offsetting account: not cash, but accounts receivable. If the point of sale does not separate that sale at the source, someone will reclassify it by hand every closing, and manual reclassifications are where figures get lost, as described in the guide to the shift close by revenue center (A guide to the shift close by revenue center in a hotel).
Every room charge from a corporate guest is a loan from the hotel to the company, and the sum of those loans is a receivable with a limit, a term and a signature. Let the system approve the normal, let people approve only the exceptions, and let the age of the balance switch credit off before the limit does.
What to do this week
- Pull the list of companies with agreements and write, next to each one, its limit, its term and its per-meal cap. If any box stays empty, that agreement is incomplete.
- Ask the front desk for this month’s aging report and separate the lodging portion from the consumption portion. If it cannot be separated, you have found your first problem.
- Match the restaurant’s shift closes for the last seven days against the room charges the front desk posted to folios. Write down the differences with dates.
- Define in writing who approves each exception in this article’s table and share it with the restaurant team at the shift meeting.
- Switch on, even if only as a calendar alert, the notice for balances more than sixty days past due for every active company.
- Check which agreements expire in the next thirty days and decide today whether they are renewed or switched off.
Inn Restaurant ties every room charge to the guest folio and to the company’s agreement, so the limit, the term and the cap are checked at the table rather than at month-end closing. If you want to see how the receivable is built from the revenue center up, the fifteen-minute demo is scheduled on the contact page (contact).
More articles
The wedding at the hotel: how to record consumption in the ballroom, the bar and the guests’ rooms
A wedding at the hotel is not one account: it is three. The couple’s, each lodged guest’s and the hotel’s own. When the three get mixed, someone overpays, someone does not pay, and the controller finds out on Monday.
Invoicing a travel agency for its guests’ consumption without disputes
The agency sends guests to your hotel with a meal plan, the restaurant serves them, and at month end the invoice goes out. If the invoice does not carry the detail per guest and per day, the agency will send half of it back. Here are the agreement, the cap and the report that prevent that.
Agreements that expire: why the system, not the server’s memory, must switch the rule off on the date
Every agreement with a company has an end date. The problem is that nobody in the hotel restaurant sees it: the server applies the usual discount, the guest signs, and the controller discovers weeks later that the folio was billed under a dead rule.
Your hotel’s restaurant already sells well. Now the hotel needs to know it.
Fifteen minutes, with your menu and your tables. Nothing to install.