Finance engineer

These finance pros will never export a CSV again

What a "finance engineer" actually is, why the role is showing up now, and how to hire (or become) one.

Charlie Rhomberg

FP&A analyst turned content marketer

Share to

Link copied!

Table of contents

Series B/C do’s and don’ts

DO uplevel the finance team

Subscribe to the 10X Finance Blog

Get FP&A best practices, research reports, and more delivered to your inbox.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

{callout}

TL;DR

A finance engineer pairs real finance and accounting judgment with a systems-and-automation mindset.
The technical execution is getting commoditized by the models; the domain expertise is now the scarce part.
Most come from within: a finance person who learns to vibe code, not an engineer who learns finance.
Pairing a deterministic data layer with probabilistic AI is a big part of the job.

{/callout}

Most finance pros are worried about AI taking their job. But an elite few are using it to turbocharge their careers.

Much of the latter camp can be labeled “finance engineers.” It's a new role that describes FP&A pros who are spending less time pulling reports, exporting CSVs, and rebuilding models by hand, and more time designing the systems and workflows that make all of it run automatically.

We dug into it in our recent webinar, Meet the Finance Engineer, where Aleph Co-Founder and CEO Albert Gozzi moderated a conversation between Stephen Hedlund (Head of Finance at Rillet) and Bo Weathersbee (CEO and Co-Founder at Till CFO).

The conversation covered what a finance engineer actually is, why the role is emerging now, and how finance people should think about hiring—or becoming—one.

Here are the highlights.

So…what is a finance engineer?

Since the role is still new, the definition depends on who you ask.

But the simplest version is this: a finance engineer is someone who brings an automation and systems mindset to finance work.

I think Palantir made this concept popular in the last decade. It's the concept of a forward-deployed engineer. As we think about it and we hire for it, it has three kind of core components with an additional finance and accounting layer onto it. So technical engineering aspect, a platform engineering aspect, and then a solutions architect component to it. They can decomp complex situations and rebuild it using first principles. The fourth layer though, I think is the most important, which is kind of having the finance and accounting domain expertise to overlay onto that technical expertise. That's truly what kind of brings it into being a finance engineer. If you can harness the models, that technical engineering component that I just described is being commoditized, which means that the accounting and finance domain expertise is now the scarcest resource. So that's where this blend comes in and it actually becomes way more valuable to have the skill set, the experience set, the judgment around domain expertise.

The magic comes from pairing finance expertise with engineering capabilities. A software engineer or AI expert who walks into the finance department doesn't know when a number “feels off.” Having the expertise to apply sniff tests to models, plus the ability to leverage increasingly powerful tools like Claude Code, is how finance engineers are 10x-ing their value.

Bo pointed to Boris Cherny, the creator of Claude Code, who's made the same bet out loud—that the people best positioned to write accounting software over the next few years are accountants.

Why is the role emerging now?

The easy answer is “the AI models got really good.” They did.

But that's only half the story. Someone has to hook up those models to your actual systems—ERP, billing, Slack, and the rest—so they can do real finance work.

Bo compared it to the shift from physical to internet businesses: you didn't just buy computers, you re-architected how information flowed. He showed what that looks like when the plumbing is there, and what happens when it isn't.

I wired in a couple of MCPs, so the Rillet MCP, the Aleph MCP, our billings MCP, and then, Slack to have to give it context. And I I scoped the project, hit plan mode in Claude Code and then told it to go. And it crushed it, like down to the penny. It was able to, using Aleph's data pipelines and data structures in Excel created fully auditable sheet for me to look at because Rillet is awesome in this way. The MCP is awesome in this way where you can not only read, but you can write. And writing is dangerous, but it is the most powerful thing if you truly know what you're doing. And so it was able to read it. It presented it to me. I could see the audit auditable file that Aleph had created. And then I I said, okay. Go. And it went and and, yeah, completely did. It told me it was about a hundred different right actions in system, in Rillet's system. So created customers that hadn't been created yet, created contracts that needed to be renewed and updated, backed all those invoices, spun all that up. A friend of mine was telling me just yesterday, he'd been trying to break into Claude Code and so he wanted to sit down and point at QuickBooks to pull a report. And so it's a family office. They have fifty plus QuickBooks books in their system. And he could not get past the authentication on the right books just from very get go, gave up completely and, you know, wasn't able to pull the exact report. This is the difference. Like, having an infrastructure that is architected from the ground up with MCPs into all the systems and versus not having that, and it's a totally night and day difference.

