Rules, AI and human review in payment reconciliation

The hybrid reference architecture

This article develops a specific control within automated reconciliation, keeping the sale, settlement and confirmation of bank receipt separate.

The design decision is not about which technology is newer. It depends on variability, verifiability, and reversibility. A step with structured input, a stable rule, and a testable result does not need probabilistic reasoning. An exception with free text and incomplete evidence should not be forced through a rigid macro. Neither technology should approve its own material effect.

The flow can be organized into eight layers with explicit contracts:

1. Capture and batch lock. An API or RPA collects files and confirms source identity, period, and fingerprint.
2. Deterministic normalization. Rules convert dates, currencies, references, and codes into a common schema; invalid input enters quarantine.
3. Deterministic matching. Exact keys, approved tolerances, and source states resolve explainable cases without AI.
4. Exception preparation. The system creates an object containing the difference, available evidence, preliminary reason, and permitted actions.
5. AI-assisted classification. The model interprets text or context, proposes a category, and names the evidence supporting its recommendation.
6. Policy gate. Rules outside the model verify amount, segregation, state, confidence, permissions, and prohibitions.
7. Approval and execution. A person authorizes the material effect; an API or RPA records it idempotently.
8. Verification and ledger. An independent read confirms remote state and links input, decision, execution, and outcome.

The OMG BPMN 2.0.2 specification provides a formal notation for processes containing tasks, events, gateways, and human participation. It does not mandate this architecture, but it supplies an important discipline: explicitly model where the work type changes and who receives control.

A rule for assigning each step

Classify a step before choosing its technology:

Model-reported confidence does not make an exception deterministic. Transition must also depend on evidence completeness, difference type, current policy, and reversibility. A polished recommendation can still be wrong.

What to do when amounts match but references do not

Illustrative example: the POS contains two COP 120,000 sales at the same store. The acquirer report contains a payment for that amount, but its reference is not the ticket number. Choosing the closest sale by date can produce a convincing but incorrect match. First check whether the authorization, terminal, merchant or processor reference establishes a unique relationship.

The deterministic rule must distinguish zero, one and multiple candidates. A unique candidate is acceptable only when it satisfies approved fields and tolerances. When two candidates remain, an AI-generated explanation can help a reviewer locate evidence, but cannot replace the missing fact. The outcome is pending identification, not reconciled with low confidence.

After identifying the sale, settlement and bank credit still need reconciliation. A correct reference does not establish that the fee matches the agreement or that the bank received the net amount. These checks need separate outcomes so a successful match does not conceal a financial difference.

The reviewer must be able to reconstruct the source files, rule version and reason a candidate was accepted. A rule change should be tested against known operations that previously produced zero, one and multiple candidates. Measuring only match rate risks rewarding false matches.

The reconciliation-object contract

Every layer should operate on the same identity. A minimum object includes:

The W3C PROV Data Model distinguishes entities, activities, and agents, along with derivation and responsibility relationships. Applied here, transactions are entities; normalization, classification, and posting are activities; software and people are agents with different roles. That structure prevents model explanation from becoming the only lineage.

Illustrative example: an ambiguous reference

Assume a bank transaction contains an abbreviated reference that does not exactly match an account receivable. The identifiers and conditions are illustrative. Normalization validates date, currency, and amount; exact matching finds no key. Rather than trying combinations through RPA, the flow creates an exception.

AI compares the text with authorized documents and proposes a candidate account, citing the artifacts it used. The gate checks that the account is open, the amount is compatible, and the agent lacks permission to apply the payment. An analyst accepts or rejects. Only then does the robot open the legacy system, record the application with an idempotency key, and exit. An independent read confirms state; if it differs, the case stays open.

Each technology performed the work it could demonstrate. AI did not write, RPA did not interpret ambiguity, and the person did not have to gather all evidence manually.

Failure is isolated by layer

The architecture also defines continuity:

• when a schema changes, quarantine occurs before classification;
• when the model is unavailable, the ambiguous queue waits while exact matches continue;
• when the policy gate fails, no material write is released;
• when RPA loses confirmation, remote state is queried before retry;
• when no approver is available, escalation does not become approval;
• when verification disagrees, the object is not marked reconciled.

The NIST AI Risk Management Framework Core calls for defined human-AI roles, oversight, and controls for third-party components and data. Separate layers make it possible to apply controls to the component introducing risk instead of treating the agent as one box.

Representing the architecture in Quantum

The public daily reconciliation capability provides business context. In Quantum Automation Center, the object can bring together status, runs, timelines, artifacts, logs, and human approval. The public Quantum ontology documentation helps preserve one business identity across agents and automations.

Quantum does not turn interpretation into a deterministic fact or replace financial policy. Its value here is exposing the boundaries: which component proposed, which one validated, who approved, which robot executed, and which read verified.

The counterargument: an end-to-end agent is simpler

On the surface, yes. One interface that reads, decides, and posts reduces initial orchestration. But that simplicity concentrates classification, permissions, retries, and evidence. When a write is uncertain, the team must reconstruct whether interpretation, policy, or execution failed. The hybrid architecture accepts more contracts in exchange for localized testing and recovery.

Do not add layers for aesthetics. If a step can be a rule, keep it a rule. If an API replaces brittle screen interaction, retire RPA. If the person always rebuilds the recommendation, remove AI or improve context before adding autonomy.

When not to use this architecture

Do not use AI when stable keys and tolerances resolve every relevant case. Do not use RPA when the system provides a reliable, auditable API. Do not build an intelligent exception queue when ambiguous cases are so rare that manual review is cheaper and clearer.

And do not automate the material effect when segregation, reversal, and independent verification cannot be defined. The hybrid architecture is not a way around those decisions. It is a way to express them as executable gates and evidence that survives every component.

• Unique candidate with evidence
• Fee checked separately
• Bank credit confirmed