Hotel PMS Contracts and the Clauses That Bite

The demo decides which system you like. The contract decides what the next five years actually cost you. Term length, the notice window before the agreement renews itself, how far the price can rise, who owns the data and what format it comes back in if you leave: none of that appears in a product walkthrough, and all of it is in the document somebody emails you at the end of the process with a request to sign by month end. A PMS system is chosen in a few weeks and lived with for years, which makes the paperwork a bigger operational decision than the feature comparison that got you there.

This is not legal advice and it is not a template. It is the set of clauses that reliably cause problems in hotels, written from the buyer's side: what each one does, what a reasonable version looks like, and which ones a vendor will move on if you ask. Some cost nothing to fix at signature and are close to impossible to fix afterwards. Others quietly change the monthly number you budgeted, such as whether the channel manager sits inside the licence or is billed as a separate module once you connect your third distribution partner.

The order below follows the order things go wrong. Renewal traps first, because they are the most common and the most avoidable. Then pricing mechanics, licensing, data rights, service levels, fees, integrations, payments and exit. A pre-signature checklist is at the end for anyone who wants the short version. If you are earlier in the process and still comparing products, how to run a hotel PMS demo comes first.

Why the Contract Outlives the Demo

Software selection in hotels tends to be front-loaded. Weeks go into shortlists, demos, reference calls and a feature comparison of cloud PMS systems, and then the commercial terms arrive at the point when everyone is tired and the decision feels made. The contract gets a quick read, the obvious numbers are checked, and it is signed.

The asymmetry is worth stating plainly. The vendor has written this document many times and has seen every objection to it. You are reading it once, under time pressure, with no comparison set. That does not make the vendor adversarial, and most of the terms will be ordinary. It does mean the defaults are drafted from their side, and defaults left alone become your operating reality for years.

Consider what actually happens over a typical PMS lifespan. The person who signed leaves. The account manager who promised something verbally moves to another patch. The pricing sheet from the sales process is not part of the agreement unless it was attached as a schedule. The integration you were told was coming is still coming. What survives all of that is the document, and specifically the parts of it nobody read.

Three clauses account for most of the pain, in roughly this order: the auto-renewal and its notice window, the price increase mechanism, and the absence of a usable exit. None of them is exotic. All of them are cheap to fix before signature and expensive afterwards.

Term Length, Auto-Renewal and the Notice Window

Almost every cloud PMS agreement renews itself. That is normal and not sinister; nobody wants the reservation system switching off because a purchase order was missed. The problem is the combination of an automatic renewal with a notice window that starts long before you would naturally think about it.

Here is the shape of the trap. A three-year term ends on 31 March. The contract requires 90 days' written notice of non-renewal. That means the decision has to be taken, agreed internally and served in writing by 31 December, which in most hotels is the single worst week of the year for anything resembling strategic thought. Miss it by five days and you have committed to another full term, at whatever the renewal price turns out to be.

Read three things together, never separately.

The initial term and what it renews into. A three-year initial term that renews for successive three-year periods is a very different commitment from one that renews annually. The second is far more common in reasonable drafting and much easier to live with. If the draft renews for the full original term, ask for annual renewal periods instead. This is one of the easiest changes to win.

The notice window and the form of notice. How many days, and delivered how. Some agreements still require written notice by post or courier to a named legal address, and an email to your account manager does not count. If the clause specifies a method, follow it exactly and keep proof.

Whether the renewal price is knowable in advance. A renewal that carries over current pricing is fine. A renewal at then-current list prices means you are agreeing now to a number you will not see until later.

The practical defence takes about two minutes and costs nothing. On the day you sign, put two entries in a shared calendar that does not depend on one person still working there: the notice deadline itself, and a reminder 30 days before it. Attach the contract reference and the required notice method to both. Hotels that do this stop having renewal accidents entirely, and it is remarkable how few do it.