Same models, opposite outcomes. In one case, the model had access to the right systems, clean data, and auditable workflows. It could do all kinds of useful things, like updating contracts and booking invoices. In the other, it couldn't even get past authentication.

AI is only as useful as the context it can access and the workflow it can safely act inside. Connecting source systems to LLMs, making sure the data is clean, and giving the model the right rails to operate within is becoming a core part of the finance engineer role.

It's also a big piece of the headcount argument, if you need one. As Albert put it, the bar for this role is “automation that lets you keep the finance team flat while the company scales.” That's the ROI case that survives a budget review.

What goes in the job description

Say you've convinced leadership to let you bring on a finance engineer. What are you actually looking for?

A strong financial foundation is a must. Real finance or accounting experience is an indicator that this person has the judgment to know when an output is wrong.

The harder part is finding someone who can pair that judgment with systems thinking. Bo called out two traits that matter most: altitude control and curiosity.

As we hire, we look at, do they have that altitude control of being able to, like, zoom way out and get it forty thousand feet to look at the problem, holistically across you mentioned payroll, but that's a huge one. That involves HR, it involves sales often, you know, when commissions are involved, it involves obviously finance operations. So they need to be able to see the system as a whole integrated unit. But then they need to have the altitude control to go all the way down into the details to understand like when you process payroll and it does not have a native integration and all you get is an export of CSV, how do you work around that process and how do structure the data pipeline so that it ingests correctly? Then the third thing I would say is just a sense of curiosity. Some of our best engineers on our team are curious people that, know, one was so curious, he moved to Russia to learn about Russia's economy during grad school. And so just that wide ranging curiosity about how the world works and and how things operate is important.

A finance engineer needs to zoom out far enough to see the full system—payroll touching HR, sales, commissions, finance ops, and reporting all at once—then zoom all the way back in to the broken integration that's gumming up the workflow.

Albert's add: don't expect one person to do everything well. Hire the person who's strong in systems thinking and analytical judgment, then pair them with people who are great at partnering across the business. A team that complements each other well is a better bet than searching for unicorns.

The mandate is simple: go automate

If one line captures the job, it's this: the mandate is to automate. Finance engineers need to constantly be on the lookout for manual processes they can take off their team's plate.

That's why I like this title of, like, finance engineer specifically. Like, the whole mandate is go automate. Right? Look for the most manual task. Look for the things consuming time, and then just go take care of them. Right? So we we have one one question in the chat about, like, real real workflows. We've got, like, an AR agent now that will review invoices that are overdue and then see when the last time the like, we sent an email to them for our inbox, go draft an email, include a link to the invoice, and then we don't just let it send to the customer directly. Like, we still review it and and ship it. But, like, we could set it so it could just go. Right? But so rather than, like, us every Monday, whatever, pulling a report, seeing what's overdue, how much, going to get the invoice, getting the email from, you know, who the customer is, drafting up the emails, sending it them to follow-up. Right? It just gets done, and it's still, like, flagging things to us, and we can make it more aggressive. We sound like a pirate, you know, whatever we want to. But, like, it actually, like, just handles that workflow end to end, and that's, like, the finance engineer mindset.

To put it another way: look for the low-hanging fruit, automate it, then move on to the next workflow. Rank your team's workflows by how much time they eat, and start at the top.

So you want to become a finance engineer

The very first thing is you have to decide if you're okay banging your head against the wall. The fact that everyone's on this webinar means you're in the point zero one percent of AI right now. And we're in such early innings and the tools are really powerful, but they're still really raw and rudimentary from probably what we'll see in two to three years. So you have to be a tinkerer. So you have to decide, like, do I wanna just wait for everybody to figure this out and adopt it later and buy the software later? Or do I wanna be a part of building this now live for my company? And if you are in that camp, which is way more fun, I think, as a builder and entrepreneur, then I would say I would say dive into Claude Code or Codex as, like, a starting point.

AI tools are undeniably powerful, but they're also new. They haven't been pressure-tested across the finance department yet. You have to be okay with some bumps along the way.

You also need to carve out time to develop the finance engineering skillset. Both Stephen and Bo protect time to build: Stephen with every-other-Friday build blocks across the company, Bo with a “promote yourself day.”

A few accelerants they mentioned:

A Claude Code course they built and open-sourced for finance folks that starts at “what is a terminal.”
An “intent framework” doc that interviews you about your real job and encodes your guardrails into a file the model reads every time.
Finance communities where people troubleshoot in the open.

Keep the probabilistic layer thin

