The CFO blueprint: Inside our finance team's AI transformation

Foreword

By Pranav Sood, CFO, Airwallex

Before I joined Airwallex, I spoke to more than 20 CFOs at private equity-backed businesses about where their Finance teams were using AI. The adoption I saw was spotty and slower than I had expected. Most of those CFOs named the same three blockers: lean teams, risk aversion (particularly in Controllership), and data hygiene. What experimentation there was sat mostly in FP&A, on budget variance analysis and management reporting slides.

The sense I got was that many teams were adding AI to the processes they already ran, and very few had stopped to redesign those processes first. I came into this role convinced the opportunity in Finance was far larger than anyone was treating it.

I also came into it by an unusual route. I'm a CFO who never trained as an accountant, and my path here ran through strategy consulting, business operations, general management, and private equity. That gave me a habit of asking what drives the work before deciding what to change, and of testing a hypothesis before the data is perfect. Both proved useful starting points for a Finance transformation.

My view is that our job as CFOs starts with getting the fundamentals right, by which I mean accurate reporting, sensible capital allocation, and properly managed risk. Those stay non-negotiable. What should change is how long they take, and AI is how we get that time back. The hours it frees up go into work the business needs from Finance and too rarely gets, such as building trust with regulators, partners, and customers, and helping colleagues make the hard commercial calls.

At Airwallex, Finance is leading its own transformation, run like a product roadmap, and I’d argue every Finance team should lead its own. As we've worked through ours, I’ve kept thinking about those CFOs I spoke to before I began here and how much of what we’re learning could’ve helped them get started. 

This guide is for them, and for every finance leader at the same starting point. It sets out the four decisions we made, in order, what we learnt from each, and the tools we’d hand to another Finance team. We’ve made mistakes along the way, and I’ve left them in because they’re probably the most useful part. If you take one thing from this, I’d rather it was the sequence than any single tool. Some of you will be just starting out, and others will be further along than we are in places, so take what’s useful to your team and leave the rest. This is how we’re transforming our own function, and hopefully it saves you a few detours we took along the way.

How to use this blueprint

The guide follows four decisions, in the order we'd recommend making them. If you're starting out, read it in order, because each decision rests on the one before it. If you're already partway through your AI implementation, go straight to the decision in front of you.

Chapter 1: Fixing the data foundations shares how we rebuilt our Finance data so every team works from the same definitions and AI has numbers it can trust. Start here if your teams don’t yet agree on what the data means, or don’t trust it enough to layer AI on top of it.

Chapter 2: Mapping the work before automating anything walks through how we recorded every task across Finance to see where our time went and where the pressure peaked. This is the place to begin if you don’t yet have a clear picture of where your team’s time goes.

Chapter 3: Building a roadmap for each function shares how Controllership, Treasury, Tax, and FP&A each turned that map into their own priorities. It’s most useful if you know where your automation opportunities are, but not which ones each team should tackle first.

Chapter 4: Deciding who builds, and how builds get finished explains how we moved from scattered AI experiments to one shared way of building tools the whole function can use. Read this one first if your team is building tools that rarely get finished or shared.

Each chapter opens with where we started, then shares what we did and what we learnt along the way, including what went wrong. We close each one with our lessons learnt and the steps we took, so you can try the same approach with your own team.

Chapter 1: Fixing the data foundations

It’s easy to deploy AI straightaway, and understandably tempting. That’s where we started, but we soon discovered that the real benefit came from fixing our data foundations first.

Many CFOs ask whether financial data is too sensitive to put in front of AI. Our experience suggests another question should come first: is your financial data structured well enough for AI to use reliably? What looks like a security problem is often a readiness problem. When data is fragmented, inconsistently defined, or poorly governed, it's hard to trust anything AI does with it, and a conversational interface on top of bad data only gets you to the wrong answer faster.

The usual approach is to subscribe to AI tools, connect them to the data, and produce an analysis. The order that worked for us runs the other way. We started with the insights the business needed, identified the data required, and then designed a data dictionary that every team agreed on and AI could read and use to reason correctly. Before investing in tools and tokens, it’s worth checking whether your Finance team can answer yes to three questions:

1. Do we have a single source of truth for our financial data?

2. Does everyone define the metrics in the same way?

3. Can a machine understand those definitions?

If the answer to any of them is no, this chapter is a good place to start. It shows how we got to a yes on all three, including the parts that were harder than we expected.

Take ownership of the foundation

