What a group-level P&L looks like for a hospitality group

Running one hospitality site is hard. Running five is a different problem. The operational complexity multiplies, but more importantly, the information problem multiplies: you now need to know what is happening across five kitchens, five sets of stock, five cash-ups, and five GP figures, and you need to know it in time to do something about it.

Most multi-site operators deal with this by asking each GM to send a weekly spreadsheet. The spreadsheets arrive on different days, in slightly different formats, with figures that reflect different assumptions about what gets included and what does not. The structural fix for this is consolidating reporting at source rather than reconciling it afterwards. The group finance team spends half a day reformatting and reconciling before they have anything that looks like a consolidated picture. By the time it is ready, the week it describes is already three days in the past.

This is how most hospitality groups actually manage their estate. It works, after a fashion. It is also consistently late, frequently inaccurate in small ways that compound into larger ones, and entirely dependent on the consistency of the people producing the inputs.

What a group P&L is trying to do

A group-level P&L answers one question: across all the businesses in the portfolio, what is the combined financial performance?

That answer has to be built from site-level data. You cannot have a meaningful group view without reliable site views. The consolidation is not a transformation of the data: it is an aggregation of figures that must mean the same thing across all sites before they can be added together.

This is where most manual consolidation processes fail. The revenue figure at site A includes private hire deposits in transit. Site B records them differently. Site C has a bar operation that uses a different category structure to the other sites. When you add these figures together, the sum is not a group P&L. It is a sum of inconsistent inputs dressed as one.

The three levels that have to work together

A functioning group P&L depends on three levels of data each doing their job.

Outlet level: individual departments within a site — restaurant, bar, room service, events space — each with their own cost and revenue tracking. This is the most granular layer, and the one most commonly missing. Without it, site-level figures are blended in ways that hide performance variation between departments.

Site level: the property P&L, consolidating all outlets within a single venue. Revenue by department. Gross profit by category. Labour and fixed costs allocated correctly. This is the layer most GMs are used to managing. The quality of the site-level P&L is determined by how reliably the outlet-level data feeds into it.

Group level: the consolidated view across all sites. Comparable figures that have been produced using the same definitions, the same category structures, and the same timing. A group P&L produced from site figures that are already consistent is fast to build and reliable to use. One assembled from inconsistent inputs requires manual reconciliation every time.

What consistent actually means

Consistency in a group context is harder than it sounds because hospitality operations legitimately differ between sites. A city-centre restaurant has a different revenue mix to a country hotel. A bar operation on a rooftop has different cost structures to a restaurant on the ground floor.

Consistency does not mean making every site look the same. It means applying the same framework to different operations: the same categories for cost and revenue, the same timing for when things are recorded, the same treatment of items like deposits, voids, and transfers between departments.

When the framework is consistent, a group finance director can look at GP% across five sites and know the figures are comparable. Site A at 66% and site B at 61% is a meaningful observation. If those figures were produced by different processes, the comparison tells you nothing.

The timing problem

A group P&L is only useful if it arrives when there is still time to act on it.

A consolidated view of last month's performance, produced on the twentieth of the following month, tells you what happened. It does not tell you what is happening now, and it does not arrive in time to correct anything.

The operators who manage groups most effectively tend to run a weekly Flash P&L, a fast, estimated view of each site's performance for the week, alongside the formal monthly management accounts. The Flash is approximate. The management accounts are precise. Both are necessary because they answer different questions: the Flash answers "how is this week tracking?" and the management accounts answer "what happened last period?"

For this to work, the data needs to flow automatically. A weekly Flash that requires each GM to submit a spreadsheet is not faster than the monthly accounts: it is the same manual process run four times as often. The value of a weekly group view comes from it being automatic, not from someone compiling it.

The consolidation that should not require effort

In a system that is working properly, the group P&L is not built. It exists. The outlet-level data feeds the site-level view, and the site-level views roll into the group view, in real time, using a consistent framework applied at every level.

A group finance director who wants to see this week's GP across all sites does not request a report. They open the group dashboard. A regional manager who wants to understand why one site's bar margin has deteriorated does not email the GM. They drill into the bar department's figures directly. Understanding site-level versus group-level GP is the analytical discipline that makes those conversations productive.

The conversation shifts from "can you send me the numbers?" to "I'm looking at the numbers, let's talk about what they mean."

What this requires technically

A group P&L that works without manual consolidation requires the data to be structured consistently at source: the same categories, the same timing, the same framework applied at every site from day one.

It also requires inventory and finance to be in the same system or genuinely integrated. A GP figure at site level that is produced by manually reconciling a stock take spreadsheet with an invoice export and a POS report is not a live figure: it is a calculation done whenever someone has time to do it. When the three data sources are connected, the GP figure is current and continuous.

Hops is built around this structure. Multi-level hierarchy is native, not configured: outlets within a site, sites within a group, all using the same category framework, with consolidated views available at every level. Stock takes, purchase invoices, and POS data connect to produce GP figures that are grounded in what actually happened, not reconstructed from memory and spreadsheets on a Friday afternoon.

For operators who are currently managing a group from weekly spreadsheet submissions, the practical difference is not just efficiency — it is the quality of the decisions available when the information is timely and reliable.