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.
The agreement with the company expired on June 30. On July 1, its travelers keep arriving at your hotel restaurant, keep saying "to my room, please", and the server keeps applying the usual discount, because nobody told him it no longer exists. The guest is not lying, the server is not stealing, and the sales manager did not forget on purpose. The rule simply lived in people’s memory, and people do not have an expiry date.
The rule nobody switched off
A corporate agreement is a set of rules: a discount on food, a cap per dinner, what can be charged to the room, how many days the company has to pay. Each of those rules has a start date and an end date, and both are written in the contract. What is almost never written is who switches them off when the date comes.
In practice, the agreement is communicated once, when it is signed. The sales manager sends an email, someone tapes a note to the register, the servers learn it at the shift meeting. From then on, the rule travels by word of mouth, from shift to shift, and it outlives its own end date because nobody has a reason to doubt it. The familiar traveler arrives, the discount is applied, everyone is happy until the controller closes the month.
The same happens in reverse: the agreement was renewed with new conditions, but the server keeps applying the old ones. Or the company never renewed, but its travelers keep coming and nobody bills them the full rate because "they have always had an agreement". Each of those scenarios is money billed wrong, and none of them is visible at the table.
Anatomy of a validity period
A well-defined validity period is not just an end date. It is four dates and one decision, and the system needs to know all of them to act without anyone having to remember.
| Element | What it defines | Who decides it |
|---|---|---|
| Start date | From which day the rule applies to charges | Sales, at signing |
| End date | Until which day, inclusive, the rule applies | Sales, at signing |
| Advance notice | How many days before the end sales and the controller are notified | Controller |
| Grace period | Whether charges after the end are accepted under the old rule, and for how many days | General manager |
| What happens at expiry | Whether travelers pay the full rate, pay directly, or are denied the room charge | General manager with sales |
The element most often forgotten is the last one. Deciding that an agreement expires is easy; deciding what happens to the traveler who arrives the day after is what prevents the awkward scene in the restaurant. If the decision is "full rate, charged to the room", the system does it on its own. If it is "pays directly", the server sees it on screen before taking the order and mentions it naturally. What cannot happen is for the decision to be made at the table, with the guest waiting.
The day after: four ways to bill wrong
When the rule lives in memory rather than in the system, the day after expiry produces one of these four errors. All four are silent: the check prints, the guest signs and nobody complains.
- The phantom discount: the company no longer has an agreement and its travelers keep receiving the discount. The hotel gives away margin to someone who no longer negotiated it.
- The old condition: the agreement was renewed with a smaller discount or a different cap, but the register still has the previous one. The difference between the two conditions is lost at every dinner.
- The dead credit: the agreement expired and the credit with it, but consumption keeps going to the folio and from there to a receivable the company, rightly, does not recognize.
- The overcharge: the agreement was renewed, but nobody communicated it and the server bills the full rate. The traveler complains at the front desk, and the hotel corrects it with a courtesy that should never have existed.
Of the four, the third is the most expensive, because it is not just margin: it is entire consumption the hotel already served and will now argue over with a company holding an expired contract. The company accounts page (Master accounts and agreements) explains why credit must be a rule with a date and not a habit.
An illustrative example with numbers
The figures below are invented to show the calculation. They are not from any hotel or any company; they only serve to see what a month of an unswitched rule costs.
An example company had an agreement with your hotel restaurant: 15 % off food, valid until June 30. It did not renew. In July, its travelers kept having dinner: 40 dinners at a menu price of 520 each. Nobody switched the rule off, so the discount was applied to all 40.
| Item | Calculation | Amount (illustrative example) |
|---|---|---|
| Consumption at menu price | 40 × 520 | 20,800 |
| Discount applied under the dead rule | 20,800 × 0.15 | 3,120 |
| Revenue recorded | 20,800 - 3,120 | 17,680 |
| Margin given away in July | What should have been billed minus what was billed | 3,120 |
Now take the opposite variant: the company did renew, but at 10 % instead of 15 %, and nobody updated the register. On the same 20,800, the correct discount was 2,080 and 3,120 was applied. The difference is 1,040 in one month. It looks small until you multiply by the number of companies with agreements and by the months it takes someone to notice. And in neither case was there bad intent: there was a date nobody looked at.
Renewing is not editing
When an agreement is renewed, the natural reaction is to open the existing rule and change its end date and percentage. It is a mistake, and one that costs at closing. If you edit the rule, June’s charges end up tied to a rule that now says 10 %, and the controller reviewing in August cannot explain why 15 % was applied in June.
The right way is for the old rule to close on its date and the new rule to be born with its own. Two records, one history. Every charge stays tied to the rule that was in force the day it was served, and any audit, internal or from the company, can reconstruct which condition applied to which dinner. It is the same thing the controller does with room rates: nobody edits last year’s rate, this year’s is created.
And if the company asks for retroactive effect
Sometimes the renewal is signed in July with validity from July 1, and there were already dinners billed under the previous rule or with no rule at all. That is not solved by editing either: it is solved with a line adjustment, with the reason "retroactive renewal", on the affected charges. The company’s statement shows the original charge and the adjustment, and both sides see the same history.
The notices that arrive before the date
Switching the rule off on the date solves the incorrect billing, but it does not solve the relationship with the company. That is what advance notices are for, and the system must send them without anyone asking.
- Thirty days before the end: notice to the sales manager with the company’s consumption over the last twelve months, so the renewal is negotiated with data rather than recollections.
- Fifteen days before: second notice to sales with a copy to the controller, including the company’s outstanding balance. A company with past-due balances should not be renewed on the same terms.
- Five days before: notice to the restaurant manager and the front desk, so the team knows what will happen with the travelers arriving the following week.
- On the end date: the rule switches off. The next day’s charges are processed under the decision defined in the validity period, and the system records that the rule stopped applying.
- The day after: report to the controller with that company’s charges processed without an agreement, to confirm none slipped through under the old rule.
Notice that the system does not send the notices to the server. It sends them to whoever can decide: sales, controller, manager. The server does not need to know when the agreement expires; the server only needs to see, when taking the order, whether the guest in front of them has an active rule or not. That is the difference between trusting memory and trusting the date.
Reconciling with the company
When the agreement lives in the system with its dates, the statement the company receives can show, next to each charge, the rule that was applied and its validity. The company sees that June’s dinners carry 15 %, that July’s carry the 10 % of the renewal, and that the only dinner without a discount was July 1, when the new rule had not yet been signed. There is nothing to argue about because there is nothing to interpret.
Without that, reconciliation is an hour-long call in which the company’s controller asks why three dinners carry a discount and two do not, and the hotel’s controller digs through checks to find who served each table and ask which rule they applied. That time is cost too, even though it never appears in the example table. The article on how to write an agreement that does not generate disputes (How to write a hotel corporate agreement that does not end in a dispute) covers what the contract must say so this conversation never happens.
An agreement is a rule with a start date and an end date, and the system must switch it off on that day without depending on anyone remembering. Renewing means creating a new rule, not editing the old one, and advance notices go to whoever decides, not to the server, who only needs to see whether the guest has an active rule.
What to do this week
- Make a list of every active agreement with its end date. If any has no date, assign one today, even a provisional one.
- Find the agreements that expired in the last six months and check whether their travelers kept receiving conditions after the date. Quantify the difference.
- Define in writing what happens with charges the day after expiry: full rate to the room, direct payment, or manager consultation.
- Remove the note taped to the register. If the agreement is not in the system with dates, it does not exist for billing purposes.
- Set up the thirty, fifteen and five-day notices for sales, controller and restaurant, even if they start as calendar alerts.
- At the next renewal, create a new rule with its date and close the previous one. Do not edit the old one.
Inn Restaurant stores every agreement as a rule with a start date and an end date, applies it to the charge at the table while it is in force and switches it off on its own when it expires, with advance notices to whoever decides. If you want to see what an agreement about to expire looks like from the point of sale, the fifteen-minute demo is scheduled on the contact page (contact).
More articles
The Tuesday corporate traveler and the Saturday family: two different ways of consuming in the same restaurant
Your hotel restaurant does not serve one guest: it serves two who never meet. The Tuesday one dines alone, late, with the check going to the company. The Saturday one has a long breakfast in a group, lives at the pool and pays by card. Read them together and you understand neither.
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.
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.
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.