The Finance Engineer Job Description Is a Spec for Infrastructure Nobody Has Built

#finance #ai #career #data

VulnCheck, a security company in Boston, is hiring a Finance Engineer. The posting asks the hire to connect the GL, billing, CRM and spend management systems "via API/MCP." To build Claude-powered workflows that draft variance commentary and flag anomalies. And to own the financial model's technical architecture, "including version control and forecast logic."

Read that last one again. Version control. For a financial model. Owned by someone whose team is listed as Finance.

That is not really a job description. It is a systems requirement, written by a company that needed a capability, found no product that provides it, and hired a person instead.

We went looking to see whether this was one unusual posting or a pattern. It is a pattern, and the pattern says something uncomfortable about the tooling underneath.

What the postings actually say

So we counted. In July 2026 we queried the public job board APIs of 1,061 candidate employers across the US and Europe, scanned all 27,278 open postings on the 421 live boards that answered, filtered on the department each employer assigns to the posting itself, and coded every survivor from full text. That produced 37 qualifying requisitions across 26 employers, published with the full method, the adjudication rules and the corpus in The Finance Engineer Role: Job Posting Statistics. Three findings matter here.

Nobody agrees what to call it. Thirty-seven requisitions, thirty-seven distinct titles. No two employers word it the same way, and exactly one calls the job plainly "Finance Engineer." The rest are Agentic Finance Engineer, Tech Lead for Finance & Supply Chain Engineering, Head of Engineering for Finance Systems, Finance System Architect Manager, Order to Cash Track Lead for Finance Engineering, and so on. Sixteen of the thirty-seven carry no finance word in the title at all: Brex's "Data Engineer," OpenAI's "Workday Engineer," Attentive's "Anaplan Application Developer," ElevenLabs' "Systems Architect," each sitting inside a finance or accounting department. A title search cannot find this population, which is the first thing anyone counting it should know.

It is also rare. Of the 987 open finance-department roles across those 421 employers, 26 were engineering roles. That is 2.6%, or one in thirty-eight. This is not yet a wave. It is a small number of companies making a specific and expensive bet.

And they are making it alone. The obvious alternative is to let a vendor deploy an engineer instead, which is exactly what the forward deployed engineer boom is for. On the same boards there are 348 open FDE postings across 66 employers. Precisely one requisition is finance-facing. Widen it to every deployment-shaped role, solutions architects and implementation engineers included, and you get 545 requisitions of which 14 touch finance, nearly all of them presales attached to a platform sale. Nobody is coming to build this for you.

And it is not only an American story. A dedicated European pass over 91 additional employer boards found the role in Germany, the UK, Spain, Sweden and Poland: Helsing hiring a Finance Data Engineer in Munich, Zilch a finance analytics engineer in the UK, Celonis a Finance Systems Engineer in Madrid, Lovable a Financial Systems Engineer in Stockholm. Europe runs at 1.9% of finance-department openings against 2.6% in the US, so the gap is real but narrow. What Europe does not have is the vocabulary: not one European posting calls the job a finance engineer.

It mostly, but not always, sits in Finance. Twenty-six of the thirty-seven are placed by their employer in a Finance, Accounting or Finance Systems department: Anthropic, OpenAI, Coinbase, Databricks, Brex, Stripe, Twilio, Attentive, Cloudflare, SoFi, Mercor, Affirm, VulnCheck. Where a reporting line is spelled out, it names a finance leader: VP of FP&A, Head of Finance Systems, Senior Manager of Finance Data and AI.

The eleven exceptions complicate the tidy version of this story. Klaviyo runs an entire "Finance Engineering" function out of IT & Security. Block puts a Senior Finance Systems Engineer in Engineering, CoreWeave and Epirus theirs in IT, Harvey in Product, Whoop in Business Intelligence. So the direction of travel is real, and finance is staffing its own systems rather than filing tickets for them. But roughly one role in three is still owned outside finance, and anyone claiming the shift is universal has not counted.

It wants two careers in one person. Spring Health's Senior Finance Engineer posting asks for "4+ years designing and deploying automation, AI, and/or ML systems in Finance" and, separately and additively, "4+ years in FP&A, Strategic Finance, Accounting, or Finance Transformation." Its named tool list runs NetSuite, Pigment, Airbase, Claude, ChatGPT, Gemini. Commercial LLMs, listed by name, in the requirements section of a finance role.

The tell is in what these postings assume already exists

Strip the postings down to their verbs and a shopping list appears. Across the corpus, employers casually assume the following are available to a finance team:

Version control over a financial model. Not over a file. Over the model: what changed, when, by whom, and what it moved downstream.
An API surface over financial logic, not just over financial data. Model Context Protocol is now named by protocol in four postings across three employers, all inside finance departments: VulnCheck, ElevenLabs, and both of OpenAI's Enterprise AI Platform roles. An agent interoperability standard released in late 2024 has become a line item in corporate finance hiring.
Conventions that persist between sessions and between people. When the posting says "assemble reporting packages," it assumes the definition of ARR used in October is the definition used in March.
An audit path from an output number back to the assumption that moved it. Every posting mentioning close, variance commentary or ASC compliance assumes this implicitly.

Every one of those four is unremarkable in software engineering. Git, APIs, schemas, commit history: solved decades ago. None of the four is standard in finance. And the reason is not that finance teams are less sophisticated. It is the substrate.

