Step-by-step flow from expected and incoming transactions to resolved matches. How LedgerMatch scoring works and how to interpret results.

End-to-end flow

Reconciliation follows four steps. Each step has its own data and APIs; this page explains how they connect.

1. Expected — Define what you anticipate

Create expected transactions with merchant, amount, currency, expected date, reference, and description. These represent payments you anticipate receiving. Expected transactions are the candidates LedgerMatch searches when an incoming transaction arrives.

See Expected Transactions in the API Reference.

2. Incoming — Receive actual payments

Incoming transactions represent payments you have received. They enter via:

Manual — Create via API with full fields
Stripe — Sync from Stripe; field mappings transform charge data
CSV — Bulk upload; field mappings map columns
EBICS — Import from bank statements

Each incoming transaction starts as PENDING. See Incoming Transactions for details.

3. Match — LedgerMatch finds and ranks candidates

When LedgerMatch runs (auto, manual, or scheduled), it:

Takes the incoming transaction
Fetches expected transactions for the same tenant and environment (candidates)
Scores each candidate using embedding similarity, amount, date, and reference
Returns ranked matches with confidence (0–1) and per-field scores

Matches are stored with status PENDING. If confidence meets your threshold and auto-accept is enabled, the top match may be auto-accepted. Otherwise, you review and accept or reject manually.

See LedgerMatch Integration for scoring details and Matches for resolving matches.

4. Resolve — Accept or reject

Accept — Confirms the match. Links incoming to expected; both become MATCHED.
Reject — Rejects the match. The incoming remains available for other candidates or stays UNMATCHED.

When you reject, you can optionally provide a reason. Rejected matches help LedgerMatch learn over time (when feedback is supported).

Understanding match scores

LedgerMatch returns several scores per match:

Attribute	Meaning
confidence	Overall match score (0–1). Used for auto-accept threshold.
embeddingSimilarity	Semantic similarity of merchant/description.
amountScore	How well amounts align.
dateScore	How close transaction dates are.
referenceMatch	Whether reference IDs match.
autoMatched	True if the system auto-accepted based on threshold.

Use confidence for threshold decisions. Use the component scores and explanation to understand why a match ranked high or low when reviewing manually.

Best practices

Set a sensible threshold — matchingConfidenceThreshold (e.g. 0.8) balances auto-accept rate with false positives. Start conservative and adjust.
Review multiple candidates — When several matches are above threshold, autoAcceptOnlyWhenSingleMatch forces manual review to avoid wrong links.
Use reference when possible — Strong reference matches (invoice IDs, transaction IDs) improve confidence.
Keep expected transactions up to date — Stale or duplicate expected transactions can produce noisy candidates.

Incoming Transactions — How incoming transactions enter
Matches — Match lifecycle and resolving
LedgerMatch Integration — REST vs gRPC, retry, timeout

API Reference

For endpoints and request/response samples, see Matches and Expected Transactions in the API Reference.

Match Flow