Who Should Own Finance Automation — IT or Finance?

The Question That Decides the Project Before It Starts

Most finance automation evaluations begin with a product question — which platform, what it costs, whether it integrates with our ERP.

The question that actually determines success is asked far less often, and usually too late: who owns this?

Not who signs the contract. Who is accountable twelve months after go-live. Who can change the approval matrix. Whose performance review reflects whether processing time went down.

Organisations that answer this early tend to succeed regardless of platform. Those that leave it ambiguous end up with working software nobody has changed their process to use — the most expensive outcome, carrying the full cost and none of the benefit.

Why Ownership Becomes Ambiguous in the First Place

The ambiguity is structural rather than political — finance automation genuinely sits across both functions.

It looks like an IT project: software to procure, a security review to pass, systems to integrate, identity and data residency to configure. All squarely IT’s domain, and IT is right to own them.

It is a finance project: the problem, the process, the metric, the people whose work changes and the controls being enforced are all finance.

Both functions have a legitimate claim, so the default resolution is usually that whoever is more available takes it — a poor basis for assigning accountability.

The three patterns that emerge

IT owns it. The evaluation is run by a digital transformation or automation team; finance is consulted but not accountable. Common where a CIO has stood up a dedicated AI group with a mandate to find use cases.

Finance owns it, IT is a blocker. Finance drives, but every technical dependency waits on an oversubscribed IT team. The project moves in bursts separated by long stalls.

Nobody owns it. Both functions treat the other as the owner. The evaluation proceeds for months, then quietly expires.

All three are recoverable — and much cheaper to prevent than to fix.

Why IT-Led Finance Automation Stalls

Pattern one deserves the most attention, because it is the one that looks healthiest from the outside. There is a team, a budget, momentum, and often genuine technical competence. It still fails, for three reasons that have nothing to do with capability.

IT is oversubscribed, and finance work queues

Enterprise IT teams are structurally over-committed. Infrastructure, security, compliance and the core roadmap consume capacity, and those carry hard deadlines — audit dates, licence expiries, regulatory changes.

Finance automation carries no equivalent deadline. Manual invoice processing is painful but not a compliance breach, and it will keep working next quarter. So when capacity is contested it slips — and slips again next quarter for the same reason.

One related dynamic is worth naming: where a separate AI or automation group has been created alongside the team owning the core ERP, those groups often compete. The ERP owner sees a new system touching their integration surface; the automation group sees a mandate to deliver. That tension is rarely resolved by the finance team who just wants invoices processed faster.

IT cannot authorise finance process change

This is the deepest problem, and better project management does not solve it.

Automation delivers value by changing how work is done — removing approval steps that exist only because the old system could not enforce a rule, auto-approving low-value matched invoices, replacing manual reconciliation with an exception queue.

Every one is a finance decision IT cannot make. So when IT leads and finance is merely consulted, the safe default is to replicate the existing process exactly.

The result is an automated bad process: invoices still route through four approvers because they always have. The integration is clean, the project ships on time — and processing time barely moves, because the bottleneck was never the software.

IT is not measured on finance outcomes

Both the IMA and IFAC frame finance transformation as a business-outcome discipline rather than a systems programme. IT is measured on platform outcomes: uptime, consolidation, security posture, cost. Finance automation improves none directly, and often worsens one by adding another system to the estate.

So the function accountable for delivery has no scoreboard reflecting success, while the function with the scoreboard has no accountability for delivery. Projects survive that only on individual goodwill — which does not survive reorganisation.

Why Finance-Led Projects Stall Too

Finance-led is generally the better default, but it fails in its own characteristic ways.

Technical dependencies bottleneck. API credentials, network access, SSO, security review — each requires IT, waits in IT’s queue, and finance cannot escalate.

Security review arrives too late. Finance selects a platform and negotiates commercially, then submits it for review — and discovers a data residency or authentication requirement that disqualifies it. Months lost.

Integration is underestimated. “It connects to our ERP” hides complexity around custom fields, historical data and reconciliation that finance teams reasonably lack the experience to probe.

Finance capacity is already committed. The most common and least discussed. Where an ERP migration or statutory programme is running, the senior finance people the project needs are already allocated. It gets approved, then starves.

What Is the Right Ownership Split?

The workable model separates outcome ownership from delivery ownership, and states both explicitly.

