How to consolidate reporting after an acquisition.

Consolidated reporting starts with shared definitions, then mapping, then a reporting layer that reconciles both businesses.

To consolidate reporting after an acquisition, work in a fixed order. Agree on what each key measure means across both businesses, map the customers, products, and locations in one system to their equivalents in the other, build a reporting layer that pulls from both and reconciles to the books, and automate the reports people use most. Starting with dashboards usually means rebuilding them later.

The order matters because the two companies almost certainly measure the same things differently. One recognizes revenue on invoice and the other on completion. One counts a customer per site and the other per parent account. One includes freight in gross margin and the other leaves it out. Combined numbers built on those differences look precise and mean very little.

Consolidating reporting does not require consolidating systems first. Companies usually need combined numbers long before they are ready to move an acquired business onto a new ERP or CRM, and a reporting layer can combine data from both while the systems stay separate. That keeps the fund and the board informed without forcing a rushed migration.

Agree on the definitions across both businesses before building anything.

Start with the measures the board and lenders actually review: revenue, gross margin, bookings or backlog, customer counts, headcount, and any operating measures in the investment thesis. For each one, write a definition in plain language, the source system in each business, and the exact rule for edge cases such as credits, returns, intercompany sales, and partial periods.

The finance leaders of both businesses should agree on these definitions together, with an executive who can settle disagreements. Some differences are accounting policy and must be aligned under the combined company’s policies. Others are operating conventions that can stay local, as long as they are translated consistently into the shared measures. Write down which is which.

Keep the definitions in a versioned document everyone can find, with a named person responsible for changes. When a definition changes, record the date and restate the affected history so trends stay comparable. A definitions document people actually consult prevents a familiar problem: two executives bringing different numbers for the same measure to the same meeting.

Map customers, products, and locations between the two systems.

Combined reporting depends on knowing that a customer in one system is the same customer in the other, and that two product codes describe the same service. Build mapping tables for customers, products or service lines, locations, and the chart of accounts. Each entry links an identifier in one business to the shared identifier the reporting layer will use.

Expect the mapping to be messy. Customers appear under slightly different names, one business tracks products at a finer level than the other, and account structures do not line up line for line. Decide on a shared level of detail for each dimension, map both businesses to it, and keep a list of records that could not be matched so someone resolves them.

Maintain the mappings as living data, not a single exercise. New customers, products, and locations appear constantly, and each needs a mapping before it shows up correctly in combined reports. Give the task a clear home, usually in finance operations, and report on unmapped records so gaps are caught before a board package goes out rather than after.

Build a reporting layer that pulls from both systems and reconciles to the books.

The reporting layer is a shared data store that receives scheduled extracts from each business’s accounting and operating systems, applies the mappings and definitions, and feeds the combined reports. It can be a modest data warehouse with a reporting tool on top. What matters more than the technology is that every transformation is written down and repeatable.

Build reconciliation into the layer from the start. Each load should compare totals against the general ledger of each business and flag differences before anyone sees a report. When combined revenue ties to the sum of both ledgers, finance can defend the numbers. When it does not, the check points to where the difference entered.

Keep the ability to see each business separately as well as combined. Leaders of the acquired company still need a view of their business alone, and the fund often wants to track the acquisition against its deal model. A reporting layer that can slice by legal entity, by location, and in total serves all three without separate spreadsheets.

Automate the most-used reports first, and design for the next add-on.

Automate in order of use and pain. The financial package and the board package usually come first, followed by the operating reports managers review most often, such as sales pipeline, backlog, or utilization. Each automated report retires a manual assembly step, and each one tests the definitions and mappings against real scrutiny from the people who read it.

Design the layer so the next acquisition is an addition, not a rebuild. Each new business should arrive by mapping its systems to the existing shared definitions and dimensions, not by changing them. When a new add-on exposes a gap in a definition, update the definition deliberately and restate history, rather than creating a special case for one company.

Baybloom Software builds connected reporting and the data work behind it for companies combining acquisitions. Whoever does the work, consolidated reporting holds up when definitions are agreed on first, records are mapped carefully, every load reconciles to the books, and the design expects more businesses to join it over the hold period.

Put it into practice

Talk through the project you are considering.

Bring the workflow, the systems around it, and the questions you need to resolve. We can help define a useful next step.