Bank Statement Reference Matching - Match Descriptions to Orders and Invoices
How to match messy bank descriptions to order and invoice references when references are truncated, missing or inconsistent.
Try with sample files | View sample report
Problem statement
Bank descriptions often contain partial references, customer names, processor IDs, or free text. A reliable workflow needs exact matching first, then careful fallback rules.
Reference matching example
| Line item | Amount |
|---|
| Raw bank description | PAY INV1042 ACME LTD |
| Extracted candidate reference | INV1042 |
| Expected invoice amount | $1,240.00 |
| Review status | Exact after normalization |
Why references fail
- Banks truncate long payment descriptions.
- Customers enter invoice numbers with spaces, prefixes, or typos.
- Processors use payout IDs instead of order IDs.
- Several payments share the same amount and date.
- Internal transfers and fees appear in the same bank export.
Files to collect
- Bank statement export with description, reference, date, and amount fields.
- Order or invoice export with expected references and amounts.
- Payout or processor export with alternative IDs that may appear in bank descriptions.
Reference matching workflow
- Preserve the raw bank description before you start normalizing or extracting anything from it.
- Normalize references by removing spaces, punctuation, and common prefixes.
- Extract candidate IDs from bank descriptions.
- Match exact references before fuzzy or amount matching.
- Check whether the bank description actually contains a payout ID or processor reference instead of a customer-facing order or invoice number.
- Use date and amount as supporting evidence, not the only proof.
- Flag ambiguous matches where several rows could be correct.
- Keep unmatched bank rows separate from unpaid source rows.
Review checks
- Same amount appears multiple times on the same date.
- Reference prefix changed between systems.
- Bank description contains payout ID, not order ID.
- Customer name matches but amount does not.
- Several invoices or orders share similar references and only one fits the bank row exactly.
How Reconcile Locally helps
- Keeps the raw bank description, extracted candidates, and source references visible together in one review flow.
- Separates exact reference matches from amount-only candidates and ambiguous rows that still need manual proof.
- Exports a review-ready list for rows that still need another file, another period, or a human decision.
What still needs manual review
- Some bank feeds remove too much context, so final acceptance still requires manual review.
- Same-value rows and repeated customer names can keep the best match ambiguous even after normalization.
- Amount and date alone are not enough evidence for a final match when references remain weak.
Content review and sources
Written and reviewed by the Reconcile Locally product team. Last reviewed June 7, 2026.
Guidance is checked against current product behavior and first-party documentation where available. Reconciliation results still require human review.
Frequently asked questions
Should I rely on amount-only matching?
Only as a fallback. Amount-only matches are risky when many payments share the same amount or date.
What should happen to ambiguous matches?
Put them in review with the competing candidate rows visible instead of marking them as final matches.
What if the bank description contains only a payout ID?
Use the payout or processor export as a bridge. A payout ID may still prove the source, but you should not force it into an invoice or order match until the supporting export confirms the link.