AI Bank & Invoice Reconciliation Software

What bank reconciliation is

Bank reconciliation is the check that the money your records say moved is the money that actually moved. In its classic form you take the balance on the bank statement, take the cash balance in your books, and explain every difference between them until both arrive at the same figure.

The differences fall into a few familiar groups. Timing differences: a deposit you recorded on the 31st that the bank credits on the 2nd (a deposit in transit), or a payment you sent that has not cleared yet (an outstanding payment). Bank-only items: fees, interest, card charges and direct debits that appear on the statement before anyone has entered them. Errors: a transposed figure, a payment booked twice, a receipt posted to the wrong account. A reconciliation is finished when each difference has a name and the adjusted balances agree.

Doing that by hand means reading a statement line by line, ticking each one against an invoice, a payout or a ledger entry, and keeping a list of what is left. On a busy account that is hundreds of lines a month, and the dangerous ones — a missing row, a payment made twice — look perfectly normal on their own.

The three questions, and which ones FlowParse answers

Every bank reconciliation comes down to three questions. It is worth being precise about which of them software actually answers.

• Is the statement itself complete and correct? FlowParse answers this for every statement, before anything else, from the figures the bank printed.
• Which bank lines are explained by a document? FlowParse matches each line to an invoice, a bill or a payment-processor payout, and records why.
• Does the bank balance agree with the cash balance in your books? This last step happens in your accounting software. FlowParse does not import your general ledger, so it does not produce a book-to-bank reconciliation statement — it hands you the verified transactions and the matched results to finish it with.

In practice the first two are where the hours go. Once every line on a statement you can trust is either matched to a document or listed with a reason, the book-side reconciliation in QuickBooks, Xero or Sage is a short job.

How it works, step by step

A run has a fixed order, and each step works only on what the step before could not settle.

• Upload both sides. Bank statements on one side — PDF, scan, photo, Excel or CSV, one month or twelve. Invoices, bills or payout reports on the other. Each file is read into structured data, the same way the bank statement converter and the invoice parser read it.
• Check every statement. The balance chain and the totals are tested before a single transaction is used. The verdict travels with the report.
• Match. Exact matches with an identifier first, then similar names and references, then combinations — several payments for one invoice, or one payment for several.
• List the rest. Invoices with no payment come back unpaid; bank lines no document claims come back as unmatched transactions; anything uncertain comes back as a question.
• Review and export. Accept, reject or match by hand, then download Excel, a PDF report or an import file for your accounting software.

Stage one: the statement has to add up

Reconciling against a misread statement gives you confident nonsense: an invoice reported unpaid because the row that paid it was read with one wrong digit, or a balance that is out by an amount nobody can find. So every statement is judged first, with two independent checks built only from figures the bank itself printed.

Both are calculated in whole cents, and a statement passes when the gap is no more than two cents. The outcome is one of three: verified, failed with the size of the gap, or not verifiable when the statement prints no balances to test against. Not verifiable is reported as exactly that, not as an error, because there is no evidence of one.

Why both checks matter: on a real 60-page statement from our validation set, 99.2% of rows passed the running-balance check, and the statement still did not reconcile — the opening balance plus every transaction missed the printed closing balance by 1.46 million. A row-by-row view looked almost perfect; the totals check is what showed the statement could not be trusted as read. The same checks are described in full on the financial data validation page.

When a statement won't reconcile: read the difference

When the totals check fails, the size of the gap is the best clue you have. Before searching row by row, look at the number itself — most differences fall into a few recognisable shapes.

The running-balance check narrows it further: the first row where the chain breaks is usually where the problem starts. That is why both checks are shown — the totals tell you whether something is wrong, the chain tells you where.

A failed check does not always mean a reading error. Statements that combine several sub-accounts on one document, or that print the closing balance before pending items, can legitimately fail to add up as printed. The report gives you the gap and the row, and the decision stays with you.

How often to reconcile, and in what order

Monthly is the usual rhythm, and many lenders, auditors and tax advisers expect each month's bank balance to be reconciled before the books for that month are closed. It lines up with statement periods, catches a duplicate payment while the supplier can still refund it, and keeps each run small. Busy accounts — a shop taking card payments every day, a marketplace seller with weekly payouts — are often easier weekly, because a week of transactions is short enough to clear in one sitting.

With several accounts, order matters. Reconcile the main operating account first, because most invoices are paid from it. Then the card account, whose payments to the card provider show up on the operating account as one lump sum. Then savings or deposit accounts, which mostly hold transfers to and from the other two. Transfers between your own accounts are the easiest unmatched lines to clear once both statements are in the same run: the same amount leaves one account and arrives in the other on the same or the next day.

