Bank statement reconciliation software for firms

Bank statement reconciliation software for an accounting firm should do one thing the bank feed can't: read the bank's own statement PDF, prove it read it correctly against the statement's printed subtotals and running balance, and then tie every line to the ledger so any transaction the books are missing, or have twice, is visible. The feed is a convenience. The statement is the record. Reconciliation means the books match the record, and the software's job is to make that comparison mechanical.

We run an accounting firm, and the statement is where every cleanup and every monthly close starts for us. Here's what we learned building the tool that reads it, including the parts where accuracy has to beat speed.

Why bank feeds alone miss transactions and create duplicates

Bank feeds are good at what they're for: pulling recent transactions into the ledger so someone can categorize them. They're bad at being the record, for reasons any bookkeeper who's reconciled a year of feed knows.

Feeds drop transactions. A connection that hiccuped on the 14th skips two days and nobody notices until the reconciliation is off by $1,340. Feeds duplicate on reconnect, pulling the last ninety days again and creating a second copy of every transaction the bookkeeper already coded. Feeds start mid-month when a client connects a new account, so the first partial month never ties. And feeds go stale when the client changes a password and doesn't tell anyone, leaving a gap that grows until someone checks.

Every one of those failures is invisible from inside the feed. The only way to see it is to compare the ledger against something the feed didn't produce, and that something is the statement the bank printed.

Reading the bank's PDF and checking it against its own subtotals

A statement is a structured document, but not a consistent one. Every bank formats it differently, the same bank changes formats between years, and a scanned statement is a picture of a document rather than the document. Reading it means extracting every transaction line with its date, description, and amount, and knowing which column is a debit and which a credit on a page where the bank put both in one column with a sign convention it never explains.

The part that makes the read trustworthy is that the statement checks itself. Every statement prints a beginning balance, total deposits, total withdrawals, and an ending balance. Most print a running balance per line or a daily balance summary. Those are check digits. If the extracted deposits sum to the printed deposits total, the withdrawals sum to the printed withdrawals total, and beginning plus deposits minus withdrawals equals the printed ending balance, the read is correct. If they don't, the read is wrong somewhere, and the software has to say so rather than hand over a list that looks complete.

That's the rule we built to: reconcile each page against the statement's own totals before anything is compared to the ledger. A page that doesn't tie is flagged and re-read, and if it still doesn't tie a person looks at it. The alternative, extracting fast and hoping, produces a reconciliation that's off by one missed line, which is worse than no reconciliation because it looks done.

Card statements, loan statements, and escrow statements have their own arithmetic (a card's ending balance is a liability that grows with purchases; a loan statement has principal, interest, and escrow components), and the software has to know what kind of statement it's reading to check it correctly.

What a line-by-line tie-out surfaces

With the statement read and proven, every line gets matched to a ledger transaction by date, amount, and description. What's left after matching is the reconciliation's actual findings, and they sort into a short list.

On the statement, not in the books. Deposits the feed dropped, bank fees nobody entered, a wire that came in while the feed was disconnected, checks that cleared from a checkbook nobody told the bookkeeper about. These are missing revenue or missing expense, and each is a line to add.

In the books, not on the statement. Duplicates from a feed reconnect, a bill payment entered when the check was written and again when it cleared, a deposit recorded from the invoice and again from the feed, an outstanding check that's now nine months old and was probably voided and rewritten. These are the transactions to remove or reverse.

Matched on amount, off on date. Usually fine; sometimes a sign that two similar transactions got matched to each other and a third is missing.

A monthly reconciliation done this way takes minutes of review, and the review is of a list of exceptions rather than of two documents side by side. The reconciled balance per account, recorded on the close checklist, is a fact: the ledger matches a statement that matched itself.

Accuracy over speed: what happens when a page doesn't tie

The temptation with any document-reading tool is to make it fast. Read all twelve pages at once, return the list, move on. We chose the other direction on purpose.

Pages are read one at a time, in order, because the running balance on page four depends on page three being right. A page whose totals don't tie stops the process for that statement. The software doesn't guess at the missing line or drop it; it reports the page and the difference, and either re-reads with a different strategy or asks a person to look. A statement is only marked reconciled when every page ties to its own printed check digits and the whole statement ties beginning to ending balance.

That costs seconds per statement. It saves the hour a bookkeeper would otherwise spend finding the one line an eager parser skipped, and it means the number on the close checklist can be trusted by the reviewer, the tax preparer, and the lender who reads the balance sheet later.

Twelve months in minutes: the cleanup use case

Where this matters most is the catch-up engagement. A client arrives with a year of unreconciled books and a folder of statements, or a login. The old method was a bookkeeper with two PDFs open, reconciling each month by eye, which is where cleanup quotes of twenty hours became sixty.

The new method: upload or pull the twelve statements, let each one be read and proven against its own totals, then tie all twelve to the ledger at once. The findings list for the whole year comes out in one pass: every missing deposit, every duplicate, every fee. Step 2 of the cleanup sequence, which used to be the longest step, becomes the shortest, and the bookkeeper's time goes to the categorization and balance-sheet work that needs judgment. It's how four full-year restaurant cleanups closed in under ten hours of staff time before the September deadline; the whole sequence is in our guide to running a cleanup in the right order.

Where the platform comes in

Woven is our product, and statement import is the piece of it we're most particular about. It reads the bank's own PDF, whether uploaded or pulled, reconciles each page against the statement's printed subtotals and running balance before trusting it, knows the difference between a checking, card, loan, and escrow statement, and ties every line to the ledger so the exceptions are the reconciliation. Statement import is included on every firm plan, and bank connections through the feed are free, so the feed does the daily work and the statement proves it. Firm pricing is per client at $39, $32, or $25 a month depending on volume. To watch a twelve-month tie-out run on a real file, book a demo.