We couldn't always answer those questions ourselves. While annualised revenue grew from under US$5 million in 2018 to more than US$1.3 billion today, we prioritised accuracy, and each product owner defined their own data schema. The numbers held up, but they didn't fit together. At various stages, Product and Finance could give you different counts of active customers.

When we moved our corporate data from BigQuery to Databricks, we used the migration to zero-base the foundation, which meant auditing everything we had and rebuilding it from scratch instead of copying the old structure across. We redesigned it for how we’d use it in future. Finance wrote the specification for the rebuild, and Engineering ran the migration.

That split is the first thing we’d recommend you copy. Engineering knows how to move data, and Finance knows which decisions the data has to support. If you have a migration or ERP change coming, that’s your moment to write the specification, because a foundation built on your decisions will hold up for years.

Start from the decisions, then work back to the data

It’s tempting to start with the data you already have. We found that it made more sense to start with the decisions our team makes. Our controller explaining a movement at month-end needed one set of data, and FP&A running a flux analysis needed another. We listed those needs, so we knew which dimensions had to exist. From there, we built a taxonomy, settled on the naming, and agreed on what went in which table.

The same thinking works at a smaller scale. When Controllership rolled out our ERP in 2024, the team asked which data points it would need downstream, and added the respective data columns to the chart of accounts. One of those columns records the vendor for every expense, accrual, and cost. Our budgets are set by vendor, so AI can now compare actuals to budget by vendor and division, without anyone having to rebuild that analysis by hand. A Budget ID does the same for the P&L, linking every cost to a budget line.

Anchor everything to one source of truth

Most Finance teams have one version of the numbers they trust more than the rest, and that’s the one you should build on. We anchored our model to our reconciled ledger, because that’s the one Finance reports from.

Treasury did the same for cash. The team rebuilt our whole bank account landscape: which accounts exist, how they connect, and how they’re opened, closed, and maintained. That layer now carries our liquidity management, our treasury risk dashboard, and the way we manage cash balances day to day.

Agree on definitions across every Finance function

Tax, Treasury, Controllership, and FP&A each needed the data cut a different way, so the same metric could mean something different to each team. For example, we took a metric as common as "revenue by market" and asked each team which market a sale belonged to:

• Controllership put it in the market of the Airwallex entity that issued the invoice.

• FP&A put it in the market where the customer was based.

• Tax needed both, because its filings depended on them.

That’s three correct answers and three different numbers for revenue by market. If you repeat that exercise across every metric your teams share, it’s easy to see why meetings would open with a debate about whose number was right.

We fixed it by doing the slow work: defining each metric once, writing the definition down, and naming one person to own it. It was the hardest part of the whole project, and it’s the part we’d most encourage you to copy. Because every team helped write the definitions, every team understood them and used them.

Write your definitions for machines as well as people

An AI agent given access to tabular data would need to guess what each column means based on the naming conventions. That’s why we wrote a plain-language description of every field in a data dictionary, assuming a model would read it, and built a Context Hub on top of it. An agent reading the Context Hub learns what each field means, which entity booked it, and how the number was reconciled, so it works from our definitions instead of its own.

Then, deploy AI

With that foundation in place, the use cases follow. Explaining why operating costs moved in EMEA last month used to mean opening the ledger, chasing tags, and rebuilding the comparison by hand. Now an analyst asks an agent through Hex, Cursor, or Claude, and the movements come back attributed. Because the underlying data is reconciled and the definitions are documented, we trust those answers enough to act on them.

Expect the work to keep coming. Older periods were never tagged to our current standard, so a flux analysis that reaches back in time still sends people digging. Every product we launch and every market we enter also brings undefined dimensions. The difference is that each new gap now gets added to a foundation that already holds.

Our lessons learnt

1. Finance wrote the specification, and engineering ran the migration. We listed the decisions our team made and let those decisions set what the data must hold.

2. One metric, one definition, one owner. We defined data so an AI model could easily follow it, especially where different teams defined metrics differently.

3. We added tags proactively. Adding a vendor column during an ERP rollout meant that AI could compare actuals with budget in future.

Chapter 2: Mapping the work before automating anything

Before automating anything, we wrote down every task our Finance team does in a single spreadsheet. That gave everyone in Finance one view of where our time was going.

Most people in Finance have a job they’d love to hand over to AI. But if you start automating those jobs one by one, without a shared view of where the team’s time goes, it’s hard to tell which projects will make the biggest difference to the function as a whole. Priorities then tend to be set by whoever argues hardest for their own.

We wanted a fairer way to prioritise projects, so we started by having every team across Finance and Corporate Development document their work line by line. We ended up with a database of 600 tasks covering hundreds of thousands of hours a year.

