Post-Acquisition Data Integration

Acquired companies keep their own ERP while management needs shared definitions. Beetl maintains the data layer that makes the numbers comparable.

Where this starts

First scope
A small number of systems and one recurring group-level data flow
Output
A maintained data layer with shared definitions across the group
Deliberate boundary
One operating group and its subsidiaries, not a pooled environment across unrelated portfolio companies

Source systems

  • Multiple ERP systems
  • Database exports
  • Vendor and customer masters
  • Files and spreadsheets
  • Operational systems

Beetl answer

One comparable set of numbers

Problem signals

After an acquisition the data is rarely missing. Each company answers the same question in its own vocabulary: one runs SAP, one runs Dynamics, one runs something a local team built. Cost centres do not line up, and one supplier is three records across the group.

Supplier spend usually shows it first. The same supplier appears under its legal entity, a brand name and an old company name, so the group can miss a rebate threshold it has already crossed. Intercompany invoices counted as external spend inflate the procurement baseline the other way.

The usual fix is a consolidation workbook that one controller maintains. It breaks when it has to scale, when that person is away, or when someone asks how a number was derived.

We connect each company's systems read-only and keep a source-faithful copy of what came out. Shared definitions become mapping tables, SQL and rules you can review. When two records are treated as one, the evidence stays attached.

The first deployment covers one operating group and its subsidiaries, not a pooled raw-data environment across unrelated portfolio companies. That keeps the data model honest and the isolation questions simple.

  • The top-supplier report changes with the ERP it was exported from.

  • Rebate thresholds crossed at group level stay invisible in each company.

  • Intercompany invoices look like third-party spend until someone checks the evidence.

  • Consolidation runs on one person's workbook, and nobody else can reproduce it.

How we work

Shared definitions come first. If two records from two companies are treated as the same thing, the reason has to stay visible.

  1. 01

    Read each company as it is

    Different ERPs, different exports, different conventions. Nothing is migrated or replaced, and each source is kept in a source-faithful form.
  2. 02

    Make the matches explainable

    What counts as the same supplier, the same cost, the same entity. A match may come from a VAT ID, an IBAN, a legal-name change, or an acquisition history. The evidence matters as much as the match, so it stays attached to it.
  3. 03

    Run it as a recurring flow

    The reconciliation stops being a monthly rebuild. Definitions are versioned, and next month starts from the decisions already made.

What you are left with

A maintained data layer, not a one-off reconciliation. It can feed dashboards, queries, a warehouse, or later operational destinations.

  • One recurring group-level view with the source records still traceable behind it.

  • Shared definitions kept explicit and versioned, so a changed rule is a visible decision, and a confirmed match is kept for next month rather than redone.

  • A data layer that can feed dashboards, plain-language queries, or a warehouse without rework.

Bring two companies whose numbers will not line up.

Tell us the systems each one runs and the first group-level view you need. We will scope one recurring data flow across them.