This worked case belongs to the group booking change reconciliation guide, which covers what to inventory before a property system replacement. This page stays inside a single dispute and the decisions in it.
The case file (Illustrative)
Every name, number and date below is invented. Nothing here describes a real hotel, client or completed deal.
| Item | Illustrative value |
|---|---|
| Operator | A 640-person hotel management company |
| Property | A 300-room conference resort it manages |
| Group | A professional association, two-day annual meeting |
| Disputed line | Plated lunch on day two at $62.00 per person |
| Contract term | A guarantee deadline set before the event |
| People deciding | Group sales manager, catering manager, meeting planner, executive chef, banquet captain, event accountant, director of events |
| Outcome | Invoice corrected to the count served, variance cleared |
Hotels record these numbers in separate fields because they mean different things. In Oracle OPERA Cloud's sales and event module, for example, a catering event carries Expected, Guaranteed and Actual attendees: the guaranteed number is the contracted minimum, and the actual number is the billed figure that determines what the client is charged. Three fields means at least three numbers that can disagree, and in this case they did.
OracleSeven steps: what happened, who decided, what was recorded
Step 1, March 4: contract and first event order. The group sales manager signs the association to 200 expected attendees for the day-two lunch. Decision: plan to 200. Record: the signed contract and version one of the event order.
Step 2, April 15: guaranteed count given on time. The meeting planner confirms 220 before the guarantee deadline, and the catering manager amends the event order. Decision: 220 becomes the minimum the client pays for. Record: event order version two with the guaranteed count and its date.
Step 3, April 17: the late request. Two days after the cutover, the planner emails the sales manager asking for 260. Nobody at the hotel confirms the new number in writing. Decision: none, and that silence is the exception. Record: an email in the sales manager's mailbox, outside the event file.
Step 4, April 18 morning: the kitchen decides what it can add. The executive chef sees the email forwarded late and sets 231 covers, the most the kitchen can produce from food already ordered. Decision: cap production below the request. Record: the kitchen production sheet.
Step 5, April 18 at service: the count. The banquet captain counts 252 guests served, with some plates portioned from the buffet line. Decision: serve everyone who arrives. Record: the captain's count sheet, signed.
Step 6, April 19: the first posting. The event accountant bills from the planner's email: 260 covers, $16,120.00. Decision, made by default: the requested number governs. Record: the posting to the group master.
Step 7, April 26: dispute and correction. The planner disputes the invoice. The director of events lays the contract clause, the April 15 guaranteed count, the unconfirmed email and the captain's count side by side and approves billing on 252: above the 220 minimum, and the hotel never accepted 260. Record: a correcting posting of minus $496.00 (8 covers at $62.00), a revised invoice of $15,624.00, and a note giving the reason.
OPERA Cloud supports that kind of fix directly: an event can be reopened, the billed revenue changed and only the difference posted. Its Posted Event Revenue report then shows billed and posted amounts per event with the variance between them, which is the closest thing the system produces to a reconciliation log. The reason for the change, though, is in step 7's note, an email or a binder.
The fork at April 17: confirm the change or let it drift
Every useful record in this case traces back to step 3. Up to then the paperwork describes an ordinary meeting. At that point the hotel had two paths.
| Path | What the records would show | Result |
|---|---|---|
| Confirm or decline 260 in writing the same day | An amended event order or a written refusal, a kitchen sheet that matches, one invoice | No dispute; nothing to reconcile |
| Leave the email unanswered | Four numbers (220, 231, 252, 260) in four records, a disputed invoice, a correction with a reason | The hotel bills, is challenged, and has to reconstruct what governed |
The second path is worse operationally and far richer as evidence, because someone had to decide which record wins and write it down. A single final invoice for $15,624.00 hides all of that.
Why this sequence is useful evidence
An AI developer studying how service businesses handle disputes needs to see the inputs a person weighed, the rule they applied and the checked result. This chain has all three: the initial problem (a late, unconfirmed change), the authorized action (the director's decision with its reasoning) and the verified outcome (a variance of zero after the correcting posting). The general case for break notes of this kind is made on the reconciliation exceptions data page, and exception handling for AI agents explains why the resolution matters more than the error.
Two things make a hotel's archive stronger: the versions survive (not just the final event order), and the reason travels with the correction. Where those live is mapped in the records across systems guide.
Recognizing similar cases at a hotel client
Put these questions to the director of events or the event accountant and write down only the answers. None needs a file opened.
- When a planner changes numbers after the guarantee deadline, is the change confirmed in the event order, by email, or not at all?
- Are superseded event order versions kept, or overwritten by the latest?
- Does the banquet captain's count get filed with the event, and for how many years?
- When a banquet invoice is corrected, is the reason recorded, and where?
- Roughly how many group events a year end in a billing adjustment?
Several yes answers suggest a decision-rich history. The same pattern of a late change, a judgment and a documented fix appears in freight, as the logistics exceptions guide shows. More hospitality context is on the hospitality page.
What qualifies, and what only SourceX can settle
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.
Partners never collect invoices, event orders or exports; discovery stays at metadata level. Unknown until SourceX reviews it with the company: whether the operator or the owner controls these records under the management agreement, how client and attendee details would be removed, whether there is SourceX's current data needs and any offer. The who-can-license decision tree helps find the signer, and the referral brief template turns the answers above into a one-page note. Partners sign the Channel Partner Agreement before submitting introductions.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the director of events confirms that event order versions, captain's counts and correction reasons were kept for years, register as a partner, check the company on who qualifies and read the program terms before you introduce it.