ExactSum went into 2025 as an observation: lenders were drowning in bank statements, and every tool they had was built for a cleaner world than the one landing on their desks. We came out of it with a product, a catalogue of bank formats we would rather not have needed, and four decisions we would defend to any credit committee. This is the short version of the year.
What we decided
Read the statement the applicant actually sends. Open banking works when the applicant consents, the bank is covered and the API stays up. Most of the time at least one of those is missing, and what arrives is a PDF, a scan or a phone photo. So ExactSum reads that. Any bank, any layout, PDFs and images alike. The document on the underwriter's desk is the input, not the document we wish they had sent.
Extraction is half the job. The lenders we sat with did not want rows in a spreadsheet. They wanted answers. Is this applicant a gambling risk? Are there payday loan repayments buried in the history? Does the salary landing in the account match the salary on the form? Is there a sign of distress on page 47 that a tired reviewer would miss? The analysis went on top of the extraction from the start: gambling detection, debt tracking, income verification and spending categorisation, rather than being left as an exercise for the reader.
Every bank is its own problem. A generic parser gets most of a statement right and then quietly gets the rest wrong. We chose to handle each format's quirks specifically and test against real statements from real lending workflows. The table below is a sample of what that meant this year.
Accuracy is measured, not claimed. In December we re-ran extraction against statements checked line by line by hand and moved the published figure from 98 percent to 99.4 percent. The number sits on the site because it was measured, and it moves when the measurement does.
| Bank | What its statements do |
|---|---|
| Barclays | Drops the year from the date column and expects you to work it out from context. Prints the date once and leaves it blank for the rest of the day. Adds balance rows that are not transactions. |
| HSBC | A mainframe-era layout with misaligned text, no running balance, and a "D" suffix on some amounts that can make a lender misread overdraft status. |
| Santander | Ordinal dates such as "1st January", fee tables laid out like transaction tables, and marketing between the two. |
| Starling | Landscape pages with the column headers on page one only, then hundreds of pages without them. |
| Revolut | Several currencies and several accounts in one PDF, newest transaction first. |
| Scans and photos | Skewed pages, shadows, a thumb over the balance column. Still a statement, still has to be read. |
What we built
Most of the year was spent with lenders rather than in the codebase: SME lenders, asset finance funders and brokers reviewing hundreds of statements a day from pubs, hotels and construction firms, where an experienced analyst spends 20 to 30 minutes on a single statement. That time turned into a list of what the product had to do, and December was when the list became the platform.
The extraction engine was rebuilt around large language models reading each page, with a second model standing behind the first so that one provider having a bad day does not stop a lender's queue. Statements are processed page by page, so a 300-page file no longer succeeds or fails as one unit. Every file access is checked against the account that uploaded it. On top of that went the plumbing a lender expects: plans and quotas, billing, API keys, a login, a mobile menu and a light theme for people who do not underwrite in the dark.
| Period | What happened |
|---|---|
| Spring | A year of conversations with UK lenders about what actually lands on an underwriter's desk. The format catalogue starts. |
| Summer | The first piece on a single bank's statements, Barclays. Good design, hidden complexity. |
| Autumn | The analysis layers take shape: gambling, debt, income verification and categorisation on top of the transactions. |
| December | Engine rebuilt on language models with a fallback model, page-by-page processing, quotas and billing, API keys. Accuracy re-measured at 99.4 percent. |
What we wrote
Three pieces, each written to be argued with. Parsing Barclays bank statements in June. Why we built ExactSum in December, which is the origin story in four minutes. Parsing HSBC bank statements at the end of the month, on the mainframe legacy and the "D" suffix.
What we learned
The things that break extraction are never exotic. They are a date printed once per day, a running balance that restarts at the top of each page, a suffix letter after an amount. Each one is trivial on its own and each one silently corrupts a lending decision if missed. The only defence we found is boring: test against thousands of real statements, keep every failure as a regression case, and never let the model guess a balance it cannot see.
The other lesson was about the people. Nobody we met wanted less judgement in underwriting. They wanted less transcription. An analyst who spends half an hour re-keying a statement is not underwriting for that half hour, and the product's job is to give that time back with the evidence attached.
The model is not better than a person at reading a bank statement. It just does not get tired on page 47.
What comes next
2026 is about three things. More banks, including the US formats that lenders across the Atlantic have started sending us. An API, so a lender can put ExactSum inside its own workflow rather than beside it. And turning analysis into decisions: a lender's own rules applied to every file, so the clean cases clear themselves and the grey area lands on a desk with the reasons written down. Law firms have also started using the same engine for source of funds work, and we intend to follow that.
Thank you to every lender who sent us a statement that broke something. That is how the engine got better, and it is how it will keep getting better.
See ExactSum in Action
Send a handful of statements from cases you have already decided. We run them in front of you and show where every figure came from.
Book a Demo