Engineering & integration

Acquisition data integration for portfolio-company reporting

Bring an acquired company's data into a controlled reporting model. Preserve source history, map accounts and entities, and separate acquired contribution from comparable operating performance.

The problem

The acquisition closes before the reporting systems agree. Different account codes, calendars, customer records, and operating definitions make the first consolidated view difficult to trust. A useful integration establishes continuity while preserving the detail needed to explain a change.

Common signals

When this work becomes useful

Concrete output

What the engagement can produce

An acquisition source contract

Document source owners, extract cadence, entity identifiers, fiscal calendars, currencies, reporting cutoffs, and available history. Keep legal acquisition date, reporting inclusion date, and data availability separate so partial periods remain visible.

Approved mappings with history

Map accounts, companies, locations, customers, and products at the required reporting grain. Retain original source codes, unmapped records, effective dates, and the reviewer responsible for classification changes.

A controlled integration path

Implement approved file, database, or API ingestion with source versioning, duplicate detection, validation, and a replacement policy. A corrected submission updates the active view without destroying the previously approved pack.

A comparable performance bridge

Show existing-company change and acquired contribution separately. Add explicit currency, calendar, reclassification, and elimination adjustments where required. Reconcile the bridge to the consolidated total and retain the approved basis of comparison.

Scope variants

Shape the engagement around the need

First reporting cycle after an add-on

Connect a bounded set of finance sources and KPIs for the incoming entity. Deliver its reconciled contribution, mapping record, unresolved exceptions, and approval path before expanding into detailed operating data.

A repeatable acquisition onboarding pattern

Build a reusable source-request checklist, staging model, mapping review, and acceptance record for a platform business. Preserve business-specific exceptions instead of forcing every acquisition into the same assumptions.

Coexistence during system migration

Maintain a reporting path across legacy and target systems. Define the source of authority by entity and period, reconcile overlap, and test the reporting handoff before switching the active source.

Delivery approach

From current state to clear ownership

Define the reporting perimeter

Agree the entities, periods, measures, reporting currency, and treatment of partial periods. Confirm which historical comparisons are supported by actual records and which require an explicitly labeled assumption.

Map and validate an initial extract

Check completeness, uniqueness, signs, units, and source totals before transformation. Review unmapped accounts and duplicate entity keys with the people who understand the acquired company's records.

Reconcile the first combined output

Compare the incoming contribution and consolidated measures to approved source reports. Keep adjustments separate from raw actuals, preserve any elimination entries, and make unresolved differences visible to the reviewer.

Prove the next reporting cycle

Test a late file, a corrected prior period, a changed mapping, and the next scheduled extract. Release with source ownership, exception handling, documentation, and a defined process for onboarding the next entity.

Technical context

Platforms and disciplines

What we need to begin

Engagement fit

Clear boundaries make better projects.

Often a good fit

  • Buy-and-build platforms with recurring add-ons
  • Portfolio CFOs preparing the first combined reporting pack
  • Operating partners comparing acquisition and existing-company performance
  • Integration teams retaining multiple source systems during transition

Probably not the right fit

  • Legal merger integration or purchase-price accounting advice
  • Unsupported pro forma history presented as actual results
  • A full ERP replacement hidden inside a reporting integration

Anonymized proof

Permadyn's anonymized reporting accounts describe financial and operating source context, definitions, and governed review. The acquisition guide provides a fictional revenue bridge to make the method inspectable; it does not claim a named acquisition integration or a client growth result.
Explore representative work

Questions

What teams often ask first

Must every company move to the same ERP first?

No. A shared reporting model can start with approved extracts or interfaces from the existing systems. The first requirement is an agreed data contract and reconciliation path, not a single ERP vendor.

How do you keep acquisition growth from distorting comparisons?

Retain the reporting population for each period and identify the incoming contribution separately. For example, a fictional base moving from 50 to 55 plus 15 of acquired revenue reaches 70: 40% reported growth, but 10% growth within the unchanged base under the stated assumptions.

What happens when historical data are incomplete?

Retain the gap and explain its effect on the comparison. Use actual, estimated, and pro forma labels deliberately. The finance owner must approve any supplementary assumptions before they enter a management view.

Can this support healthcare acquisitions?

Yes, with an appropriate scope and approved access. Location hierarchies, service dates, claims maturity, labor periods, and acquired reporting cutoffs need explicit treatment. The healthcare private equity page describes those operating distinctions.

What proves the integration is ready?

Agreed source and output totals reconcile; mappings and adjustments have owners; duplicate and late-source cases behave as intended; and a reviewer can reproduce the released figures. The acceptance record also lists unresolved exceptions and whether they block publication.

Related capabilities

Continue through the system

Related resources

Discuss an acquisition reporting gap

Describe the incoming company, source systems, and first reporting decision. Start by defining the data and reconciliation work needed for an accepted combined view.

Discuss an acquisition reporting gap

The packaged engagements and delivery models make the commercial boundary visible without forcing every project into the same shape.