Reconciliation is matching what should have happened to what actually did.
Every source, matched with tolerance, one-to-many and many-to-many — with a reason attached to every exception that doesn’t clear on its own.
What reconciliation is
Reconciliation is the process of matching two or more independent records of the same activity — a bank feed and a ledger, a remittance and a claim, a settlement file and a set of transactions — to confirm they agree, and to explain every case where they don’t. A rules engine handles the matches someone anticipated: same amount, same date, same reference number. Everything else — a partial payment, a batch settlement covering a hundred transactions, a fee netted out of a deposit — becomes a manual exception, worked by hand, usually at month-end, usually under time pressure.
That is why reconciliation breaks in the same way across very different industries: bank reconciliation, payment and settlement reconciliation, vendor and carrier invoice reconciliation, revenue and billing reconciliation, rebates and incentives reconciliation, intercompany reconciliation, and balance-sheet reconciliation are all instances of the same underlying problem — two sources of truth that should agree, don’t, and no system owns explaining why.
Ingest → Match → Explain → Resolve → Act
Ingest
Agents read every source in its native shape — EDI, DMS exports, host files, PDFs, portals, bank feeds — no manual re-formatting.
Match
One-to-many and many-to-many matching, with tolerances, fuzzy matching, and ML-suggested pairings.
Explain
Every exception comes back with a proposed reason, not just a red flag.
Resolve
Routine exceptions clear automatically within the thresholds you set; judgment calls go to a human, with full context attached.
Act
The rest of the platform acts on what reconciliation finds — recovering, disputing, and closing the books on it.
How Astridex matches — the matching logic
A rules engine has one mode: exact match. Astridex has six.
One-to-one
The simple case: one transaction, one record. Handled instantly, same as any rules engine.
One-to-many
One settlement or deposit covering many underlying transactions — the normal case for payment processors and toll settlement, not the edge case.
Many-to-many
Groups of transactions on both sides that only reconcile against each other as a set — common in freight accruals and intercompany.
Tolerance matching
Amounts that agree within a configurable threshold — a foreign-exchange rounding difference, a fee variance — clear automatically instead of queuing as exceptions.
Fuzzy matching
Records that refer to the same event with different identifiers — a shortened reference number, a reformatted invoice ID — matched on the underlying pattern.
ML-suggested matching
For the genuinely ambiguous cases, Astridex proposes the most likely match with its confidence and evidence, for a human to confirm.
Exceptions with reasons, not just red flags
An exception queue that only says “doesn’t match” pushes the entire investigation onto a human, every time. Astridex proposes a reason for every exception it can’t clear on its own — a timing difference, a fee that wasn’t netted correctly, a rate that changed mid-period — with the evidence attached, so a person is reviewing a hypothesis instead of starting from zero. That reason code is also what makes reconciliation a source of continuous improvement rather than a recurring chore: patterns in why things don’t match point directly at where a process, a contract, or a system integration needs to change.
AI reconciliation vs. a rules engine vs. spreadsheets
| AI reconciliation (Astridex) | Rules engine | Spreadsheets | |
|---|---|---|---|
| Matches one-to-many and many-to-many | ✓ | partial | — |
| Reads native source formats (EDI, PDFs, portals) | ✓ | partial | — |
| Explains why an item didn’t match | ✓ | — | — |
| Runs continuously, not just at close | ✓ | partial | — |
| Tolerance and fuzzy matching | ✓ | — | — |
| Full audit trail on every match and override | ✓ | partial | — |
| Scales to millions of transactions a month | ✓ | ✓ | — |
| Deployed in days | ✓ | — | ✓ |
Every reconciliation type
One matching model, applied to every kind of break.
Bank
Continuous matching across every account and entity.
Learn more →Payment & settlement
Processor and gateway settlement, netted to the deposit.
Learn more →Vendor & carrier invoice
Invoices matched to contracts, rates, and delivery evidence.
Learn more →Revenue & billing
Usage, contracts, and invoices kept in sync with the GL.
Learn more →Rebates & incentives
Claims matched to the credit memos that should follow.
Learn more →Intercompany
Cross-entity matching, elimination-ready.
Learn more →Balance sheet
Every GL account reconciled to its supporting schedule.
Learn more →By industry
Where reconciliation breaks look different — and where Astridex has built the deepest playbooks.
Office Technology & MPS Dealers
Meter reads, OEM rebates, and lease funding against e-automate.
Learn more →Tolling & Mobility Payments
Passage-to-settlement reconciliation.
Learn more →Shipping & Logistics
The full shipment-financial lifecycle, not just a three-way match.
Learn more →Healthcare Billing & RCM
Remit-to-deposit-to-contract, at line level.
Learn more →Reconciliation, answered
What is reconciliation in finance?
Reconciliation is confirming that two independent records of the same activity — like a bank feed and a ledger — agree, and explaining every case where they don’t.
What is automated reconciliation?
Automated reconciliation uses software to match records and surface exceptions without manual line-by-line comparison. AI reconciliation goes further: it matches one-to-many and many-to-many with tolerance and fuzzy logic, and proposes a reason for what’s left.
What is continuous reconciliation vs. month-end reconciliation?
Continuous reconciliation matches transactions as they happen, so breaks surface the day they occur. Month-end reconciliation batches the same work into a single close-week sprint, which is why breaks are found late and under pressure.
What is transaction matching software?
Transaction matching software is the engine underneath reconciliation — the logic that pairs records from two or more sources. Astridex’s matching engine supports one-to-one, one-to-many, many-to-many, tolerance, fuzzy, and ML-suggested matching.
Does Astridex replace our ERP’s built-in reconciliation module?
Most ERP reconciliation modules only see data inside the ERP. Astridex reconciles the ERP alongside the sources it can’t see — DMS, toll host, carrier, payer, and processor systems.
How is this different from BlackLine, Trintech, or FloQast?
Those tools are strong at balance-sheet close management for controllers. Astridex is built for operational, multi-source reconciliation — the industries whose money moves through systems the ERP never sees.
Can reconciliation run daily instead of monthly?
Yes, for any source that reports at that cadence. Astridex reconciles at the cadence each source actually supports — we don’t promise daily reconciliation on a source that only settles weekly.
What happens after a reconciliation break is found?
The rest of the Astridex platform acts on it — Collect chases a short-pay, Pay disputes a carrier or claims a credit, Close books the adjustment — all from the same reconciliation record.
See reconciliation on your data.
Connect your systems read-only and watch Astridex match what rules can’t — no slides.