In a lot of industries — nonprofits, financial services, insurance, real estate — the unit that matters isn't the individual. It's the household. John and Mary Smith are one household giving one pledge, owning one policy, holding one mortgage. But your database might have them as two separate records, or as one household, or as three records (John, Mary, and "John and Mary Smith"). Matching across those variants is called household matching, and it's harder than it looks.
Why household matching is hard
A few patterns that make the naive approach break:
- Joint name conventions vary. "John and Mary Smith", "John & Mary Smith", "Mr. and Mrs. Smith", "Smith Family", "John Smith (and spouse)" — same household, five string variants.
- Same household, different contact points. John uses his work email; Mary uses a Gmail. Same phone number, same address — but no email overlap.
- Roommate vs. household distinction. Two people at the same address aren't necessarily a household. College roommates share an address but usually have separate financial and civic identities.
- Kids count — sometimes. If John and Mary Smith have two adult children also at the same address, some organizations want them in the same household (family unit) and some want them as separate households (adult independents). The right answer depends on the use case.
Step 1: Pick a household definition
Before matching, document what you mean by "household". For a nonprofit, it's usually "people who share a giving decision" — typically spouses, sometimes including adult children who give from a joint account. For a bank, it's "people whose finances are co-mingled" — spouses plus dependents. For a marketing team, it's "people at the same mailing address" — simpler but broader.
The household definition determines what signals the matcher can use. Same address is a weak household signal on its own (roommates); same address + same last name is stronger; same address + joint-name pattern in the record is stronger still.
Step 2: Handle joint-name patterns explicitly
The biggest win is teaching the matcher to recognize joint-name patterns as household identifiers. "John and Mary Smith" should match to the household record "Smith, John & Mary" — they're the same household, just formatted differently. Similarly, a singleton "Mary Smith" at the same address should match to the same household, even though her name alone isn't the household name.
In ListMatchGenie's donor reconciliation workflow, configure the match profile to treat "John and Mary Smith" / "Smith Family" / "John & Mary Smith" as equivalent. The engine preserves the original string for display but matches on the household key.
Step 3: Multi-field scoring for household confidence
Single-field matches aren't enough. You need to combine signals:
- Same last name + same address → likely household
- Same last name + same address + joint-name pattern → very likely household
- Different last names + same address → roommate? second marriage with different surname? investigate
- Same address only → weak, probably review-queue
Weight these so confident household matches auto-confirm and ambiguous ones go to human review. This is where probabilistic matching earns its keep — you're not trying to force a binary yes/no at the boundary cases.
Step 4: Preserve the individual records
Household matching doesn't mean collapsing individuals into a single blob. It means linking the individual records to a household identity. John still has his own email and phone; Mary still has hers. But the gift history, the mailing address, and the salutation are associated with the household.
This is why good household matching outputs include both sides of every match — the individual record from the source, the household record from the master, and the signals that tied them together. Your CRM then decides whether to merge, link, or leave separate based on the organization's data model.
Step 5: The review queue is critical
Household matching has more ambiguous cases than individual matching. Two people at the same address with different last names could be a second marriage, a parent and adult child, a landlord and tenant, or two roommates. No algorithm can tell without more context. The review queue is where your team brings that context.
Build the review UI (or use a tool that has one) to show the full household candidate side-by-side with the new record. Show the signals that agreed (address, phone) and disagreed (last name). Let the reviewer confirm, reject, or punt to someone more senior.
Industries where this matters most
- Nonprofits — household-aware donor giving rolls up correctly; joint gifts aren't split; acknowledgement letters go to the household.
- Financial services — household net worth for wealth management; joint account holders matched; family financial planning.
- Insurance — household policies bundled (auto + home + umbrella); dependents linked to primary policyholder.
- Real estate — co-buyers on a listing, co-borrowers on a mortgage, household-level outreach.
- Healthcare — family coverage, dependents under a primary subscriber.
If your data has any of these patterns, the default "match by individual identity" approach will leave money and accuracy on the table.
The short version
Household matching is a different problem than individual matching. Don't try to force it through an email-based deduper. Pick a household definition, teach your matcher to recognize joint-name patterns, combine multiple signals, preserve both sides of the match, and build a review queue for the ambiguous cases. If you're in an industry where households matter, the effort pays back the first time you stop sending two tax receipts to the same couple.
