Reconciliation matching rules: a reference

Every reconciliation engine is a stack of rules applied in order of confidence. The order matters more than the individual rules, because the first rule that fires wins and the ones after it never run.

This is the seven types, what each catches, and where each one is wrong.

The seven rule types

1 · Identifier match

The only rule that matches on meaning rather than on coincidence. A payment carrying a reference that identifies the invoice it settles can be matched with certainty.

Catches: anything where the link was preserved end to end. Fails when: the reference was truncated, reformatted or replaced in transit — routine on some rails and in some statement formats. Watch: references that identify the payer rather than the payment. ACME LTD tells you who; it does not tell you which invoice, and a payer with four open invoices produces four candidates.

2 · Exact match

Amount and date agree, one record, one line.

Catches: most routine one-to-one activity. Fails when: two invoices have the same amount — common with recurring services, retainers and subscriptions. Two $2,400 invoices from the same client and one $2,400 receipt is genuinely ambiguous, and an engine that picks the older one is guessing. Watch: date windows. A payment initiated Friday and settled Tuesday needs a window; too wide a window increases collisions.

3 · Tolerance match

Amount within a defined difference.

The rule to write narrowly and specifically. Tolerance should encode a known cause, not a general allowance:

Fails when: one wide tolerance covers everything. It then also absorbs transposed figures, genuine short payments and near-duplicates — invisibly, because matched items stop being examined.

4 · One-to-many

One bank line represents several records. The settlement case: a deposit covering forty invoices.

Catches: aggregated settlements, batch payments. Requires the breakdown. The bank line carries a total. Splitting it correctly requires knowing what it contained, which has to come from the payment platform or the payment itself. Without that, the engine can only try combinations that sum to the total, and at forty candidate records more than one combination will sum correctly. That is not matching; it is a plausible arrangement. Watch: fees. A settlement net of fees will not sum to the gross records at all until the fee is accounted for separately.

5 · Many-to-one

Several lines against one record. Part payments, instalments, a customer paying an invoice across two transfers.

Catches: staged and partial settlement. Fails when: the record is closed on the first payment, so the second has nothing to attach to. Watch: the invoice must stay open with a visible remaining balance — partial payment handled as “paid” is a common and expensive misconfiguration.

6 · Fuzzy match

Similarity in the description field.

Use for suggestion. Do not auto-post.

The description on a bank line was designed to fit on a bank statement, not to identify a transaction. Fuzzy matching infers meaning from evidence never intended to carry it. It is genuinely useful when it proposes a match a person confirms in one click, and expensive when it posts one nobody sees.

This suggest-versus-post setting is the single most consequential configuration choice in most matching engines, and it is usually left at whatever the default was.

7 · Rule-based treatment

Not really matching — a policy: anything matching this pattern gets this treatment.

Catches: the recurring, recognisable, low-value tail. Bank fees, subscriptions, standing charges. The failure mode is specific and quiet: a rule keeps working after the world changes. Written when a supplier sold you one thing, it keeps coding their invoices to that account after they start selling you another. The reconciliation completes, the money is in the wrong account, and because it balanced nobody looks.

A wrongly matched item is more dangerous than an unmatched one, because unmatched items are visible by definition. Review rules quarterly against what they currently catch, not what they were written to catch.

The order to apply them

1. Identifier — certainty first.
2. Exact — one-to-one, no ambiguity.
3. Tolerance, cause by cause, narrow.
4. One-to-many and many-to-one, only where a breakdown exists.
5. Rule-based treatment for the known tail.
6. Fuzzy, as suggestions in a review queue.
7. Everything else into exceptions, deliberately.

The last step is the one that gets skipped. An engine tuned so that nothing lands in exceptions has not solved reconciliation — it has hidden it, by matching low-confidence items automatically.

The metric to watch

Not match rate. Match rate at each confidence level.

A 95% match rate composed mostly of identifier and exact matches is a healthy process. The same 95% composed mostly of fuzzy and wide-tolerance matches is a monthly balanced set of books that may not be true, and there is no way to tell them apart from the headline number.

Where Fynex fits

Fynex is built so that rule 1 always applies. The payment carries what it settles — the invoice, the fee deducted, the settlement it arrived in — from the moment the payment is made, so the link is preserved rather than reconstructed from an amount, a date and a truncated string.

That removes the need for the lower rules rather than performing them better. Aggregated settlements arrive with their breakdown, so one-to-many is arithmetic instead of inference. Fees post as fees rather than as a tolerance. Part payments settle their portion and leave the remainder open.

Where you are matching from bank statements today, the order above is the right order, and the fuzzy suggest-versus-post setting is worth checking this week.

Related: unmatched transaction · payment reconciliation · Duplicate transactions in bank feeds · Reconciliation