Five systems that disagree: the operator's case for a single source of truth

Picture the COO on a Tuesday, owner review in two days, asking a question that should take ten seconds to answer. What did F&B actually do last month. Simple. The PMS gives one number. The catering system gives a different one. The POS gives a third. Finance, working off the accounting export, gives a fourth, and it is the only one anyone is allowed to put in front of an owner. Four answers to one question, and the person who owns the entire P&L cannot tell you which is right without an hour of reconciliation and two phone calls.

This is not a back-office problem. It is the central operating problem of running a hotel in 2026, and almost nobody names it correctly. The COO does not have a reporting problem. The COO has five systems that each tell the truth, in their own language, about their own slice of the building, and no place where those truths are forced to agree. That is the whole thing. Every dashboard that died, every flash report that lied, every owner meeting that turned into a forensic exercise traces back to this one root.

This post is the foundation for everything else we write. It defines the problem the way an operator feels it, names what it costs, and lays out the model we use to fix it. The other pieces in this library are instances of this one.

Why five systems give five answers

Start with the systems. A full-service hotel runs the business on at least five that matter, and each one was built to do a different job well.

The PMS (Opera, OnQ, Maestro) owns the guest and the room. It knows who is in house, what they paid for the room, and what posted to the folio. It is the system of record for occupancy and rooms revenue, and it is excellent at that. It is also where a banquet charge sometimes posts and sometimes does not, depending on how the property routes it.

The RMS owns the forecast and the rate. It knows demand, pace, and pricing for rooms. It does not know catering, it does not know food cost, and it does not pretend to. It answers one question, rooms, and answers it well.

The sales-and-catering system (Tripleseat, Delphi, Amadeus) owns the event pipeline. It knows what is booked, what is tentative, the contracted head count, and what the banquet event order says the client agreed to pay. It is the only system that knows future catering revenue. It is also a CRM the sales team treats as a sales tool, not a finance tool, so its revenue is an estimate until the event happens.

The POS (Toast) owns the transaction. It knows what was rung, in which outlet, at which price. It is the truth about what walked through the restaurant and the bar. It does not know contracted catering, it does not know the folio, and its idea of a “cover” is whatever got rung as a seat.

The labor system owns the schedule and the clock. It knows hours, wages, and who worked. It is the truth about cost, and it almost never lines up cleanly with the revenue periods the other four use.

Here is the part operators miss. None of these systems is wrong. Each holds a true piece. The PMS is right about the room. The POS is right about the check. The catering system is right about the contract. They disagree because they answer slightly different questions, on slightly different calendars, with slightly different definitions of the same word. A “cover” is a seat in Toast, a contracted head in Tripleseat, and an entree in the chef’s count. None of them is lying. They were never built to reconcile, so they never do.

Why they never reconcile on their own

You might think this resolves itself over time. It does not, and the reason is structural.

Each system has its own owner, its own update cadence, and its own definition dictionary, and all three drift independently. The revenue manager retrains the forecast. The catering team adds a market segment. The chef rebuilds the bar menu in the POS. Finance changes how a banquet charge routes through the folio. Every one of those is a correct local decision that quietly moves a number some other team reads. Nobody tells the other systems, because there is no mechanism that would. The drift is not a bug. It is the natural state of five systems maintained by five teams with no shared contract between them. We wrote about one face of this in the five PMS fields nobody trusts; the same rot lives in every system you own.

So the gaps do not close. They are reconciled by hand, by a person, every single month. That person is usually in finance, and what they produce is the one blessed version of last month that goes to the owner. It is correct. It is also forty-five days old by the time it lands, and it lives nowhere except a workbook on one analyst’s machine. The operating decisions got made weeks earlier, off the unreconciled numbers, because that is all anyone had in time to act.

What it actually costs

This is where it stops being an IT annoyance and becomes a P&L problem. Four costs, all real, none of them on any invoice.

You make decisions on the wrong number. The reconciled truth arrives after the month is closed. Every yield call, every labor cut, every catering hold decision in the live month gets made off a single system that only knows its own slice. You priced a soft week off rooms pace and never saw the catering pipeline that would have filled it. The decision was not wrong because the operator was careless. It was wrong because the right number did not exist yet.

You pay the reconciliation tax. Add up the hours. The analyst rebuilding the F&B number every month. The catering manager exporting Tripleseat to tie out to accounting. The controller’s two-day close that is really a two-week argument. This is a standing tax on skilled people, paid monthly, forever, and it buys you nothing except trusting last month’s number forty-five days late.

Your close is slow, and slow close means slow decisions. A month-end that takes two weeks to reconcile leaves the operator half a quarter behind reality at all times. By the time you can see clearly what April did, you are deep into May with June’s decisions already on the table.

