Revenue inflation after a merge

Understand the likely causes

• The product lookup contains two rows for A and one for B. Expanding the matches repeats A’s10. Other cases can instead lose unmatched facts through an inner join or multiply totals by mixing different grains.

Freeze the metric and inputs

Record the exact source rows, intended grain, preparation steps and affected metric. Preserve a small synthetic reproduction with key types and duplicates intact; do not expose a private extract. Establish the expected30 before inspecting the visual. A format change, DISTINCT over amounts or removing a category can make a number look better while corrupting legitimate repeated sales. Keep the original evidence and distinguish the first step where row count or total changes. That boundary is more informative than the last visual showing the inflated result.

Inspect key cardinality and expansion

Audit uniqueness on the side intended to provide one product attribute per fact. A left nested merge can retain two left rows before expansion while one nested match table contains two A rows. Expansion then produces A/10/x, A/10/y and B/20/z. The following record is a reasoned teaching result, not a captured M-engine output. Compare unmatched keys as well: a different join kind can hide missing products by removing facts instead of duplicating them. A successful query preview proves neither key integrity nor total preservation.

before:2 facts, total30
right-side key A:2 matching attribute rows
after expansion:3 rows, amounts10+10+20=40
required invariant: one approved product version per intended fact date

Repair the business-key contract

Determine whether the duplicate represents an upstream defect, several legitimate product versions or a missing composite key. If attributes change historically, choose the version effective for the fact under the approved model rather than keeping whichever row happens to sort first. A separate dimension with an appropriate surrogate key can be necessary. Correct the source/preparation contract and rerun affected reconciliation; do not alter a valid revenue measure to cancel duplication. Also review whether the same expansion duplicated cost, which can leave a margin percentage deceptively unchanged.

Verify coverage and context

Verification should reconcile original fact identities, row counts and30 total after the intended lookup resolution, then check A and B separately and an unmatched-key case. Confirm relationship filtering and report selections after preparation is corrected. This guide performs no M, DAX or GUI execution and connects to no source. Its trace is an editorial expected result. A future authorized engine check must record actual inputs and outcomes; local reasoning alone cannot establish that the published model contains the repaired rows or that every downstream report uses the revised definition.

Keep it from recurring

• Keep key-uniqueness, unmatched-key and before/after-total checks with every merge. Version the historical attribute rule and maintain lineage from analytical facts back to their source identities. Review schema changes before recurring refresh.