← Blog
8 min read

The Excel-and-Power-BI handoff that holds post-merger reporting together

The post-merger Excel workbook holds the consolidation together, but the human decisions baked into its formulas never reach the Power BI layer above.

Ray Kameda
Ray Kameda
Co-Founder & Chief Product Officer
Two-panel cover. Left: cell H47 of consolidation.xlsx in the cost rebaselining sheet, an orange comment ribbon above the cell reading 'Verified part equivalence with engineering 2026-03-12, Müller confirmed', a multi-line IF/VLOOKUP formula below that returns €4.62. Right: a Power BI group reporting dashboard for YTD 2026 with a top strip of headline KPIs (Revenue €48.3M, Margin 31.7%, COGS €33.0M, EBITDA €6.2M), a 'Standard cost by family' table where the Connector family row is highlighted in orange and shows DE €4.20, US €4.95, Group €4.62, and a focal card labelled 'Consolidated standard cost - Connector family' displaying €4.62 with a 'minus €0.08 vs plan' and '184,000 units this period' annotation. Below the dashboard: 'Inherits the number. Doesn't inherit the comment.' An orange arrow labelled 'draws from' connects the workbook formula to the dashboard.

For months or years after a manufacturing acquisition, the Excel workbook is the consolidation engine. The Power BI card shows the resolved number but never the formula or the comment beside it. That is what fails at year-end audit.

Imagine it's Tuesday, 9 months after the deal closed. The acquired German subsidiary ships parts to the US entity at one standard cost; the US entity books the same part-number-equivalent at a different one. The group Power BI report shows a single consolidated figure. The new Private Equity (PE) operating partner sends a message asking how that figure was computed. The controller opens her workbook. The answer is in cell H47, with a comment from March about a phone call with engineering.

What the industry sees

The discourse around post-merger reporting clusters into three vendor categories.

The first is the Excel-from-ERPs category. Spreadsheet Server, Jet Reports, and a long tail of competitors connect Excel to 140 ERP systems and deliver consolidated data into the workbook automatically. This is the category that takes the controller's existing tool seriously.

The second is the Power BI migration category, made urgent by Microsoft's deprecation of the legacy Excel and CSV import experience in Power BI Service. From 31 May 2026, new semantic models can no longer be built from the old import path. From 31 July 2026, existing models stop refreshing. Vendors and Microsoft itself are pushing controllers toward Dataflows, OneLake, and the Fabric stack.

The third is the consolidation platform category. OneStream, Tagetik, BlackLine, and SAP S/4 Group Reporting are credible products with mature audit trails, validation rules, and workflow approvals. Large groups deploy them; mid-market acquirers buy them on the way to scale.

Each of the three is correct as far as it goes. Each assumes the upstream ERPs already agree on what a vendor, an account, or a standard cost means. During the integration window, they don't.

What the controller is actually doing

The controller in the opening scene has seen the workbook fail twice in the last year. Once in August, when she went on leave and her replacement could not produce the monthly consolidated cost report because the inheritance of cell logic across the file's 22 sheets existed only in her head. Once in October, when the auditor asked how the group standard cost for the connector parts family had been computed, and the answer took 3 days to reconstruct from comments, email threads, and a conversation with the engineering lead.

The single decision behind that group standard cost is worth walking through.

The acquired German subsidiary books the connector part costs at €4.20 standard. The US sister entity books the same part-number-equivalent at €4.95 standard. Engineering confirmed in March that the parts are mechanically identical; the cost difference is a methodology choice. The controller decided to report a weighted blend of €4.20 × 0.55 and €4.95 × 0.45, which resolves to €4.62, reflecting the rough share of group production volume that each entity contributes.

That decision lives in cell H47 of the consolidation workbook. The formula is an IF wrapped around two VLOOKUP calls and a weighted blend. A comment above the cell reads: Verified part equivalence with engineering 2026-03-12, Müller confirmed. The Power BI tile labelled Consolidated standard cost €4.62 draws from H47.

The reframe is implicit. The workbook is doing the consolidation. The dashboard is reporting the result.

The gap the BI tooling doesn't close

Microsoft Fabric tracks data lineage in the technical sense. The semantic model behind the Power BI tile knows which dataflow refreshed it; the dataflow knows which file it pulled from; Purview catalogs the assets across the tenant. If the question is which file was the source of the consolidated standard cost figure, Fabric answers it.

Microsoft Fabric lineage view showing the dependency chain from a source Excel workbook through dataflows to semantic models to report visuals, with each asset labelled by type and refresh status.

The question Fabric does not answer is the one the PE operating partner actually asked. He wants to know why €4.62 and not €4.57 or €4.78. The answer is in the weighted blend the controller chose. The reason she chose 55/45 and not 50/50 is the rough split of group production volume between the two entities as of Q1. The reason a blend is acceptable at all is the engineering confirmation that the parts are equivalent. None of that lives anywhere a second person can audit.

This is the gap that opens between the workbook and the BI layer. The workbook is where the decisions are made. The BI layer is where the resolved numbers are displayed. The decisions never reach the display, and the display never sees behind itself. When the controller leaves, the audit asks, or the PE quarterly review runs, the loss is asymmetric: the dashboard is still there, the rationale is gone.

Three-layer architecture diagram. Top: the dashboard layer (Power BI tiles, Excel reports, OneStream/Tagetik, BlackLine/S4 Group Reporting). Middle, highlighted in orange: the decision-capture layer that currently exists only in the controller's head and the consolidation workbook's formulas and comments. Bottom: source systems from the acquired entities, three ERPs with mismatched semantics. Arrows flow upward from sources through the missing layer to the dashboards. Right-side annotations: 'Numbers display here' on top, 'Decisions made here, mostly uncaptured' in the middle, 'Data origin, mismatched semantic' on the bottom.

