Invoice and Payment Matching Software

What payment matching is

Payment matching — also called invoice matching, invoice-to-payment matching or, on the receivables side, cash application — is the job of tying every bank payment to the invoice it settles. The output is a simple answer per invoice: paid, not paid, or paid wrong. Getting there is the hard part, because a bank line rarely says which invoice it belongs to in a way a spreadsheet formula can read.

A typical description looks like "NORTHSTAR OFFICE SUPP NS1042" or "STANDING ORDER 2000.00". The first carries the supplier, abbreviated, and the invoice number with its hyphen dropped. The second carries nothing but an amount. Done by hand, matching means scanning a statement for each invoice, comparing figures, and deciding in your head whether a payment of the right amount is really this invoice or just the same number by coincidence.

FlowParse does that comparison for every invoice against every transaction, scores each pairing on the same rules every time, and writes down the evidence. It works for both directions: money you paid suppliers (payables) and money customers paid you (receivables). The direction of the transaction is not used to filter, so the same run handles both.

It is not the same as three-way matching, which compares a purchase order, a goods receipt and an invoice before anything is paid. Payment matching happens after the money moved, and its question is whether the money that moved settles what was billed.

"Invoice matching": the two things people mean

Search for invoice matching software and you will find two different products under one name. It is worth thirty seconds to know which one you need, because they sit at opposite ends of the purchase cycle.

FlowParse does the left column, end to end: it reads the invoices and the statements from their PDFs, scores every pairing, and ends each invoice in an explicit status. For approval-side matching against purchase orders and goods receipts, see three-way match software — a different control that runs before the payment ever leaves.

How the matching works, step by step

A run has a fixed order. Each step works only on what the step before it could not settle, and each one claims the transactions it uses, so the same payment is never counted against two invoices.

• Read both sides. Invoices and bank statements are uploaded as PDFs, scans, photos, Excel or CSV and read into structured data — invoice number, supplier, total, currency and date on one side; date, description and amount per transaction on the other. This is the same extraction the invoice parser and the PDF bank statement converter use.
• Check the statement against itself. Before a single invoice is matched, the statement's own arithmetic is tested: each running balance against the one before it, and the opening balance plus credits minus debits against the printed closing balance, to within two cents.
• Exact matches first. Pairings with the exact amount and something that identifies the payment — the invoice number in the description, or a confident supplier match — scoring 90 or more are settled.
• Similar matches next. Pairings that reach 70 on similar names, a near amount or an identifier are settled from what remains.
• Combinations. Several payments that together equal one invoice, and one payment that equals several invoices, are searched for explicitly.
• Everything left is described, not guessed. An invoice with a candidate that fits but proves nothing becomes a possible match; one with nothing becomes unpaid, or out of scope if its date falls outside the statements you uploaded.
• An optional second look. Only the leftovers can be sent for an AI review, which may suggest a transaction but never decides one. More on that below.

The order is the design. Arithmetic settles what arithmetic can prove, so a match that an exact amount and an invoice number already confirm is never second-guessed, and the expensive, less certain steps only see the handful of rows that are genuinely unclear.

How a match is scored

Every invoice is compared with every transaction, and each pairing gets points for four kinds of evidence. The total is capped at 100. The weights encode one rule above all: an amount is not an identification.

Currency works as a gate, not a bonus. When a transaction states its own currency and it differs from the invoice's, the pairing is dropped entirely: a EUR invoice is not settled by a GBP payment of the same number. Many statements print no currency per row, so only a stated mismatch excludes a pairing.

Supplier names are compared two ways. One counts how many of the supplier's significant words appear in the description, after legal forms like Ltd, GmbH or Inc and payment noise like SEPA or TRANSFER are dropped. The other measures how much of the name survives as overlapping letter pairs, which forgives truncation such as "NORTHSTAR OFF SUPP". A similar name counts as an identification only if at least half of the supplier's own words appear verbatim — which is what keeps "North Star Office Solutions" from being accepted as "Northstar Office Supplies".

Why an exact amount alone is never "paid"

An exact amount and a date in the window add up to 70 points. That is enough to show you the transaction, but not enough to call the invoice paid, because nothing in it says the payment belongs to this invoice. FlowParse reports it as a possible match and asks.

This is the most common mistake in automated matching, and the most expensive one. Rent, retainers, subscriptions and split invoices produce identical figures every month. A matcher that treats "same amount" as proof will happily mark March's invoice paid with February's payment, and the error only surfaces when a supplier chases money you thought you had paid — or when you chase a customer who already paid you.

