"Which AI should we implement in the finance function?"
I get some version of this question every week. From founders, from CFOs, from recruiters writing job specs for AI-native finance leaders who have already implemented an AI-native ERP.
It is an understandable question. Finance leaders are being asked to improve productivity, strengthen controls and support a growing business without growing the team at the same rate. AI promises help with all three.
It is also a familiar question. We have been asked versions of it for years, with the technology swapped out. Machine learning. Then RPA. Then iPaaS. Now AI.
Each time, it starts too far downstream.
Before choosing the technology, we need to understand where the work happens, what makes it expensive, and which responsibilities we want to take on ourselves.
Look at where finance work actually happens. Travel is in a booking tool. Expenses and cards are in a spend platform. Billing might run through Stripe and something custom. FP&A has its own application. HR is one provider, payroll another, sometimes several more if the company operates across countries. Tax may be in-house or outsourced. Bill processing has an entire market of applications of its own.
And between those systems sit the reconciliations, allocations and schedules that someone still maintains in Excel.
In many companies, the ERP serves as the accounting backbone, while much of the operational work happens in connected applications. By the time an entry reaches the ledger, several people and systems may already have touched it.
So when the conversation turns to an AI-native ERP, the useful question is: which part of this process does it improve?
Bank statement processing, bill capture and ledger chat can be useful capabilities. But those features alone do not establish how well a product handles the complete process.
The ERP is one part of the evaluation. We need to examine the whole landscape.
Measure the completed process #
Take a single card transaction.
An employee buys something. They find the receipt, submit it, choose a category and explain the business purpose. Depending on the policy, a manager approves it. Finance checks the treatment, resolves whatever is missing and makes sure the transaction reaches the ledger correctly. Somebody reconciles it later.
A spend platform can automate several of those steps. It also requires work of its own: maintaining users, mapping categories to the chart of accounts, correcting receipt matches, investigating incomplete exports and explaining to employees where to submit things.
Both belong in the evaluation. The subscription price captures neither the full benefit nor the full operating cost.
A feature can save time inside an application without saving time across the process. An approval becomes faster but produces more exceptions for finance. Receipt capture improves while employees spend longer fixing categories. An integration removes a manual export, but somebody still needs to establish whether every transaction arrived.
The unit of analysis is the completed process, not the screen.
For spend management, I start with four unit costs:
- Cost to process one business card transaction.
- Cost to process one out-of-pocket reimbursement.
- Cost to resolve one personal purchase made on a company card, including identification, recovery and correct accounting treatment.
- Cost to process one mileage request.
Each includes three components:
- Business users' time: submitting, explaining, correcting and chasing.
- Finance and approvers' time: reviewing, handling exceptions, posting and reconciling.
- Full software cost: licences, implementation, integration, administration and ongoing maintenance.
The categories need clear boundaries so that the same work is not counted twice. Shared costs need a consistent allocation, and routine transactions should be distinguishable from exceptions.
This gives us a baseline. It makes visible the costs that a subscription comparison misses.
Then we need to ask whether the process works well.
Run quality measures alongside cost: turnaround time, correction rate, the share of transactions completed without manual intervention, and whether exceptions reach someone able to resolve them. Check whether approvals were applied as intended and whether supporting evidence is available.
Read those measures together. A low average processing cost can conceal a handful of expensive failures. A high automation rate can conceal errors discovered during the close. A process that becomes cheaper by weakening necessary controls may simply move effort and risk downstream.
The objective is dependable completion at an acceptable cost.
That gives AI a concrete test. If a feature improves those outcomes enough to justify its full cost, it is valuable. The same is true of a conventional rule, a better integration or removing an unnecessary approval.
The technology matters. It determines what is possible, how reliably it works and what it costs to keep working. The label "AI-powered" does not answer those questions.
Ask what the vendor contributes #
Once the process is visible, ask what each product is doing for the company.
A spend product may combine banking and card infrastructure with receipt capture, policy controls, approval routing, accounting integrations and support. Some of those capabilities may overlap with services the company already buys.
Where an existing platform meets the requirements, a separate product has to justify its additional cost, administration and integration work. Where the requirements exceed that platform's capabilities, a specialist product may earn its place.
Calling something a workflow layer does not prove it is expendable.
A mature workflow may contain years of accumulated handling for cases that look trivial until they fail. Depending on the service, the vendor may maintain integrations, support changing requirements, enforce permissions, preserve audit evidence and help users resolve payment problems.
Those are real responsibilities. Bringing the workflow in-house means assigning them to somebody else.
The question is how well the vendor carries those responsibilities, and whether the price is reasonable compared with the alternatives.
Decide where control is worth the responsibility #
There is still a strong case for controlling more of your own operating logic.
The signs are familiar. The same policy is configured differently in four tools. A routine approval change requires extensive workarounds. Accounting treatment depends on a spreadsheet two people understand.
At that point, the company is paying for software while maintaining a parallel process around its limitations.
Some rules deserve deliberate ownership: approval thresholds, allocation methods, entity treatment, exception routing and the conditions under which a transaction can post automatically.
Ownership means being able to read those rules, see how they were applied, test a change, establish who authorised it and move them if the surrounding technology changes.
That does not require custom software. A purchased platform may provide enough visibility, flexibility and portability. For a standard process, adopting the vendor's conventions can be the economical choice.
Greater control earns its keep when the rules change frequently, span several systems or materially shape how the business operates.
The benefit is flexibility. The price is responsibility.
Somebody must document the logic, manage access, test changes, monitor execution and fix failures. Somebody else must be able to take over when that person leaves.
Moving rules out of several applications can reduce fragmentation. It can also create a new dependency on a central platform or a small internal team. That tradeoff belongs in the decision.
Compare complete costs #
Build-versus-buy arguments often compare a full vendor bill with a partial internal budget.
Five tools at €50,000 a year cost €1 million over four years, before internal administration and integration costs. That looks like a substantial budget for an internal alternative.
But how much remains after infrastructure, platform licences, development, testing, support and continuity? Can the internal team deliver the same scope and service level, including when something fails during a payment run?
Apply the same accounting to the purchased option. Include implementation, configuration, administration, integration maintenance and the effort spent working around product constraints.
The comparison needs the same scope, service level and time horizon, with realistic assumptions about transaction growth, changing requirements and failures.
Until both sides are complete, €1 million is a headline, not a business case.
Be equally accurate about the savings.
Minutes recovered across thousands of employees can reduce friction and create useful capacity. They do not automatically become cash savings. Time recovered within finance may support better analysis, reduce overtime or allow the business to grow without another hire.
These are different outcomes. State which one the business case expects, and how the company will realise it.
The strongest evidence is a measured pilot: one defined process, a baseline and a record of what changed. Include implementation effort and the work required to keep it running.
Give agents the same test #
Agents may change the economics of finance software.
An agent that can read a receipt, retrieve the relevant policy, propose accounting treatment and route an exception could reduce the need for people to move between applications. It could also make some workflow functionality easier to reproduce elsewhere.
That is worth testing.
Permissions still need to be enforced. Duplicate postings need to be prevented, detected and corrected. Decisions need to be traceable. Failed actions need to be detected and recovered. Uncertain cases need to reach a person able to resolve them.
Performing the visible steps is only part of the job. The surrounding controls and operating responsibilities remain.
So the test stays the same: does the agent reduce total effort, preserve or improve controls, and run reliably at an acceptable cost?
Sometimes the answer may justify replacing a specialist product. Sometimes it may justify running the agent inside that product, where the controls and transaction handling already exist.
The conclusion should follow the evidence.
Hire for that judgment #
This also answers the hiring question.
Experience implementing AI is useful. So is experience shortening a close, fixing a reconciliation process or consolidating a fragmented stack. What matters is what improved and whether the improvement lasted.
Can the person explain where work accumulated? Can they distinguish a process problem from a software limitation? Can they establish a baseline, assess controls and compare the full cost of alternative approaches?
Do they know when a standard product is sufficient and when greater control justifies the maintenance burden?
Ask them to walk through one process they changed: what it cost before, where it failed, what they introduced and what responsibility the team took on afterwards.
That will tell you far more than the label on the technology they implemented.
"Which AI should we buy?" becomes a useful question once you know which work should disappear, what it costs today and how you will know the process has improved.
By then, you have a concrete job for the technology — and a way to tell whether it did it.