Integration Guys Ltd

A day of an accountant's time, per company

Every business lending decision starts with the numbers. Before a credit team can judge a borrower, someone has to take that company's financial statements and lay them out in the bank's standard form, so that every borrower can be compared on the same basis. In lending this is called spreading.

At a UK lender I know well, spreading a company's accounts used to take an accountant up to 24 hours. Every set of accounts is laid out differently, uses different line names and groups things in different ways, so each one had to be read, interpreted and keyed in by hand.

Today it takes about five seconds, and costs around 10p instead of around £60.

This post is about how we got there, why it was the right first AI project for a bank, and the benefit we did not plan for, which turned out to be the most interesting part.

Why this was the right first project

A bank is not the place to start with AI by putting a model in front of customers or letting it make credit decisions. We were not sure where to start, so we deliberately picked something low-impact that sat just outside the main line of the business, where we could prove value without putting anything at risk.

Spreading ticked every box:

• Clear inputs and outputs. Published accounts in, the bank's standard form out.
• Contained. If it got something wrong, an analyst would catch it before it reached a credit decision. Nothing customer-facing changed.
• Measurable. Hours per company and pounds per spread, before and after.
• Expandable. If it worked, the same pattern could be applied to other documents the lending team reads by hand.

We delivered it in six weeks. The numbers did the persuading: once the business saw a day's work turn into seconds, it had the confidence to fund the next phase. Earlier this year I wrote about why most AI projects fail before they start. This project is the counter-example I had in mind.

Spreading is a mapping problem

At heart, spreading is the same problem I have spent my career on. Every company's accounts are a different source format. The bank's standard form is the target. The work is mapping one to the other, faithfully, every time.

That means the lessons from earlier in this series apply directly:

• The standard form is the contract. As with any implementation guide, the hard part is agreeing what each line in the target means, and which source lines belong in it. A model can read a balance sheet. It cannot decide your bank's credit policy on how to treat a director's loan.
• The mapping is quick; proving it is the job. As in last fortnight's test, getting a plausible first draft is the easy part. Checking it against spreads your accountants have already done by hand is what tells you whether to trust it.
• Write the decisions down first. Writing down the rules for awkward cases before the build is what lets you build quickly without building the wrong thing.

At a high level, the tool ingests the documents a business provides, such as its profit and loss account and its bank statements. UK business accounts follow broadly similar formats, which helps, but no two are laid out quite the same. The AI reads each one and maps it into a single internal format that the risk team works from, so every borrower arrives in the same shape regardless of how their accountant chose to present them.

What made it safe enough for a bank

A regulated lender cannot adopt a tool because it is fast. It has to be able to explain every number that feeds a credit decision. Three principles mattered more than the model:

• The decision stays human. The AI prepares the spread. People in the credit team still make the lending decision, and they can see where every figure came from.
• Every figure is traceable. Every decision the system makes is audited and logged, so any figure can be traced back to where it came from. When something is wrong, that trail is how the error is found, corrected and fed back into the model. If you cannot show your working, an auditor will not accept it, and nor should your credit committee. I wrote about this in The Black Box Problem.
• Uncertainty is surfaced, not hidden. Any case where the AI is unsure goes to a person to review, rather than being quietly forced into a line. The person's answer is then fed back, so the system learns from grounded, human-checked data.

That feedback loop is what made the system better over time rather than worse. Over time the number of these anomalies has fallen significantly, because every human correction becomes something the system has learned from. It is the same lesson as keeping a data cleaner from rotting: the review step is not overhead, it is how the AI improves.

The benefit nobody asked for

The business case was about new lending: spread faster, decide faster, free the accountants for work that needs their judgement.

The more interesting result came from the economics. When a spread costs £60 and a day of someone's time, you do it when you have to: when the loan is written and at scheduled reviews. When it costs 10p and takes seconds, you can do it whenever you like.

So we do. When a borrower files new accounts at Companies House, the system spreads them automatically and re-reviews the existing loan. Any risk it finds is raised straight to the lending team to review. We now actively review the whole back book, without adding a single member of staff. The back book gets looked at when something actually changes, rather than on a calendar date. That is a better way to manage credit risk, and it costs almost nothing.

That is the pattern I would look for in any AI project. The first win is doing the old job faster. The bigger win comes from asking what you would do differently if the job were nearly free. A 600-fold fall in cost does not just make the old process cheaper. It makes new processes possible.

What I would tell others

1. Start where a mistake is cheap. Pick a contained, measurable job outside the main line, where a person checks the output before it matters.
2. Measure in pounds and hours. "24 hours to five seconds, £60 to 10p" persuaded the business faster than any demo.
3. Treat it as a mapping problem. Agree the target, write down the rules for awkward cases, and test against work people have already done by hand.
4. Make every number traceable. In a regulated business, a figure you cannot explain is a figure you cannot use.
5. Ask what becomes possible when it is nearly free. The re-review of the back book was not in the business case. It may end up being the most valuable part.

If you are looking for the right first AI project in a regulated business, I am happy to compare notes.

Earlier in this series: MCP is the new EDI, The Mapping Took Four Minutes and Spec First, Prompt Second.

Next week: what changes for a CTO when every developer has an agent?