How to consolidate reporting across multiple restaurant sites

A single restaurant produces a P&L. A group of restaurants produces several P&Ls that then need to become one. The gap between those two things is where most multi-site operators lose time, accuracy, and management visibility. The group-level P&L that operators actually want to be working from depends entirely on what happens at this consolidation stage.

The manual consolidation process is familiar to anyone who has worked in a multi-site finance team. Spreadsheets arrive from each site. Someone reformats them into a consistent structure. Discrepancies are resolved, categories are reconciled, and eventually a group view emerges. It is accurate enough to report from and arrives late enough that most of the operational decisions it should inform have already been made.

This is not a people problem. It is a structural one.

What makes consolidation hard

Consolidation is difficult when the underlying data is inconsistent. Three categories of inconsistency cause most of the friction.

Category structures. Site A records wine sales under "beverage." Site B records them under "wet stock." Site C has a separate category for sparkling versus still. When you add these together at group level, the sum is not comparable. Someone has to map them to a common framework before the consolidated figure means anything.

Timing. Site A closes its weekly report on Monday morning. Site B closes on Wednesday. Site C is usually ready by Friday. The group view cannot be current until every site has submitted, and the submission timing varies by how busy each GM was, whether anything unusual happened during the week, and whether the finance team has chased.

Treatment of specific items. Deposits in transit, intercompany transfers, voids and refunds, promotional discounts: each site may handle these differently unless the treatment has been standardised explicitly. Small inconsistencies compound at the group level.

What consistent data at source looks like

The solution to consolidation difficulty is not a better Excel template. It is consistent data at source.

When every site uses the same category structure, records items with the same timing conventions, and treats specific items the same way, consolidation becomes addition rather than reconciliation. The group view is not assembled: it exists, as a natural consequence of the underlying data being structured correctly.

This requires a shared framework applied from the point of setup. Not retrofitted after each site has already been running independently for a year. Not approximated by a finance team member who has to normalise inconsistent inputs each week. Applied consistently from day one, at every site, with any site-level exceptions explicitly managed rather than hidden in different category names.

The frequency question

A consolidated group view produced monthly is useful for period-end reporting. It is not useful for managing what is happening this week across the estate.

Multi-site operators who manage their businesses effectively tend to run a weekly Flash view alongside the formal monthly consolidation. The Flash is approximate — it uses estimated cost of goods and unreconciled revenue — but it answers the operational question: across all sites, is this week tracking to plan?

For a weekly Flash to be operationally useful, it cannot require manual assembly. If the underlying data is current and consistently structured, the Flash is a view of that data, not a compilation exercise. The finance team reviews it rather than builds it.

Site-level visibility within the group view

Consolidated reporting does not mean replacing site-level visibility with a group total. It means making both available simultaneously.

A group FD who sees that consolidated GP has dropped two points this week needs to be able to drill into the individual site figures to identify which site is driving the change. A regional manager who looks after three sites needs to see those three sites clearly, alongside a cluster total, without losing the ability to go deeper into any one of them.

The reporting hierarchy should reflect the management hierarchy: outlet level, site level, cluster or regional level, group level. Each person in the management structure sees the level relevant to their decisions, with the ability to go deeper where something looks off.

How Hops approaches this

Hops builds multi-level hierarchy as a native structure rather than a reporting add-on. Sites are configured within a group from the start, using consistent category frameworks. The group view exists as a real-time aggregation of site data, not a weekly assembly exercise.

For groups where multiple sites have historically been managed independently with their own systems and structures, migration requires aligning those structures. Hops supports this, but the underlying principle holds: the value of consolidated reporting depends entirely on the consistency of the data it consolidates. The inventory management challenges that accompany multi-site growth are closely linked to this same consistency requirement on the stock and purchasing side.

If your current group reporting process involves a finance team member spending significant time each week normalising site submissions before a group view is possible, the underlying data structure is the problem Hops is designed to solve.