Map every task in the same format

Each team described its tasks against the same columns:

• Category, the type of work.

• Process, meaning where the task sits in the team's workflow.

• Frequency, whether daily, weekly, monthly, annual, or ad hoc.

• Time, measured in hours per cycle.

• Current maturity, or how automated the task is today.

• Target maturity, meaning how far it could realistically go.

The distance between current and target maturity showed how much work remained on each task and whether it deserved our attention. Splitting the results by function and by region turned the spreadsheet into a heat map, and let us benchmark one team against another to spot where one spent far more time on the same kind of work.

One thing we got wrong early on was leaving the maturity scale open to interpretation, so one team’s “mostly automated” wasn’t another team’s, and the results didn’t compare cleanly. If you try this with your own team, it’s worth agreeing up front what each maturity level means and how much detail each column needs, so every team describes their work the same way.

Start with the work that recurs

About 80% of our tasks recur: daily cash positions and bank reconciliations, journal entries, expense and invoice approvals, and the same tax returns filed every month or quarter. Work like this follows a structured process, which made it the clearest place for us to start, and automating even part of a daily task pays back every day it runs. Each routine hour we remove goes back to the ad hoc work where our team’s judgement is needed most, such as answering a regulator’s request or making a local call on an unusual transaction.

Prioritise peak pressure over annual hours

Annual hours measure the total work across the year, while peak pressure looks at when that work compounds. For our Finance team, the biggest peak is month-end close, when everyone works to close the books as quickly as possible through a strict process with cross-team dependencies. A task that costs a few hours a year can hold up everyone queued behind it, and that’s when mistakes are more likely to happen. FP&A has its own peak in the annual budget build.

A useful question to ask of your own map is which task, if it ran late on the second day of close, would hold up the most people. That’s often a better place to start than the task with the most annual hours. Our first targets are the month-end tasks that take longer than they should, because every hour saved there lets the next team in the chain start sooner.

Ask the people doing the work

About 20 hours of interviews with people across the team revealed the peaks that the spreadsheet alone had hidden. Asking each team where its work broke down, and when everyone was at full stretch, told us what the columns had left out.

Those conversations brought good news as well. In Tax, the data and processes behind some jurisdictions’ filings turned out to be cleaner than the team expected, so they kept their current processes and used them as the model for other jurisdictions.

Use the map to set priorities, and expect a long list

The map confirmed much of what our intuition already told us, and it gave us something we lacked before: an objective view to test that intuition against, shared by the whole team. We could rank tasks by hours, frequency, peak pressure, and how far they sat from where they could be, and defend our prioritisation.

The mapping also produced about 100 automation projects, with citizen developers within the team building many of them. Getting more of them over the line is the subject of Chapter 4. First, each team turned its part of the map into a roadmap of its own, which is where Chapter 3 picks up.

Our lessons learnt

1. We had to first define each maturity level before teams started scoring. We had initially left ours open to interpretation, and the results didn’t compare cleanly.

2. We looked at the tasks that created month-end bottlenecks. A task that took only a few hours a year could still delay every team waiting on it at close.

3. We talked to the people doing the work. Our 20 hours of conversations found the peak pressure moments that the spreadsheet had hidden.

Chapter 3: Building a roadmap for each function

A single AI roadmap for the whole of Finance can look like the tidiest option. Our map showed us that each function needed its own, because the work in each one recurs and peaks in different ways.

Mapping the work gave us a shared view of where our time went across Finance. It also showed us that our four functions work in very different ways. In Controllership, most tasks recur and converge at month-end. Treasury handles a high volume of daily, rules-based activities, while FP&A and Strategic Finance spend their time on complex, forward-looking questions that need judgement. Tax, meanwhile, faces similar compliance obligations across many countries, and each region has its own way of handling them.

We’ve set out how each function turned its part of the map into a roadmap, along with where we think you might start if your teams work in a similar way.

Controllership: freeing up time from recurring work and the month-end peak

Controllership carries the largest share of our Finance hours, and 86% of its tasks recur. When Ralph Karsten, our Group Financial Controller, looked more closely, he found that half of the tasks were daily, which meant even partial automation would pay back every working day. The work is split between our Shared Service Centres (SSCs), which run standard processes such as procurement, accounts payable, and travel and expenses, and our regional teams, who spend about 40% of their time on ad hoc and annual work, from regulator requests to local licensing questions.

