Insights · Reporting

Why hotel groups want one version of the truth — and still don't buy it

By the YMME team·8 min read·September 2026

Every owner of more than two hotels has said it in some form: “I want one number I can trust.” The reporting project still gets pushed to the next budget, and then the one after that. The want has not gone away. The meeting just keeps ending on three questions that nobody at the table can answer with confidence.

Quick answer. Groups postpone reporting because they cannot check three things before they commit: whether the product runs in production or only in a slide deck; whether it will read the systems the group has, with mixed PMS versions, several tills and inherited accounting; and whether it still works when a vendor refuses to provide an interface. Each of the three can be checked in a single demo if you know what to ask for.

The objection is never the one on the slide

The polite reasons are always available. Price. “We are waiting for the PMS upgrade.” “Finance has it in Excel.” They are true enough to end the meeting and false enough that the same meeting happens again next year.

The real objection is about trust, and the distrust has been earned. The 2026 Hotel Operations Index found that only 11% of hotels run a fully integrated technology stack. A buyer who has already paid for two systems that promised a single view is not being difficult when they hesitate. What they lack is a way to test the promise before the invoice.

Does it actually exist?

A roadmap is not an answer, and neither is a demo seeded with round numbers. Ask whether the product is running today, on somebody else’s hotels, on data that arrived this morning.

There is a simple way to tell. Ask to see the parts of the product that only exist after it has been through real data: a source-status screen that shows when each feed last arrived; a journal of what was sent to whom and when; a list of screens switched off for a particular group because that group does not keep the data behind them. A product that has never been deployed has none of these. None of them are needed until the first real hotel breaks the first assumption.

A vendor who can show you which screens are dark is showing you a system that has been used.

Will it read the group I have?

No group runs one PMS and one till. It runs whatever each hotel arrived with: two properties on different major versions of the same property system, a resort with its own restaurant platform, an accounting structure inherited with an acquisition and never quite merged, a budget that only exists in the controller’s spreadsheet.

The honest answer to “will it read all that?” is a map, not a yes. For each source: which properties draw from it, which version, how it is read, and what happens when a hotel migrates from one system to another. The migration matters more than it sounds. When a property changes PMS, the model has to record which source is authoritative before the changeover date and which after, or the history breaks at the point where the owner most wants to compare.

Ask for that map for your own properties. If the vendor cannot draw it in the demo, they will be working it out during the contract, at your expense.

What if the PMS vendor says no?

This is the objection that kills the most projects and gets discussed the least. The PMS belongs to another company with no reason to help. The till vendor has an interface, but not for your version. The accounting system exports a file once a night and will never do anything else.

Integration is not the same thing as an interface. A reporting layer built for real groups takes data however the group can give it. In production today that means eight different methods running side by side. They fall into four families:

Read the database directly. A read-only connection to the system’s own tables, where the vendor allows it. The freshest data and the fewest moving parts.
Use the vendor’s interface, whichever one works. The documented API, or the one the vendor’s own portal calls. We run two different channels to the same vendor today because the documented one turned out not to be the one that worked.
Take files. Exports from the vendor’s portal, scheduled drops onto a shared folder, a managed intake folder for the budget workbook that finance already maintains.
Parse what the hotel already prints. The night-audit statistical report exists in every hotel. It is a perfectly good source of occupancy and rate when nothing else is available.

A nightly file means yesterday’s number instead of this morning’s. You still get the number.

And the one nobody puts in the brief

Under the three questions there is a quieter worry: that a real reporting layer will show, in front of the board, which data the group does not have.

Treatment-room utilisation needs a register of rooms. Departmental profit needs agreed cost-allocation rules. Budget against actual needs a budget that somebody signed. In the fullest deployment we run, 77 views are designed; 43 are live with data, 22 are waiting on extraction work and 12 are waiting on data the customer has not yet started to keep. Those numbers are not a weakness of the product. They are what an honest reading of the group looks like.

The vendor you want tells you before the contract which screens will stay dark, and why. The one who promises everything is the first one the finance director stops believing.

What to ask in the next demo

Show me the source-status screen for a live group. Show me the send journal. Draw the source map for my properties, including the one that changes PMS next year. Tell me which of your integration methods you would use for each system I run, and which of my screens will be dark on day one.

If they need a paid workshop before they can answer any of that, you are buying a project, not a product.

Where YMME fits. YMME Score is the reporting and intelligence layer of the YMME platform. It runs in production on several groups in different configurations: six families of screens, role-based access, scheduled delivery to phone and inbox, a monitor on every source. It reads our own products and other vendors’ systems alike, which is the principle the whole platform is built on. If you want to run the three questions against it, ask us for the map.