A leading UK asset finance lender went live with ExactSum last week. Here’s what the first seven days actually looked like — not the pitch-deck version, the real one. The point of writing it up is that “week one” is the part most vendors skip over. ROI numbers from month six are easy. The first seven days are where the actual work happens.

Day Zero: What We Set Up Before Go-Live

Before any live cases flowed through the system, two things needed to be in place: the parsing layer had to handle the bank statements this lender actually sees, and the Decision Engine had to reflect their underwriting policy rather than ours.

The first was straightforward. The lender’s deal flow runs through the usual UK high-street and challenger banks — Barclays, HSBC, Lloyds, NatWest, Starling, Tide, and a long tail of business-banking platforms. ExactSum already parses these. We ran their five most awkward historical cases through the pipeline to confirm, including one with mid-statement bank changes and one with a 140-page deposit account.

The second took longer and mattered more. Their head of credit walked us through their existing manual checklist — the things their underwriters actually look for when assessing a file. That checklist got translated into a starting ruleset for the Decision Engine: account verification, customer concentration thresholds, headroom against committed outgoings, unpaid-item tolerance, tax compliance signals, and a handful of sector-specific exceptions.

The thresholds were theirs, not ours. Our job was to wire the policy in, not to write it.

Day One: First Live Cases

Monday morning, the first real applications arrived. Three things were tested in the first session that no amount of pre-launch demoing fully covers:

Does the speed actually translate? Demos run on clean files in calm conditions. The first live cases included one statement uploaded as a phone screenshot of a screen, one password-protected PDF, and one merged bundle of six monthly statements in the wrong order. All three parsed correctly. The phone screenshot took longer than the others, but it produced the same structured output.

Do the underwriters trust what they see? The first three cases were reviewed in parallel — the existing manual process alongside the ExactSum output. The numbers reconciled. Where the underwriter had previously written “average monthly turnover £42k”, the engine returned £41,873. The conversation in the room shifted quickly from “is this right” to “this is right, what do we do with the time we just got back”.

What happens when the engine refers a case? The first Refer-to-Underwriter outcome of the week was a customer-concentration breach — 71% of revenue from a single counterparty. The decision pane showed exactly which rule triggered and exactly which metric drove it. The underwriter agreed with the referral, and the case moved forward with eyes open. That’s the whole point: surface the thing that needs a human, hide the things that don’t.

Decision: Refer to Underwriter Account verification Pass Tax compliance Pass Customer concentration Refer Top counterparty: 71% of total revenue Threshold for referral: 60% Headroom ratio Pass Unpaid items Pass Trend & seasonality Pass View source transactions →

Days Two to Five: Volume

Once the first day’s reconciliation was clean, the team moved to running new applications through ExactSum first and using the manual process as a check rather than the other way around.

A few things stood out across the week:

Auto-Approve outcomes cleared faster than anyone expected. Cases the team would previously have spent thirty to sixty minutes on were reviewed in a glance — the underwriter scanned the metrics, scanned the rule outcomes, and signed off. The bottleneck moved from “reading the statements” to “reviewing the engine’s reading of the statements”, which is a much shorter task.

Decline outcomes were the unexpected win. Files that would previously have been read in full before being declined were declined in a glance. The lender’s manual process had no way to triage these earlier — every file got the same attention regardless of whether it was going anywhere. The engine surfaced the obvious nos in seconds, which freed up time disproportionately.

Refer-to-Underwriter became where the day actually went. Which is exactly the goal. The middle stack is the work that justifies an underwriter’s job. The rest is administration.

Where underwriter time goes Before automation Auto-approved (~40%) Referred (~35%) Declined (~25%) After automation Auto-approved (~40%) Referred (~35%) Declined (~25%) Where the day now goes.

No major edge cases broke the parser in the first week. One statement format triggered a layout warning rather than a clean parse — we patched it the same afternoon, the lender re-ran the case, and it cleared.

Day Seven: The Conversation We’re Having Now

The first weekly review sits at the end of week one. Three things are on the agenda, and they’re the same three things any lender should expect to be discussing at this stage:

Threshold tuning. A few rules need adjusting. The customer-concentration threshold flagged a couple of cases that, on review, the underwriting team would have approved anyway — the threshold was set conservatively at launch and now has real evidence to tune against. This is normal. Rulesets aren’t written once; they’re refined as the engine sees more files.

Coverage gaps. A couple of niche scenarios the manual process used to catch implicitly — through underwriter judgement rather than written policy — need to be encoded as rules. This is one of the underappreciated benefits of running an engine alongside a manual process: it forces tacit knowledge to become explicit policy.

What gets automated next. Bank statement extraction is the foundation, but the lender’s full credit pack includes filed accounts, management accounts, and asset valuations. The conversation about what else to bring into the same pipeline starts here.

What Week One Actually Tells You

It’s too early to write a case study about ROI. ROI lives in months three through six, when threshold-tuning has settled and volume has run through the system long enough to compare against the same period the year before.

What week one tells you is something different and arguably more important: whether the implementation works. Whether the parsing handles your real files, not the marketing examples. Whether the rules reflect your policy, not the vendor’s defaults. Whether the underwriters trust the output enough to act on it. Whether the small operational frictions — file uploads, user permissions, weekly review cadence — are bearable.

This implementation cleared all four. The harder questions — how much time it actually gives back, how the credit outcomes compare, where the rule edges are — will be answered with data over the next quarter, not with assertion now.

We’ll write that piece when the numbers are in.

See How Week One Could Look at Your Lender

We'll set up a sandbox with your real statements and your underwriting policy, and walk you through the first cases together.

Book a Demo