Reconciliation Agent

The backend agent that compares two independent data sets record by record and surfaces every anomaly — so nothing closes out with a silent discrepancy buried in it.

What Is the Reconciliation Agent?

The Reconciliation Agent is one of TotalApp's Core Agents. It compares two independent data sets — invoices against purchase orders, bank statements against accounts payable — record by record, and surfaces every mismatch as a structured anomaly for review.

Two-sided reconciliation is one of the most common, highest-stakes manual tasks in finance and operations, and it is exactly the kind of repetitive comparison work that is error-prone when done by hand. Instead of a spreadsheet VLOOKUP or a manual line-by-line check, every reconciliation run uses the same configurable matching logic, so nothing closes out with a silent discrepancy buried in it.

In one sentence

Give the Reconciliation Agent two data sets and the fields that define a match — it returns every matched pair, every partial match, and a structured report of every genuine mismatch.

How It Works — Match, Classify, Report

1. Configurable Matching → 2. Classification → 3. Anomaly Report

Phase	What happens
1. Configurable Matching	Match keys are defined per reconciliation type — there's no fixed schema assumption. The agent handles many-to-one and one-to-many matches, not just exact 1:1 pairs (e.g. a split invoice against a single purchase order, or a combined shipment against multiple line items).
2. Classification	Every pair is classified — a true match, a partial match (such as an amount off by a rounding difference, distinguished from a genuine mismatch), or a confirmed discrepancy. Each classification includes the specific fields that did or didn't align.
3. Anomaly Report	One structured report per reconciliation run, sortable by severity — a $2 rounding gap is not treated the same priority as a missing record entirely.

Partial matches aren't discarded as noise

A record that's off by a rounding difference is deliberately distinguished from a record that's genuinely missing its counterpart. Collapsing both into the same "mismatch" bucket would bury the discrepancies that actually need investigation under the ones that don't.

Key Capabilities

Configurable Match Keys

Define what counts as a match per reconciliation type — no fixed schema assumption, so the same agent serves invoice/PO matching and bank/AP matching alike.

Many-to-Many Matching

Handles split invoices, combined shipments, and other non-1:1 matching patterns that a naive exact-match comparison would miss entirely.

Structured Anomaly Reports

Every discrepancy compiled into one sortable report — amount, source, and severity — instead of scattered flags across a spreadsheet.

Audit-Ready Exports

Export reconciliation results directly into month-end close and audit documentation, with every discrepancy's classification and severity intact.

Output — What You Get Back

Field	Meaning
`matched`	Record pairs that align cleanly on every configured match key.
`partial_matches`	Pairs that align except for a minor, quantified difference (e.g. rounding).
`discrepancies`	Confirmed mismatches, with the specific fields that failed to align and the source of each side.
`severity`	A per-discrepancy severity used to sort the report — larger or structurally significant gaps rank above trivial ones.

Re-runs incrementally, not from scratch

As new records arrive on either side, the agent re-runs the comparison without re-checking pairs that were already confirmed matched — keeping ongoing reconciliation runs fast even as data sets grow.

Frequently Asked Questions

Does it only handle exact 1:1 record matches?

No — many-to-one and one-to-many matches are handled explicitly, such as one purchase order split across several invoices, or several shipments combined into a single bill. This is one of the main reasons a spreadsheet VLOOKUP falls short for real reconciliation work.

Can I reuse this for a reconciliation type other than invoices or bank statements?

Yes — match keys and field mappings are configured per reconciliation type, so the same underlying agent serves any two-sided comparison, not only the invoice/PO and bank/AP examples it ships with.

How does it distinguish a rounding difference from a real problem?

Partial matches are classified separately from confirmed discrepancies precisely so a trivial rounding gap doesn't get the same priority — or get lost in the noise — as a record that's genuinely missing its counterpart.

Does this pair with the ETL / Parser Agent?

Yes — the ETL / Parser Agent is commonly used first to turn unstructured inbound data (an emailed invoice, for example) into a clean schema-conformant record, which the Reconciliation Agent then compares against the other side of the reconciliation.