Because so much of that recurring work is routine, Controllership’s roadmap starts there, and every hour they automate frees their regional controllers to focus on work that requires their judgement. The biggest single drain on time was procurement, which ran through a platform that no longer fit the business. Later this year, Controllership will switch its current procurement system to Airwallex, which will let the team automate more processes and fix the pain points the map uncovered.

Month-end brings a different kind of pressure, when the whole team is on high alert and working at full capacity to close the books as quickly as possible. The close follows a strict process with dependencies across teams, so a single bottleneck can hold up everyone waiting behind it. That pressure is a big part of why we’ve invested in a faster close; while it used to take us 10 days, Controllership is now working towards a zero-day close.

If your controllers spend most of their week on recurring tasks, the daily ones are probably where automation will pay back soonest.

Treasury: writing rules for the daily volume, and taking forecasting apart

Every day, our Treasury team manages more than 40 currencies and hundreds of millions of dollars, and 75% of their tasks happen daily, from alert handling and rebalancing to FX, safeguarding, and interest income management. The map showed that 17% of those tasks were very easy to automate, and the team had already made good progress on them.

Rebalancing used to rely on static thresholds, along the lines of “if a balance exceeds US$100,000, move funds”. It now runs on programmatic rules that respond to a range of signals. Forecasting has been harder because it depends on external, less-structured data and human judgement, so instead of trying to automate it all at once, the team is working through the forecasting process piece by piece.

If your treasury team still moves cash based on fixed thresholds, rebalancing is likely the first process worth looking at.

FP&A and Strategic Finance: taking out the preparation and keeping the judgement

Most FP&A and Strategic Finance tasks were classed as highly complex to automate because they involve ambiguity, analysis across many dimensions, and a great deal of judgement. Budgeting, in particular, is difficult to automate as a whole process. But much of the work within it involves checking submissions, reconciling formats, and assembling comparisons, so we started there.

Our analysts use AI-assisted coding to build a consolidated FP&A hub, where AI helps match around 3,000 accounting entries to budget items each month. Because we budget at the level of individual spending lines, this lets us move from the full P&L into any one of them without manual work. The hub also incorporates each new month’s actuals as they become available, so we can assess requests against the latest results during the budget process.

Our budgeting tool also validates and consolidates divisional submissions as they arrive, handling differences in format that analysts previously reconciled manually. This gives us an earlier combined view of proposed spending and more time to work through the choices with teams. That time also goes into investigating why numbers moved, and we expect analysts to frame questions around a decision and look for evidence that could overturn their own conclusions.

If your planning team’s work feels too complex to automate, the preparation around it is usually a more realistic place to begin.

Tax: standardising across regions, then building once

Our Tax team manages compliance across 26 countries, and up to 75% of their compliance tasks can be automated. The map showed how much the regions had in common. Each were preparing similar filings, but gathered their figures from local controllers through their own sources and processes. So if we’d built a tool for each region, we’d have built the same tool several times over.

Instead, the regions first agreed on a single process and dataset, and the team built one tool for all of them to use. VAT and GST returns now run almost end-to-end, with pipelines that pull data from accounts payable and receivable, calculate the liability, and draft the return. Our external tax agent now reviews those drafts instead of preparing them, and we expect to save around US$1 million a year by bringing more of the filing process in-house. Transfer pricing documentation is next, followed by direct tax and FATCA reporting.

Our lessons learnt

1. Daily work was our clearest starting point. When half of a team’s tasks are daily, even partial automation pays for itself every working day.

2. Where the work needed judgement, we automated the preparation around it. FP&A started by checking and consolidating budget submissions, and Treasury took forecasting apart one piece at a time.

3. We standardised processes across regions before we built anything. Tax agreed on one process and one dataset first, and then built one tool that every region could use.

Chapter 4: Deciding who builds, and how builds get finished

When we first gave our Finance team AI tools, the people closest to the work started building straight away, and most of our best ideas came from them. What we learnt along the way is that those builders also needed shared standards for scoping, testing, and shipping, so they could see the tools to completion and share them across the whole function.

We don’t think everyone in Finance has to be a builder, though we’d like everyone to be using AI in their work. In our first year of building with AI, we ran on citizen development, where accountants and analysts with no engineering background spotted a problem in their own work and built a tool to fix it. That approach surfaced opportunities we’d never have spotted from the top, but it also left us with 144 tools, most of which stalled before completion. Citizen development was good at finding opportunities, but turning them into tools the whole function could rely on needed more support.

Let the people closest to the work build

In our experience, the people who do the work understand its problems better than any engineer, and AI now lets them build without writing code by hand. One of our senior accountants taught herself to build with AI and cut the time our payroll consolidation took from two days to 10 minutes, a process that had meant pulling together and anonymising 15 files.

