Why We Built ExactSum

ExactSum started with a simple observation: lenders were drowning in bank statements.

About a year ago, I started talking to lenders across the UK. These were companies reviewing hundreds of bank statements every day as part of their affordability assessments. Not simple personal statements with a dozen transactions — I'm talking about statements from pubs, hotels, and construction companies. Hundreds of pages. Thousands of transactions.

Every single one needed to be reviewed, categorised, and analysed before a lending decision could be made. And every single one was a PDF.

The Format Problem

What struck me was the variety. Every bank does things differently.

NatWest has a fairly standard layout. HSBC still uses that old-school mainframe design — you can tell it hasn't changed in decades. Starling goes landscape mode with a modern look. Revolut throws multiple currencies onto a single statement. Barclays drops the year from date columns and expects you to work it out from context.

For lenders processing hundreds of applications, this inconsistency was painful. Their teams were spending hours manually extracting data, or using generic PDF tools that mangled half the output. Every bank format was a new headache. Every scanned document was a gamble on whether the data would come through correctly.

The existing solutions weren't much better. Legacy providers with clunky interfaces. Open banking integrations that only worked when the applicant cooperated and the bank's API didn't time out. Nothing that reliably handled the reality of what actually lands on an underwriter's desk: a mix of PDFs, scans, photos, and formats from dozens of different banks.

Building for the Real Problem

So we built ExactSum. Not another PDF-to-Excel tool, but a proper analysis platform designed for how lenders actually work.

The core insight was that extracting transactions from a PDF is only half the job. Lenders don't just need data — they need answers. Is this applicant a gambling risk? Are there payday loan repayments buried in the transaction history? Does the stated income match what's actually coming into the account? Are there signs of financial distress that a manual reviewer might miss on page 47 of a 60-page statement?

We built the AI extraction engine to handle the format variety — every bank, every layout, PDFs and images alike. But then we layered analysis on top:

• Gambling detection — Identifying transactions to betting companies, casinos, and gambling platforms, including ones that try to obscure their names
• Debt tracking — Spotting payday loans, buy-now-pay-later repayments, and other debt obligations that affect affordability
• Income verification — Matching salary deposits against stated income, identifying irregular income patterns, flagging discrepancies
• Spending categorisation — Breaking down where money goes so underwriters can assess lifestyle spending and financial behaviour

The Variety Problem at Scale

The technical challenge that keeps us sharp is the sheer variety of bank statement formats. We've now processed statements from hundreds of different banks and financial institutions. Each one has its own quirks.

HSBC puts a mysterious "D" suffix on some amounts. Santander uses ordinal date formats like "1st January" instead of standard dates. Some banks print the date once and leave it blank for subsequent transactions on the same day. Others restart their running balance at the top of each page. A few don't include running balances at all.

Every one of these quirks is a potential source of errors if you're using generic extraction tools. We've built specific handling for each one, tested against thousands of real statements from real lending workflows.

What We're Solving

The lenders we work with were spending significant time and money on manual statement review. An experienced analyst might take 20-30 minutes per statement. Multiply that by hundreds of applications per week, and you're looking at multiple full-time roles dedicated to nothing but data entry and basic categorisation.

ExactSum reduces that to minutes per statement, with analysis that's more consistent and thorough than manual review. Not because AI is inherently better than humans at reading bank statements, but because it doesn't get tired on page 47, doesn't miss the gambling transaction buried between two grocery purchases, and doesn't accidentally skip a row when transcribing from a 382-page PDF.

That's why we built ExactSum. Not because the world needed another fintech product, but because lenders needed a tool that actually understood bank statements — in all their messy, inconsistent, format-varying reality — and could turn them into reliable lending intelligence.