Flo

Transaction Reconciliation

Template-driven, two-tier matching between partner files and your ledger.

Financial institutions and PSPs receive settlement files, bank statements and gateway exports every day. Reconciling them against the internal ledger is slow, error-prone, and a mandatory control for accurate financial reporting. It is also where finance teams quietly lose whole days each month.

LedgerFlow's reconciliation engine is built around reusable, configurable templates. Each template captures how one partner's file format maps to your ledger — columns, data types, timezone conventions, amount tolerances and text extraction rules. You configure a partner once. After that: upload, match, and get a precise breakdown of confirmed matches, items needing review, and genuine exceptions — with a full audit trail from import through to resolution.

KYC & Verification →

How It Works — One Workflow, Five Stages

Reconciliation follows a straightforward path from raw partner file to resolved exception:

Stage	What happens
1 · Configure	Define the partner relationship once — file layout, tolerances, extraction rules
2 · Link	Attach the ledger accounts this partner settles against
3 · Upload	Submit a file; it is validated against the stored format before anything is accepted
4 · Match	The two-tier engine compares partner rows against your ledger
5 · Review	Confirmed matches, items for review, and exceptions on both sides

Each stage has its own screen and can be revisited independently. Adjusted a tolerance? Re-run matching without re-uploading the file. Nothing is destructive, and nothing forces you back to the start.

Every import keeps a permanent audit record — the file, who loaded it, when, the period it covered, and how many rows matched — so a reconciliation performed months ago can still be explained.

End-to-End Pipeline — Template to Results

The diagram shows the pipeline from configuration through to matched results and exceptions.

Strict match (green) — every configured criterion is satisfied at once: the amount is within tolerance and the date and time are within variance and all mapped identifiers agree. High-confidence, independently verifiable, no review needed.

Loose match (orange dashed) — the identifiers agree, but the amount or date sits outside tolerance. Rather than silently accepting or silently dropping these, the engine surfaces them for a human decision: is this an expected partner fee, or a real discrepancy?

That two-tier distinction is the practical difference between a tool that reconciles and a tool that just reports a percentage. Anything auto-matched is genuinely certain; anything uncertain is put in front of a person with both values side by side.

Strict always wins. A row already strictly matched is never downgraded, so re-running with wider tolerances can only ever promote loose matches to strict — never the reverse. Re-running is always safe.

Matching stays fast at scale because the engine narrows the search to the period the file actually covers before it compares anything — so a one-week statement is matched against one week of ledger activity, not against your entire history.

Creating a Template — Upload a Sample

Every partner relationship starts with a template, and creating one starts with a sample file.

Upload a sample (header row plus at least one data row) and LedgerFlow reads it for you: it captures the column names, infers the type of each column — numeric, date, time, identifier, structured data or plain text — and stores a sample row to work against.

That inference is what turns a specification exercise into a five-minute task. You are correcting a sensible first guess rather than describing a file format from scratch.

The template is created immediately; mapping and tolerances come next, guided by the inferred types. You can return later to refresh the sample without losing any of your existing configuration.

Column Mapping — Point Fields at Your Ledger

Next, map each column in the partner file to the ledger concept it represents:

Mapped field	Purpose
Debit amount	The value column for money out
Credit amount	The value column for money in
Date & time	Combined, or split across separate date and time columns
Description	Free-text memo or narrative
Reference	Confirmation number, cheque reference, payment ID
Application identifier	The partner's own transaction identifier
Transaction identifier	A transaction-level unique identifier
Supplemental data	Any additional structured payload

Only map what the file actually contains — anything unmapped is simply ignored during matching, so a sparse partner file needs no workarounds.

The configuration screen shows live sample data next to each selector, so you can see exactly what you are mapping instead of counting columns in a spreadsheet.

Tolerances — Built for Real-World Data

Partner files are never perfectly aligned with your ledger. Reconciliation tools that demand exact equality generate mountains of false exceptions and get abandoned. Two tolerance settings widen the window without giving up precision:

Time variance (0–120 minutes) — settlement files routinely report the partner's local time, or carry processing lag between the event and the report. The variance window extends the comparison in both directions so that a genuine match is not rejected over a clock difference.