One more point on term length. Longer terms are routinely offered at a discount, and the discount can be genuine. Judge it against three questions. Is the price fixed for the whole term or only the first year? Is there a termination for convenience clause that gives you a real exit if things go badly? And are you confident about the parts of the platform you have not used yet? A three-year term with locked pricing and a twelve-month exit is a better deal than a one-year term that renews at list.

How the Price Goes Up

Very few contracts say the price will never change. What varies is how much control you have over the change, and there are four common mechanisms, in descending order of how comfortable they should make you.

Index-linked clauses deserve a closer look than they usually get, because the wording tends to be short and the effect is not. Check whether the index is named specifically, whether it is the index for your country or the vendor's, and whether the clause is symmetrical. An index can fall as well as rise, and a clause that only ever moves upward is a one-way ratchet dressed as a neutral formula. Also check whether the indexed increase is in addition to a discretionary uplift elsewhere in the document, which happens more often than you would expect.

Then look for the increases that are not called increases. A discount described as introductory, promotional or first-year expires by design, and the step up when it does is frequently larger than any annual uplift. Modelling that properly is the point of a full hotel PMS total cost of ownership exercise rather than a comparison of monthly rates. Ask directly what the fee will be in year two and year three, in writing, and have the answer attached to the agreement rather than left in an email thread.

Growth-based increases are the third category and the one that surprises hotels that are doing well. If the fee is per room and you convert a store cupboard into two rooms, the fee moves. If it is per user and you hire seasonal staff, it moves. That is not unfair, but it should be predictable, which means understanding the counting unit before you sign rather than discovering it on an invoice.

What You Are Actually Licensing

The single most common source of unexpected cost is not the headline rate. It is a mismatch between what the buyer assumed was included and what the contract actually grants.

The Counting Unit

Per room, per user, per property, per booking or a flat platform fee: each behaves differently as you grow, and each has an edge case worth pinning down before signature.

Per room is the most common in hotel software and the easiest to budget. The questions to ask are which rooms count, whether rooms taken out of service for refurbishment still count, and whether the number is fixed at signature or recalculated periodically. A property closing a floor for three months should not be paying for it, and many agreements will accommodate that if asked.

Per user needs a definition. Named users, where each individual has a licence, is very different from concurrent users, where a pool of licences is shared. In a hotel with three shifts and a lot of part-time cover, named-user pricing can cost several times what concurrent pricing would, and the practical consequence is worse than the money: staff start sharing logins, which destroys any audit trail and creates a genuine security problem. If the pricing model pushes your team toward shared accounts, the pricing model is wrong for a hotel.

Where the Modules Stop

Modern platforms are sold as suites and licensed as components. The demo shows one continuous product. The order form lists modules, and the boundaries between them are where budgets break.

Go through the order form line by line against what you saw and ask, for each capability you are counting on, whether it is inside the licence, an extra module, an extra fee per transaction, or a professional services engagement. The ones that most often turn out to be separate are advanced or custom reporting, the booking engine, the channel manager beyond a small number of connections, revenue management, housekeeping mobile apps, guest messaging, API access, and any form of accounting integration. None of that is unusual. It only becomes a problem when it is assumed rather than confirmed.

Two follow-ups are worth asking in the same breath. Are there limits inside the modules you are buying, such as a cap on API calls, emails, SMS messages or stored documents, and what happens when you exceed them? And is there a fair use clause, which is a limit without a number attached, and therefore a limit whose meaning is decided later by the vendor?

Who Owns the Data

Your PMS holds the operational history of the business: guest records, reservations, rates, folios, tax records, correspondence. Who owns it, and what the vendor may do with it, deserves an explicit clause rather than an assumption.

A well-drafted agreement says the hotel owns its data and grants the vendor a limited licence to process it for the purpose of providing the service. Anything materially weaker than that is worth a conversation. Watch for three patterns in particular.

Silence. If ownership is not addressed at all, you are relying on general law and the rest of the agreement to imply it. Ask for an explicit statement; a vendor with nothing to hide will not object.

Broad secondary use. Clauses permitting the vendor to use your data for product improvement, benchmarking, analytics or training are common and not automatically unreasonable, particularly where the data is aggregated and de-identified. What matters is whether those words are defined, whether guest personal data is excluded, and whether you can opt out. A right to use aggregated, anonymised statistics is a different proposition from a right to use your data.