If you are catching up on months that were never reconciled, start with the oldest period and carry each closing balance forward. A wrong opening balance in month one shows up as the same difference in every month after it, and fixing it at the start clears all of them at once.

Stage two: matching bank lines to documents

Each bank line is compared with each invoice or payout on four kinds of evidence: the amount, the invoice number or reference in the description, the supplier or customer name, and the date. Every match carries a 0–100 confidence score and the reasons behind it.

One rule matters more than the rest: an amount on its own is never treated as proof. Rent, subscriptions and retainers produce the same figure every month, and a tool that ticks a line because "the amount matches" will reconcile March's invoice against February's payment. An exact amount with nothing else identifying it comes back as a possible match for you to confirm. It takes the invoice number in the reference, or a confident name match, for a line to be settled automatically.

Matching works in both directions — payments to suppliers and receipts from customers — and across several statements at once. The full scoring table, every status and a worked example are on the payment matching software page.

Where the AI sits — and where it is not allowed

"AI reconciliation" usually means a model deciding which payment belongs to which invoice, and hoping it decides well. FlowParse's engine is built the other way round: the passes run in a fixed order, and the model is the last of them, allowed to see only what every deterministic pass before it could not settle.

The order is the whole design. First the statement itself is proven against its own balances. Then stage A matches on exact money plus an identifier — the invoice number sitting in the bank narration, read by a pattern, not by a model, because asking a model to read what a regular expression can read is slow, expensive and less reliable. Stage B scores normalised names and references by similarity. Stage C assembles combinations — several payments for one invoice, one payment for several. Stage D describes what is left honestly. Only then does stage E offer the model that leftover handful: on a real 312-invoice run, typically fifteen or twenty rows, not the ledger.

And the model's contract is deliberately narrow. It may suggest a transaction, with a reason and a confidence. It may say "no idea" — which is a useful answer and is recorded as one. It may not decide anything: every suggestion comes back as a possible match, capped below the confidence any deterministic match carries, and a person still has to accept it. It never sees a row a human has already decided. A match that arithmetic can prove is never put to a model's opinion — and that one sentence is most of what separates reconciliation you can audit from reconciliation you have to trust.

The cost follows from the same order. A tool that sends every row to a model pays for the whole ledger; an engine that sends only the exceptions pays for the exceptions. The difference on a month of statements is the difference between a fraction of a cent and a bill nobody wants to explain — and there is a hard ceiling besides: past twenty-five unresolved invoices in a run, the honest answer is "a person should look", not more model calls.

AI invoice reconciliation, concretely

For invoices against bank transactions, the evidence ladder is explicit, and each rung has a number. Every match is scored 0–100, and the thresholds decide what the engine is allowed to say:

The name matching is tuned for how banks actually print things. "NORTHSTAR OFFICE SUPPLIES FP1001" against "Northstar Office Supplies Ltd" is a truncation with noise, not a typo — so names are compared by bigram overlap, which scores a long common run generously, after stripping the legal forms and payment noise (Ltd, GmbH, SEPA, BACS, ref…) that appear in every second name and identify nobody.

Each invoice ends with one status from a fixed vocabulary — paid, unpaid, partial payment, duplicate payment, overpaid, amount mismatch, date mismatch, possible match, no match — with the transaction that decided it and the reasons attached. A duplicate payment is two bank lines claiming the same invoice; a partial payment is a line short of the invoice with evidence it belongs to it; an amount mismatch names the gap. Nothing is folded into a generic "unmatched".

Combinations: when one-to-one is the wrong shape

Real ledgers are not one invoice to one payment. A customer pays three invoices with one transfer; a supplier is paid in two instalments; a processor nets a refund against a payout. Stage C searches those combinations deliberately — several transactions that together settle one invoice, and one transaction that together with others explains several invoices — and claims the transactions it uses, so the same bank line is never spent on two different explanations.

Only approved records leave the system: a rejected match never exports, an accepted one always does, and everything else exports only when its status has earned it. The export carries the decision trail — who matched what, on what evidence — which is what makes the result auditable rather than merely convenient.

Payouts from payment processors and marketplaces

If you sell through Stripe, Shopify, Amazon or eBay, your bank does not show individual sales. It shows a lump-sum transfer — "STRIPE TRANSFER", "AMAZON.COM PAYMENTS" — that is sales minus fees, refunds and reserves. Reconciling that by hand means finding the payout report that explains each deposit.

Upload the settlement or payout statement next to the bank statement and each transfer event becomes its own record to match: the transfer amount, the transfer date, the provider's name as the bank prints it, and a payout reference when the report has one. A report that pays out twice in one period, or holds back a reserve and releases it later, produces two deposits — and two records — so each lands against the right line on the statement.

