Before connecting a new system to your PMS: an integration test checklist

PMS integration testing is the acceptance work a hotel does before a new system is allowed to exchange live data with its property management system (PMS). It checks four things: the direction and timing of each message, the mapping of codes on both sides, how the link behaves on bad days, and who signs off.

The vendor says the interface is finished. Three weeks later the month-end balance does not tie, and nobody can say which system moved the charge. The gap is rarely the software; it is the acceptance work nobody wrote down. After reading this, you will be able to run a structured PMS integration test: agree the terms on paper, map the codes, run ten scenarios, define what happens to a failed message, and sign off in three places.

What is PMS integration testing, and what does it actually check?#

It is the acceptance work that decides whether a new system may exchange live data with your PMS. It checks messages, not demo screens.

An integration is two systems exchanging messages. Every message has a direction (who sends it), a trigger (what makes it go), a format (what fields it carries) and an owner (who answers for it). Testing means proving each of those four properties for every message the new link will carry.

Separate "the connection works" from "the data is right". A link can pass a quick smoke test and still post the wrong amount to the wrong account. Name the three failure classes before you test, because each needs a different scenario.

Test on a copy of the live system with realistic data, not on the vendor's demonstration property, so that your own room types, taxes and departments are in play. Write the acceptance criteria down before the first test; without them, "it works" becomes an opinion and the argument moves to the invoice. The hotel owns the test even when the vendor runs it: someone on your side must be able to say what was tested and what was skipped.

What should you agree on paper before the first test?#

Four things for every message: direction, fields, timing and owner. If any of the four is missing, the test cannot fail, only argue.

Direction means stating which system is the source of truth for each field. A rate, a guest name and a bill total may each have a different answer, and that is fine as long as it is written. Fields means listing exactly what is sent, and also what is deliberately not sent, such as guest notes or identity document details, with the reason recorded next to it.

Timing means saying whether the message goes instantly, in a batch at a fixed hour, or only when a person presses something, and what delay is acceptable before it counts as a fault. Owner means naming who is accountable when a field is wrong, and who may change the mapping after go-live. A mapping changed by two people is a mapping nobody controls.

Put the agreement in a dated annex to the contract. The person who agreed it verbally will eventually leave, and the annex is what survives. Add a short "never" list: what the new system must never change in the PMS on its own, such as a closed bill or a past business day.

How do you check the mapping on both sides?#

You compare code lists, not screens. Every code in one system needs a named twin in the other, and the twin must be tested.

Build one sheet with three columns: code in the sending system, code in the receiving system, tested yes or no. Nothing is finished until the third column is filled. Cover the families that cause the most month-end work: room types, rate plans, tax rates, payment types, revenue departments and accounting accounts.

Watch for codes that look equal but are not. Two room types that both map to a single "standard" code will produce a correct-looking bill with the wrong revenue split. Watch for one-to-many as well: a single restaurant department may need to split across two accounting accounts, and the split rule has to be written down, not assumed.

Test with a deliberately awkward case: a discount, a split bill, a zero-value charge, a guest name with characters the other system may not accept. Keep the sheet after go-live; it is the first document anyone needs when a number looks wrong six months later. For background on how these links carry messages, read how hotel PMS integrations work, explained in plain words.

Which scenarios must pass before go-live?#

Normal days and bad days. A clean reservation proves the link exists; the ten scenarios below prove it can be trusted.

Run each scenario with a real person watching both systems at once, and record the result with a date and a name. Include at least one scenario that crosses the night audit, because a day change while a message is in flight is where date logic breaks. Include at least one duplicate, sent on purpose, to see whether the receiving system recognises a message it has already processed. Include one scenario with the network down, to see what the sending system does with the message it could not deliver.

For a channel or distribution link, the last item matters most: check the round trip, not one direction. How a channel connection handles messages, delays and errors is covered in how a channel manager connection handles messages, delays and errors.

What should happen when a message does not arrive?#

It must be visible, retried to a limit, and owned by a named person. A message that disappears quietly is the most expensive kind of fault.

Retry with a limit, then park the message somewhere a person can see it. Silent dropping and endless retrying are both failures, in opposite directions. Require duplicate protection on the receiving side, so that a retried message does not become a second charge on a guest bill.

Run a daily reconciliation of counts and totals on both sides, by a person, at least until the link has proved itself over a full month-end close. Route alerts to a role, not a person's mobile: who is called at 02:00, and who is called at 10:00. A night auditor cannot debug an interface at three in the morning.

Agree a manual fallback and train staff on it: post the charge by hand, note why, and reconcile it when the link returns. Keep the message log long enough to cover a month-end close, so that a question asked in week four can still be answered. What you should demand from the vendor on response times is covered in support and uptime terms in hotel software contracts.

Who signs off, and when do you look again?#

Three signatures and a review date. Front office confirms guest-facing correctness, accounting confirms money correctness, IT confirms operational correctness.

The vendor signs the technical sheet; the hotel signs the acceptance. These are different documents and should not be merged into one. The sign-off lists what was tested, with dates and names, and equally what was not tested and is therefore not covered by anyone's promise.

Set a review date after the first month-end close, and a second one after the first high season, when volume exposes what a quiet week hides. Ask for notice before any version change on either side, and a written statement of what changed, in plain language rather than a release note. Keep a short regression list, the five or six scenarios that touch money and dates, and rerun it after every update. Record who may approve a mapping change after go-live; without that name, the integration slowly drifts away from the document that described it. To check the money side properly, see what moves from the PMS to the accounting system at day end, and how to check it.

What to do next#

Before you book a test slot, write the four-line agreement for each message: direction, fields, timing, owner. The checklist only works if the paper exists first, because a test can only confirm an agreement that was made. Then run the ten scenarios, sign off in three places, and put the review date in the calendar next to the month-end close.