Finance Transformation Before Technology: What Business Leaders Should Diagnose First

Automate last, after the process has earned it

In The Algorithm, former Tesla President Jon McNeill describes a sequence that ends with automation only after requirements have been challenged, unnecessary work removed, the remaining process simplified and cycle time improved.

The finance application is straightforward: do not automate a process merely because it exists.

Once workflows are configured, integrations built and data migrated, process decisions become expensive to change. Premature automation effectively pours concrete over assumptions that have not been tested.

Where risk and scale permit, pilot the redesigned process using simple tools. A limited manual run can expose missing exceptions, unclear ownership and poor-quality inputs before they are embedded in a system. The purpose is to understand the logic before making it rigid.

Technology should follow operating design, not substitute for it.

Start with the business outcome

“Modernise finance” is too broad to guide a transformation. A useful programme begins with specific outcomes, such as:

• earlier and more reliable performance visibility;
• stronger cash and working-capital control;
• scalable multi-entity processing and clearer accountability;
• improved board, investor or lender reporting;
• less dependence on manual work and individual knowledge;
• better support for expansion, transactions or regulatory scrutiny.

These outcomes create a basis for prioritisation and prevent the project from being defined by whichever features are easiest to demonstrate. If leadership cannot explain the business problem in plain language, the project is not ready for software selection.

Diagnose the decisions finance must support

Finance exists to protect value and help the organisation allocate resources well. The diagnostic should therefore begin with decisions, not reports.

Which decisions are currently made too slowly or with insufficient evidence? Where does management lack confidence? Which questions repeatedly require bespoke analysis?

Examples might include whether to accelerate hiring, enter a market, change pricing, fund an investment, manage liquidity or respond to underperformance.

Once these decisions are clear, the required information, timing and level of detail can be designed around them. This connects the transformation directly to the dynamic decision-support model described in From Static Budgets to Dynamic Decision Support.

Walk the process as it actually operates

Documented procedures often differ from daily practice. Interviews and workshops are useful, but they should be tested against real activity.

A CFO or business leader can learn a great deal by following one transaction from beginning to end: submit a mock expense claim, request a purchase order, trace a customer invoice through to collection or follow a month-end balance from source system to board report.

Experiencing the process reveals practical friction that a high-level process map may miss:

• repeated manual entry;
• bottlenecks, late approvals and unclear hand-offs;
• reconciliations created by disconnected systems;
• controls performed too late to prevent error;
• permanent workarounds and dependence on particular individuals;
• repeated data requests because nobody trusts the source.

The purpose is not to produce a perfect process map. It is to identify where time, control and decision quality are being lost.

Separate value, necessary control and waste

A “does the customer pay for this?” test can challenge activity, but it is too narrow for finance. Customers do not directly pay for statutory reporting, fraud controls or tax compliance, yet those activities protect value and may be legally required.

A more useful classification is:

Duplication, rework and obsolete approvals operate as an administrative tax on the business: they consume capacity without improving decisions, control or customer outcomes.

Challenge the third category for deletion. For necessary controls, ask whether the same objective can be achieved earlier, more proportionately or with less manual intervention. The aim is not to sacrifice control for speed; it is to stop treating every inherited step as equally valuable.

Give every requirement a source and an owner

Many requirements survive because “finance needs it”, “the auditors asked for it” or “we have always done it this way”. Those statements are not sufficient evidence.

For each material requirement, identify its source:

• law or regulation;
• contractual obligation or financing covenant;
• accounting, tax or audit requirement;
• internal policy or risk decision;
• historical practice or individual preference.

Each requirement should have an owner who can explain its rationale and approve any change. A statutory obligation cannot be removed because it is inconvenient. A lender requirement may be negotiable but not ignorable. A historical custom, however, may have outlived the risk it addressed.

In regulated or high-risk areas, proposed changes should involve the appropriate legal, compliance, tax, audit or risk expertise. The question is not “How do we bypass this?” It is “What requires it, what risk does it address and can we achieve the same objective better?”

Measure touch time and cycle time

Process speed is often discussed vaguely. Two measures make it more useful:

The gap can reveal queues, information delays, hand-offs and rework. A month-end close may take many calendar days even though active work occupies only a fraction of that period. An invoice may take minutes to raise once approved but wait days for operational confirmation.

Not every hour between touch time and completion is waste. External dependencies, deliberate reviews and contractual timing may be necessary. The gap is a diagnostic signal, not an automatic deletion target.

The consequence also depends on the process. Reducing internal delays in billing, dispute resolution and collections can accelerate cash conversion; a faster close gives leadership earlier visibility. Accelerating supplier payments indiscriminately could weaken liquidity. The objective is purposeful flow, not speed for its own sake.

Clarify ownership, decision rights and control

Technology cannot resolve ambiguity about who is accountable.

If approval limits are unclear, a digital workflow will automate confusion. If responsibility for customer or supplier data is disputed, a new system will not make that data reliable. If nobody owns a forecast assumption, a more sophisticated model will still contain unchallenged inputs.

For each critical process, leaders should define:

• who owns the outcome;
• who provides and approves information;
• which decisions can be made at each level;
• which exceptions require escalation;
• how completion and quality will be monitored;
• which controls are required by the underlying risk.

Controls should reflect fraud and payment risk, segregation of duties, access rights, data quality, tax and regulatory obligations, and external assurance needs. They should be embedded as early as practical. The aim is reliable, proportionate control that supports the speed and scale of the business—not maximum control at any cost.

Assess data before promising better reporting

Reporting transformation depends on common definitions and dependable source data.

Terms such as revenue, active customer, project profitability or adjusted earnings can mean different things across teams. If the definitions are unresolved, a dashboard can display contradictory answers more attractively without resolving the underlying issue.

Leaders should identify the information that matters, agree its definition, establish its source and assign ownership for quality. Historical data may need cleansing or mapping before it can support reliable comparison. Good reporting begins with data governance, even when the organisation does not use that label.

Understand the existing technology landscape

Only after the business, process, control and data issues are understood should the organisation assess technology options.

This includes more than the accounting system. Leaders should understand how billing, banking, payroll, procurement, expenses, operational platforms and reporting tools interact—and where data is re-entered or spreadsheets perform essential system functions.

In my own finance leadership roles, I have selected and implemented accounting systems, introduced reporting and control tools, and led finance technology integration as organisations scaled. The value came from aligning the chart of accounts, approval logic, controls, data and ownership—not from software alone.

Software enables change; operating design creates it.

Build the case for change

A transformation should have an explicit economic and operational case. The benefits may include capacity released from manual processing, faster reporting, fewer errors, stronger control, avoided recruitment, improved cash management or better leadership decisions.

Simplifying the operating model before selecting technology can also reduce configuration, customisation, integration and change-management effort, lowering both implementation risk and the overall cost of transformation.

Not every benefit can be reduced to a precise number, but expected value, implementation cost, organisational effort, dependencies and risks should be visible. Some improvements may come from clearer ownership or process redesign before a major system investment; others will depend on a platform change.

Design implementation around adoption

A technically successful launch can still fail as a business transformation.

People need to understand the purpose of the change, their new responsibilities and how performance will be measured. Processes require realistic testing; data migration and integrations require disciplined validation. After launch, the organisation must confirm whether benefits are being realised.

A practical transformation sequence is:

This sequence keeps the initiative anchored to business outcomes throughout.

The executive finance transformation diagnostic

Before committing to finance technology, leadership should be able to answer the following questions:

If these questions cannot be answered, the organisation is not yet ready to select technology. It is ready to diagnose.