Guides › Bank reconciliation›Reconcile bank statements against accounting records. Fibula guide.

Reconcile bank statements against accounting records. Fibula guide.

Match every supplier invoice to its bank transaction. Flag what does not balance. Catch errors no one else does.

9 min read•Intermediate•Updated May 2026

What you'll build

By the end of this guide, you have a workflow that reads a bank statement, pulls out every transaction, and cross-checks each one against the supplier invoices Fibula has already processed. Matches get ticked off, mismatches get flagged, missing payments get surfaced.

This is what makes Fibula different from Zapier or Docparser. They move data from one place to another. Fibula remembers it. The reconciliation node looks back across every invoice that has ever flowed through this workspace and checks whether the payment on the bank statement actually lines up.

That is the moat. Cross-document checking, automatically, every time a statement comes in.

Before you start

You need three things:

  1. A Fibula account with invoices already flowing in. If you have not done that yet, run the Xero guide or the Google Sheets guidefirst. Reconciliation needs invoices to match against.
  2. One or two recent bank statements as PDFs.
  3. About 15 minutes. This guide is a touch longer than the others.

Step 1. Set up the bank statement Document Schema

Bank statements are different from invoices. Different from the invoice Document Schema: extracts a table of transactions, not a single set of header fields (vendor, total, date). You want every row.

Drag a Document Schema onto the canvas. Set the document type to "Bank statement". Fibula will extract the table: date, description, amount, balance, one row per transaction.

Step 2. Add the Reconciliation node

Drag the Reconciliation box onto the canvas and connect it after the Document Schema. This is Fibula's memory feature. The node holds a stateful view of every document that has flowed through this workflow's invoice pipeline. When new transactions arrive, the node walks through each one and asks: do I already have an invoice that matches this payment?

That is the part no rule-based tool can do. The reconciliation node remembers. Every supplier invoice that has come through your accounts payable workflow is sitting there, ready to be matched.

Bank rows matched against invoices Fibula already processed.

Step 3. Configure match rules

Click the Reconciliation box and set the matching rules. Most teams start with something like this:

  • Invoice total within $0.50 of the bank transaction amount.
  • Invoice date within 7 days of the transaction date.
  • Vendor name fuzzy match (so "Acme Corp" matches "ACME CORPORATION LTD").

Save and move on. You can always come back and tighten or loosen any of these later.

Tip
Start loose. Run a real statement through, see what matches and what does not, then tighten the rules to cut down on false positives. Tightening too early just gives you a wall of unmatched rows and you cannot tell which ones are real problems.

Step 4. Test it with a real statement

Upload a recent bank statement to the workflow. Fibula extracts the transactions, then the Reconciliation node walks through each one against your invoice history.

Open the reconciliation view. Each row is either ticked (matched to an invoice on file), flagged (matched but with a discrepancy), or unmatched (no invoice found at all). Click any row to see which invoice it lined up against, or which ones it considered and rejected.

What this catches

This is the bit most bookkeepers do not realise they need until they see it. A few real examples of what reconciliation catches:

  • Duplicate invoices paid twice. Two payments to the same vendor for the same amount in the same month. One of them is almost always a duplicate someone forgot to flag.
  • Mismatched amounts. Invoice says $4,280, bank shows $4,820. Transposed digits, a fat finger somewhere, possibly fraud. Either way, you want to know.
  • Missing payments. Invoice is on file, due date has passed, no matching transaction on the statement. Vendor is going to call soon. Get ahead of it.
  • Unmatched transactions. Money left your account but Fibula has no invoice for it. Either an invoice was paid without going through the system, or someone authorised a payment they should not have.

None of this falls out of a "data movement" tool. You need a system that remembers what came before. That is the whole point.

What this costs

Bank statements are long. A single statement can have a hundred transaction rows, so the token cost per document is higher than for a single invoice. We recommend Claude Sonnet 4.6 or GPT-5.4 for statement extraction because the table accuracy matters more than the savings on a cheaper model.

Ballpark cost is ten to fifty cents per statement, depending on length and model. Check the pricing page for the exact numbers.

Troubleshooting

The three issues that come up most:

  • A match did not fire that should have. First, check that the statement Document Schema actually pulled the row out cleanly. If the amount is wrong by a cent or the date is off by a day, the match rule will reject it. Loosen the tolerances and re-run.
  • The wrong invoice was matched. Usually means your vendor name fuzziness is too loose. "Acme" matched "Acme Holdings" when it should have matched "Acme Corp". Tighten the vendor rule.
  • Some transactions did not get extracted. Your bank's statement format may need a nudge. Open the bank statement Document Schema, add a custom prompt that calls out the column order or how multi-line descriptions wrap. Two or three examples is usually enough.