Practical guide

Join results to records with an exception report

Last materially reviewed 2026-09-27

Quick answerA successful join should expose unmatched and multiply matched rows instead of hiding them.
What to know

Define one-to-one expectations

Document the reconciliation key and any intentional one-to-many relationship created by input deduplication. Keep the original result file untouched. Perform the mapping in a separate working copy so a reviewer can reproduce it.

What to know

Report the exceptions

Count matched records, unmatched inputs, unmatched outputs and duplicate keys. Review a sample of the actual field mapping with appropriate privacy controls. A spreadsheet that contains no empty cells is not proof that the join was correct.

What to know

Synthetic failure test

Use records A, B and C. Return A twice, C once and no B. A robust local check reports a duplicate and a missing result. It must not choose the first A silently or assign the duplicate to B. Resolve the cause before writing anything back to the live system.

What to know

Put it into practice

A join review should distinguish zero matches, exactly one match and multiple matches for each expected input under the chosen rule. Do not allow a spreadsheet's default lookup behaviour to hide multiple matches. In a fictional fixture, key A returns twice, key B returns once and key C does not return. Record A as ambiguous, B as matched and C as missing. An operator must investigate A and C before a write-back. If deduplication deliberately creates one observation for several source rows, make that one-to-many relationship explicit and preserve each row's independent permission state. Keep the transformation version with the receipt so later reviewers can reproduce the association. Sorting the output differently should not change the result. If it does, the process still depends on position and needs correction before it is trusted with live records. Before accepting the join, compare the exception report with the original input keys, not merely with the output row total.

Continue when useful

Next: Stage the return before writing to the live list

Review the proposed changes as a separate artifact before applying them.

Open Stage the return before writing to the live list →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27