To be settled automatically, a pairing needs the exact amount plus an identifier: the invoice number in the reference (60 + 35), or a confident supplier name (60 + up to 25), usually with the date on top. Those pairings land in the 90s and are reported as paid with the method "deterministic", which means it was decided by equality, not by an opinion.

Every status a match can end in

Instead of a single matched or unmatched flag, each invoice comes back with one of these statuses, the transaction or transactions behind it, the amount paid and the difference still open.

The difference between amount mismatch and partial payment is deliberate. A payment of 85 against an invoice of 90 is not an instalment plan — it is a bank fee, a short-paid line or a misread digit, and calling it partial would tell you to wait for a second payment that is never coming. A payment of 900 against 1,000 is a part payment, and the missing 100 is a live balance to chase.

Unpaid and no match are different claims for the same reason. An invoice dated after the last transaction you uploaded was never in scope. Reporting it as unpaid would send you after money that may already be sitting on next month's statement. The tool for chasing what is genuinely open is unpaid invoice detection.

Duplicate payments and duplicate invoices

A second full payment of the same invoice is the costliest error in a ledger and one of the hardest to see by eye, because each payment looks correct on its own. After an invoice is settled, FlowParse looks for another unclaimed transaction with the exact amount that is also identified as this invoice's. If there is one, the invoice is reported as a duplicate payment, with both transactions listed.

Duplicate invoices are a different problem: the same document entered twice, which leads to paying it twice. Before matching starts, invoices with the same number, the same supplier and the same amount are found, and every copy after the first is marked as a duplicate invoice and left out of matching, so it cannot claim a payment that belongs to the original.

When two invoices share an identical recurring amount and only one payment exists, the payment goes to the invoice it fits better. The other is not quietly reported as unpaid: it comes back as a possible match pointing at the same transaction, with a note to check which invoice it really paid.

Several payments for one invoice, one payment for several

Both happen every month and neither can be seen one row at a time. A customer pays a large invoice in instalments; a supplier is paid once for a month of small invoices. FlowParse searches for both after the single-transaction passes.

• Many payments → one invoice. Up to five identified payments whose sum equals the invoice total within its exact tolerance.
• One payment → many invoices. One payment that equals up to five identified invoices from the same run, to within five cents.
• Bounded on purpose. The search considers at most 14 candidates at a time, so it finishes in a second rather than hanging on a large ledger. Anything beyond that is shown to you as leftovers.

The sum is never in doubt — a combination is only reported when it adds up exactly. What the confidence then reflects is how well each part was identified. Parts confirmed by an invoice number or an exact supplier name make the combination as certain as a single exact match. Parts identified only by a similar name leave it as a possible match, for you to confirm.

Can software match partial payments?

Yes — when it treats a partial payment as a first-class outcome instead of a failed match. FlowParse reports an identified payment that comes in short as a partial payment with the amount still owed stated, matches up to five instalments that together settle one invoice as a combination, and matches one payment that settles several invoices the same way. The one thing it will not do is guess: a short payment with nothing identifying it stays a question, not a silent write-off.

The three partial shapes are different problems and are reported differently. A short payment against an identified invoice is a balance conversation with the customer. Instalments that sum exactly to the invoice are simply how the customer chose to pay, and reconcile clean. A payment short across several invoices at once is usually a deduction or an early-payment discount taken — which is exactly the row an accountant wants surfaced, not absorbed.

Cash application: the receivables side of the same engine

On the receivables side this work has its own name — cash application: taking the payments that arrived and applying them to the open invoices they settle. The engine is the same, pointed the other way. Customer receipts on the statement are matched to your sales invoices on amount, the invoice number buried in the transfer reference, the payer's name and the date — and a customer who pays three invoices with one transfer is handled by the combination pass, not left as unapplied cash.

What is left genuinely unapplied — a receipt no invoice explains — is listed, with the engine's best possible matches attached as questions where the evidence is partial. That shrinks the pile a person has to work from the whole receipts list to the exceptions, which is what cash application software is actually for.

A worked example

Four invoices and the statement lines that paid them, scored with the rules above. The names and figures are invented for the example.

The first two settle on their own. The Kestrel invoice is clearly the one paid — its number is in the reference — but 100.00 is missing, which is too much to be a rounding difference, so it is a part payment. The rent line is probably the rent, but "STANDING ORDER" proves nothing, so it waits for you to accept it with one click. That is the whole idea: the engine is sure where it can prove it, and honest where it cannot.

The bank statement is checked before matching

Matching against a misread statement produces confident nonsense: an invoice reported unpaid because the transaction that paid it was read with a wrong digit. So every statement is checked first, and the verdict travels with the report.

