The first 30 days after a PMS go-live: daily and weekly checks

A PMS (property management system, the software that holds reservations, rooms, bills and reports) go-live is not finished on cutover night. For 30 days you reconcile daily: arrivals, guest balances, channel bookings and identity notifications; then weekly: deposits, agency bookings, month-end and e-documents, all through one issue log until written sign-off. This pms go live checklist covers the month after the switch.

The morning after cutover the front desk is calm, the night audit rolled, and everyone exhales. Three weeks later a guest arrives holding a deposit receipt from March that nobody can find in the new system, and the room was sold at a rate the channel never received. After reading this article you will know what to check every morning of week one, what moves to weekly in weeks two to four, how to run the vendor relationship, and how to close the project in writing. It follows the cutover night checklist that comes before this phase.

Why is the first month after a PMS go-live its own phase?#

Because cutover tests whether the system runs, while the first month tests whether its numbers are true, and only the second test protects your money.

On cutover night you prove one thing: the business day can open and close. The errors that cost money surface later, when an old deposit is claimed, an agency rate is mapped to the wrong code, or a group block is picked up twice.

Three things change at once on day one. The system becomes the record of truth, the old system becomes a reference, and the vendor relationship moves from project mode to support. The month has a shape: days 1 to 7 are daily, hands-on reconciliation; weeks 2 to 4 are weekly reconciliation plus the first month-end; the last step is a written close.

Assign three owners before day one: the front office manager for daily operational checks, the accountant for money and documents, the general manager for the issue log and sign-off. Unowned checks do not happen. Write the exit rules in advance too: how many clean nights end hand reconciliation, how long read-only access to the old system lasts, and what counts as acceptance. Deciding these during a busy week means deciding them badly.

Expect the first week to be slower than normal operation. Plan lighter arrivals, extra front desk cover, and no rate or package changes in the first seven days.

Days 1 to 7: what do you check every morning?#

Every morning of the first week, compare four lists against their source: arrivals, guest balances, bookings that arrived from outside channels, and the identity notifications produced by yesterday's check-ins.

Arrivals first. Print today's arrival list and check it against agency vouchers, group rooming lists and direct bookings taken before cutover. A missing arrival becomes a walk-in at 23:00.

Balances second. For every in-house guest, compare the balance in the system with the deposit or prepayment record. Deposits paid before cutover are the classic first-month loss: the guest remembers paying, the new system never saw it.

Channel bookings third. Count yesterday's bookings in the system and compare the count with each channel's own extranet. Then open two of them and confirm the rate and the room type match what the channel sold.

Identity notifications fourth. Confirm that each check-in produced its guest identity notification (KBS, the guest identity notification duty) from the check-in flow, and that none was prepared twice. Ask your accountant or legal adviser to confirm your scope and timing.

Cash and cards need daily attention, not weekly: reconcile the shift report against the actual drawer and the card terminal batch every day. Small differences found daily are explainable; found weekly, they are arguments. Check room status at shift change too, so a clean room is never sold as dirty or the reverse.

Open the issue log on day one, before the first problem, so that the first problem is recorded rather than remembered. If rate codes or revenue codes are still being adjusted, follow setting room types, rate codes and revenue codes up in the right order before changing more.

How do you hand-check the night audit in the first week?#

You redo the night audit's arithmetic yourself from the day's documents and compare it with the system's reports, for seven consecutive nights, and you stop only when three nights in a row match with nothing unexplained.

Pick three reports and no more: the manager's report, revenue by revenue code, and the guest ledger or city ledger balance. More reports in week one produce confusion, not control.

Check the business date: it should advance once per night and never twice. A double roll hides a day of revenue or duplicates it. Check that every occupied room-night posted exactly one room charge, and that total room revenue equals occupied rooms multiplied by their rates for that night.

Check corrections: a mistake must appear as a void and a reversing entry, never as a deleted line. If a charge vanished without a pair, the trail is broken and the accountant needs to know the same day. Check currency too: foreign-currency postings should use the daily central-bank rate for that business date, not a rate typed by hand.

Write the difference down even when you can explain it. An explained difference that is not written down becomes an unexplained one next week.

Define the exit rule now: three consecutive nights with zero unexplained difference ends hand reconciliation. Until then, the accountant signs the nightly comparison.