Confusing ownership with data protection. These are separate questions and both need answering. Commercial ownership is contractual. Data protection is regulatory: under GDPR the hotel is normally the controller and the vendor the processor, which requires its own data processing agreement covering purpose, sub-processors, international transfers, breach notification timelines and deletion on termination. If the vendor cannot produce a DPA on request, that tells you something about how much of this they have thought about.

Two smaller points that come up in practice. Ask where the data is physically hosted, because the answer has both regulatory and latency consequences. And ask what the backup regime is, specifically the recovery point objective and recovery time objective, which are the two numbers that describe how much data you could lose and how long you would be down. Those numbers belong in the agreement, not in a reassuring sentence on a website.

Getting Your Data Out

This is the clause that nobody negotiates and everybody eventually needs. It is also the one where the gap between what a contract promises and what is operationally useful is widest.

Almost every agreement grants some right to export data on termination. The right is close to worthless unless four things are specified: what is included, in what format, within what timeframe, and at what cost. Anyone who has run a PMS migration knows which of those four tends to be discovered late. A commitment to provide data on request, with no further detail, allows a vendor to satisfy it with a set of PDFs delivered in ninety days for a fee quoted at the time.

What a Complete Export Contains

The distinction that matters is between the records you can see in a report and the structure that makes them usable. Migration projects run aground on the second, not the first.

The retention side is the mirror image and matters just as much. How long does the vendor keep your data after termination, and what is the deletion process? You want enough time to be sure the migration is complete, and then genuine deletion with confirmation. Indefinite retention of guest personal data by a supplier you no longer use is a liability sitting on someone else's server.

One practical test is worth more than any amount of clause-reading. Ask, during the sales process, for a sample export from a demonstration property in the format you would receive on exit. A vendor confident in their export will send it. A long pause is itself an answer.

The Service Level Agreement

A PMS that is down stops check-ins, checkouts and rate updates simultaneously. The SLA is where the vendor states what availability they commit to and what happens when they miss it.

Start with the number, but do not stop there, because uptime percentages compress very large differences into very similar-looking figures.

On a slide, 99.9% and 99% look like neighbours. In practice one is under an hour a month and the other is the better part of a working day. If a commitment is offered without a percentage, or with a percentage but no measurement method, treat the whole clause as decorative.

Then read the definitions and exclusions, which is where most of the value of an SLA is decided.

What counts as downtime. Total unavailability only, or degraded performance too? A system that takes forty seconds to load a folio is not down by most definitions and is unusable in practice at a busy desk.

What is excluded. Scheduled maintenance almost always is, so check how much notice you get and whether it can land on a Friday evening in August. Third-party failures, your own connectivity and force majeure are also standard exclusions. A long exclusion list can hollow out a strong-looking percentage.

How it is measured and who measures it. Usually the vendor's own monitoring. That is normal, but ask whether you can see the status history and whether past incidents are published.

What the remedy is. Nearly always a service credit, usually a percentage of the monthly fee, often capped and frequently requiring you to claim it in writing within a short window. Understand that credits are symbolic rather than compensatory: a few percent of one month's fee does not cover a Saturday of manual check-ins. Their real function is as a signal of how seriously the vendor takes availability, and as a trigger, because repeated credits should feed into a termination right.

That link is the clause most worth adding if it is missing. Ask that a defined pattern of SLA failure, for example three consecutive months below target, gives you the right to terminate without penalty. It changes the incentive in a way that a small credit never will.

Support Scope and Response Times

Support is sold as a feeling and delivered as a schedule. The gap between twenty-four seven support and twenty-four seven support for critical issues only, with everything else answered within two business days, is enormous, and both are described the same way on a website.

Four things need to be explicit. The hours, in a named time zone, including whether weekends and public holidays are covered, which matters because hotels are busiest precisely when offices are shut. The channels, since phone support for a system-down event is a different service from a ticket queue. The severity definitions, meaning who decides that an issue is critical and what the response time is for each level. And the difference between response and resolution, because a commitment to respond within an hour is a commitment to reply, not to fix.

