In this article
Design defensible links instead of relying on equal amounts or familiar descriptions.
Begin with identity, not resemblance
Two records can look similar without describing the same event. An amount, a date and a familiar description may narrow a search, but each can repeat. A matching design should explain which identifier is created at each step and whether that identifier survives into the next system. Where an identifier is transformed, document the transformation rather than hoping a reviewer can infer it.
Keep business identity separate from source identity. An invoice reference describes a business object; an external transaction reference identifies a record in another system. The relationship between them may be one-to-many. Treating one as a universal key can fail when installments, adjustments or grouped settlements appear.
Specify the normalization rules
Formatting differences are common reasons for missed candidate links. A reference might arrive with spaces, punctuation or a different letter case. Normalization can help, but careless normalization can collapse distinct identifiers. Decide which changes are safe for each field, preserve the original value and test collisions with deliberately similar fictional examples.
Amounts need their own context. Currency, direction, precision and the meaning of a gross or net value belong in the comparison. Do not strip a currency label simply because every current sample uses the same currency. A future source change can turn that shortcut into a subtle mismatch. The same principle applies to accounts and legal entities.
Separate candidates from accepted matches
A candidate generator can be deliberately broad so it finds possibilities. The acceptance rule should be narrower and explainable. A reviewer needs to know whether a match was supported by a stable reference, an approved composite key or a manually assessed exception. These categories are an editorial design suggestion, not a description of a specific Modern Treasury matching engine.
For a fictional batch, three entries share a date and amount. One has the expected external reference; two have only a similar memo. A broad search may surface all three, but accepting all three would create duplicate relationships. Require the evidence appropriate to your flow and preserve ambiguity when the available data cannot choose safely.
Measure the rules, not just the hit rate
A higher match rate is not automatically better. A loose rule may produce more false matches and hide the very exceptions the process is meant to reveal. Review samples of accepted matches as well as unmatched cases. Record which rule version produced each result so that later rule changes can be assessed fairly.
When a source changes its format, rerun controlled examples before promoting a rule. Include repeated amounts, missing references, grouped activity and overlapping date windows. Keep a rollback path for the rule configuration without deleting the historical explanation of prior decisions. The goal is a matching process that a colleague can defend, not a number that looks good on a dashboard.
A fictional tabletop exercise
Construct a small fictional matching set with repeated amounts, two entities and one missing reference. Run the proposed rule by hand before implementing it. Mark every candidate relationship, then independently mark the relationships that meet the acceptance standard. Compare the two lists. A rule that finds many possibilities but cannot safely accept them may still be a useful search tool. It should not be labeled an automatic resolution rule. Keep these examples as regression cases when the rule changes. A future modification should explain any new accepted link, especially when the earlier version intentionally left an ambiguous case for a person to review.
Your working questions
- Which field identifies the event, and which merely helps locate possible records? Write down the distinction so a convenient search filter does not become an undocumented acceptance rule.
- Can normalization create a collision between two real-world identifiers? Test the edge case, keep original values, and make ambiguous candidates available for review.
- How will you detect a false match after the rule is deployed? Sample accepted links, track rule versions and retain enough evidence to explain corrections without rewriting history.
Use this as a discussion aid
The workflow in this article is an original educational framework. It is not a product configuration, accounting opinion, contractual promise or instruction to move funds. Keep real records in your organization’s approved systems, with the access and retention rules that apply there. A public documentation review cannot establish your permissions, bank coverage, implementation settings or operating agreements. Ask the authorized owner to verify those details before changing a process.
Source check: October 12, 2026. Product statements are limited to the linked official references below; fictional examples and proposed checklists are editorial teaching material. This independent publication is not Modern Treasury and cannot access an account or investigate a payment.
Continue the investigation
Separate event time, posting time and observation time · A return, a reversal and a correction are not interchangeable · Map the payment operation before choosing a workflow