CSV join duplicate keys can produce more output rows than either source contains for a particular record. That is not automatically a malfunction. A join combines matching rows, and repeated keys can create several combinations.
The problem appears when you expected one match and then add up the repeated values as though each output row were a separate transaction.
Count the combinations for one key
Consider a sample key A17. The left table has two rows with that key. The right table has three. An ordinary matching join can produce six combinations: each left row paired with each right row.
If the left rows contain an amount, that amount can appear once for every matching right row. Summing the joined amount column without accounting for the relationship can inflate a total.
PostgreSQL's table-expression documentation explains join behavior in terms of matching rows. The same relationship question is useful when joining files, even if you are not writing SQL.
State the expected relationship first
Is each customer supposed to match one address record? Does one order legitimately match several line items? Are both sides event lists with repeated keys? These are different models.
If you expect the right-side key to be unique, check that expectation before joining. Data Quality Rule Checker can test supported uniqueness rules. A failed check should trigger an investigation, rather than a blind removal of repeated rows.
Sometimes the key is incomplete. A product code may need a region or a version to identify the intended record. Use the source's documented identity fields. Adding an arbitrary second column merely to reduce matches can hide the underlying ambiguity.
CSV Merge and Join explicitly multiplies matches for repeated keys and has an output-row limit. Before joining a large dataset, inspect a small representative subset or a synthetic example with the same relationship.
Choose a repeated key and list its rows on both sides. Predict the number of matching combinations. Then compare that prediction with the result. This gives you an explanation for the count instead of treating it as an unexplained surprise.
Also examine unmatched records under the chosen join type. A total can change because rows disappeared, because matches multiplied, or because both happened. Those causes need different fixes.
For reporting, decide whether the calculation belongs before or after the join. An order-level total should not casually become a line-level sum. Keep the intended unit of one row visible in the analysis, and document any aggregation rule. A joined file that opens successfully can still represent the wrong unit for the question you are answering.