What a working version looks like

OneStream, Tagetik, BlackLine, and SAP S/4 Group Reporting are downstream tools. They assume the consolidation logic has already been agreed on, the chart of accounts has been mapped, and the entities share a stable common semantic. Once those conditions are met, they are excellent at workflow approvals, validation rules, and audit certification. None of those conditions are met during the integration window.

The missing layer sits one step upstream of where those tools begin. It captures, for each decision the controller makes inside her working surface, the records being matched, the evidence supporting the match, the person who made it, and the date. The working surface stays Excel. The dashboards stay Power BI. The consolidation platform, when the group is large enough to deploy one, stays whatever it is.

What this captures is the layer of reasoning that currently sits inside formulas and comments. Cell H47's IF/VLOOKUP becomes a decision record: parts DE-CONN-4471 and US-CONN-1108 mapped as equivalent, evidence linked to the engineering email, blend ratio 55/45 chosen on Q1 production volume, controller Müller, dated 2026-03-12. The number is still €4.62. The reasoning is now portable, replayable, and audit-readable.

At Beetl we are building exactly this layer for post-acquisition manufacturing groups. The first version focuses on the cross-entity reconciliation decisions controllers make inside consolidation workbooks today: vendor-master equivalence, standard cost normalization, account remapping, intercompany flagging. The captured record is the unit of work; the working surface stays Excel; the dashboards stay whatever they were.

Two-panel concept diagram. Left side labelled TODAY shows cell H47 in consolidation.xlsx: an orange comment ribbon reading 'Verified part equivalence with engineering 2026-03-12, Müller confirmed' sits above an IF wrapped around two VLOOKUP calls that returns €4.62, with the footnote 'the reasoning behind it lives in one controller's head and the comment ribbon, second readers reconstruct it from scratch'. Right side labelled WITH BEETL shows the same decision as a structured record: DECISION parts mapped as equivalent, PARTS DE-CONN-4471 equals US-CONN-1108, EVIDENCE engineering email 2026-03-12, REASONING methodology choice with the parts mechanically identical, BLEND 55 over 45 on Q1 group production share, RESULT €4.62 highlighted in orange, AUTHOR Müller group controller, DATED 2026-03-12, STATUS verified and audit-readable and replayable. An orange arrow labelled 'captured as a record' connects the two panels.

Closing

The Excel-and-Power-BI handoff is not going away. It is doing real work, for real reasons, in the only window during which a single controller can hold the consolidation in her head. The structural problem is what gets captured underneath it.

A starting diagnostic for any post-merger reporting environment: ask the controller for read-access to the consolidation workbook, then count the unique external-workbook references in the formulas. That number is the integration debt the deal model did not price.

FAQ

What lives inside the post-merger consolidation workbook that the BI layer doesn't see?
Cell-level decisions: which records were matched across entities, on what evidence, by whom, and when. The Power BI tile draws on the resolved number but inherits none of the rationale that produced it. Examples include vendor-master equivalence decisions, cross-entity standard cost blending, account remap choices, and intercompany flagging. Every one of these lives inside an Excel formula and, if the controller is conscientious, a comment beside the cell.
What is cost rebaselining and why does it matter for post-merger reporting?
Cost rebaselining means bringing the standard cost numbers from each acquired entity onto a common basis so the group can report a single figure. Each entity arrives at the deal with its own chart of accounts, costing methodology, and history of cost decisions; the group cannot just sum them. When two entities book the same physical part at different standard costs (in the example used in this article, €4.20 in Germany and €4.95 in the US), rebaselining is the methodology decision that produces the group figure: a weighted blend, a primary source, or a recalculation from raw inputs. Those methodology choices are exactly what gets lost when the group dashboard only shows the resolved number.
Why don't consolidation platforms like OneStream, Tagetik, or BlackLine solve this during integration?
Those platforms live downstream of where the reconciliation work happens during PMI. They assume the entities have already agreed on a common chart of accounts, vendor master, and cost methodology. During the integration window, those agreements are still being negotiated, and the workbook is where the active reconciliation takes place. Consolidation platforms become the right answer once the group is large enough to deploy one and the mappings have stabilized.
What does Microsoft's 2026 Power BI Excel-import deprecation mean for post-merger controllers?
Starting 31 May 2026, new Power BI semantic models cannot be created from the legacy Excel and CSV import path. From 31 July 2026, existing models built on that path stop refreshing. Controllers are being pushed to Dataflows, OneLake, or Fabric. The migration does not address the workbook itself; it only changes how Power BI consumes it. The audit-trail gap between the workbook and the dashboard remains regardless of which path Power BI uses to draw the number.
How long does the Excel-as-consolidation-engine window last after an acquisition?
For the duration of integration, which in manufacturing is rarely the 6 to 18 months PMI playbooks describe. ERP migrations for mid-market and Mittelstand carve-outs commonly run multi-year projects. The workbook stays load-bearing until the upstream systems agree on a common semantic, which can take years rather than quarters.
What is a quick diagnostic to measure post-merger reporting integration debt?
Ask the controller for read-access to the consolidation workbook. Count the unique external-workbook references in the formulas using Excel's Find & Replace on the '[' character across the file. That count is a reasonable proxy for how many separate sources the controller is hand-reconciling at every close. It is the integration debt the deal model did not price.

Want to see this with your data?

Book a 30-min intro