Trust erodes, and that is the expensive one. The first time the dashboard number and the board number disagree in front of an owner, the operator stops trusting the dashboard. Then the team does. Then everyone routes back to their own spreadsheet, and you are running a portfolio on private workbooks only their authors understand. This is exactly how dashboards die inside ninety days and why the flash report lies. Both are symptoms. The disease is five systems that disagree.

The Operator Intelligence model

Here is the fix, and here is the part the rest of this library is built on. The answer is not a sixth system. It is not ripping out the five you have. The answer is a model with three parts, and every engagement we run is some combination of them.

One: a single connected source of truth. Not one system to rule them all. One layer that reads from all five, holds the agreed definition of every number once, and reconciles continuously instead of monthly. The PMS keeps owning the room. The POS keeps owning the check. Tripleseat keeps owning the pipeline. You connect them rather than replace them, and you define “cover” and “F&B revenue” exactly once, in a place every report inherits from. The five systems still disagree at the source. They just stop disagreeing in front of the operator.

Two: an operator-intelligence layer that reads the way an operator already thinks. A reconciled data warehouse is not the deliverable. A COO does not think in tables. A COO thinks in questions: is this period ahead or behind, where is the money leaking, what do I do about it this week. The intelligence layer sits on top of the connected source and answers in that language, so the operator reads the number the way they would read a pace curve, not the way an analyst reads a query result. This is the difference between what a COO actually needs on one screen and a wall of tiles nobody owns.

Three: an operating cadence that makes it a daily habit. A reconciled truth that nobody opens is worth nothing. The number has to live in the Monday meeting, owned by a named person, read every week, the same way rooms pace already is. The cadence keeps the whole thing alive past ninety days. It is also the part that fails most, because it is a habit problem, not a data problem.

Those three parts are the Operator Intelligence model. One connected source of truth, an intelligence layer that thinks like an operator, and a cadence that makes it a habit. Everything else we write is one of them in detail.

How to start: the playbook

You do not boil the ocean. You start with one number and earn the next.

Step 1. Pick the one number that matters

Not the data lake. One number the operator already fights about every month. F&B revenue is usually the right first target, because it pulls from the most systems and disagrees the loudest. Pick the question that wastes the most reconciliation hours and starts the most owner-meeting arguments. That is your wedge.

Step 2. Map which system owns each input

Trace every input to the system that is the real source of truth for it. Rooms revenue lives in the PMS. Outlet revenue lives in the POS. Catering revenue lives in the sales-and-catering system until the event happens, then in the folio and the accounting export. Labor lives in the labor system. Write down, for every input, the single system that owns it. Most properties have never done this on paper, and the act of doing it surfaces three disagreements you did not know you had.

Step 3. Define the number once, in plain English

Before any code, write the definition a DOSM or a controller could read. What counts as a cover. Whether banquet F&B includes service charge. Which calendar the period runs on. Get the controller, the F&B director, and the catering office to agree to it in one room. This is the hardest step and the one everyone skips. The definition is the contract. Skip it and you have automated a disagreement instead of resolving it. This is the same discipline as redesigning the workflow before you automate it.

Step 4. Connect, do not rip and replace

Pull the agreed inputs from each owning system into one place on a schedule. The systems stay exactly where they are, doing exactly what they do well. You are not migrating Toast or replacing Opera. You are reading from them into a layer that reconciles to the definition you just wrote. This is the build-versus-buy decision most operators get backwards: you rarely need to buy a new system, you need to connect the ones you already pay for.

Step 5. Make it the operating cadence

Put the one reconciled number on the screen in the Monday meeting, owned by a named human, read every week. When it survives a month of being read out loud and matching the close, add the next number. The single source of truth grows one defensible number at a time, and each one earns its place by being trusted in the room.

The data is already in the building

Here is the honest part, the same one true of almost every reporting gap we see. Nothing in this playbook requires new software. The F&B revenue is already in the PMS, the POS, and the catering system. The labor is in the labor system. The actuals are in the accounting export. You already pay for every system that holds a piece of the answer.

The reason you do not have one number is that those systems were never made to agree, and no person can hold the reconciliation in their head fast enough to act on the live month. That is not a buying problem. It is a connection problem, a definition problem, and a habit problem, which is exactly the three parts of the model above.

You can do this yourself. Pick the one number, map the owners, define it once, connect rather than replace, and make it the cadence. Some teams should run it exactly that way and never call anyone. If you would rather the one number just existed, stayed current, and matched the close without an analyst rebuilding it every month, that is the thing we build. Either way, stop running the building on five systems that disagree. You own the whole P&L. You should only have to ask the question once.