Another team member built AirQuire so Mac users could post journal entries directly, rather than waiting for Oracle to add this functionality. The tool also enriches transaction data as it’s entered, checking that line descriptions and required fields are filled in properly.

Our Tax team took the same view when they hired a tax professional with more than 12 years’ experience, rather than an engineer, to focus only on automation and AI. He’s guided by our Head of Tax and a senior manager, both of whom have automated processes before.

Watch where citizen development stalls

Left to run on its own, citizen development created plenty of activity but less coherent results, and our projects tended to stall at 70% completion. Knowledge stayed with the people who built each tool, and without a shared roadmap, teams rebuilt tools that others had already completed. Ralph Karsten, our Group Financial Controller, saw that three regions could spend weeks solving the same problem without knowing about each other. Most of our tools were also dashboards and applications, which still required someone to feed them data and carry the output into the next system.

Ralph’s answer was an AI innovation programme, with a central steering committee connecting every region and a rule that every project starts with a written product requirements document (PRD). Because of its success, we scaled the programme across Finance.

Hire someone to set the standards

One of Pranav’s first decisions as CFO was to create a finance engineer role reporting directly to him, responsible for AI transformation across Finance. It’s still a rare hire in a Finance team, and he expects it to become a standard one. Turning a personal workaround into a process 40 people across four regions can rely on is a product skill, and Finance teams have rarely needed to develop it.

Our finance engineer, Andrey Lebedev, sets the standards for how we scope, test, and decide a tool is ready for production. Where teams have the capacity to build, he guides them, and where they don’t, he builds alongside them.

Put every build through the same four steps

We'd rather finish fewer tools and see every one of them adopted, so every build now follows the same process:

1. We scope it properly, because that step saves the most time later.

2. We build the MVP in three to four weeks, with check-ins twice a week. If the deadline slips out of reach, we cut the scope and keep the date.

3. We test it for two to three weeks with three or four people from other regions, who know in advance that we’ll expect proper feedback.

4. We ship it and lock it, publish one link in a team-wide sheet, and push adoption across every region.

Finished tools and Skills go into central repositories that everyone in Finance can use and learn from.

Check whether you need software at all

Some problems need a tool, and some only need a Skill: a set of written instructions that tells an AI model how to do a task the way a team does it. Our headcount reconciliation could have become a planning tool with a two-way data sync. The team first asked whether people would ever leave their slides for a new tool. When it was clear that they wouldn’t, they created a Skill. Overnight, the Skill opens the spreadsheet, counts the rows, counts the boxes on the slide, and flags every gap for the morning.

Make transformation part of every leader's job

Our leadership team owns the transformation of its own departments, and each leader has OKRs tied to the efficiencies AI delivers. Those efficiencies only appear once a tool is used across the whole function, by people who trust it enough to stop using a spreadsheet alongside it.

Our lessons learnt

1. We decided to cut the scope, but keep the date. An MVP shipped in three to four weeks is worth more than a fuller tool that stalls at 70%.

2. We hired for the domain, then taught the building. Tax hired a tax professional with more than 12 years’ experience, rather than an engineer, to automate compliance.

3. We counted a tool as finished only once the whole function had used it. Locking it, sharing one link, and pushing adoption across every region is how a fix built in one region becomes a tool everyone relies on.

Where to start

Every change in this guide began with one small, unglamorous step: a definitions workshop, a spreadsheet of tasks, an interview with a team lead, a list of the tools people had already built. Your first step is the first of the four decisions your team hasn't made yet. Go back to "How to use this blueprint" at the start of this guide, find the one that describes your team today, and give it an hour of your leadership team's time this week.

• If your data comes first, put your heads of Controllership, FP&A, Tax, and Treasury in one room and ask each to define one metric you all report. If you get more than one answer, you've found your starting point.

• If mapping comes first, ask each team to list the tasks it repeats every week, with the hours each one takes.

• If roadmaps come first, ask each function head when their year peaks and which task holds everyone up, and when.

• If building comes first, list every tool your team has built, who owns it, and who else uses it.

None of this stays done for long, because we keep launching products and entering markets, and each one brings new work to map and new data to define. We're still working through our own roadmap, and we expect to go round all four decisions again as the business grows.

A frontier that keeps moving is the best reason to start now, and Finance is the function best placed to lead. It already knows where the numbers come from, where the hours go, and which decisions the business depends on. Every month you spend on the foundation, the map, and the standards is a month your team will build on for years. Choose the decision that fits where your team is today, book the hour, and get started.