One statement, hundreds of unlabeled debits
A business bank statement covering a full month can easily run to several hundred transaction lines, and none of them come tagged as belonging to a specific loan or advance. Before any recurring pattern can be separated into individual positions, every one of those lines first has to be read accurately and turned into structured, usable data.
Why bank statements are hard to automate
Every bank has its own statement format, and the relevant fields — date, amount, description, running balance — can appear in different order and under different headings from one bank to the next. A solution built for one specific format breaks down the moment a business banks somewhere new, or an advisor reviews a statement from a bank they haven't seen before.
Reading from a statement's own printed structure rather than a template built for one bank sidesteps that fragility entirely. A community bank's statement and a national bank's statement look nothing alike on the page, but the same underlying fields — a date, an amount, a description — are present in both, and extraction is built to recognize those fields regardless of how a specific bank happens to lay them out.
How accuracy is actually measured
Every field carries its own confidence score, not just a single overall pass/fail for the whole statement. A date read cleanly from a well-formatted digital PDF might score near-perfect confidence, while a smudged figure on a faxed statement gets flagged individually — the rest of that same statement's clean fields aren't held hostage to the one unclear line.
In practice this means review time concentrates exactly where it's needed: a handful of flagged fields on an otherwise clean 300-line statement, rather than a blanket instruction to re-check everything because one number looked uncertain.
PDF, CSV, or a scanned statement — all read the same way
Not every bank statement arrives as a clean digital PDF. Some banks export a CSV directly; older accounts sometimes only have a scanned or faxed paper statement on file, especially for a position that's been running for a year or more. Each format is read through the pipeline appropriate to it — a scan or fax goes through OCR first — but the output is the same structured field set either way, so downstream grouping and export work identically regardless of what the source document actually was.
The fields that get read
| Field | Used for |
|---|---|
| Transaction date | Establishing each debit's weekday cadence |
| Debit/credit amount | Building an amount range for each recurring series |
| Description text | A secondary signal when a funder name is legible |
| Running balance | Confirming no transaction is missed or double-counted |
| Opening/closing balance | A completeness check across the whole statement |
Every field is captured whether or not it turns out to matter for MCA reconciliation specifically — a payroll deposit, a vendor payment, an ordinary card purchase are all read the same way as a recurring ACH debit. That completeness is deliberate: the same read supports general bookkeeping reconciliation alongside the loan-ledger use case, from one upload.
The opening and closing balance in particular double as a quick sanity check on the extraction itself — if every transaction has been read correctly, the running balance should tie out cleanly from the statement's stated opening figure to its stated closing figure.
Raw transaction data vs. a usable ledger
Reading the statement is a direct extraction — every line, exactly as printed. Turning that into a usable loan ledger means grouping the recurring debits by pattern, which is what the daily ACH debit separation feature does on top of the raw data this page describes.
Keeping these two steps distinct rather than one opaque black box matters for trust: the raw, unfiltered transaction data is available to review on its own, independent of whatever grouping logic ran afterward. If a grouping decision ever looks questionable, the underlying transaction data it was built from is right there to check it against.
How it works
One or more bank statements are uploaded, fields are recognized automatically regardless of the bank's format, and the result is displayed structured and ready for review — with anything uncertain flagged for a quick manual check before it's exported.
Processing many statements at once
A folder of statements — several months for one business, or one month across several clients — can be uploaded together rather than one at a time. Each statement is still read and structured independently, so a batch upload doesn't risk one statement's data bleeding into another's; it's purely a convenience for getting a large volume of documents through the same review step in one sitting rather than many.
For an advisor working across a caseload of clients with stacked MCA debt, this is where the time savings compound the most — the difference between an afternoon spent uploading and reviewing twenty statements versus an afternoon spent manually transcribing even a handful of them.
More than one bank account at once
Some businesses hold operating funds across more than one bank account — sometimes deliberately, sometimes as a legacy of switching banks. Each statement is read on its own terms, so having more than one bank in play adds no extra setup burden.
This matters specifically for MCA reconciliation because a funder's debit doesn't necessarily come from the account a business thinks of as its "main" one — some funders debit a secondary or reserve account by agreement. Reading every account a business actually uses, not just the primary one, is what keeps the resulting ledger complete.
When the debit pattern changes mid-statement
A new position starting, an existing one paying off, or a position shifting from a fixed amount to a percentage-of-sales structure each shows up as its own dated set of transactions. Reading every period's data independently, rather than assuming the pattern is static, keeps the extracted ledger accurate through any change.
This is also why reading several consecutive months together, rather than one isolated statement, tends to produce a more reliable ledger — a change that looks ambiguous within a single month's data is often obvious once the prior and following months are visible alongside it.
Each individual transaction still carries its own exact date, which is what makes this kind of cross-month comparison possible in the first place — the raw data doesn't collapse a month's activity into a summary figure, so a change that happened on a specific day in a specific month stays visible exactly where it occurred, rather than getting smoothed into an average.
Bank and NSF fees mixed into the same statement
A monthly maintenance fee, an overdraft charge or an NSF fee for a returned debit are read as their own transaction lines, distinct from the position-related debits around them, so they don't get blended into a recurring series they don't actually belong to.
This distinction matters more than it might first appear — an account under repeated NSF pressure from stacked debits can generate a cluster of fees that, read carelessly, look like their own small recurring position. Keeping fees in their own category from the start avoids that specific confusion downstream.
The manual process this replaces
Manually, this means opening each statement, scanning line by line for anything that looks recurring, and typing candidates into a spreadsheet — a process that for a statement with hundreds of lines easily takes an hour or more, and is vulnerable to transcription errors precisely because it's repeated so often.
It's also a process that scales poorly with client volume — an advisor or bookkeeper adding a second or third client with stacked MCA debt doesn't just add work, they add a second and third fully manual transcription routine running in parallel, each one carrying the same transcription-error risk as the first.
With tooling vs. by hand
By hand, the task is fully workable for a short statement. The advantage of automatic reading shows up as the transaction count grows — the time per statement drops to minutes instead of an hour or more, without a loss in accuracy.
| By hand | Automatic |
|---|---|
| An hour or more per statement, transcribing line by line | A couple of minutes per statement, any line count |
| Transcription error risk grows with transaction volume | Every line read the same way regardless of volume |
| Effort multiplies with each additional client or account | Additional statements queue the same way as the first |
Where the structured data goes next
Structured output exports to Excel or CSV, ready to drop into whichever spreadsheet template a bookkeeper or advisor already uses for tracking MCA positions, or to import into a broader bookkeeping system alongside a business's other financial records. The extraction itself doesn't assume a specific downstream format — it produces clean, complete transaction data that fits whatever process comes after it.
A CSV export in particular works well as an intermediate format precisely because it's widely supported — most bookkeeping software, spreadsheet tools and even custom internal tracking systems can ingest a CSV directly, without needing a purpose-built integration for this specific data.
Who this is relevant for
Bookkeepers who receive monthly bank statements for clients with MCA debt, restructuring advisors reviewing multiple clients' accounts, and business owners handling their own bookkeeping directly.
Each of these has a slightly different scale of need — a single business owner reading their own account, a bookkeeper reading statements for a handful of clients, or an advisor working across a larger caseload — but the underlying task is identical at every scale. What changes is only how many statements pass through the same process in a given month.
How often statements arrive, and why it matters
Bank statements typically arrive monthly, which makes this a recurring, predictable task — and that predictability is exactly what makes it worth automating, even if any single statement only takes a few minutes by hand.
A predictable monthly cadence also means the reading step can become part of a routine rather than a special task reached for only when something prompts it — uploading the new statement as soon as it's available, the same way each month, keeps the underlying transaction data current without requiring a deliberate decision to catch up on backlog.
Get started with your first statement
The easiest way to see if this fits your organization's bank statements is to try it with one real statement — the result shows immediately which fields were recognized correctly.
There's no setup step required before that first upload — no template to configure for a specific bank, no account mapping to define in advance. The statement is read from its own printed structure the first time it's uploaded, the same way it would be on the hundredth upload.
What happens to your data
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
For a bank statement carrying a business's full financial picture, that matters — full details are on the security page.
A typical example with three positions
A business with three stacked MCA positions uploads a single monthly bank statement covering 240 transactions.
| Category | Transactions |
|---|---|
| Recurring debits (all positions) | 62 |
| Ordinary business expenses | 158 |
| Deposits and transfers | 20 |
Read automatically, the full 240-line statement is structured in a couple of minutes, ready for the position-separation step that turns the 62 recurring debits into three distinct ledgers.
Done by hand, a statement of this size — 240 lines, three overlapping recurring series — is exactly the volume where manual review becomes genuinely time-consuming and error-prone: enough transactions that a quick eyeball scan reliably misses something, but not so many that the task feels obviously impractical to attempt manually, which is often what leads a business or bookkeeper to try it by hand anyway before eventually looking for a faster way through it.