It is also expensive, and the shape of the expense is the tell. Seventeen postings disclose a US base range, spanning $112,000 to $385,000, with a median band midpoint of $231,500.

The sharper number comes from OpenAI, which publishes structured bands on every role and has enough openings to compare like with like. Its five finance-department engineering roles carry a median band midpoint of $307,500. The other forty-five roles in the same finance department: $228,000. Its two hundred and ninety-seven product engineering roles: $309,000.

So a finance-department engineer there is paid 35% above the rest of the finance organization, and within half a percent of a product engineer. The premium is not for finance expertise, and it is not a cost-centre discount. These companies are paying full engineering rates for engineering work that happens to sit in finance, which is what you do when you have concluded the capability has to exist and no vendor sells it to you.

The spreadsheet is an excellent calculator and a poor substrate

This is worth saying plainly, because the anti-Excel genre is tiresome and mostly wrong.

Excel is extraordinary at what it does. It is the lingua franca of finance, readable by anyone in the building without training, the format your investor and your auditor and your acquirer all accept, and the fastest way in the world to answer a question with numbers. Nothing here argues for replacing it as the deliverable. It is not going anywhere and it should not.

But a spreadsheet has properties that make it a bad foundation for the four requirements above:

A file copy is not a version. Model_v4_FINAL_rev2_JD.xlsx records that something changed. It does not record what, or why, or what it broke.
The API is over cells, not over logic. You can read D14. You cannot ask what D14 means, what feeds it, or whether it is an input or an output. That distinction does not exist in the file format.
Intent does not persist. The reason a growth rate is 12% lives in the modeler's head, or in a comment, or nowhere.
There are no types. 0.12 might be a tax rate, a margin, a churn assumption or a rounding artifact. A human infers it from context. An agent guesses.

So when a company writes "own version control and forecast logic for the financial model," the honest answer available to a finance engineer today is a stack of workarounds: a naming convention, a folder of .xlsx files in a git repo that nobody can meaningfully diff, and a page of documented conventions that goes stale within a quarter. It works right up until someone changes an assumption and half the links quietly stop following.

That is the gap the job postings are papering over with a hire.

"We will ask for examples"

There is a second thing happening in these postings, and it is the part most likely to change how the role is filled.

Finance hiring ran on credentials for a long time, and for a defensible reason: the work was invisible. It lived inside someone else's ERP, under an NDA, in a file you could not take with you. There was nothing to show, so people showed a CPA, an MBA, a bank on the résumé.

The postings in this corpus are not asking for that. They are asking what you built. The automation you shipped, the close you cut from seven days to two, the agent workflow your team actually uses. That shift only works if the work is showable.

Here is the problem: most finance work still is not showable. A spreadsheet is something you attach, not something you show. It carries your employer's real numbers, it takes forty minutes to explain, and its structure is inseparable from its data, so you cannot share the thinking without also sharing the confidential inputs.

A model whose structure is separable from its data is a different artifact. The logic, the dependency graph, the conventions, the timeline: shareable, forkable, reviewable, and provably yours, with nobody's actuals inside it. That is a portfolio piece. It is also, not coincidentally, the same property that makes version control and API access possible in the first place.

What a substrate for this role would need

If you are stepping into one of these roles, or writing one of these job descriptions, the underlying question is what you build on. The requirements are consistent enough now to name:

Structure separated from data, so the logic can be versioned, reviewed and reused without dragging the numbers along.
A dependency graph that is explicit, so a change to an assumption produces a knowable set of downstream effects rather than a surprise.
Conventions written down in a form the tooling reads, not just the humans. This is what FINANCE.md is for: currency, units, sign convention, what your organization means by ARR, carried with the model instead of in someone's memory.
An agent-addressable interface, because the postings already assume the LLM is in the loop. If your agent has to re-read the entire model to change one number, you will pay for it in tokens and in drift.
Excel on the way out, always. The deliverable is still .xlsx. A substrate that traps you is worse than the spreadsheet it replaced.

Layerz is built for exactly this shape: structured models an agent drives over MCP, with the structure versioned separately from the data, and clean Excel export that is never paywalled. It is worth being clear about what it does not do. It is not an ERP and will not run your close. It does not replace NetSuite, Workday or your billing system, which are the systems most of these postings spend their time integrating. And if your work is genuinely one-shot analysis, a spreadsheet and a good prompt will beat it on speed every time.

Where it earns its place is the part the postings keep describing and no spreadsheet can hold: a model that persists, that an agent can change without breaking, and that you can hand to someone else with the reasoning intact.

The bottom line

The finance engineer role is real, it reports into Finance, and it is being asked to deliver software engineering guarantees on top of a substrate that offers none of them. Right now the gap is being closed by hiring unusually capable people and letting them improvise infrastructure out of file naming conventions.

That works, for a while. It is not a foundation. The postings have already written the spec. The question is only whether the person filling the role has to build it from scratch.

Layerz is a financial modeling substrate that keeps a model's structure separate from its data, versioned, and drivable by any AI agent over MCP or REST. Finance teams use it as the layer their agents and their Excel exports both sit on top of. Explore Layerz

The corpus behind this piece is open: 37 requisitions, 26 employers, method and exclusion rules published, with the coded data on Hugging Face under CC BY 4.0. Recount it and disagree if you think we drew the line in the wrong place.