How to reconcile migrated reservations when the totals match
Check future reservations by reference, occupied night and room type after a PMS change. Use a worked example and a reusable reconciliation worksheet.
The essentials
- Matching reservation counts and room-night totals does not establish that individual stays have the correct dates.
- Compare each reservation, then compare reserved rooms for every occupied date and room type, including zero counts.
- Keep unresolved mismatches pending and repeat both checks after corrections.
Check references and nightly distribution
Match each future reservation to its approved source record, then compare reserved rooms by occupied night and room type. Overall totals can agree while individual stays have incorrect dates or room types.
Use this manual checklist before accepting the new system’s future-reservation records. It covers dates, quantities, room types and statuses—not in-house stays, financial opening balances or a complete migration sign-off.
Set a common comparison point
Name a reconciliation owner and agree which source records are authoritative. Keep both sets of records and the working worksheet in the hotel’s approved workspace. Use reservation references rather than copying guest details.
- Record the property, extraction time and time zone for both sets of records.
- Define the included reservation statuses and how equivalent statuses are mapped between systems.
- Define the future-arrival range, and include every occupied night of those stays, even when departure falls beyond that range.
- Record the approved room-type mapping. Similar category names are not proof of equivalence.
- Keep a separate amendment log for bookings created, changed or cancelled after extraction. Bring both sets to the same comparison point before judging differences.
Ask the provider how source and destination records can be matched if reservation references change. Do not rely on guest names alone or silently exclude unmatched records.
Match every reservation before aggregating
Create one comparison row per reservation, or per room component where a reservation contains different room types or date ranges. Check for source records missing from the destination, unexpected destination records and duplicates.
| Field | What must agree |
|---|---|
| Source and destination references | A traceable match, including any approved reference change |
| Arrival and departure | Exact dates, not just the same number of nights |
| Room quantity | Number of rooms reserved for each relevant part of the stay |
| Room type | Equivalent category under the approved mapping |
| Reservation status | Equivalent operational status under the agreed mapping |
| Physical-room assignment | Check separately where applicable; record whether it should be retained or assigned later |
| Outcome | Matched, mismatch or pending, with explanation, owner and recheck result |
Do not change a source record merely to make the two systems agree. Investigate whether the difference is an error, an approved mapping or a later amendment.
Worked example: all summary totals agree
Hypothetical example: each reservation is for one room. Both records are included under the same status rule, and the room-type names map directly.
| Reference | Room type | Source arrival | Source departure | Destination arrival | Destination departure |
|---|---|---|---|---|---|
| SAMPLE-A | Double | 2026-12-11 | 2026-12-13 | 2026-12-12 | 2026-12-14 |
| SAMPLE-B | Twin | 2026-12-12 | 2026-12-14 | 2026-12-11 | 2026-12-13 |
Both sets contain two reservations and four room-nights: two Double room-nights and two Twin room-nights. Even the total reserved rooms on each date agrees. Nevertheless, both reservations have incorrect dates.
For this worksheet, expand each stay into its occupied nights: include the arrival date and exclude the departure date. SAMPLE-A should occupy December 11 and 12, not December 12 and 13.
| Occupied date | Room type | Source reserved rooms | Destination reserved rooms | Difference |
|---|---|---|---|---|
| 2026-12-11 | Double | 1 | 0 | -1 |
| 2026-12-11 | Twin | 0 | 1 | +1 |
| 2026-12-12 | Double | 1 | 1 | 0 |
| 2026-12-12 | Twin | 1 | 1 | 0 |
| 2026-12-13 | Double | 0 | 1 | +1 |
| 2026-12-13 | Twin | 1 | 0 | -1 |
The combined date-and-room-type check exposes what the summary totals hide. The reference check identifies the stays to investigate. Neither check replaces the other: offsetting errors can still produce a zero difference in an individual worksheet row.
Build the nightly worksheet, including zeros
Make one row for every occupied date and mapped room type in scope. Include combinations present in either set, entering zero where the other set has no reserved rooms. For each row, total the reserved room quantities—not merely the number of reservation references.
| Field | What to record |
|---|---|
| Occupied date and room type | Date and approved mapped category |
| Source reserved rooms | Total room quantity in the approved source |
| Destination reserved rooms | Total room quantity in the records under review |
| Difference | Destination count minus source count |
| Affected references | Source and destination references contributing to the mismatch |
| Explanation | Verified cause or the question still unresolved |
| Owner | Person responsible for investigation or correction |
| Recheck result | Dated result after correction, or pending with the next follow-up time |
Compare reserved rooms with reserved rooms. Remaining sellable inventory is a different quantity and is not a substitute for the destination reservation count.
Booking.com’s inventory documentation defines availability by room type and date, while restrictions can apply to room type, rate plan and date. Those are Booking.com-specific definitions; the worksheet here is an original manual reconciliation method, not its prescribed migration procedure.
Use the reservation view to investigate
In Stayelier, reservation details bring together dates, status, room assignment, rate plan, extras and recorded payment balance. Use the individual stay to investigate a reference-level mismatch. The rate calendar provides context for nightly inventory by room type and date; it is not the reserved-room comparison worksheet.
Explore Stayelier’s reservation workspace
These views support manual inspection. They do not establish a Stayelier import tool, migration service or automatic reconciliation report. Confirm how the required comparison records will be supplied before beginning.
Use the existing PMS demonstration evaluation guide for broader software checks
Correct discrepancies and repeat both checks
- Trace each mismatch to its source and destination references. Check the amendment log and approved mappings before requesting a correction.
- Use the agreed provider procedure to correct the records. Keep the explanation and responsible person in the working record.
- Reopen each affected reservation and repeat its field comparison.
- Rebuild the nightly comparison across the full scope to confirm that the correction has not introduced another difference.
- Check unmatched records, duplicates and post-extraction amendments again before recording the reconciliation outcome.
For the hypothetical example, correcting both date ranges should restore the source distribution and make every nightly difference zero. Accept that result only after SAMPLE-A and SAMPLE-B also pass their individual checks.
Keep unresolved discrepancies pending. A named owner or a support request is not evidence that a mismatch has been resolved. Record the comparison version, recheck time and person approving the completed reservation reconciliation.
A reservation reconciliation pass does not prove that guest-facing availability or distribution settings are correct. Booking.com documents that closing a room type can prevent booking even when individual room-and-rate combinations are open. Test sales settings separately; do not alter closures simply to make this worksheet balance.