Ask what is out of scope as well. Configuration changes, report building, training for new staff, and help with third-party integrations are commonly chargeable professional services rather than support. That is reasonable, but you want the day rate in the contract rather than discovered when you need it. Also ask whether support is included in the licence or sold as a percentage of it, and whether the premium tier the salesperson described is the tier on your order form.

Implementation, Migration and Training Fees

The recurring fee gets negotiated. The one-off fees often do not, and in year one they can rival the subscription.

Build a complete inventory before you commit, and insist that anything quoted is fixed rather than estimated. An estimate is a number that grows. The usual list runs to setup and configuration, data migration from the previous system, interface or integration setup for each connected product, training, on-site attendance if any, and go-live support, which is sometimes charged separately from ordinary support.

Data migration deserves particular attention because it is the line most likely to be quoted vaguely and to expand. Establish what the vendor will actually do rather than what they will accept. Will they take an export from your current system and load it, or do they expect a template you populate? Which entities are covered: guests, future reservations, historical stays, folio detail, rate structures? How many rounds of validation are included before extra days start being billed? And what happens if the data arrives dirty, which it will, because it always does.

Get the training model in writing too. Train-the-trainer, where the vendor trains two of your managers who then train everyone else, is cheaper and puts the burden on you. Full-team training is more expensive and more effective. Both work. Discovering which one you bought during go-live week does not.

Finally, ask what happens to these fees if the project stalls for reasons on their side, and whether any part of the implementation fee is refundable if go-live never happens. It is an uncomfortable question and the answer is informative.

Integrations, APIs and Third-Party Charges

No PMS runs alone. It talks to a channel manager, a booking engine, a payment provider, a door lock system, an accounting package and probably several more. How that estate fits together is its own subject, covered in hotel PMS integrations and open APIs. The contract needs to say something honest about that, because integration is where multi-vendor blame becomes an operational problem.

Ask which integrations are certified and live today, rather than possible or planned. There is a meaningful difference between a partner listed on a website and a connection that a named hotel is running in production right now. Ask for that hotel. A reference call with a property using your exact combination is worth more than any part of the feature matrix.

Then establish who pays for what. Some vendors charge a per-integration fee, some charge the partner instead, and some charge both sides. Some charge for API access as a separate module, and a few meter it by call volume, which turns an architectural decision into a monthly variable cost. If you plan to build anything yourself, or to use a consultant who will, get API access terms and any rate limits in writing before signature rather than after.

Two forward-looking questions are worth asking while the deal is still open. What happens if the vendor discontinues an integration you depend on, and is there any notice commitment attached? And if a connection breaks between two suppliers, who owns the incident? The honest answer is usually that neither party owns it and you will be relaying messages between two support desks, which is exactly why it is worth asking now.

When the Contract Bundles Payments

Many platforms now bundle card processing, and the economics of that deserve separating from the software decision. It can be genuinely good: one reconciliation, one support path, fewer integration failures. It can also lock two decisions together that have very different lifespans.

Read the processing terms as though they were a separate contract, because commercially they are. What is the rate, and is it interchange-plus or a blended rate that hides the components? What are the chargeback fees? What is the settlement timing, which is a cashflow question rather than a cost question? Is there a minimum monthly volume or fee? And, most importantly, is use of the bundled processor mandatory, or may you keep your acquirer?

The clause to look for specifically is whether the software pricing is conditional on the payments arrangement. If the subscription discount evaporates when you move processing elsewhere, then the two are one contract and should be evaluated as one. That is not a reason to walk away, but it is a reason to model the total properly. Where the platform also handles card data, confirm the PCI DSS compliance scope and who is responsible for what, and get the vendor's current attestation of compliance rather than a general assurance.

Termination, Cure Periods and Suspension

Three separate rights hide under this heading, and buyers routinely assume they have all three when the draft grants one.