Each running-balance step is tested — the previous balance plus this transaction should equal this balance — and the statement as a whole is tested: opening balance plus credits minus debits should equal the printed closing balance, within two cents. The result is one of three states: verified, failed with the size of the gap, or not verifiable, for a statement that prints no balances to check against. Not verifiable is not treated as an error, because there is no evidence of one.

These are the same checks described in detail on the financial data validation page, and they are why a matched result can be trusted to rest on the figures your bank actually printed.

Reviewing, overriding and the audit trail

Every result can be accepted, rejected or matched by hand to a transaction you choose. The engine's own verdict is never overwritten: the original status stays on the record next to your decision, with the time and the action.

That matters when someone asks later why an invoice was booked as paid. An export that says "amount mismatch, accepted by the reviewer" can be audited; one that silently says "paid" is a rewrite of history. The totals on screen are recomputed after every change, so the counts you export are the counts you see.

The report always shows two numbers side by side: ready to export, and needs review. They add up to the number of invoices, so nothing can drop out between the report and the export. Only paid, date-mismatch, manually matched and accepted results are ever ready to export — a possible match cannot reach your accounting software by accident.

The optional AI second look

Some descriptions defeat any rule: a remittance that names a parent company, a card payment under a trading name nobody recognises. For those, you can ask for an AI review of the leftovers. It is never run on its own and never sees the whole ledger.

• Only unresolved invoices are sent — possible matches, amount mismatches and no-match results — at most 25 per run.
• Each comes with a shortlist of up to 8 unclaimed candidate transactions, not the full statement.
• It may suggest a transaction with a one-sentence reason, or answer that nothing fits. It is told that a similar amount alone is not a reason.
• A suggestion comes back as a possible match. You still accept or reject it. Results you already decided are never sent.
• It uses one page per invoice reviewed from your allowance, and is checked against your balance before it runs.

What you get out: Excel, PDF and accounting files

The reconciliation downloads as an Excel workbook, a PDF report, or a file for your accounting software containing only the approved results.

• Summary — counts per status, money invoiced and money accounted for, and the statement check.
• Matched — settled results ready for accounting, each with the transaction that decided it.
• Unpaid, Partial Payments, Mismatches and Duplicates — one sheet per kind of problem, so each can go to the person who fixes it.
• Unmatched Transactions — bank lines no invoice claimed: often a missing invoice, a refund or a fee.
• Audit Trail — every review action, with the engine's original verdict next to the decision.

The accounting export produces import files for QuickBooks, Xero, Sage, Zoho Books, NetSuite, MYOB, Wave, FreshBooks, FreeAgent, DATEV and 1C from the approved results. It is a file you import; FlowParse does not connect to your ledger and does not mark invoices as paid there for you.

Payment matching through the API

The same engine is available as POST /api/v1/reconcile for teams that already have invoice and transaction data, or want to run matching inside their own system. Send invoices (or marketplace settlements), plus transactions, one bank statement or several, and get the full report back as JSON: statuses, confidence, matched transactions with their reasons, unmatched lines and the statement check.

A bare list of transactions is accepted too; the statement check is then simply absent, because there are no balances to test. Each call is billed one page per invoice or settlement plus one per statement, at the API rate of €0.035 per page, from a top-up balance. The details are in the API documentation and on the pricing page.

What it doesn't do

So that you can decide whether it fits your process, here is what FlowParse payment matching does not do today.

• It does not connect to your bank. Statements are uploaded as files; there is no live bank feed.
• It does not post to your ledger or mark invoices paid in your accounting software. It produces files you import.
• It does not convert currencies. A payment in another currency is not matched to an invoice, rather than matched at a guessed rate.
• It does not do three-way matching against purchase orders and goods receipts — see three-way match software for that.
• It does not decide uncertain cases for you. A possible match stays a question until someone answers it.

Who uses payment matching

Bookkeepers closing a client's month, who need to know which supplier invoices were paid and which were paid twice. Small finance teams doing cash application on receivables, matching customer remittances to open invoices. Accountants preparing year-end, who inherit a folder of invoices and twelve statements and need a defensible list of what is open.

If your question is the other way round — whether the bank statement itself agrees with your books — that is bank reconciliation. If you need invoice-by-invoice reconciliation with the full workspace, see invoice reconciliation and the reconciliation engine behind all of them.

Try it on your own files

Add a few invoices and the statement they should have been paid from in the tool above. Each document is read the same way as a normal conversion and uses pages from your allowance; the free plan includes 10 pages a month, and no card is needed. The report shows you, invoice by invoice, what was paid, what was not, and the transaction behind every answer.