A finance report doubled its totals after adding a lookup table

If a report total rises immediately after customer, project, or classification data is added, compare the transaction population before and after that step. Record the number of rows, distinct transaction identifiers, and monetary total at each stage. A lookup intended to add a label can multiply an amount when more than one lookup record matches.

Choose a transaction that repeats in the final result and inspect every matching row on the other side. The repeated records may represent several customer contacts, effective-dated classifications, or duplicate account mappings. Keep those explanations separate. Deleting extra-looking rows from the export hides the condition that will reproduce the error at the next refresh.

PostgreSQL's documentation explains that a joined result includes matching row combinations. Microsoft's Power BI guidance similarly emphasizes consistent fact-table grain. For the finance review, write the grain in ordinary terms: one invoice, one invoice line, one payment allocation, or one journal line. Decide which identifiers establish that unit.

For a hypothetical example, one $900 invoice has two contact records. Joining its header to both contacts creates two result rows containing $900 each. Summing those rows produces $1,800 even though the invoice register still contains one $900 sale. The contact records can both be legitimate; they are unsuitable as an unrestricted amount-producing join.

Check whether the measure belongs at the header or line level. An invoice total repeated on each legitimate line will also be overstated if the report sums that header amount. The team needs an explicit measure rule alongside the row definition.

Ask the developer to show how each transaction obtains the intended classification. A current-customer report may need one designated current record; a historical report may need the record valid at the transaction date. An invoice-line report may need line amounts, while a payment-allocation report needs the amount allocated to each invoice. These choices change the query's meaning.

Where two detailed datasets must be compared, consider whether each should be summarized to an agreed common grain before they are combined. Have the reporting owner approve that grain. Aggregating first can solve multiplication, but it can also discard information required for the decision if the grouping is too broad.

Do not accept a distinct sum of monetary values as a general fix. Two different $900 invoices must still contribute $1,800. Removing equal values without respecting transaction identity can replace an overstatement with an understatement.

Use a small test set containing a transaction with no matching lookup, one match, several matches, and two separate transactions with the same amount. Add the actual condition that caused the defect. Compare distinct identifiers and expected amounts with the untouched source, then inspect the classifications assigned to the test records.

Review filters and unmatched records as well as the total. A repair that drops unclassified transactions may produce an attractive result by excluding part of the business. Give unresolved mappings a visible exception treatment agreed by finance.

Before replacing a distributed report, identify which periods and recipients received the inflated version. Retain the old output, repaired query version, and reconciliation. Explain the reporting correction without posting a ledger adjustment unless the underlying books also require an independently approved correction.