This map is part of the group booking change reconciliation guide. For the dispute that shows why the joins matter, see the worked late-headcount case.
The systems behind one function: where each record lives
A group function touches more systems than any one person at a hotel uses. Sales lives in one, the culinary team in another (or on paper), the front office in a third, finance in a fourth, and the client contact's messages in whatever inbox they reached.
| System | Record it holds | Linking key out | Usual owner |
|---|---|---|---|
| Sales and catering platform | Contract, business block, event orders and their revisions, attendee fields | Block ID, event ID | Director of sales and events |
| Culinary production (system or file) | Production sheet with covers set per function | Event ID or event date plus function name | Culinary director |
| Function operations | Head count sheet, banquet check | Event ID, function room, date | Banquet manager |
| Property management system billing | Postings to the group's posting master, correcting postings | Event ID to posting master folio number | Front office and event accounting |
| Receivables and the ledger | Final invoice, credit notes, payment | Folio or AR account number, invoice number | Director of finance or controller |
| Shared events mailbox or CRM | Client change requests, hotel replies | Group name in subject line, sometimes the block ID | Unassigned, or the sales manager |
OPERA Cloud illustrates how tightly the first hops can be modeled inside one product: catering events are created from a business block and carry an expected attendee count, a guaranteed count and an actual count, and charges post to a checked-in posting master once the event reaches Actual status. Other platforms divide these steps differently; the question for each client is where their own lines fall.
The linking keys, and where each one breaks
Each join fails in a predictable way, usually during a system change or a busy season.
- Block ID to event ID. Strong while the sales platform is in service. Breaks when event orders are overwritten instead of versioned, so only the last number survives.
- Event ID to production and count. Often a manual join. Breaks when culinary and function sheets are filed by date on paper and discarded after a retention period.
- Event ID to posting master folio. Strong inside one vendor's suite. Breaks when correcting postings carry no reason code, so the correction is visible but unexplained.
- Folio to invoice number. Breaks when credit notes are posted to receivables as generic adjustments with no reference back to the event.
- Mailbox to event. Weak by design. A client contact writes "Annual Meeting lunch numbers"; nothing in the message carries a system key.
The Posted Event Revenue report in OPERA Cloud shows billed and posted amounts per event with the variance between them, so a reviewer can see which events were corrected. It cannot say why; that answer lives across the other hops.
One fully joined case (Illustrative)
Below is what a complete chain looks like for the fictional day-two lunch from the worked case, with every identifier invented. This is the target state a hotel's records can be measured against.
| Hop | From record | Key carried | To record |
|---|---|---|---|
| 1 | Signed contract, block BLK-0417 | BLK-0417 | Event order EV-2291, versions 1 and 2 |
| 2 | Event order EV-2291 v2, 220 guaranteed count | EV-2291, April 18 lunch | Production sheet, 231 covers |
| 3 | Production sheet | EV-2291, Terrace room | Head count sheet, 252 served |
| 4 | Head count sheet | EV-2291 to folio PM-8802 | First posting and correcting posting with reason |
| 5 | Folio PM-8802 | Invoice INV-55310 | Revised invoice and payment |
| 6 | Client email, April 17 | Subject "Annual Meeting lunch" only | Matched to BLK-0417 by hand |
Five of the six rows carry a system key. The last needs a person to match the email to the block, which is exactly where most histories lose the reason a number changed.
The weakest join: planner correspondence
The change request is the hop most likely to be missing and the one that explains the exception. Ask whether event-level correspondence is attached to the booking record, saved in a CRM against the account, or left in individual mailboxes. If it is in personal mailboxes, ask what happens when a sales manager leaves. If it is attached, ask from which year. Mailbox ownership is often unclear in a managed hotel, and who owns data in a shared group system sets out how owners, operators and brands split control.
Export questions for the system administrators
On exports, confirm rather than assume. OPERA Cloud, for instance, offers configurable General and Back Office exports in formats such as CSV, JSON and TSV with chosen columns and filter conditions. Whether a property's configuration includes event order revisions, attendee change history and correction reasons is a question for its administrator. Write "unknown" until they answer.
- Does the sales platform keep each event order version with a timestamp and user?
- Are attendee field changes logged, or only the current values?
- Do correcting postings carry a reason code or free-text note?
- Do receivables credit notes reference the event or folio?
- Which years does each system cover, and which earlier systems were never migrated?
The same join-mapping approach on the finance side is covered in general ledger reconciliation, and the broader value of break-resolution notes is on the reconciliation exceptions data page.
Qualification and the open questions
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.
The partner fills in the system map with names, years and owners only. What stays open until SourceX's review: which hops the company has rights to license, how client and attendee details are removed, whether the mailbox is in scope, SourceX's current data needs and any offer. The referral brief template has a field for the systems and the weakest join. More sector context is on the hospitality page.
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 map shows a hotel company whose event IDs still join contracts, counts, postings and invoices across years, register as a partner, check the company on who qualifies and read the program terms before you introduce its finance or events leader.