You wanna keep the probabilistic layer as thin as possible and the deterministic layer as fat as possible with your workflows. And so what that means is AI is really good at generative, like, computation where it probabilistically creates things. In finance, you do not want probabilistic thinking with your finance data. Like if a journal entry needs to match to the penny, you don't need it to sometimes match to a penny, sometimes match, you know, give or take, you know, five hundred dollars. You want it to be exactly right the exact same time. And that's largely just boring data engineering that has been around for for decades.

AI is great at generative, probabilistic work. But finance still needs a trusted, deterministic source of truth: clean data pipelines, governed business logic, auditable calculations, and systems that tie out the same way every time.

That's why a deterministic foundation like Aleph matters so much. It gives AI something solid to work on top of—live finance data, controlled formulas, and logic that finance can inspect and trust. The model can help interpret the work, but the underlying numbers aren't being reinvented from a prompt.

Bo framed the division of labor as a 10-80-10 sandwich: you set the intent up front, the model does the bulk of the work, and finance verifies the output at the end.

How to actually find one, and how to get found

Where do you find these finance engineers, and how do you bring them on board?

In a lot of cases, they're already doing the work in public.

I met him, an accountant in Austin a few months back, and he was looking for a new role. Had applied to, like, two thousand jobs and not found, like, any he was particularly excited about. And he started posting about what he was building, like, by coding on LinkedIn. And then a few weeks later, actually got outbounded by a CFO looking for someone who was very AI native and building here and could do these things. So he started, like, doing the work, and then someone found him.

The accountant didn't wait for someone to hand him the perfect finance engineer job description. He started building, posted what he was learning, and made the work visible enough for a CFO to find him.

Two practical moves fall out of that:

If you're hiring, make vibe coding part of the interview: hand over a messy dataset and watch how someone works through it. Bo has candidates record a Loom of the whole build, and he just hired a controller who'd been posting about using Claude Code on his accounting workflows.
If you want the job, do the work in public. Post what you build. The receipts are the résumé now.

Make yourself invaluable in the AI age

The role is new, the title is fuzzy, and nobody fully agrees on what to call it yet.

That's where the opportunity lies.

The finance people who figure out what to hire for, or who become the hire themselves, will get a valuable head start.

A few resources to keep going:

Subscribe to the 10X Finance Blog

Get FP&A best practices, research reports, and more delivered to your inbox.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Frequently asked questions

What is a finance engineer?

A finance engineer is a finance or FP&A professional who brings an automation and systems-design mindset to finance work. Instead of manually pulling reports, exporting CSVs, and rebuilding models by hand, they design the workflows and connect the systems that make that work run automatically—while keeping the financial judgment to know when a number looks wrong.

What does a finance engineer do?

A finance engineer hunts for manual, recurring finance workflows—reporting, reconciliations, variance analysis, invoicing—and automates them using AI tools, MCPs, and clean data pipelines. They connect source systems like the ERP, billing, and CRM to large language models, build internal tools, and stay in the loop to review and verify outputs before they’re trusted.

What skills does a finance engineer need?

The foundation is real finance or accounting expertise (often a CPA or CFA) to know when an output is wrong. On top of that, a finance engineer needs the ability to zoom out to the whole system and back down to the details, plus curiosity, AI fluency (prompting, MCPs, and vibe coding), and the storytelling and collaboration skills to partner across the business.

How is a finance engineer different from an FP&A analyst?

A traditional FP&A analyst executes workflows: pull the report, add the variance commentary, update the model. A finance engineer redesigns those workflows so they run automatically, with enough context for the business to trust the output. The shift is from number-cruncher to workflow orchestrator—defining the logic, setting the controls, and deciding where a human still needs to sign off.

Why is the finance engineer role emerging now?

AI models have become powerful enough to do real finance work, but only when they’re connected to clean data and the right systems. Someone has to build that architecture—wiring source systems into the models and making the data trustworthy. As the technical execution gets commoditized by better models, deep finance domain expertise becomes the scarce, valuable input, which is exactly what the finance engineer provides.

How do you become a finance engineer?

Start by automating one manual workflow with a tool like Claude Code or Codex, then carve out dedicated time to build the habit. Learn to connect AI to your systems with MCPs, and keep a clean, deterministic source of truth underneath. Then build in public—post what you create on LinkedIn—so hiring managers can see the work. Many finance engineers get found precisely because they made their building visible.

Discover Aleph today

Book a demo

Start a free trial

Screenshot of an income statement spreadsheet comparing revenue, cost of revenue, and operating expenses for Jan 25 and Feb 25, alongside a sidebar menu with options including 'Income Statement,' 'Analyze with AI,' and other budget categories.