The pair that looks right still needs a reason

Two records have the same amount, nearby dates and a similar reference. A reconciliation product can recognise that resemblance quickly. The harder question is whether they describe the same event or obligation. In a large population, several records may satisfy the superficial criteria. Choosing one can make a queue smaller without making the financial conclusion better. I want engineering teams to understand that distinction before a matching percentage becomes a sales promise. A product can help an institution organise evidence, but resemblance does not give the supplier authority over the customer's accounting decision.

Similarity is evidence rather than authority

Matching rules often begin with sensible observations. A reference is likely to recur across related records. Amount and date can narrow the search. A combination of fields can provide stronger evidence than one field alone. The weakness appears when the rule's assumptions are forgotten. A reference may be unique only within a source or period. Several transactions may share an amount. A date may describe processing rather than the underlying event. The product must preserve enough context to distinguish a reliable relationship from a convenient pairing that happens to satisfy the current rule.

The responsible design includes a way to express uncertainty. If more than one candidate remains plausible, the system should not silently convert that situation into certainty because a ranked list requires a first item. A score can help organise review, but its position in a list does not establish that the highest candidate is correct. I ask what evidence would distinguish the alternatives and whether the product has it. If the answer depends on a client specialist's judgement, the workflow should make that judgement possible and retain its basis. Hiding the ambiguity merely relocates the work to a later dispute.

Our proposed release was tested against 8,200 historical record pairs that the participating client's authorised team had already adjudicated. Fifty-four suggested pairings were plausible under the proposed rules but wrong against that reviewed relationship. The figure was not a count of realised customer losses or live account corrections. It was evidence that the automatic path needed narrowing before release. We examined the groups involved rather than remove only the fifty-four known examples. Excluding ambiguous same-value groups reduced the simulated automatic-closure rate from 91% to 76%, leaving more work for an explicit review process.

The client's responsibility remained visible throughout. We supplied the product and explained the evidence behind its behaviour. The institution approved its use and retained authority over closure rules and accounting treatment. That boundary should not become an excuse for weak engineering. A supplier cannot responsibly say that every consequence belongs to the client while concealing the assumptions in its own recommendation. We need to make those assumptions accessible enough for the client to evaluate the product, configure it appropriately and understand where a proposed result needs human examination.

Make the difficult groups part of the test

A demonstration dominated by easy matches can produce a reassuring percentage while teaching little about the cases that matter. The test population should include the circumstances that could defeat the rule: repeated values, reused references, partial records and different meanings attached to dates. The exact cases depend on the product and the institution. The point is to choose evidence capable of challenging the proposition, not simply a volume large enough to make the result look substantial. Thousands of ordinary examples do not substitute for a small group that exposes an unsupported assumption.

Historical adjudication is useful evidence, but it also needs scrutiny. We should understand who made the earlier decision, what records were available and whether the population is appropriate for the proposed use. A system trained or tested against inconsistent decisions may reproduce inconsistency confidently. In our review, client specialists explained the basis of the relevant relationships and helped examine the disagreements. The engineering team did not treat a stored status as an unquestionable truth without understanding how it had been established. Evidence is stronger when its origin can be followed and its limitations stated.

We also needed to preserve the test conditions. If a later report changes the population, the exclusions or the meaning of automatic closure, a percentage may no longer be comparable with the earlier figure. I want the release record to show what was examined and why a group moved to review. That allows a future team to understand whether a higher rate reflects a better rule, a different workload or a relaxed condition. Without that record, the company can gradually lose the reasoning behind a cautious design while retaining only a complaint that the product does not automate enough.

The test should examine the review path as well as the automatic one. Referring a record to a person is not useful if the person cannot see the source, the candidates and the reason for referral. A queue labelled ambiguous can become another form of opacity. We worked with delivery colleagues on the evidence shown to the client reviewer and on the record of the resulting decision. The aim was to make the remaining judgement efficient and accountable, rather than claim that human involvement itself made the product safe. People need a workable task, not an unexplained exception count.

Price the review work honestly

Sales colleagues were right that 76% was less attractive than 91% in a demonstration. It implied more work for the institution and a narrower immediate benefit. I did not try to remove that consequence from the discussion. The alternative was to sell a headline whose meaning depended on allowing ambiguous groups into the automatic path. A responsible commercial proposition should explain which work the software removes, which work it improves and which judgement remains. That may produce a smaller promise, but it gives the customer a basis for estimating the service it will actually operate.

Review work also has a cost inside the supplier. The product needs evidence displays, workflow states, decision records and support knowledge. Those features can seem less exciting than another matching technique, but they determine whether the institution can handle the cases the algorithm appropriately declines. Engineering investment should reflect the whole product, including the work left outside automation. If the roadmap rewards only the automatic rate, teams may be tempted to hide ambiguity or make the manual path progressively less usable. The measure should support the service rather than distort its development priorities.

For directors of a software company, the useful question is what stands behind a performance claim. They can ask how the test population was chosen, what the product treats as a match and who remains responsible for a financial conclusion. They do not need to choose individual rules. They should understand whether a commercial promise is supported by the evidence and whether the continuing review burden has been considered. A board paper that presents a single percentage without its meaning can invite approval of a proposition materially different from the one engineering has actually tested.

The best outcome is not the largest number of records closed automatically under any rule we can invent. It is a product that helps the institution distinguish established relationships from unresolved ones and act on both responsibly. That requires explanation, a useful review path and honest economics. Our narrower release accepted more visible work because the evidence required it. I would make that choice again: a pairing that looks right should remain open to examination until the reason for treating it as right can be stated and supported.