1. Two PMS records are not necessarily duplicates: a Booking.com reservation can contain several booked rooms.
2. Compare the overall confirmation, each booked-room reference, and the current stay before deciding what to retain.
3. Correct only the proven extra record, preserving the guest's booking, financial history, and future update path.
Two arrivals appear after a Booking.com date change. Both show the same lead guest and confirmation number. Deleting the newer one seems obvious—until the Booking.com Extranet shows that the guest actually booked two rooms.
Reconcile identities before editing your Property Management System (PMS). The question is not simply whether two rows look alike. It is whether they represent the same booked room twice, two legitimate rooms, or different versions of a changed stay.
Distinguish the Booking From Each Room Within It
Start with the current reservation in the correct property's Extranet. Check room quantity and the details of each booked room, including dates, room type, status, and occupancy. Do not infer quantity from the number of emails or PMS arrivals.
There are three references to keep separate:
- Booking.com confirmation: identifies the overall reservation, which may include more than one room.
- Booked-room reference: distinguishes an individual room reservation within that booking. This is not the room-type code or the hotel's physical room number.
- PMS reservation reference: identifies the hotel's own record. Its format need not resemble either Booking.com reference.
Where available, add the booked-room reference from the provider's reservation details. Technical exports may call it `roomreservation_id` or `RoomStay IndexNumber`, depending on the connection format. Staff do not need to read interface messages; ask the provider to establish the correspondence when the screen does not expose it.
A blank component reference is a reason to investigate, not a reason to delete. Older, cancelled, or manually created records may need their original history recovered before a reliable match is possible.
If reception works only from names, both a legitimate second room and an outdated copy can look like an extra arrival. In Smart Order's front desk reservation calendar, compare the source booking with room assignments and payments before deciding which operational entry needs correction. Let the confirmed identity determine the action, not the row's position on the screen.
Check the Booked Rooms Before Removing an Arrival
Review connected reservation details, room assignments, and recorded payments in Smart Order before resolving an apparent duplicate.
Build a Room-Level Identity Trail
Use a short case note rather than changing references in the live booking to make them match. Assign one owner and pause duplicate charges or messages while the identity question is unresolved. Keep genuine rooms protected without adding a hold for every suspicious row.
- Record the current Booking.com confirmation, room quantity, and latest effective details for each booked room.
- Find every related PMS record, including inactive entries and records moved off today's arrivals. Search the source confirmation first, then the other known references.
- Pair each booked-room component with its PMS record or records. Include the old and current dates, source, creation time, and last change time.
- Identify what the modification actually changed. Separate a date or room-type amendment from an added room, a partial cancellation, or a genuinely separate booking.
- Ask the provider which PMS record will receive the next change or cancellation if that cannot be established from the available history.
Consider a hypothetical two-room reservation, confirmation B-Example, with booked-room components R-A and R-B. The PMS holds one record for each. Two arrivals are correct, even though the lead name and overall confirmation match.
Now suppose R-A moves from November 12–14 to November 13–15. The PMS retains the old R-A record and creates another for its revised dates, while R-B remains valid. There are three operational entries for two booked rooms. The suspected duplicate is the pair representing R-A—not R-B simply because it shares the confirmation.
Room-type codes alone cannot resolve this. Two booked rooms can be the same type, and a modification can change a room's type. Likewise, different stay dates do not prove two independent bookings when one row matches the previous version.
If the Extranet shows separate confirmations, investigate both commitments before calling either a duplicate. Do not cancel a real reservation merely because the guest name repeats.
Choose the Correction Only After the Identity Is Clear
Two legitimate booked rooms: retain both operational stays. Correct misleading labels or missing reference links through the approved process; do not reduce room quantity to tidy an arrivals list.
One booked room represented twice: identify the record that retains the supported connection to future updates. Preserve room assignments, guest notes, payment references, and posted financial activity from the other record before closing it through the PMS-approved duplicate process.
A changed room cannot be matched confidently: protect the current guest obligation and escalate. Do not replace source IDs by hand, move transactions speculatively, or assume the newer record is automatically the connected one.
Use the hotel channel-manager connection to establish the intended reservation update path with support. A correct-looking date on a manually created copy is not proof that future cancellations will reach it.
Confirm whether a PMS close, void, merge, or cancellation action could send a cancellation back to Booking.com or release inventory. Choose the supported internal correction, not a guest-facing channel cancellation. Financially posted or checked-in records need supervisor and finance review rather than deletion.
Retain a cross-reference explaining the relationship between the old entry, the surviving entry, and the booked-room component. Staff should not have to repeat the identity investigation next shift.
Reconcile Room Nights, Money, and the Next Change
Count the current booked rooms on each stay night after correction. In the example, R-A should occupy November 13 and 14; R-B follows its own unchanged dates. Removing the old R-A copy must not release R-B's inventory or add an extra room to sale.
Inspect the actual inventory movement before adding any manual adjustment. Closing the proven duplicate may already correct the count. The target is each legitimate booked room counted once, not one PMS row per overall confirmation.
Review payment totals and guest tasks separately. Preserve genuine deposits, posted charges, and authorized transaction references without copying the same collection twice. Keep card details out of ordinary notes and screenshots.
Finally, confirm the corrected stays appear on their proper arrival dates and assigned rooms, without duplicate reminders or housekeeping work. Monitor the next supported reservation event to verify it reaches the intended booked-room record. If no event has occurred, record that follow-up as pending rather than claiming it passed.
The useful closing note is specific: which booked-room component was duplicated, which PMS record remains connected, what financial information was preserved, and how room-night totals were verified. “Deleted the second booking” is not enough.