Amount variance — inter-bank fees, foreign exchange rounding and platform charges create small systematic differences. A configured tolerance absorbs them, so a 2-cent rounding difference does not land on an analyst's desk.

Timezone handling — partner timestamps are interpreted in whichever timezone that partner reports in, and normalised before comparison. All standard IANA timezone identifiers are supported, so a partner in Johannesburg and one in New York can both be reconciled correctly against the same ledger.

Text Extraction — Find the Reference Anywhere

Partner files love to bury the identifier you actually need inside a larger blob of text — a narrative field containing a reference, a description with an embedded payment ID, a structured payload with the key three levels down.

LedgerFlow applies per-field extraction rules before comparison, so it can reach in and pull out the value that matters:

Pattern extraction — pull a reference out of a longer text field using a configurable pattern.
Structured-data extraction — pull a specific key out of a structured payload on either side.
Combined — extract a reference from the partner's free-text field, and match it against a value held deep inside your own structured transaction data.

This is the difference between reconciling a partner automatically and telling finance "that one has to be done by hand". Every extraction rule is previewed live against your sample row before you save, so you can see it working before you trust it.

Linking Ledger Accounts to a Template

Before importing, link one or more ledger accounts to the template. The engine only ever searches transactions belonging to those accounts — the scoping mechanism that prevents cross-account contamination and keeps matching fast.

Currency consistency is enforced by the platform, not by procedure. The template's currency must match every account linked to it, and all accounts on one template must share a currency. These are hard constraints enforced at the core, so reconciling dollar transactions against a euro account is not a mistake you can make — not through the UI, not through the API, not through an integration written by a third party. To handle multiple currencies from one partner, use one template per currency.

Multi-account templates cover the common case where one partner statement spans several of your internal accounts — a settlement account and a fees suspense account, say. The engine searches all linked accounts at once and attributes each match to the correct one.

Loading a File — Validated Before It Lands

Importing a file against an existing template takes three steps: choose the template, describe the batch ("ACME May settlement, week 3"), and upload.

Before a single row is accepted, the uploaded file's structure is validated against the stored template. If the partner has quietly changed their format — a new column, a reordered field, a changed type — the import stops and reports exactly what differs.

That check matters more than it sounds. The classic reconciliation disaster is not a failed import; it is a successful import of a file whose columns shifted by one, producing thousands of confident, entirely wrong matches. Here that cannot happen silently.

Once validated, every row is stored with a full audit record: the filename, the timestamp, who loaded it, the period covered and the row count.

Duplicate Protection

Every row carries a unique fingerprint of its exact content, and the platform refuses to store the same row twice.

What happens on a duplicate: the row is skipped and recorded separately, with a reference back to the original. Nothing is lost, nothing is double-counted, and you get an exact list of what was skipped and why.

What counts as a duplicate: the entire row, character for character. A single genuine difference produces a different fingerprint. That is deliberate — it catches an accidental re-import of the same file, while still allowing a corrected re-upload of rows you previously rejected.

This prevents the single most common and most expensive reconciliation error: importing the same settlement file twice and generating double-counted matches that nobody notices until the month-end numbers do not agree.

Duplicate lists can be downloaded for partner queries.

The Two-Tier Matching Engine

Matching runs in the background. Submit a run and the platform queues it, works through it, and notifies the screen live when it finishes. Nobody sits watching a browser tab, and a large file cannot time out mid-reconciliation.

Before matching, the data is normalised. Every partner row is unpacked according to your column mappings, converted to the correct type, timezone-adjusted, and put through any extraction rules you configured — so the comparison happens between two clean, comparable sets of values rather than between raw text and structured ledger data.

Then the engine narrows the search. It works out the period the file covers, widens it by your tolerance, and confines matching to that window. This is why reconciliation stays fast as the ledger grows: a week's statement is matched against a week of activity whether your ledger holds a million transactions or several billion. Reconciliation time tracks the size of the file, not the size of your history — which is precisely the property that reconciliation tools tend to lose in year three.

Precedence is guaranteed. A confirmed strict match is never overwritten by a weaker one, so re-running after adjusting tolerances refines results in one direction only. You can experiment with settings without risking work already done.