Matching the deposit is half the job; the other half is booking what it is made of. A payout is gross sales minus the processor's fees, minus refunds and chargebacks, plus or minus reserve movements. Book the gross sales as income and the fees as an expense, and the payout clears to zero against the bank line — rather than booking only the net amount, which understates both your income and your costs. The payout report carries those components; the bank statement never does, which is why the report has to be part of the reconciliation and not just the statement.

What the unmatched list usually contains

The most useful output of a reconciliation is often not the matches but the bank lines nothing explains. FlowParse lists them on their own sheet. They are almost always one of these:

On the invoice side the mirror image appears: invoices with no payment at all. Those are listed as unpaid — unless the invoice is dated outside the period your statements cover, in which case it is reported as out of scope rather than unpaid, because the payment may simply be on a statement you did not upload. Chasing what is genuinely open is covered on the unpaid invoice detection page.

How classic reconciliation items show up

If you are used to preparing a bank reconciliation statement, this is how its familiar lines map onto what FlowParse reports.

By hand, in a spreadsheet, or with FlowParse

There are three common ways to reconcile a bank statement against invoices. Each has its place.

The spreadsheet route stays the right choice for a handful of transactions a month. Once a statement runs to dozens of lines, or arrives as a scanned PDF, the typing and the formula-building become the reconciliation.

A month-end routine

A routine that keeps reconciliation short, whichever tools you use:

• Download every statement for the month — all accounts, including the card account — as PDF or CSV.
• Collect the month's sales invoices, supplier bills and payout reports in one folder.
• Run them together. Look at the statement check first: a failed statement means a page is missing or a figure was misread, and nothing downstream should be trusted until it is fixed.
• Clear the possible matches and mismatches — they are the questions only you can answer.
• Work through the unmatched transactions with the table above: fees and interest booked, missing bills found, transfers paired.
• Export the approved results to your accounting software and finish the book-to-bank reconciliation there.

Reviewing and the audit trail

Every result can be accepted, rejected, or matched by hand to a transaction you choose. The engine's original verdict stays on the record next to your decision, with the time — so a year later the file still shows that a short payment was accepted by a person, not silently called paid.

The report always shows two numbers side by side: ready to export, and needs review. They add up to the total, so nothing drops out between the screen and the export, and only settled or accepted results ever leave for your accounting software.

What you get out

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

• Summary — counts per status, money invoiced and money accounted for, and the statement check.
• Matched — settled results, each with the bank line that decided it.
• Unpaid, Partial Payments, Mismatches and Duplicates — one sheet per kind of problem.
• Unmatched Transactions — every bank line no document explained.
• Audit Trail — every review decision with the original verdict beside it.

Import files are available for QuickBooks, Xero, Sage, Zoho Books, NetSuite, MYOB, Wave, FreshBooks, FreeAgent, DATEV and 1C. If you only need the statement itself in your accounting software, the bank statement converter exports it on its own, including as a QuickBooks .QBO file.

Bank reconciliation through the API

The same engine runs as POST /api/v1/reconcile. Send invoices or settlement statements, plus one or more bank statements (or a plain list of transactions), and get the full report back as JSON — the statement check, every status with its matched transactions and reasons, and the unmatched lines.

When you send full statements, the statement check runs too; a bare transaction list carries no balances, so the check is simply absent. Each call uses one page per invoice or settlement plus one per statement, at the API rate on the pricing page. Details are in the API documentation.

What it doesn't do

So you can judge whether it fits your process:

• It does not import your general ledger or cash book, so it does not compute the book balance or produce a book-to-bank reconciliation statement.
• It does not connect to your bank. Statements are uploaded as files; there is no live feed.
• It does not post entries into your accounting software. It produces files you import.
• It does not convert currencies. A payment in another currency is not matched rather than matched at a guessed rate.
• It does not decide uncertain cases for you. A possible match stays a question until someone answers it.

Who it's for

Bookkeepers who receive a client's statements as PDFs and need to know which invoices were paid before closing the month. Small businesses selling through Stripe, Shopify or Amazon, whose bank shows lump-sum payouts instead of sales. Accountants picking up a year of unreconciled statements, who need to know first whether the statements are even complete. And finance teams that receive statements from several banks in different layouts, and want one report in the same shape for all of them.

For the invoice-by-invoice view of the same run, see invoice reconciliation; for how the engine decides, the reconciliation engine.

Try it on your own statement

Add a statement and a few invoices in the tool above. Each document is read like a normal conversion and uses pages from your allowance — the free plan includes 10 pages a month, with no card needed. You will see the statement check first, then every invoice with the bank line behind it, and the lines nothing explains.