A PMS integration is not automatically a source of truth.

Integration answers the wrong question first.

When a hotel says two systems are integrated, the usual question is whether data can move between them.

Can the booking engine read availability? Can the channel manager send reservations? Can the guest portal find the stay? Can the pricing tool push a rate?

Those questions matter. They are not enough.

The more important question is what happens when two connected systems disagree.

The website says the room is available. The PMS says it is blocked. The pricing tool has one restriction. The channel manager has another. The guest portal says payment is complete. Finance sees an unsettled transaction. An OTA cancellation arrives after the reservation record has already changed internally.

At that moment, “integrated” tells you almost nothing.

You need to know which system is allowed to be believed.

That is the source-of-truth decision.

A source of truth is not the system with the nicest interface.

It is the system that owns the state.

Ownership means more than displaying the latest value. It means the system has authority to create that state, change it, explain how it changed, and survive a disagreement with another system.

For a reservation, that usually means answering questions such as:

• Which system creates the reservation identity?
• Which system owns its current status?
• Which system decides whether an amendment is valid?
• Where is the durable record before another provider is acknowledged?
• Which system can reverse or cancel the state?
• What happens if a downstream delivery fails?

If nobody can answer those questions clearly, the operation has an integration map but not an authority model.

That distinction becomes expensive as the stack grows.

The hotel does not need one source of truth for everything.

“One system to rule them all” is not the answer either.

A specialist system can legitimately own a specialist domain.

The practical goal is one clear authority for each important type of state.

A simplified hotel or accommodation map might look like this:

| State | Authority question | |---|---| | Property and unit identity | Where is the canonical property, room, unit and unit-type structure maintained? | | Availability | Which system can finally say whether inventory is sellable? | | Reservation | Which record is authoritative when booking state changes? | | Rate and restrictions | Which system is allowed to publish the current selling decision? | | Guest payment | Which system owns the commercial payment state, even if a payment processor moves the money? | | Security deposit | Where are hold, expiry, release, capture and exception states governed? | | Guest profile and consent | Which record owns identity, permission and communication preference? | | Housekeeping and maintenance | Which workflow owns the operational job without silently changing reservation truth? | | Owner statement | Which ledger and policy definitions produce the number shown to the owner? |

The answer does not have to be the PMS in every row.

It does have to be explicit.

A channel manager is usually a pipe, not the property truth.

This distinction is easy to blur because the channel manager is extremely important.

It may publish rates, availability and restrictions to many channels. It may receive bookings, modifications and cancellations. It may hold mappings between room types and external channels.

That does not automatically make it the system that should own the property's reservation and inventory truth.

A useful boundary is:

The property system owns the operating state. The distribution layer moves that state to and from external channels.

That boundary matters because external distribution is a message problem and property operations is a state problem.

If a channel booking arrives, the dangerous moment is not when the webhook is received. It is when the platform tells the channel “accepted” before the booking is durably stored and understood internally.

If a rate publish fails, the dangerous response is not an ugly error. It is silently assuming the channel now agrees with the property system.

The infrastructure can be bought. The authority and reconciliation rules cannot be vague.

Sync is not reconciliation.

Another common mistake is assuming that because a system sends updates regularly, drift will take care of itself.

It will not.

Sync asks:

Did we send the latest state?

Reconciliation asks:

Does the other system now hold the state we believe it holds?

Those are different controls.

A reliable integration needs both.

For example, a rate publish can return success while one mapped rate plan is wrong. A booking can arrive twice. A reservation modification can be processed before the original event is visible to another worker. A channel mapping can change after a successful prior publish.

The platform needs a way to compare important states, surface drift and let an operator resolve the exception without inventing a new truth on the fly.

This is less exciting than an integration demo.

It is much closer to the work that prevents oversells, missing bookings and wrong money.

One writer matters most when money or inventory can move.

Hotels frequently create accidental two-writer systems.

The RMS can publish rates. The PMS can publish rates. The channel manager can hold manual overrides. Someone updates an OTA extranet because a promotion is urgent.

Nothing breaks immediately, which makes the setup feel flexible.

Then nobody knows why the guest saw the rate they saw.

The same risk appears with inventory, cancellation status, deposits and owner accounting.

A useful rule is:

For any state capable of creating a booking, moving money or changing a contractual obligation, one authority should be identifiable at execution time.

Other systems can recommend, display, cache or transmit the state.

They should not silently become a second writer.

Migration should change authority deliberately, not gradually by accident.

A PMS replacement is particularly risky because the operation cannot simply stop taking bookings while the team decides which database it trusts.

A controlled migration needs an authority cutover, not only a data import.

That means defining:

1. What system owns each state before cutover.
2. What data is migrated and what remains historical.
3. What reservations and balances are reconciled before the switch.
4. When the old writer loses authority.
5. When the new writer gains authority.
6. How distribution is republished from the new source.
7. What conditions trigger rollback.
8. How drift is checked during the parallel window.

If both systems remain informally authoritative “for a while,” the migration is not safer. It is simply harder to diagnose.

The website should not become a shadow PMS.

This matters directly to hotel and holiday-home websites.

A direct-booking site needs property content, rooms or units, prices, availability, restrictions and booking state.

The quickest technical implementation is often to copy enough of that data into the website and keep going.

The commercial risk appears later.

A property name changes in the PMS but not the website. A unit is blocked operationally but the copied calendar is stale. A tax rule changes but checkout still uses the old logic. A reservation succeeds on the front end and fails behind it.

The direct channel should be fast and commercially owned. It should not invent a second property truth to achieve that.

This is why the Hospitality Website Conversion Brief asks which system owns each important field before design or integration starts.

The same rule applies to AI and automation.

An AI assistant can explain a reservation state.

It should not become the reservation state.

A commercial model can recommend a rate.

It should not publish unless it is the configured authority or an authorised person approves the action.

A workflow can suggest that a deposit should be captured.

It should not move money because a text model sounded confident.

The more capable the automation becomes, the more important the underlying authority model becomes.

Good automation makes ownership visible. Bad automation makes conflicting ownership happen faster.

How this informs Katalyst Stay

Katalyst Stay is the property management and operations platform for hotels and holiday homes. The useful starting point is the work your team needs to do and which existing systems it depends on.

Explore room preparation, cleaning handovers and inspection in the product walkthrough. A tailored demonstration connects that conversation to your own systems and implementation scope.

We review the current setup, agree responsibilities and demonstrate the relevant experience before proposing a rollout. Explore the Katalyst Stay product page for the product story and a focused demo.

Five questions to ask before approving another integration

Before connecting another hospitality system, ask:

1. What exact state does this system need to read?
2. What exact state is it allowed to write?
3. Which system wins if the two disagree?
4. How will we know if delivery succeeded but the states still drifted?
5. Who can resolve the exception without editing production data blindly?

If those answers are clear, the API discussion becomes much easier.

If they are not clear, another integration can make the stack more connected and the operation less controlled at the same time.

That is usually the expensive version of progress.

For the wider decision framework, read Hospitality systems fail at the decision, not the software and use the free Hospitality Systems Decision Map.