Budget Season Has a Way of Exposing Your Data Problems

We're deep into budgets, and before we start questioning next year's numbers, it's worth asking whether we trust the history we're comparing them to.

Say you're reviewing the 2027 budget against 2026 actuals and forecast. Housekeeping labor looks high. Parking revenue looks low. Breakfast CPOR is nowhere near last year. The instinct is to ask what the hotel is doing differently.

Sometimes the answer is nothing. Something is coded differently, an account isn't mapped right, or the report isn't pulling what we think it is. Before we ask a GM to defend their budget, we should make sure the comparison holds up.

Operating issue or data issue?

Housekeeping labor is up. That deserves a conversation, but "labor is up" doesn't tell us what happened.

Did wage rates go up? Did we lean on more contract labor? Did productivity slip? Are we comparing the same positions and hours in both years? Did an expense move between departments?

Each of those has a different answer and leads to a different budget decision. Wage rates mean we build it in. Productivity means we figure out why and what's realistic. Miscoded contract labor means we fix the comparison before calling it an increase.

Revenue works the same way. Parking looks low, so we ask about pricing and capture. Fair questions. But first "” is all the parking revenue actually landing on the parking line?

I don't want to solve a coding problem with an operating plan. I also don't want to wave off a real operating problem because we assumed it was coding. You have to get into the detail far enough to know which one you're looking at.

A report can tie and still be wrong

This is the most important point here.

Tying to the GL is necessary. It doesn't mean everything is classified correctly. A parking charge posting to miscellaneous income leaves total revenue untouched. An expense moving between departments leaves hotel profit untouched. The totals look fine while the individual lines say something completely different.

That matters because those lines become budget assumptions. We use revenue per occupied room for parking and destination fees, cost per occupied room for supplies and breakfast, and minutes per occupied room for housekeeping productivity. If the dollars, hours, or occupied rooms feeding those metrics are off, the metric still looks reasonable and points us the wrong way.

A real example: restaurant food cost was running 10% high all year. Meanwhile comp breakfast CPOR was coming in at $2 POR "” suspiciously low for anyone who's actually bought eggs and coffee for 80 guests. Some of the breakfast food cost was posting to the restaurant instead of the comp breakfast department. A GL mapping issue. Both lines were wrong in opposite directions, and the total was close enough that it passed every month-end review.

Across a portfolio, consistency matters just as much. If one hotel books a cost in housekeeping and another books it elsewhere, their housekeeping CPOR isn't a clean comparison. We end up questioning the hotel with the more complete reporting instead of the one that actually needs attention.

Something usually changed and the reporting didn't follow

When I dig into these, my first question is what changed and when. A PMS conversion, a new transaction code, a payroll department change, a new outlet, a new GL account. The timing of the variance usually points you to the starting place.

A new charge can be set up correctly for the front desk and never get mapped all the way through accounting and reporting. The guest is charged, payment is collected, and the transaction lands somewhere. "Somewhere" isn't good enough when we're trying to measure a specific revenue stream.

Labor needs the same scrutiny. We need to know where actual payroll dollars and hours originate, how they're assigned to departments and positions, and how they reach the reporting platform. A scheduling change doesn't tell us how actual payroll will post.

Then there's the reporting layer. An account can be right in the GL and still be missing from a report grouping or sitting on the wrong line. Reclassifying an account in one system doesn't mean every downstream report knows what to do with it.

So the useful question isn't "is the integration working?" It's "can we follow this transaction from source system to GL to report, and does it end up where we expect?" That's a much better test than confirming a file came through.

We may need a budget adjustment. We still need a fix.

Sometimes we find these issues mid-review with no time to clean up every affected period before the budget is due. That's reality, and a documented adjustment may be necessary to keep things moving.

But adjusting the baseline and fixing the underlying issue are two separate tasks. Doing the first doesn't complete the second.

"Parking looks off" isn't documentation anyone can act on. We need what's wrong, when it started, which accounts and reports are affected, and the impact. We also need an owner and a way to confirm the fix worked.

A useful note looks like this: a parking transaction code has been posting to miscellaneous income since the PMS conversion. The revenue is in total revenue but missing from the parking line. We need to quantify the affected period, correct the mapping, and have Accounting decide how to handle the historical amounts. Now someone can actually work it, and we know why reported history differs from the baseline we're using.

Reported actuals and the budget adjustment should stay separate. We should be able to explain the starting number, the adjustment, and the reason without reconstructing a conversation three months later. And once the fix is in "” check the next import or payroll posting and confirm it in the final report. A changed setting isn't a resolved issue.

Use what we find to make the rest of the year easier

Budget season shouldn't be the only time we check this, but it's a good chance to look at the business differently. At monthly close, we're focused on getting the month right and explaining it. During budgets, we're asking whether those results are a reasonable basis for next year. That wider view exposes inconsistencies we haven't fully worked through.

What matters is what we do with them. Found an unmapped transaction code? Ask how new codes get reviewed. A payroll change caused inconsistent departmental reporting? Build a validation step into that process. A GL account got left out of a consolidated report? Check how new accounts get added to the reporting structure. Otherwise we're fixing individual errors and leaving the process that created them alone.

This is why I spend time on systems and reporting. It's not separate from the finance work. It's what lets us talk about the numbers instead of spending the meeting debating whether they're right.

We should absolutely challenge wage assumptions, staffing levels, revenue expectations, and expense growth. That's the job. We just need a reliable starting point.

The goal isn't to explain the same discrepancy a little better every month. Fix it, confirm it's fixed, and use the next meeting to talk about how to run the hotel better.

---