How can an Irish hotel reconcile every future booking and deposit before switching PMS?
A full reservation calendar does not prove that every deposit arrived correctly. For an Irish hotel changing its property management system (PMS), the crucial check is whether each future stay carries the right balance and the right payer.
Choose a quiet changeover day, export all future reservations at an agreed cut-off, and match every source booking to its destination record. Reconcile booking values, payments, refunds and outstanding amounts individually, then compare totals. Separate guest balances from online travel agency (OTA) payouts and company payments: money paid to an OTA is not necessarily money received by your hotel. Approve go-live only when every difference is resolved.
Set a cut-off and build one control register
Pick a day with few arrivals, no major group movement and both suppliers available. Record the cut-off in Irish local time. Export all future arrival dates, including next year; keep in-house stays crossing the changeover on a separate handover list.
- Keep the original PMS reference and channel confirmation number. Add the new PMS reference after import; names alone are unreliable matching keys.
- Capture arrival and departure, room type, room count, status, agreed total, extras, payment references, refunds, payer and due date. Split group reservations into traceable room records without duplicating the group deposit.
- Agree who imports bookings, records opening payments and reconnects channels. Keep a timestamped change log for new bookings, amendments, cancellations, payments and refunds after the export.
Worked example: five bookings and their opening balances
Hypothetical example: a Galway hotel switches on 17 November 2026. All amounts are EUR and booking values include applicable taxes. For simplicity, OTA payouts are gross, commissions are invoiced separately, and there are no payment fees or unsettled processor transactions. Both OTA guests have paid the platform in full. These are invented figures, not customer results or market rates.
| Booking / arrival | Channel / arrangement | Current value | Hotel received | Refunded | Net opening credit | Opening outstanding / payer |
|---|---|---|---|---|---|---|
| IE-801 / 20 Nov 2026 | Direct / deposit | €600 | €200 | €0 | €200 | €400 / guest |
| IE-802 / 21 Nov 2026 | OTA Collect / bank payout | €480 | €0 | €0 | €0 | €480 / OTA; guest €0 |
| IE-803 / 22 Nov 2026 | OTA / virtual credit card (VCC) | €750 | €0 | €0 | €0 | €750 / VCC; guest €0 |
| IE-804 / 23 Nov 2026 | Direct / company account | €900 | €0 | €0 | €0 | €900 / company |
| IE-805 / 24 Nov 2026 | Direct / partial refund | €500 | €300 | €100 | €200 | €300 / guest |
| Total | 5 bookings | €3,230 | €500 | €100 | €400 | €2,830 |
For IE-805, the original €600 stay was reduced to €500. Of its €300 deposit, €100 was refunded, leaving a €200 credit and €300 to pay. Across all five bookings: €3,230 − (€500 − €100) = €2,830, comprising €700 from guests, €1,230 through OTAs and €900 from the company.
Net opening credit = received by hotel minus completed refunds. Outstanding = current booking value minus that credit. These are booking-level operational balances, not instructions to recognise revenue or create accounting receivables early.
Do not charge the OTA guest again. Rows IE-802 and IE-803 have no guest accommodation balance, although €1,230 remains uncollected by the hotel. Keep the OTA settlement route visible; do not disguise it as a new cash payment.
Run the source-to-target checks before go-live
Match every booking in both directions: each source record needs exactly one intended destination record, and each imported record needs a source. Then compare arrival dates, room nights, values, net credits and payer balances by channel and arrival month.
- Trace IE-801’s €200 to its original receipt and settlement. Show it as an opening credit, not a fresh card charge or today’s takings.
- For IE-802, verify the OTA’s payout reference, amount, expected date and payment status. A guest-paid label alone does not confirm settlement to the hotel.
- For IE-803, verify the VCC’s activation date, remaining balance, expiry and charge status. Assign collection to one system and one owner.
- For IE-804, confirm the company’s billing details, payment terms and responsibility for accommodation versus guest extras. Preserve that allocation.
- For IE-805, match both the €300 receipt and completed €100 refund. Import either the supported transaction history or its €200 net credit, never both.
Booking.com’s payment and payout documentation distinguishes guest collection from hotel payout and tracks VCC activation and funding. Check the actual reservation: for net payouts, reconcile commission and fees separately instead of treating the difference as money owed by the guest.
Agree a clear go-live decision
Re-export the destination after corrections and apply every logged change through the final cut-off. Require zero missing or duplicate bookings and zero unexplained monetary differences, even when grand totals match. Reception signs off stay details; finance signs off payments and balances. Keep automatic collection and payment reminders disabled for migrated records until verified, then check the first arrivals and payouts after handover.
Use these records in your RoomRaccoon setup review
The RoomRaccoon onboarding process includes setup review, importing existing reservations and training on invoicing and payments. Its hotel property management system presents reservation details and payment statuses. Use these review sessions to demonstrate all five payment scenarios above.
Confirm the supported import fields, opening-credit method, VCC handling and payment-token arrangements with your Onboarding Manager. Establish which steps are manual and which depend on your payment setup or package; do not assume importing reservations also transfers every financial detail.
Bring an anonymised booking export and this reconciliation table to discuss your property’s migration requirements.
Book a demo for your propertyBooking and deposit migration FAQs
Does importing a booking transfer the money?
No. Importing a reservation record does not move funds between bank accounts or payment providers. Carry forward verified payment credits using the agreed migration method, without taking another payment.
Can stored card details move to the new PMS?
Do not assume they can. Ask both payment providers whether a supported token transfer is available. Keep full card numbers and security codes out of the reconciliation register; arrange an approved collection method for any unresolved payment.
What if a refund is still pending at the cut-off?
Record it separately with its amount, transaction reference, status and owner. Do not mark it completed in both systems. Confirm which provider will finish the refund and update the register when its status changes.
Can matching totals hide an error?
Yes. Two misplaced €200 deposits can leave the overall total unchanged. Check every booking reference and payer, then totals; use sampling only as an extra review.
Sources and checks
Sources checked on 13 November 2026. The reconciliation register is a hypothetical manual control, not a RoomRaccoon import specification.
- RoomRaccoon: onboarding stages — setup review, reservation import and training.
- RoomRaccoon: property management software — reservation and payment-status context.
- Booking.com: managing payment and payout details — payer distinctions and VCC status.










