A deposit rarely names its sender cleanly
Look at the reference field on a typical membership dues deposit and it's rarely a clean, unambiguous statement of who sent it. It's a surname with no first name, a payment app handle, a code a processor generated, or — often enough — nothing at all beyond “bank transfer.”
Matching that deposit to an actual member on your roster is a small inference problem repeated hundreds of times a year, and this page describes exactly how that inference is made — what evidence it uses, when it's confident enough to call something a match, and when it isn't.
It's a narrow problem by design. This page doesn't cover reading the statement itself, or what happens to the matched result afterward — those are covered in membership dues reconciliation. What follows here is specifically the matching logic in between.
Why no single signal is enough on its own
It's tempting to think matching is just string comparison — does the reference contain the member's name? In practice that alone produces both false confidence and missed matches, because each signal has a specific way it fails.
| Signal alone | How it fails |
|---|---|
| Reference text only | A common surname matches more than one member; a nickname matches none literally |
| Amount only | Every member on the same dues tier pays the identical figure |
| Timing only | Renewal season concentrates dozens of payments into the same few days |
Combined, the three signals cover for each other's weak spots — a reference too vague to trust alone becomes trustworthy once it's the only person on the roster with that name paying that exact amount that week.
What gets read
| Field | Notes |
|---|---|
| Reference or memo text | Read exactly as it appears, abbreviations and all |
| Deposit amount | Compared against each member's expected dues for their tier |
| Deposit date | Compared against typical renewal timing for that member |
| Roster name and ID | The pool of candidates a deposit is matched against |
Confidence levels, not a single yes or no
Every match carries a confidence level rather than a flat matched-or-not label, because treating a strong three-signal match the same as a weak one-signal guess would hide exactly the information a treasurer needs to know where to look twice.
High confidence
Reference, amount and timing all agree with one member and no one else on the roster. Shown as matched.
Medium confidence
Two of the three signals agree strongly, the third is missing or ambiguous. Shown as a suggested match to confirm.
Low confidence or none
No combination of signals points clearly to one member. Shown as unmatched, with whatever partial information exists.
When one deposit covers many members
Payment processors that collect dues on an association's behalf frequently settle in batches — dozens of members' payments arriving as one lump-sum deposit on the bank statement, days after the individual payments were actually made.
The bank statement alone can't attribute that lump sum to anyone; the per-member breakdown lives in a separate settlement report the processor generates. Reading both together — the statement for the total that actually landed, the settlement report for who contributed what to it — is what makes matching a bulk deposit possible at all.
A settlement, broken down
One bulk deposit of $2,340 lands on the statement from a payment processor, with a settlement report listing 26 member payments that fed into it.
| Step | What happens |
|---|---|
| Statement read | One deposit, $2,340, dated the 3rd, reference is the processor's batch ID |
| Settlement report read | 26 line items, each with a member name and individual amount, summing to $2,340 |
| Cross-check | The 26 individual amounts are confirmed to add up to the single deposit |
| Member matching | Each of the 26 names is matched against the roster individually |
The result is 26 individually matched member payments instead of one opaque lump sum — and the cross-check step matters on its own: if the settlement report's line items didn't sum to the deposit total, that mismatch would be surfaced rather than silently ignored.
How it works
Upload statement, roster, and settlement reports
Whatever documents exist for the period — the roster doesn't need reformatting first.
Every deposit and line item is read
Amount, date and reference text, kept linked to its source document.
Matched against the roster
Reference, amount and timing combined into a confidence level per match.
Export
Matched, flagged and unmatched groups, each with its confidence level and evidence.
The same four steps run whether the source is a single clean bank statement or a mix of statement, settlement report and a hand-maintained roster spreadsheet — the reading step normalizes whatever comes in before the matching step ever runs.
The same person, five different names
One member can appear on a bank statement as “J SMITH,” on the roster as “Jane Smith,” on a joint account as “J & R SMITH,” on a payment app as a handle bearing no resemblance to either, and on a paper check with a maiden name the roster was never updated with.
Matching is tolerant of common variations — initials, order, joint-account formats — without stretching into pure guesswork. A maiden name or a payment app handle that shares no readable text with the roster entry is exactly the case where amount and timing carry the weight, and where a low-confidence flag is the honest outcome rather than a confident-looking wrong answer.
When two members could both be the match
Common surnames are the clearest case where a single signal misleads. Two members named Patel, both paying standard dues, both renewing in the same month — a reference that just says “PATEL” can't distinguish them on text alone.
When more than one roster entry is plausible, the deposit is shown against both candidates rather than assigned to either — the honest answer when the evidence genuinely doesn't distinguish them, and a five-second decision for a person who knows the two members apart in a way the document doesn't.
A roster that gets more useful over time
The first time a member pays from an unfamiliar reference — a new bank, a name variation the roster hasn't seen — that payment is more likely to need confirmation. Once confirmed, the same reference reappearing next renewal cycle is recognizable, and matching that specific member gets more confident with each period rather than starting from zero every time.
That improvement is a natural effect of reading every statement the same consistent way, not a setting anyone has to configure or a model that has to be retrained.
Not generic bank reconciliation
Worth distinguishing this from bank reconciliation in the accounting sense — matching a bank line to an entry already recorded in a ledger. That's a different problem with a different structure: the ledger entry usually already states who and what, and reconciliation is confirming the bank agrees.
Member payment matching starts from less: a bank line and a roster, with no ledger entry yet naming who paid. The matching itself is what creates that missing piece of information, rather than confirming information that already existed elsewhere.
That difference is why a generic bank reconciliation tool, built for the confirm-what-you-already-recorded case, tends to handle membership dues poorly — there's nothing pre-recorded to reconcile against, only a roster of who's expected to pay and a statement of what actually arrived.
Who uses this
Treasurers
Turning a statement into a paid/unpaid list without transcribing every line by hand.
Membership committees
A current, evidence-backed answer to who has renewed this cycle.
Chapter and branch finance staff
The same matching applied consistently at every local level before rolling up.
Bookkeepers serving associations
One repeatable process across every client's roster and statement format.
All four groups are, at bottom, asking the same question in different words: whose payment is this. Answering it consistently is what the matching itself provides, regardless of which role is asking.
How matching improves as more statements go through
The first statement matched against a roster produces the weakest results the process will ever produce, because nothing yet exists to compare unfamiliar references against beyond the roster itself. Every statement after that improves on the one before it, for a specific reason: a reference confirmed once becomes a known pattern the next time it appears.
A member who pays from a joint account under a spouse's name is a low-confidence match the first time — flagged, confirmed by a person, and resolved. The second time that same joint-account reference appears, the system has already seen it confirmed once before, and the match comes back with meaningfully higher confidence without anyone having to re-confirm it from scratch.
That improvement compounds across a membership base over several cycles — not because anything about the underlying method changes, but because the pool of previously-confirmed reference patterns keeps growing, and each new statement benefits from everything the previous ones already resolved.
It plateaus rather than climbing forever, which is worth expecting rather than being surprised by. Once most of an association's regular payers have a confirmed reference pattern on file, each new cycle's confidence improvement gets smaller — the process has essentially learned the membership base, and what remains flagged tends to be genuinely new situations rather than a backlog working itself down.
Every match keeps its evidence
A matched result that just says “paid” next to a member's name is only half the record. What makes a match defensible later — when a member disputes a charge, or a board member asks how a specific figure was reached — is being able to point to exactly which deposit, on which date, with which reference, produced that conclusion.
Every match carries its evidence forward: the original deposit amount and date, the reference text as it appeared, and the confidence level assigned. None of that gets collapsed into a single yes-or-no once the matching runs — the reasoning stays attached to the result, not discarded the moment a decision is made.
That distinction matters most in exactly the situations where it's needed: a member insisting they paid when the roster shows otherwise, or a new treasurer trying to understand why a predecessor resolved an ambiguous case one way rather than another. An answer backed by the actual bank line is a very different conversation than one backed by someone's recollection.
What the exported result actually contains
The output isn't a single flat list — it's structured so that each of the three outcomes can be worked with on its own terms, because a treasurer's next action differs depending on which group a payment landed in.
Matched: member, amount, date, reference and confidence level, ready to mark paid.
Flagged: the same fields plus the specific reason confirmation is needed — an ambiguous name, a mismatched amount.
Unmatched: whatever partial information exists on the deposit, with no member attached, kept visible rather than dropped.
Splitting the export this way means each group can be handed to whoever needs it — the matched list straight to the membership roster, the flagged list to a person for a five-second confirmation, the unmatched list to whoever investigates gaps — without anyone having to first sort a single undifferentiated file by hand.
The format is a plain spreadsheet, not a proprietary file only one tool can open — a deliberate choice, since the whole point is feeding results into whatever the association already uses, not adding another system to depend on.
What this doesn't do
Doesn't force a match below confidence
An ambiguous deposit stays flagged rather than being assigned to whichever member seems statistically likelier.
Doesn't update your roster
It matches against the roster you provide. Keeping member records current remains your membership system's job.
Doesn't decide membership status
It reports what matched and what didn't. Policy about late or missing payments is yours to apply.
Doesn't work from a roster with no expected amounts
Matching needs a rough expected amount per member to use as a signal — a roster with names only, no dues tier, weakens the match considerably.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Member and financial data are never used to train AI models.
Full details are on the security page.