Mapping an acquired company's accounts without losing reporting history

Identify an account within its source context

Account 4100 is not a unique business definition across a portfolio. Use a mapping key that includes the source system, legal entity, and source account; add other fields when the source classification actually depends on them. Preserve the original label and value alongside the reporting category. A separate stable entity identifier helps when the acquired company changes its display name or source application.

Before joining the mapping to facts, specify the fact grain. A monthly account balance, an individual ledger posting, and an account-by-location extract require different uniqueness checks. Choose the amount convention explicitly. For example, if source revenue credits are negative but the management pack presents revenue as positive, record the sign transformation and keep the raw amount available. An unexplained sign flip can hide a real source reversal.

Reconcile the unmapped account as a visible exception

The fictional Beacon Sensors source contains $4.40 million of equipment revenue under account 4100 and $0.60 million of service revenue under 4110. The source total is $5.00 million. If 4110 has no approved mapping, the working model contains $4.40 million and its model-minus-source residual is −$0.60 million. Keep the missing account in an exception table; an inner join that drops it should not look like a complete load.

After a controller confirms that 4110 belongs to the agreed revenue category for this reporting period, the mapped total becomes $5.00 million and the residual becomes zero. That reconciliation proves the amount was included once. It does not prove every account was classified correctly: two wrongly classified accounts can offset. Review classification evidence and source completeness as separate controls.

Make effective dates unambiguous

Store when a mapping applies and when it was recorded. These answer different questions: a classification may be effective July 1 but approved August 10. Define a date convention such as start inclusive and end exclusive. Under that convention, a version beginning July 1 and ending August 1 applies to July transactions; the next version begins August 1 without overlapping the same date.

A normal change in classification should not silently rewrite the pack already approved for July. Decide whether the next management view preserves the previous classification, presents a restated comparison, or offers both with clear labels. Retain the mapping version used by each released output. Microsoft's star-schema guidance explains historical dimension versioning; the specific reporting policy and mapping approval remain the company's decisions.

Test duplicate mappings as well as missing mappings

A mapping table can contain two active rows for the same account and date. Joining the $600,000 service fact to both would produce $1.20 million of service revenue and $5.60 million overall. A row-count check may catch this before an executive dashboard does. For a simple classification, require exactly one eligible mapping for each included fact and reject overlapping effective-date ranges.

If one source account must be allocated across categories, model that as an explicit allocation rather than tolerating duplicate mappings. Record the allocation basis, approved weights, effective period, and rounding policy. The allocated outputs must sum back to the eligible input. When the source lacks evidence for an allocation, leave a named gap for finance instead of inventing a percentage to complete the pack.

Keep the mapping register and release checks together

A practical mapping register includes source system, entity, account, reporting category, sign treatment, start and end dates, mapping version, approver, approval date, and rationale. Add the source document or reconciliation reference that explains the classification. Keep the register small enough for the controller to review; store technical load details separately when they obscure the accounting meaning.

Exercise the next cycle before handoff. Replay an unchanged extract, introduce an unknown account, test a fact on each side of an effective-date boundary, and submit a corrected prior period. Confirm which source version is active and that prior releases remain reproducible. The goal is a repeatable onboarding pattern that exposes exceptions, rather than a mapping file that happens to balance once.

• Define source identity, fact grain, units, and sign convention.
• Retain all source accounts, including unmapped records.
• Require one eligible classification per fact unless an approved allocation applies.
• Reject overlapping mapping versions and test boundary dates.
• Reconcile amounts before and after mapping; review classification separately.
• Record the mapping version and source version with each approved release.
• Assign a finance owner to unknown accounts and historical restatement decisions.

Primary sources

• Microsoft: star schema, fact grain, and historical dimension versions

Related services and experience

• Acquisition data integration (Implementation service)
• Private equity analytics toolkit (Ungated methods and synthetic evidence)
• Portfolio operations dashboard (Synthetic evidence first published 2026-09-09)
• Acquisition reporting workbench (Interactive synthetic mapping and revision exercise)
• Acquisition reporting overview (Reporting perimeter and onboarding method)
• Private equity portfolio analytics (Industry practice)