Great post. Finance engineers are such a rare and valuable persona. I’m meetings some promising ones through my work as an accounting AI seed stage investor at my firm, Seguin Ventures and via my publication, The Accounting VC.
Along these lines, our area of expertise is Management Accounting models similar to the "operating system" you describe it pulls together data from a range of large source systems and traces all source data, through activities undertaken to individual products/services produced. We specialize in models for Higher Education, so those source systems are finance, HR payroll, facility management, timetabling and student management systems. We're working on AI solutions to help with the data preparation side (there are still source systems with problematic data) but also AI solutions for the interpretation of the model results and tracing of resources (people, dollars, facilities) to end products and customers. These models can be very large and complex, so interpreting the results requires expertise and an understanding of the institution, and AI is the perfect analytical assistant. We are also planning to use AI to help build the models and allowing agents to build the models, since we have nearly 20 years' worth of example models over multiple institutions, then our AI (Pilbara Intelligence) can start making recommendations on how to build the model, business rules and drivers to use, structure, standard reports etc. So, in theory, AI will find the data, clean and prepare the data, build the model, interpret the results and provide administrators and academics with analysis and recommendations. If a university were to do that themselves, it would ordinarily take a year or more, but most institutions don't build these full models, they usually rely on lots of disparate spreadsheets and teams of analysts throughout the institution, costing many man-years of effort.
I think all 4 of these skills have been useful and important for CFOs in all 4 eras. But I do agree that building the system that connects everything together has increased in importance. Without the correct business processes, AI cannot be fully leveraged and organizations will fall behind their competitors.
The line about the head of tax being the heaviest user rang true for me.
When I ran SLB in Angola we built a remote cementing design center based in Bucharest, three engineers in an office supporting rigs he’d never set foot on. The people who got the most out of it weren’t the young ones. It was the old hands who knew what a bad job looked like before the numbers showed it. The tool was like a sharp knife. In the right hand it saves hours and cost. In the wrong one you just cut faster in the wrong place.
My one worry with the 2% team. Seniors learned what “great” looks like by doing the grind for years. If agents do the grind now, where does the next head of tax come from?
I run my own small operation with a stack of AI skills I built myself, and that’s the question I keep coming back to.
The customer-level margin example is the strongest illustration here. Connecting revenue, inference costs, cloud usage, and support costs could let finance identify a contract that needs attention while there is still time to change its economics. That is a meaningful expansion of the function’s influence.
I’d qualify the claim that data has stopped being the bottleneck, though. Easier extraction doesn’t necessarily resolve conflicting definitions, incomplete contracts, disputed ownership, or inconsistent treatment across systems. An agent could reconcile the records perfectly and still apply the wrong economic interpretation. I’d want to distinguish faster access from greater confidence in what the data means.
That distinction becomes especially important with a zero-day close. Some numbers can update continuously; others depend on estimates or judgments that remain unsettled. A live dashboard would be more useful if it made those differences visible: what is reconciled, what is provisional, and what decision could materially change when an estimate is revised.
Your controls section therefore seems central to the entire thesis. If finance builds the workflows and agents that execute the work, who independently tests the assumptions, approves changes, and challenges the output? I’d want a smaller team to preserve that ability even as individual people become much more productive.
There is also an interesting tension in replacing “walk me through your model” with “walk me through your prompt sequence.” I’d still want both. The sequence explains how the result was produced; the model explains the assumptions and relationships that make it useful. A prospective hire’s ability to recognize a plausible but economically wrong answer would matter as much to me as their ability to build the automation.
For the finance engineer, I’d measure success through exception rates, review burden, and decisions improved, alongside hours saved. Fifty agents in two weeks demonstrates how accessible building has become. Knowing which five deserve production responsibility would demonstrate the finance judgment.
How are the strongest teams separating experimentation from production? The approval process for an agent’s first consequential action seems like a revealing test of whether finance has successfully redesigned its operating system.
The customer-level margin example is the strongest illustration here. Connecting revenue, inference costs, cloud usage, and support costs could let finance identify a contract that needs attention while there is still time to change its economics. That is a meaningful expansion of the function’s influence.
I’d qualify the claim that data has stopped being the bottleneck, though. Easier extraction doesn’t necessarily resolve conflicting definitions, incomplete contracts, disputed ownership, or inconsistent treatment across systems. An agent could reconcile the records perfectly and still apply the wrong economic interpretation. I’d want to distinguish faster access from greater confidence in what the data means.
That distinction becomes especially important with a zero-day close. Some numbers can update continuously; others depend on estimates or judgments that remain unsettled. A live dashboard would be more useful if it made those differences visible: what is reconciled, what is provisional, and what decision could materially change when an estimate is revised.
Your controls section therefore seems central to the entire thesis. If finance builds the workflows and agents that execute the work, who independently tests the assumptions, approves changes, and challenges the output? I’d want a smaller team to preserve that ability even as individual people become much more productive.
There is also an interesting tension in replacing “walk me through your model” with “walk me through your prompt sequence.” I’d still want both. The sequence explains how the result was produced; the model explains the assumptions and relationships that make it useful. A prospective hire’s ability to recognize a plausible but economically wrong answer would matter as much to me as their ability to build the automation.
For the finance engineer, I’d measure success through exception rates, review burden, and decisions improved, alongside hours saved. Fifty agents in two weeks demonstrates how accessible building has become. Knowing which five deserve production responsibility would demonstrate the finance judgment.
How are the strongest teams separating experimentation from production? The approval process for an agent’s first consequential action seems like a revealing test of whether finance has successfully redesigned its operating system.
The finance engineer point matches what I see building finance automations for mid-size companies. The tools are no longer the hard part. Finding the person is. Nobody has "finance engineer" in their title yet, so keyword search on LinkedIn finds almost no one.
That gap is why I built plsintro.com --> you describe the person you need in one line, and agents look for a fit instead of you scrolling profiles.
Curious how the teams you work with are hiring for this role today. Internal upskilling, or outside hires?
The Lio example is the one sellers should notice. A procurement agent doing vendor diligence will lean on public pages and AI answers about each vendor. So a wrong answer on SOC 2 or data residency gets flagged by software before a person ever reads it. Sellers will need their public facts as clean as the CFO's books.
متاسفانه با هر کسی فعالیت میکنم موقع پرداخت ناپدید میشود الان نزدیک به 2 سال است که برای من پرداخت نمیکنند از مالک تلگرام بگیر تا مالک تویتر در بین این دوپولدار گدا هستند مانند صرافی ها که پول من را پرداخت نمیکنند
I agree with the direction, especially the zero day close. The part I’d question is whether data has stopped being the bottleneck. Getting it is easier. Knowing you have all of it and that it reflects what actually happened is still hard, especially in commerce with exchanges, partial refunds, and duplicate payments across systems.
We’re building technology around this in commerce, continuously reconciling transactions and helping teams resolve discrepancies with evidence. That’s a big part of making a zero-day close and continuously updated forecasts something finance teams can actually trust.
'Reflects what actually happened' is the hard bit. A partial refund that lands in one system on Friday and another on Monday can make two honest reports disagree, and then finance spends the meeting arguing about whose number is right.
Yep, this is what I’m building today. I’ve stopped doing the work, Claude is doing all the finance and I’m managing the work and ensuring it’s accurate.
The system architect will keep their job, but the rest of the team will get automated if they don’t also become an architect.
Fire 🔥 him
Great post. Finance engineers are such a rare and valuable persona. I’m meetings some promising ones through my work as an accounting AI seed stage investor at my firm, Seguin Ventures and via my publication, The Accounting VC.
I shared this article with several of my friends. Thank you.
I have a pet peeve about search tools versus audit tools. If you’re traveling for business, and feel like having Thai, you have a Search problem.
if you’re a health inspector, with the legal responsibility of inspecting all of the restaurants in your zip code, you have an Audit problem.
If one item is missing, for a Search problem you won’t even notice. For an Audit problem, being off by one is a big problem.
I worry that the confidence of LLMs is leading people astray, especially those with Audit problems.
Along these lines, our area of expertise is Management Accounting models similar to the "operating system" you describe it pulls together data from a range of large source systems and traces all source data, through activities undertaken to individual products/services produced. We specialize in models for Higher Education, so those source systems are finance, HR payroll, facility management, timetabling and student management systems. We're working on AI solutions to help with the data preparation side (there are still source systems with problematic data) but also AI solutions for the interpretation of the model results and tracing of resources (people, dollars, facilities) to end products and customers. These models can be very large and complex, so interpreting the results requires expertise and an understanding of the institution, and AI is the perfect analytical assistant. We are also planning to use AI to help build the models and allowing agents to build the models, since we have nearly 20 years' worth of example models over multiple institutions, then our AI (Pilbara Intelligence) can start making recommendations on how to build the model, business rules and drivers to use, structure, standard reports etc. So, in theory, AI will find the data, clean and prepare the data, build the model, interpret the results and provide administrators and academics with analysis and recommendations. If a university were to do that themselves, it would ordinarily take a year or more, but most institutions don't build these full models, they usually rely on lots of disparate spreadsheets and teams of analysts throughout the institution, costing many man-years of effort.
I think all 4 of these skills have been useful and important for CFOs in all 4 eras. But I do agree that building the system that connects everything together has increased in importance. Without the correct business processes, AI cannot be fully leveraged and organizations will fall behind their competitors.
The line about the head of tax being the heaviest user rang true for me.
When I ran SLB in Angola we built a remote cementing design center based in Bucharest, three engineers in an office supporting rigs he’d never set foot on. The people who got the most out of it weren’t the young ones. It was the old hands who knew what a bad job looked like before the numbers showed it. The tool was like a sharp knife. In the right hand it saves hours and cost. In the wrong one you just cut faster in the wrong place.
My one worry with the 2% team. Seniors learned what “great” looks like by doing the grind for years. If agents do the grind now, where does the next head of tax come from?
I run my own small operation with a stack of AI skills I built myself, and that’s the question I keep coming back to.
https://rstoi.substack.com/p/the-next-ai-business-model-managed?r=u113&utm_medium=ios
The customer-level margin example is the strongest illustration here. Connecting revenue, inference costs, cloud usage, and support costs could let finance identify a contract that needs attention while there is still time to change its economics. That is a meaningful expansion of the function’s influence.
I’d qualify the claim that data has stopped being the bottleneck, though. Easier extraction doesn’t necessarily resolve conflicting definitions, incomplete contracts, disputed ownership, or inconsistent treatment across systems. An agent could reconcile the records perfectly and still apply the wrong economic interpretation. I’d want to distinguish faster access from greater confidence in what the data means.
That distinction becomes especially important with a zero-day close. Some numbers can update continuously; others depend on estimates or judgments that remain unsettled. A live dashboard would be more useful if it made those differences visible: what is reconciled, what is provisional, and what decision could materially change when an estimate is revised.
Your controls section therefore seems central to the entire thesis. If finance builds the workflows and agents that execute the work, who independently tests the assumptions, approves changes, and challenges the output? I’d want a smaller team to preserve that ability even as individual people become much more productive.
There is also an interesting tension in replacing “walk me through your model” with “walk me through your prompt sequence.” I’d still want both. The sequence explains how the result was produced; the model explains the assumptions and relationships that make it useful. A prospective hire’s ability to recognize a plausible but economically wrong answer would matter as much to me as their ability to build the automation.
For the finance engineer, I’d measure success through exception rates, review burden, and decisions improved, alongside hours saved. Fifty agents in two weeks demonstrates how accessible building has become. Knowing which five deserve production responsibility would demonstrate the finance judgment.
How are the strongest teams separating experimentation from production? The approval process for an agent’s first consequential action seems like a revealing test of whether finance has successfully redesigned its operating system.
The customer-level margin example is the strongest illustration here. Connecting revenue, inference costs, cloud usage, and support costs could let finance identify a contract that needs attention while there is still time to change its economics. That is a meaningful expansion of the function’s influence.
I’d qualify the claim that data has stopped being the bottleneck, though. Easier extraction doesn’t necessarily resolve conflicting definitions, incomplete contracts, disputed ownership, or inconsistent treatment across systems. An agent could reconcile the records perfectly and still apply the wrong economic interpretation. I’d want to distinguish faster access from greater confidence in what the data means.
That distinction becomes especially important with a zero-day close. Some numbers can update continuously; others depend on estimates or judgments that remain unsettled. A live dashboard would be more useful if it made those differences visible: what is reconciled, what is provisional, and what decision could materially change when an estimate is revised.
Your controls section therefore seems central to the entire thesis. If finance builds the workflows and agents that execute the work, who independently tests the assumptions, approves changes, and challenges the output? I’d want a smaller team to preserve that ability even as individual people become much more productive.
There is also an interesting tension in replacing “walk me through your model” with “walk me through your prompt sequence.” I’d still want both. The sequence explains how the result was produced; the model explains the assumptions and relationships that make it useful. A prospective hire’s ability to recognize a plausible but economically wrong answer would matter as much to me as their ability to build the automation.
For the finance engineer, I’d measure success through exception rates, review burden, and decisions improved, alongside hours saved. Fifty agents in two weeks demonstrates how accessible building has become. Knowing which five deserve production responsibility would demonstrate the finance judgment.
How are the strongest teams separating experimentation from production? The approval process for an agent’s first consequential action seems like a revealing test of whether finance has successfully redesigned its operating system.
The finance engineer point matches what I see building finance automations for mid-size companies. The tools are no longer the hard part. Finding the person is. Nobody has "finance engineer" in their title yet, so keyword search on LinkedIn finds almost no one.
That gap is why I built plsintro.com --> you describe the person you need in one line, and agents look for a fit instead of you scrolling profiles.
Curious how the teams you work with are hiring for this role today. Internal upskilling, or outside hires?
The Lio example is the one sellers should notice. A procurement agent doing vendor diligence will lean on public pages and AI answers about each vendor. So a wrong answer on SOC 2 or data residency gets flagged by software before a person ever reads it. Sellers will need their public facts as clean as the CFO's books.
خوش بحال شما
متاسفانه با هر کسی فعالیت میکنم موقع پرداخت ناپدید میشود الان نزدیک به 2 سال است که برای من پرداخت نمیکنند از مالک تلگرام بگیر تا مالک تویتر در بین این دوپولدار گدا هستند مانند صرافی ها که پول من را پرداخت نمیکنند
حالا با این توضیحات ایا من بگفته شما نیاز دارم
I agree with the direction, especially the zero day close. The part I’d question is whether data has stopped being the bottleneck. Getting it is easier. Knowing you have all of it and that it reflects what actually happened is still hard, especially in commerce with exchanges, partial refunds, and duplicate payments across systems.
We’re building technology around this in commerce, continuously reconciling transactions and helping teams resolve discrepancies with evidence. That’s a big part of making a zero-day close and continuously updated forecasts something finance teams can actually trust.
'Reflects what actually happened' is the hard bit. A partial refund that lands in one system on Friday and another on Monday can make two honest reports disagree, and then finance spends the meeting arguing about whose number is right.
We fixed that for commerce
Yep, this is what I’m building today. I’ve stopped doing the work, Claude is doing all the finance and I’m managing the work and ensuring it’s accurate.
The system architect will keep their job, but the rest of the team will get automated if they don’t also become an architect.
Really insightful and on point re: the evolution, focus and capabilities at hand for the role over the decades
100%