Advisory practices such as Deloitte and PwC apply the same split. The first line matters most: whoever holds the budget owns the outcome. If IT funds it, finance treats it as something being done to them. If finance funds it, IT becomes a delivery partner with clear obligations.

Give IT a veto, not the wheel

IT should be able to say no on architecture, security, data residency and integration viability — absolutely, and early, before commercial negotiation. What IT should not do is choose the workflow. A platform can be technically excellent and functionally wrong.

The Champion Metric: The Single Best Predictor of Success

If you take one thing from this article, take this. Projects that survive have one number and one named person — not a list of benefits. One metric, one owner, one target, one date. ACCA performance management guidance makes the same argument: measures without a named owner do not change behaviour.

Workable champion metrics:

Why this matters: automation projects compete against urgent work indefinitely. A champion metric converts the project from something that would be nice into something a specific person is accountable for. That person escalates, chases IT, and pushes back when it slips — because their own performance depends on it.

Projects without one rarely get cancelled. They drift, which is worse, consuming budget and attention without ever delivering value.

Choose a metric someone already feels

The metric should describe pain already being felt, not one invented for the business case. If the CFO raises close duration in every management meeting, that is the metric. Technically correct but emotionally neutral metrics — “process efficiency”, “automation rate” — do not generate the escalation energy the project needs.

How Do You Evaluate Without Finance in the Room?

This is common where the initial contact came through a technology, partnerships or transformation function rather than finance.

To be direct: you cannot properly evaluate finance automation without finance. But a technical session is not wasted, provided you know what it can and cannot settle.

What a technical-only session can establish

• Integration approach and API viability against your ERP
• Security posture, certifications, data residency — increasingly a regulated question, as MAS technology risk guidance illustrates for Singapore-regulated firms
• Identity and access management fit
• Architecture, deployment model, tenancy
• Whether the platform is disqualified on technical grounds

That last point matters — screening out unsuitable platforms before finance invests time is a real contribution.

What it cannot establish

• Whether the workflow matches how finance actually works
• Which invoice types are exceptions, and how they are handled today
• Which controls are mandatory versus habitual
• What the champion metric should be

The practical sequence

1. Technical screen (IT, no finance) — architecture, security, integration. Output: a technically viable shortlist.
2. Process session (finance-led, IT present) — walk the current process, invoice by invoice, including exceptions. Output: functional fit and a draft champion metric.
3. Joint decision — finance decides functional fit; IT holds technical veto.

The failure mode to avoid is letting step one produce the decision. A platform selected without finance will be configured to replicate the current process, because nobody in the room had authority to change it.

How Does Peakflo Fit Both Sides of This Split?

Peakflo is deliberately designed so that finance can own the process while IT retains control of the technical surface.

Finance configures the workflow

Approval matrices, thresholds, routing rules and GL coding logic are configured by finance without engineering work. This matters for ownership — when process change requires an IT ticket, process change stops happening. Approval workflow automation is built to be adjusted by the people who own the control.

IT keeps the integration and security surface

Standard API integration to major ERPs, SSO, role-based access, audit logging and defined data residency. IT governs the connection; finance operates within it.

Measurable from day one

Processing time, manual-touch rate, exception volume and approval cycle time are tracked natively rather than rebuilt in spreadsheets — a champion metric only works if measured. See AI automation KPIs for finance.

Deployable alongside an ERP programme

Operating at the capture, approval and matching layer rather than replacing the ledger, Peakflo runs against your current ERP and reconnects after migration — removing the most common reason finance automation gets deferred.

Our Verdict: How Should You Assign Ownership?

Finance should own it outright if:

• The pain is clearly financial — processing time, close duration, payment errors
• A named finance leader will accept the champion metric
• Finance has budget authority
• IT can commit to a bounded integration and security scope

IT can lead the evaluation, but not the decision, if:

• The engagement started through a technology or transformation function
• You are screening a broad platform category and need technical qualification first
• Hard architectural constraints could disqualify most options

Treat IT’s work as a screen and hand the decision to finance.

Stop and fix governance first if:

• Neither function will accept the champion metric — the project is not ready, and no platform fixes that
• Finance capacity is fully committed to an ERP or statutory programme — sequence deliberately rather than starting and starving it
• IT and finance disagree on the problem — a process session before vendor selection is far cheaper than discovering it during implementation
• The driver is “we should be using AI” rather than a specific operational pain — mandate-driven projects without a felt metric are the most reliable route to shelfware