Termination for cause lets you exit if the vendor breaches the agreement and fails to fix it within a cure period, typically 30 days. This exists in nearly every contract. It is also hard to invoke: you must show a breach of a specific obligation, which is why vague service commitments are worth so little. If the SLA is the only performance obligation and it excludes most real-world failure modes, termination for cause is close to theoretical.

Termination for convenience lets you leave because you want to, on notice. This is the clause that gives you actual freedom, and it is frequently absent from a first draft. Ask for it. A vendor may reasonably want a notice period, or for it to apply only after an initial term, or for unamortised implementation costs to be repaid. Those are negotiable positions. No exit at all is a worse one.

Suspension for non-payment runs the other way and is worth reading closely. Most agreements let the vendor suspend service if an invoice goes unpaid. That is fair in principle, but an accounting error should not close your front desk. Ask for a notice requirement and a grace period before suspension, and for suspension to require notice to a named finance contact rather than whichever address is on file.

One thing to check across all three: what happens to your data during a dispute. A suspension that also cuts off data access converts a billing disagreement into an operational emergency, and the resulting imbalance in negotiating power is precisely why the clause is written that way. Access to your own records should survive a payment dispute.

What Is Actually Negotiable

Small independent hotels often assume they have no room to negotiate. That is mostly wrong. The subscription rate is frequently the least flexible thing in the document, and almost everything around it moves, particularly before quarter end and particularly if you are a reference-able property in a segment the vendor wants.

In rough order of how readily they tend to move: the notice window, the renewal period, a cap on annual increases, implementation and training fees, a pilot or extended trial period, payment timing, and the addition of a termination for convenience clause. Headline pricing usually moves last and least.

Four things make a negotiation go better. Ask early, before the end of the quarter rather than during the final week, when you are still a prospect rather than a signature. Ask for a small number of specific changes rather than a general request for better terms, because a list of four redlines gets answered and a request to improve the deal gets a discount offered instead. Put every verbal assurance into the document or an attached schedule, since a promise about a forthcoming feature that lives only in an email is not a contractual commitment. And be willing to accept a reasonable no, because a vendor who explains why they cannot change a clause is usually telling you something true about how they operate.

If your property is part of a group, or you are buying alongside other properties, say so. Multi-property PMS terms are a different pricing conversation, and the same is true if you can offer a case study or act as a reference.

A Pre-Signature Checklist

Take an hour with the draft and a highlighter before anyone signs anything. The questions below are the ones that most often turn out to matter later.

Term and renewal. When does the initial term end, what does it renew into, how much notice is required, and in what form? Is the notice deadline in a shared calendar with a reminder before it?

Price. Is the fee fixed for the term? If it can rise, is there a stated cap? What is the price in year two and year three in writing? Is any discount time-limited?

Licence. What is the counting unit, and what happens as you grow or take rooms out of service? Which modules are included, and which capabilities you are relying on are not?

Data. Do you own it explicitly? What may the vendor do with it? Is there a data processing agreement? Where is it hosted, and what are the backup objectives?

Exit. What exactly do you get on termination, in what format, in what timeframe, at what cost? Is there read-only access afterwards, and when is your data deleted?

Service. What is the uptime commitment and what is excluded from it? What are the support hours, channels and severity definitions? Does repeated failure give you a termination right?

Money beyond the subscription. What are the one-off fees, are they fixed, and what is the day rate for anything out of scope?

Getting out. Is there a termination for convenience clause? What notice does it require? Can the vendor suspend service, and with what warning?

None of this requires a lawyer for a small property, though a solicitor's hour on a multi-year commitment is money well spent and cheaper than most people assume. What it requires is that somebody reads the document with the operation in mind rather than the excitement of a new system, and asks the questions while the answers can still change something.

The pattern worth remembering is simple. Everything in a software contract that will hurt you later is cheap to fix now and expensive to fix once signed. A notice window is a sentence today and a lost year in three years' time. An export clause is a paragraph today and a migration project that cannot start in five. The hour spent before signature is the highest-return hour in the entire selection process, and it is the one almost nobody books.