An account moved departments: preserve the intended historical mapping

A department reorganization can change last year's expense report even when no ledger entry changes. If the report joins every transaction to today's account-to-department lookup, a newly assigned department can inherit the account's entire history. Decide whether that result answers the report's question before treating it as a defect or an improvement.

Management may want historical responsibility for one review and current organizational structure for another. Name those views clearly and approve their definitions. A report that changes between them without disclosure can make a department appear to improve or deteriorate for reasons unrelated to operating performance.

Microsoft's star-schema guidance distinguishes overwriting a dimension with its latest values from retaining versions with validity ranges. Its Type 2 approach uses version-specific keys and dates, with facts linked to the appropriate version. Applied to an account mapping, the design needs an explicit rule for which transaction date selects the classification.

Choose that date deliberately. Posting date, service date and the date a record entered the reporting system may differ. The finance owner should explain which one serves the approved report. A developer should not choose whichever field is easiest to join without documenting the consequence.

Where the source keeps only the current mapping, ask how changes will be captured going forward and what evidence supports earlier periods. A new history table cannot reconstruct unknown past assignments. Mark unsupported periods or obtain approved historical mapping evidence before claiming that a comparative report preserves them.

Suppose an account moves from Operations to Product on July 1 in an illustrative reporting design. Test transactions immediately before, on and after that date. State whether the old range ends just before July 1 or uses another documented boundary convention. Each transaction should receive the intended single version.

Check for overlapping validity ranges, gaps and multiple current records. An overlap can multiply a transaction; a gap can leave it unclassified or remove it from a filtered report. Make those conditions visible during loading, with an owner who resolves them before the affected report is released.

Include an entry posted later but assigned to an earlier accounting period. Confirm whether it receives the historical mapping required by the policy. Also test a corrected transaction date and an account that did not exist at the start of the comparative period.

A genuine correction to last year's classification is different from this year's reorganization. Preserve the reason, approver and effective scope of a retroactive change. Identify which previously issued reports will change and whether the team will regenerate them or retain a reconciliation between versions.

Keep the original ledger account and source identifiers available alongside the reporting classification. The historical mapping explains presentation; it should not obscure the transaction's accounting origin. Reviewers need to trace a department total back to the same underlying entries after the organizational structure changes.

Record the report's historical or current view, selection date, boundary convention and mapping version. Give account-maintenance staff a way to propose future changes before they overwrite an active lookup. A short change example is often more useful than a long list of unexplained dimension codes.

Acceptance requires both classification tests and reconciled transaction totals. A perfectly balanced report can still assign every historical expense to the wrong department. Preserve the boundary test cases so the next reorganization checks the same business meaning.