Post your first auditable reconciliation correction
Clone the Formance Ledger on GitHub, run it locally, and post your first reconciliation correction with reviewer, rule, and model-version metadata attached.
AI reconciliation models can rank matches, draft corrections, and auto-close high-confidence pairs. These models cannot own balance-changing decisions, repair duplicate postings, or satisfy audit requirements on their own.
Your Monday board deck shows a 94% auto-match rate on payment service provider (PSP) settlement lines. By Friday, the weekly sample shows the reversal rate has climbed from 2% to 7%. The matcher's auto-accept threshold dropped from 0.95 to 0.85 during the week, but no posting carries the rule reference or the model version that approved it. Your operations team cannot tell which closures to reopen.
Fintechs that can't produce that reconciliation trail on demand burn weeks of engineering time rebuilding it from logs. They also lose any defensible answer when the next auditor asks why the model closed a specific pair in production, because once the only record is a score, the argument is already lost.
How AI reconciliation layers rules, models, and LLMs
AI reconciliation layers machine learning and LLMs on top of deterministic matching rules.
Rules consume normalized postings and reported balances, then settle exact-reference and unique-amount pairs. The model takes the unmatched pairs the rules could not close and emits pairs with a confidence score and suggested classification.
LLMs sit on top of both, drafting the column mappings, exception narration, and corrective postings a reviewer then commits.
Four reconciliation tasks AI handles better than deterministic rules
AI reconciliation pays off in four places rules cannot reach: ranking ambiguous candidate pairs, classifying residuals as timing or real differences, drafting column mappings for changed settlement files, and drafting corrective postings with exception narration.
1. Rank ambiguous candidate pairs the rules missed
Supervised pairwise classification evaluates two records at a time and ranks the pairs that rules missed. Pairwise classification gives the reviewer a queue sorted by likelihood instead of a flat list of unmatched lines.
2. Classify residuals as timing or real differences
A model trained on effective-date patterns can label a pending-in-ledger, paid-at-PSP gap as a timing difference.
Timing differences are common in unmatched queues in payment operations, and treating each timing difference as a real break spends the review service level agreements (SLA) on items that clear at the next settlement cycle.
Formance is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability. It records bi-temporal effective dates in the ledger on ingestion, giving the AI model the effective-date signal it needs and lets the reviewer check the label against the rail's settlement window.
3. Draft column mappings for new or changed settlement files
When a provider renames a column or adds a transaction type, an LLM can propose a new mapping, and someone commits to it. Schema drift produces a flood of false exceptions in a multi-PSP pipeline.
Every unmapped field turns into unmatched lines that look like money problems but aren't. The commit stays with someone who knows what the renamed column means.
4. Draft corrective postings and exception narration
The model drafts the proposed journal and the explanation, grounded in the fields the model compared, so the reviewer edits the draft instead of composing from scratch.
Consistent inspection pays at the next audit sample. A reviewer sampling closed exceptions reads the same structure each time. The time from exception to decision drops because the amounts, dates, and rule involved are already on the page.
Five AI reconciliation failures that still need a human owner
AI reconciliation cannot fix duplicate postings from retries, repair N:1 batch settlements, exercise judgment on balance-changing actions, detect root causes before adjustment, or review itself.
1. Fix duplicate postings from retries and scheduling faults
AI reconciliation cannot see duplicate postings created before the settlement file is written.
A payout retried after a dropped response records the transfer twice, and a model reading the settlement file has no reliable way to see the duplicate because the PSP processed the payout once. A scheduling fault extends the same error to a batch.
Idempotency on the write path prevents the retry duplicate on your side and prevents a repeated settlement-file ingest from duplicating a batch fault in your ledger.
In the retry case, the duplicate sits in your ledger and not in the PSP's file. In a batch fault at the PSP, both legs go out and look like valid payments to any model reading the settlement file.
2. Repair N:1 batch settlements and multi-leg shapes
AI models cannot safely repair an N:1 settlement that nets captures, refunds, and chargebacks into one credit. A many-to-one, or N:1, settlement nets dozens of legs into one bank credit and breaks 1:1 logic.
A model can propose a mapping from settlement lines to postings, but committing the mapping changes how the provider interprets every future posting. That makes the commit a design decision, and a design decision needs a named owner.
3. Exercise judgment on balance-changing actions
Write-offs, accepted differences, and attribution changes on an omnibus account, a single account holding funds for many underlying owners, each demand a named human author with standing. AI models cannot exercise judgment on balance-changing actions.
On a 710-record evaluation split, only six contemporary LLMs reached 46% accuracy on balance sheets. LLM outputs should stay a draft, and the ledger posting should remain the record.
4. Detect root causes before any adjustment
Root-cause classification depends on context the model does not have. Whether a difference is reserve, fee, FX, or fraud turns on the provider's reserve policy, the contracted fee schedule, and the rate treasury booked.
A wrong auto-classification writes a false equivalence into the books and closes a real exception. The residual gets an owner and a documented reason before any posting adjusts the residual.
5. Apply independent effective challenge to the model
No model can review itself. The soundness, training data, and drift of the model need independent human review. Vendor models carry the same requirement, because the obligation does not transfer with the model.
Nine steps to implement AI reconciliation without failing audit
Implementing AI reconciliation requires nine steps: run the write path first, the decision boundary second, and the model last.
Step 1. Fix the write path before any model
Add an idempotency key to every payout and transfer so a retry returns the original result instead of booking twice. Persist the key alongside the resulting ledger transaction so a repeat request is answered from storage, not re-executed.
Record each effective date in the ledger's bi-temporal history on ingestion so a pending-vs-paid gap carries the effective date needed to classify the gap as timing or real.
Capture both the business effective date (when the economic event occurred at the rail) and the system ingestion time, because the model needs the business date to label timing differences and the auditor needs the ingestion time to reconstruct what was known when.
Step 2. Define the three-tier decision boundary
Tier 1 automates deterministic and high-confidence matches. Exact-reference pairs, unique-amount pairs, and model-scored pairs above the auto-accept threshold. Tier 1 matches close without human touch but still write a transaction carrying the rule reference, so a sampled closure answers the reviewer's "which rule?" question.
Tier 2 has the model draft and a person commit. Column mappings for new or changed settlement files, timing-vs-real classifications on residuals, exception narration, and suggested corrective postings. The reviewer edits the draft, and the commit stays with someone who understands what the renamed column or the pending status actually means at the provider.
Tier 3 belongs to a human with standing. Ledgers record the decision. Write-offs, accepted differences, omnibus attribution changes, and any posting that moves balances between beneficial owners all live here. Each Tier 3 action names an author in transaction metadata and cites the evidence the author relied on. A model may surface the case but does not close the case.
Step 3. Set confidence thresholds with stored rule references
Pick an auto-accept threshold, an auto-reject threshold, and the review band between the two. A false positive closes a real exception and may not surface for months, while a false negative costs a reviewer's time. Start conservative (for example, 0.95 accept, 0.60 reject) and tighten only after the Step 7 reversal rate justifies the tightening.
Store the rule reference and confidence score as transaction metadata for every posting the model touches, so a reviewer who asks why a specific pair closed gets a rule ID.
Record the threshold values in force at the moment of the decision, not the current threshold, because threshold changes must not retroactively re-explain past closures.
Step 4. Build the per-asset reconciliation check
Compare expected and reported balances per asset and per account path. A multi-currency PSP with a single aggregated balance hides drift inside FX conversion; splitting the check per asset exposes a USD, EUR, or USDC shortfall that another asset's surplus would otherwise mask.
Have your application route any out-of-tolerance residual to the review queue with the model's score, rule reference, and the two balances being compared attached.
Define tolerance in absolute units per asset, not as a percentage of volume, because percentage tolerances scale breaks with throughput and let real losses hide inside large settlement days.
Step 5. Record every reviewer decision as an immutable posting
Record a correction as a new compensating operation, with metadata attached at the transaction level. The original match is never edited or deleted because the correction sits next to it in history, and the balance reflects the net effect.
Because each posting is double-entry, every correction balances across source and destination accounts, so the ledger cannot drift. A reviewer can replay the decision sequence from the postings themselves, instead of inspecting a mutable final state.
Write the correction in Numscript, Formance's purpose-built language for describing financial transactions. The posting below reclassifies $12,445.00 of a card-settlement receivable as a reserve hold, with the reviewer, rule, confidence, and classification attached as metadata.
The same posting shape applies when the receivable is in stablecoin. Change the asset code and the account path, nothing else.
// RECONCILIATION_CORRECTION// Event: reclassify part of a card-settlement receivable as a reserve holdsend [USD/2 1244500] ( source = @counterparties:psps:cardProvider:receivable destination = @counterparties:psps:cardProvider:reserve:held)set_tx_meta("event_type", "reconciliation_correction")set_tx_meta("payout_id", "payout_example")set_tx_meta("reviewer", "a.okafor")set_tx_meta("rule_id", "amount-date-v3")set_tx_meta("confidence", "0.93")set_tx_meta("classification", "reserve_hold")
Step 6. Version model and threshold changes in the ledger
Store the model version and threshold as ledger transaction metadata for each posting so a decision replays against the version that made the decision.
Log every threshold change with old value, new value, author, reason, and effective date, and treat the change itself as a Tier 3 action.
A drop from 0.95 to 0.85 inflates headline match rates by double digits while raising the reversal rate; the threshold-change log makes the drop visible.
Step 7. Measure false positives by sampling reviewer reversals
Sample auto-closed matches on a fixed cadence (weekly for high-volume rails, monthly for low) and count how many later posted as corrections. Segment the sample by rule, by provider, and by confidence band so a rising reversal rate points to the rule or the file format responsible, not just to the aggregate.
The reversal rate tracks accuracy because the headline match rate counts closures without checking whether they held up. A pipeline running at a 94% match rate and a 6% reversal rate is incorrectly closing one in sixteen auto-closures.
When the match rate and reversal rate climb together, the model closes exceptions it should have routed to review, and the reversal rate catches those closures before the next sampling review does.
Step 8. Record each daily reconciliation with a queryable attestation
Capture the reconciliation point, frequency, time, date, actions, and outcome for each reconciliation day as a queryable record linked to the postings the record summarizes, not a log line. A reviewer can then walk from the daily attestation to the individual transactions, model scores, and reviewer decisions. Every closure leaves a traceable chain the next reviewer can replay.
Fintechs that reproduce the record from scattered logs on a deadline burn hours on reconciliation cleanup.
Formance Reconciliation handles drift detection and automated matching on top of the ledger, producing the queryable attestation record directly against the postings it summarizes rather than as a separate log stream.
Step 9. Apply effective challenge to the model
Assign independent reviewers with expertise and standing to assess the model's soundness, training data, drift, and the thresholds set in Step 3. The reviewer does not report to the matcher's operating team and has authority to require changes.
Scope the review wherever the model drives balance-changing decisions, including vendor models whose internals you cannot inspect, and tie the cadence to retraining and threshold changes.
Every AI reconciliation model starts with a ledger
AI reconciliation works only when the underlying system of record can carry rule references, confidence scores, reviewer identities, and model versions on every posting.
Without a ledger built for immutable, metadata-rich transactions, every tier of the decision boundary collapses back into application logs that no reviewer can replay. The write path, the three-tier boundary, the confidence thresholds, and the daily attestation all depend on the ledger recording the evidence.