Conclusion

Finance automation is not primarily a technology decision. Platforms here are broadly capable, and the gap between best and worst matters far less than the gap between clear and unclear ownership.

The pattern that works is consistent: finance owns the outcome, the budget and the process; IT owns integration, security and identity; one named person owns one number.

The failing pattern is equally consistent: IT owns it because it looks like software, finance is consulted rather than accountable, the system replicates the existing process, and a year later everyone agrees the tool works while nothing measurable improved.

That is not caused by picking the wrong platform, but by never deciding who owned the answer.

Related: CFO approval and the business case, finance automation ROI guide, and agentic workflows for finance teams.

Want to run a process session with both functions in the room? Request a demo.

Frequently Asked Questions

Who should own a finance automation project — IT or finance?

Finance should own the outcome and hold the budget, because finance owns the metric the project exists to move. IT should own integration, security review, identity and data governance. The common failure is inverting this: IT owns the project because the deliverable looks like software, and finance becomes a stakeholder to be consulted. Projects governed that way tend to deliver a working system that nobody changes their process to use.

Why do finance automation projects stall when IT leads them?

Three structural reasons. IT teams are usually oversubscribed, so finance work queues behind infrastructure and security commitments. IT cannot authorise process change in finance, so the automation gets configured to replicate the existing manual process. And IT is not measured on finance outcomes such as days payable outstanding or close duration, so when priorities compete the finance project loses.

What is a champion metric in a finance automation project?

A champion metric is the single finance number the project is committed to moving, owned by a named person accountable for it — invoice processing time, days payable outstanding, close duration, or manual-touch rate. Projects with a champion metric survive competing priorities because someone’s performance depends on completion. Projects without one drift indefinitely.

How do you evaluate finance automation without a finance stakeholder in the room?

You largely cannot evaluate it properly, but you can scope it. A technical team can validate integration approach, security posture, data residency and architecture fit. What cannot be assessed is whether the workflow matches how finance actually works, which invoices are exceptions, and which controls are mandatory. Treat a technical-only session as an architecture screen and schedule a separate process session with finance before deciding.

What is the difference between finance transformation and IT transformation?

Finance transformation changes how finance work is performed — approval paths, controls, close sequence, headcount allocation — and is measured in finance outcomes. IT transformation changes underlying systems and infrastructure and is measured in platform outcomes. Finance automation is a finance transformation programme requiring IT delivery capability, which is why ownership and delivery must be assigned separately.

Should you wait for an ERP migration before automating finance processes?

Usually not. ERP migrations commonly run twelve to twenty-four months and consume the finance capacity process improvement also requires. Because modern finance automation platforms integrate at the capture and approval layer rather than replacing the ledger, they can be deployed against the current ERP and reconnected after migration. Waiting typically means absorbing two more years of manual cost for no structural benefit.

What if IT and finance disagree on which platform to choose?

Separate the disagreement into its two components. If IT objects on architecture, security or data residency grounds, that veto should hold — those are genuine disqualifiers. If the objection is about preference, consolidation or familiarity, finance’s functional judgement should prevail, because finance bears the consequence of a poor workflow fit every day while IT does not.

How do you keep a finance automation project alive when IT capacity is constrained?

Bound IT’s scope tightly and make it explicit. Rather than open-ended involvement, define exactly what IT must deliver — API credentials, SSO, security review, one integration mapping — with dates. Constrained teams can commit to a small defined scope; they cannot commit to indefinite participation. Platforms that let finance configure workflow without engineering support sharply reduce ongoing IT dependency.

Should a digital transformation team own finance automation?

They can lead evaluation and provide delivery capability, but they should not own the outcome unless the transformation lead is accountable for a finance metric. Transformation teams are typically measured on delivery volume rather than business results, which produces implementations that go live successfully and change nothing operationally. Pair them with a finance owner who holds the champion metric.

What is the first meeting we should run internally before evaluating platforms?

A process session, not a vendor session. Get finance and IT in one room and walk the current process end to end — how invoices arrive, who touches them, where exceptions go, what breaks. Two outputs matter: agreement on the biggest pain point, and a named person willing to own the metric for fixing it. Vendor conversations are far more productive after this than before.