The exception queue is the real control in governed reconciliation
By Equipo Quantum Developers
Summarize:
Governed reconciliation strengthens financial control when it turns every difference into an explainable exception with a stable code, evidence, owner, and verifiable closure instead of hiding the decision inside an autonomous matcher. Match rate can rise while control gets worse if nobody can explain which tolerance applied, why a case was accepted, or what happened to the unreconciled balance.
Matching and control are different problems
Matching proposes relationships between records. Control determines whether a relationship may be accepted, who may approve it, and what evidence must remain. An exact match on identifier, currency, and amount may pass a deterministic policy; a tolerated difference needs the rule version; multiple candidates or a missing source must become visible work.
The decision should not be a context-free confidence score. It should produce a result class and reason code. That output lets finance aggregate, assign, escalate, and learn without rereading free-form explanations.
The control loop in seven transitions
- Ingest: identify source, cutoff, version, and completeness.
- Normalize: align identity, currency, sign, time zone, and catalog.
- Match: apply controlled matching tiers in order.
- Decide: accept under policy or open an exception with a stable reason.
- Resolve: assign owner, required evidence, and permitted action.
- Verify: confirm the source-of-record change and accounting effect.
- Learn: propose rule changes separately from approval and deployment.
The final step does not authorize the agent to edit tolerances. A recurring pattern may create a proposal; the control owner assesses materiality, effect, and tests before versioning policy.
A queue contract, not an inbox
| Field | Control function |
|---|---|
| exception_id and reconciliation_run | identity and reproducible cutoff |
| object_refs | entries and candidate documents |
| reason_code/version | normalized cause and active catalog |
| amount, currency, materiality_band | exposure and applicable policy |
| evidence_refs | source, version, and permitted artifacts |
| proposed_resolution | suggested action, never implicit authority |
| owner and due_at | accountability and exception clock |
| approval_policy | who may accept, adjust, or escalate |
| status and state_history | open, under review, resolved, reopened |
| resolution_code and outcome_ref | closure method and later confirmation |
The queue needs filters for reason, age, exposure, source, and owner. “Pending” is not a sufficient category. Neither is a comment saying “looks right.”
Stable reasons, variable explanations
An initial catalog might distinguish exact match, within tolerance, missing reference, late source, duplicate, reversal, amount difference, currency difference, and multiple candidates. Codes remain stable while explanations incorporate case detail.
The ISO 20022 registration authority publishes external code sets that can evolve without a message-schema change. The operational lesson is to preserve catalog version and map external codes into governed internal reasons. Do not depend on provider text that can change without notice.
A reason is not automatically a root cause. “Missing reference” explains why matching stopped; the root cause might be an integration, merchant behavior, or capture rule. Keep both levels separate.
Matching tiers with visible boundaries
The first tier uses exact keys and invariant rules. The second applies approved transformations such as versioned formats or aliases. The third uses explicit tolerances by population. The fourth proposes ambiguous candidates for review. Do not put every case into one model and translate its score into “approved.”
Every tier records inputs, version, rejected candidates, and exit rule. If a source arrives after cutoff, the case retains a late-source reason and can resume; it must not disappear from measurement as if it never existed.
Illustrative example: settlement without a reference
This example is illustrative. A bank credit arrives without the expected reference. The matcher finds two sales for the same amount. Because candidates are multiple, policy prevents posting and opens an exception with both evidence records.
An analyst obtains an acquirer file, links the correct identifier, and selects “later evidence” as resolution. The system confirms posting and closes with outcome_ref. If another similar case appears, the agent may suggest an integration improvement, but cannot silently turn ambiguity into an approval rule.
The history answers what was known at opening, who resolved it, which new evidence changed the decision, and which entry was ultimately posted.
Evidence for control and audit
The GAO Green Book organizes internal control around objectives, risks, control activities, information, communication, and monitoring. The queue operationalizes that logic: it applies an activity, communicates a deficiency, and preserves remediation.
The audit family in NIST SP 800-53 Rev. 5 calls for record content such as event type, time, source, outcome, and associated identity. Although it is not an accounting standard, those fields help prevent records without an actor or outcome.
Do not copy credentials or sensitive payloads into each event. Use integrity-protected, access-controlled references.
Metrics that reveal control health
Measure eligible population, open items, unreconciled value, age by reason, time to ownership, time to evidence, reopenings, later adjustments, and ownerless exceptions. Separate straight-through matches, tolerance-based acceptances, and reviewed cases.
An aggregate match rate does not reveal whether queue exposure grew or closure required later adjustments. Trends by reason_code show where data, contracts, or integrations need repair.
Representing the loop in Quantum
In Quantum Automation Center, each reconciliation execution can link business objects, artifacts, logs, and status. The timeline retains decisions and retries; permissions and human approval express segregation; analytics group the queue by reason, owner, and outcome. The Quantum ontology connects entries, executions, and evidence.
The catalog should distinguish matcher, policy, and resolution flow so a model update cannot silently change a financial tolerance.
Counterargument: formal exceptions add friction
Managing a reason catalog and formal queue looks slower than accepting automatic matches, but effort should concentrate on material exceptions while straight-through processing remains available under approved rules. Automate classification, evidence retrieval, and preparation; preserve authority where consequences demand it.
An excessive catalog can fragment analysis. Merge codes leading to the same control and retain details as attributes rather than inventing a new reason for every case.
When not to use this loop
Do not build it for a small, fully deterministic population already reconciled by a system of record with sufficient evidence. Link that record rather than duplicate it. Do not use AI to replace an exact, stable rule or approve differences the policy has not defined.
If sources lack verifiable cutoff, identity, or completeness, repair the data contract first. A sophisticated queue cannot correct an unknown population.
The control test
Select a resolved item and reproduce its cutoff, candidates, rule, reason, authority, and outcome. Then aggregate all exceptions with the same reason and identify the improvement owner. If the only explanation is that the model “made a match,” automation exists; a financial-control loop does not.
