Reconciliation Software: What Actually Separates Platforms

Matching is a solved problem. Investigation is not.

Every reconciliation platform on the market matches well. One-to-one, one-to-many, many-to-many, tolerance-based, fuzzy on reference strings. On a typical population these techniques clear the overwhelming majority of items automatically, and the difference between vendors at this layer is marginal.

The remaining minority consumes the overwhelming majority of the effort. Each unmatched item requires someone to form a hypothesis, gather supporting records from other systems, test the hypothesis, and record a conclusion. That work is analytical, repetitive, and expensive, and it is what reconciliation teams actually spend their days doing.

Traditional automation addresses this by adding rules. Each recurring break pattern becomes a rule, the rule library grows, and the library eventually becomes its own maintenance burden. Rules are also brittle: a counterparty changes a file format or a reference convention and the rules that depended on it silently stop matching.

The meaningful advance is not more rules. It is an engine that performs the investigation itself: forming the hypothesis, retrieving the evidence, testing it, and recording the reasoning in a form a reviewer can audit.

Ingestion determines time to value

The gap between a purchase decision and a working reconciliation is usually a data problem. Sources arrive as bank statement formats, delimited extracts, spreadsheets with a header block, fixed-width files, scheme reports, and APIs, and each historically required mapping by a specialist.

Schema mapping driven by a language model changes this economics materially. The engine reads an unfamiliar file, infers the meaning of each column from its content and header, proposes a mapping, and asks for confirmation only where confidence is low. Weeks of configuration become an afternoon.

The related and often overlooked requirement is resilience to change. Source formats drift. A platform should detect a changed schema and re-map it rather than failing the load or, worse, loading it incorrectly.

Controls, evidence, and why reconciliation is a control not a report

A reconciliation is a control. Its output is not a report; it is assurance that two independent records agree, and that any disagreement has been identified, explained, and resolved by an accountable person.

That framing dictates the evidential requirements. Each run needs fixed inputs, a recorded methodology, a complete break population, an explanation and disposition for each break, an attributable reviewer, and a record that cannot be amended after the fact without detection.

Most platforms deliver the first five. The sixth is where audit challenge concentrates, because a database record is editable by definition and its current state does not evidence its historic state. Cryptographic sealing, in which each run is hashed and the hash committed at execution, is what converts an assertion of control into a testable one.

What agentic reconciliation changes

An agentic engine treats each break as a task rather than a queue entry. It has access to the underlying systems, it can retrieve additional records, and it iterates: form a hypothesis, gather evidence, test, revise, conclude.

It also has memory. When a specific counterparty's settlement behaviour has been characterised once, that understanding persists and is applied to subsequent breaks involving the same counterparty. The engine gets better at the firm's particular data rather than staying static.

Confidence gating is the control that makes this safe. Where the engine's confidence in a conclusion is high and the value is within threshold, it resolves with its reasoning attached. Where confidence is lower, or value is higher, it escalates to a named reviewer with the analysis already performed. The human decides; the engine does the work of preparing the decision.

Safeheld's position

Safeheld is built as an autonomous reconciliation engine rather than a matching tool with workflow attached. Ingestion is format-agnostic with automated schema mapping. Reconciliation is continuous rather than batch. Investigation is performed by the engine with persistent memory of counterparty behaviour and confidence-gated routing to human reviewers.

Every run is sealed with a SHA-256 Merkle root, and any party holding a sealed run can verify it independently, without access to the firm's systems.

Regulatory overlays sit on top of that engine rather than beside it, so a firm reconciling under a specific regime gets the regime's timing rules, thresholds, and reporting artefacts from the same runs that produce its operational positions.

Frequently asked questions

What is the difference between rules-based and agentic reconciliation?

Rules-based automation clears breaks that match a pre-written pattern and queues everything else for a human. Agentic reconciliation investigates the remaining breaks itself: it forms a hypothesis, retrieves supporting evidence, tests it, and either resolves with reasoning attached or escalates with the analysis already done.

How long does implementation usually take?

Time to value is governed by data access rather than software configuration. Where source feeds are available, automated schema mapping typically produces a first working reconciliation within days, followed by a period of parallel running against the incumbent process.

Why does cryptographic sealing matter for reconciliation?

Because a stored record proves its present state, not its historic state. Hashing each run at execution and committing the hash means any later amendment is detectable, which turns the firm's assertion that a control operated into something an auditor can independently test.