Skip to main content
Every financial institution compares its own records against bank statements, payment processors, and ERPs. Most teams do that work in spreadsheets. A Lerian reconciliation is one engine plus the pieces you choose around it. Matcher compares two independent datasets and reports what agrees, what does not, and why. It reconciles Midaz data, another ledger’s data, or two external feeds with no ledger at all. Data reaches Matcher through file uploads, scheduled pulls, and aggregator webhooks. You send what does not match to the ticketing tools your team already runs.

​
What you get

Matcher

Matcher applies exact or tolerance rules, scores every match from 0 to 100, and turns what it cannot pair into an exception. Matcher’s embedded extraction engine pulls transactions from external systems, so nobody moves a file by hand.

Streaming Hub

Streaming Hub delivers Matcher facts, such as a completed match run, to a webhook, a queue, or a cursor you pull. It can also deliver platform events into Matcher through a signed webhook you turn on.

Midaz

Midaz is the ledger whose exports become one side of a reconciliation. The two products stay separate services, and no connector runs between them.

Lender

Lender consumes the verdict of a completed match run and translates it into a loan servicing action.

​
How the pieces fit together

Matcher sits between the data you feed it and the systems that act on the result.
  1. You define two sources, one on each matching side. A file you upload, a transport Matcher fetches, an engine extraction, or an aggregator webhook all feed a source.
  2. Ledger data arrives the same way. You export the period from Midaz and import it as a source of type LEDGER. No live connector exists.
  3. Matcher applies your rules and scores every candidate from 0 to 100. It confirms an exact or tolerance match that scores 90 or above.
  4. A fuzzy match or a date-lag match always waits for a person. Items with no counterpart become exceptions, classified by amount, age, and source signals.
  5. You dispatch an exception to JIRA, ServiceNow, or an HTTP endpoint you configure. Each request names its own target, so Matcher escalates nothing on its own.
  6. Matcher publishes its facts on lerian.streaming.matcher. Streaming Hub delivers them to your webhook, your queue, or your pull cursor.
  7. Matcher records each audited change in an append-only audit log. Nobody can edit or remove an entry.
Streaming Hub can also deliver platform events into Matcher. Those deliveries land on one signed endpoint that deduplicates by event id and stays off until you turn it on. Matcher consumes no Kafka events.

​
What each piece owns

​
Adopt it one piece at a time

1

Start with any two sources

Reconcile a bank file against an ERP export. Matcher runs as a stand-alone product, with no ledger and no other Lerian product beside it.
2

Add your ledger

Export the period you want to reconcile and import it as a source of type LEDGER. Midaz or another ledger both arrive this way, because Matcher depends on neither. See Matcher and Midaz for the export and import flow.
3

Automate the pulls

Register a connection with the extraction engine, then create extractions instead of uploading files by hand. For Open Finance data, connect a Pluggy or Belvo account and mint a webhook token for it.
4

Route the exceptions

Point Matcher at JIRA, ServiceNow, or your own endpoint. Configure the dispatch target first, because dispatch fails without it. Verify the HMAC signature on every delivery you receive.
5

Close the loop

Subscribe to Matcher facts in Streaming Hub. When you also run credit, Lender consumes match_run.completed and moves the loan’s servicing stage. See the loan management solution.

​
Bring your own

  • Any ledger. Matcher works with Midaz or with another ledger, and it depends on neither.
  • Any source format. CSV, JSON, XML, ISO 20022 camt.053, plus regional layouts such as CNAB, OFX, and acquirer EDI files.
  • Your ticketing tools. Dispatch targets are JIRA, ServiceNow, and your own HTTP webhook.
  • Your AI client. The Matcher MCP server speaks Streamable HTTP and relays your bearer token without logging or storing it.
  • Your reconciliation screens. The Matcher UI ships as its own web application beside the Matcher API.

​
A worked example

This example reconciles one day of Pix against the BACEN settlement extract. The full walkthrough lives in Pix reconciliation.
  1. Source A holds the day’s committed Pix transactions, exported from Midaz. Source B holds the BACEN SPI settlement extract.
  2. Both field maps point external_id at the endToEndId. That value links a Midaz transaction to its BACEN settlement record.
  3. The first rule compares reference, amount, currency, and date, and scores 100.
  4. A Pix started at 23:58 settles at BACEN the next day. The date-lag rule pairs it at 85, and that pair always goes to the review queue.
  5. A Midaz transaction with no BACEN entry becomes an exception. So does a BACEN entry with no Midaz transaction.
  6. A refund carries the original end-to-end id and a new return identification. Matcher pairs it against the BACEN extract on those identifiers.

​
Start here

What is Matcher?

The reconciliation engine: rules, confidence scores, exceptions, and audit trails.

Matcher quick start

Run a first reconciliation, then review the matches and the exceptions it produces.

Matcher concepts

Contexts, sources, field maps, rules, and matches, the five things you configure.