Weeks 2 to 4: what moves from daily to weekly?#

From week two, the daily checks stay but shrink, and four weekly reconciliations take over: deposits, agency and corporate bookings, the month-end rehearsal, and electronic documents.

Deposits and advances: reconcile the deposit ledger against the bank statement weekly. This is where pre-cutover money hides, because the guest remembers paying and the new system never saw it.

Agencies and corporate accounts: check that portal bookings carry the contracted rate, that commission or net terms are recorded as agreed, and that group blocks show the correct pick-up. A block picked up twice sells a room twice.

Month-end: rehearse it in week three on a copy of the reports, so the real close in week four is the second time your team has done it, not the first. Electronic documents: e-Fatura and e-Arşiv (electronic invoice) depend on the taxpayer's scope, and invoices should wait for a person's review before sending. Check weekly that the review queue is cleared and that the accountant received everything. Confirm your own obligations and dates with your accountant.

If your restaurant, bar or spa issues fiscal receipts, confirm with your accountant which outlet uses which device or document, and test one sale per outlet per week. Track the old system's outstanding guest and city ledger balances on a single list with a named owner, and close the list item by item rather than hoping it empties.

How should you log problems with the vendor?#

One log, one reporting channel, one named owner on each side, and severity that decides the order rather than the volume of complaint.

Classify before you report. Ask first whether the problem is a defect, a configuration choice, or a training gap. Sending a training gap to the vendor as a defect burns days and goodwill.

Use four severities: a guest cannot check in or pay; a number is wrong and money is at risk; a screen or report is wrong but a workaround exists; cosmetic or wish-list. Only the first two justify a same-day call.

Every entry carries date and time, what happened, which guest or booking was affected, the workaround used, the hotel owner, the vendor owner, the promised date, and the date closed. Evidence such as report exports or screenshots stays attached to the entry.

Hold a 15-minute stand-up daily in week one and twice weekly afterwards, with the same two people on each side. It is cheaper than a thread of messages. Escalate by severity, not by frustration: an unresolved first-severity issue goes up one level on each side the same day, in writing. Agree in the contract what response and resolution times you can expect, so the log has something to measure against; support and uptime terms in hotel software contracts are worth reading before you sign, and if that was not agreed before signing, agree it now, in writing.

When do you stop running the old system's reports side by side?#

Stop when a written exit rule is met: the same report has reconciled cleanly for an agreed number of consecutive periods, and one full month-end has closed on the new system.

Running both systems costs staff hours every week and creates two versions of the truth, which is worse than one imperfect version. Set the end date before you start.

Keep read-only access to the old system for a defined period, agreed with the vendor and long enough to answer guest and accountant queries about past stays. Read-only, never write access. Document where historical data now lives, in what format, who can query it, and how a request for a 2023 folio is answered. Without that page, the old system never really leaves.

Retire reports one at a time, each with a named replacement in the new system. A report retired without a replacement is a report someone will rebuild by hand. Keep the old data export, not just the old login: access can end, an export you hold does not. For what should have moved across in the first place, see what to move, check and leave behind in a PMS data migration.

How do you close the project in writing?#

With a one-page closure note signed by the general manager that states what was delivered, what was not, who owns each recurring check, and what is still open with a date and an owner.

Sign against the acceptance criteria you wrote before cutover, not against how the month felt. If the criteria were never written, write them now and sign against them. List every open issue with its severity, owner and promised date: an open issue with no date is a closed issue in disguise.

Name the owner of each recurring check that survives day 30: daily balances, weekly deposits, month-end, e-document review, and the issue log itself. State the date read-only access to the old system ends, where the historical export is stored, and who may query it.

Book a review at day 60 and day 90. Most first-month workarounds quietly become permanent processes, and only a scheduled review catches that. Then hand the team from project mode to operations: refresher training by role, and a short written routine that new front desk staff can follow from their first week. PMS training by role before and after go-live gives the structure.

What to do next#

Write the exit rules before day one: how many clean nights end hand reconciliation, how long read-only access lasts, and what the closure note must contain. The month then runs as one loop. Daily checks protect the guest, weekly checks protect the money, the issue log protects the relationship, and the sign-off turns all three into a routine that outlasts the project.