Reviewing Results — Four Clear Answers

When matching completes you get four views — and, more usefully, four decisions already made for you:

Strict matches — every criterion agreed. High confidence, no review required. This is the pile you do not have to look at.

Loose matches — identifiers agreed but an amount or date diverged. Surfaced for human review with the partner value and the ledger value side by side, so an operator can tell at a glance whether it is an expected partner fee or a real problem.

Partner exceptions — rows in their file that are not in your ledger. Either transactions you need to post, or activity outside the scope of this template.

Ledger exceptions — transactions in your ledger with no counterpart in their file. Reversals, internal transfers, or genuine discrepancies to raise with the partner.

A day-by-day summary compares transaction counts and totals against matched counts and totals, which is how you spot a systematic gap — a partner who stopped reporting one transaction type on the fourteenth — rather than chasing individual rows.

Export — Everything, in a Format Auditors Accept

Every category of result exports for audit trails, partner disputes and downstream systems:

Matched records — partner rows alongside the ledger transaction each was matched to, including the confidence level, so an auditor can verify every pairing independently rather than taking the match rate on trust.

Unmatched partner records — ready to send back to the partner as a query list.

Unmatched ledger records — for internal investigation or controller sign-off.

Duplicates — everything rejected as an exact repeat, with the original import referenced.

Exports are generated live from current data, so they always reflect any adjustments or re-runs since the original import. Filenames carry the import reference and timestamp, so a file pulled out of an archive two years later can still be traced back to the exact run that produced it.

API-First — Every Screen Is Also an Endpoint

The web interface is built entirely on the same public REST API that third-party systems use. There is no separate "API mode", no reduced integration surface, and no capability reserved for the UI. If an operator can do it, an integration can do it.

That means the whole pipeline — provisioning templates, delivering files, triggering matching and retrieving results — can run with no human involvement at all:

Automated settlement ingestion — a gateway or bank delivers files on a schedule; import and matching happen unattended, and a human is involved only when something needs judgement.
ERP integration — an external system pulls match results and exceptions to drive journal entries or payment instructions downstream.
Audit pipeline — a compliance tool builds an independent reconciliation record for regulatory reporting.

Base URL: https://api.ledgerflow.ai

Authentication is the same across the whole platform — authenticate once, then present a bearer token, or federate through OIDC single sign-on. See Platform Architecture for the full model.

Full specification: https://swagger.ledgerflow.ai — every reconciliation endpoint, parameter and response schema, browsable without writing code. Or point an AI coding assistant at the platform and have it write the integration for you — see Integrate at AI speed.

What You Can Automate

Configuration — list and create templates, read and update column mappings, adjust tolerance and timezone settings, and link ledger accounts. Typically a one-time setup per partner, but fully scriptable when you are onboarding partners at volume.

Operations — validate a file against its template before committing to it, create an import batch, deliver rows, and trigger matching. Duplicate rows are discarded automatically, so a retried delivery is harmless.

Results — retrieve confirmed matches, ledger exceptions, unmatched partner rows and the day-by-day summary, then feed them into your ERP, audit platform or data warehouse.

Matching runs asynchronously: trigger it, then either poll for completion or subscribe to the platform's real-time event stream and be told the moment it finishes.

End-to-End Automation — The Whole Loop

After a one-time template setup, a fully automated reconciliation is four steps:

1 · Validate — confirm the file still matches the agreed format. If the partner changed it, you get a precise description of what differs and can alert a human before anything is imported.

2 · Deliver — create the import batch and submit the rows. Duplicates are rejected automatically, so retries and overlapping deliveries are safe.

3 · Match — trigger the run and wait for the completion event.

4 · Collect — pull confirmed matches, ledger exceptions and unmatched partner rows into your downstream systems.

Steps 3 and 4 can be repeated at any time — adjust a tolerance and re-run without re-delivering anything.

The end state most customers reach: reconciliation runs overnight, and the finance team arrives to a short list of genuine exceptions instead of a day of matching.

Create a reconciliation template

Architecture overview

Integrate at AI speed

API documentation