This is part 4 of Finance AI Field Notes. Part 3: The goals CFOs are setting for AI.
Every finance leader I talk to frames the AI decision the same way: do we buy something ready-made, or do we build in-house? After reading roughly 105 live job postings from companies choosing "build," and the adoption data from companies choosing "buy," I think the binary itself is the mistake.
The case for ready-made — and its honest failure mode
Ready-made comes in two flavors. Embedded (your ERP vendor's agents) and point solutions (close tools, AP automation, reconciliation SaaS).
Embedded is what CFOs say they want — 56% prefer platform AI from existing vendors per L.E.K.'s survey, and the reasons are sound: one vendor, one data model, one contract. The failure mode is delivery: the German SAP user group found ~3% of SAP customers running SAP Business AI in production, and 77% of SAP's own AI-active enterprises using non-SAP tools to get there. SAP's chief product officer called adoption of its agent-builder "minimal." The embedded promise is real; the embedded timeline is not yours to control, and your process gets whatever shape the vendor decided.
Point solutions deliver faster, but each one adds a silo — and "integration complexity" is already on Gartner's list of the top CFO blockers. Buy four point tools and you've re-created the fragmentation you were trying to escape, now with four AI roadmaps you don't control.
The case for in-house — and its honest failure mode
The build lane is booming: about 70% of the corporate postings in my scan use build language. And the logic is genuinely strong. Your close checklist, your intercompany maze, your approval matrix — no vendor ships that. Kraken is hiring an architect to build "an agentic finance layer that runs alongside the existing stack today." CSC Generation says agents are "the mandate, not an aspiration."
But look at how the build is staffed: almost always one headcount. One architect, one automation engineer, one "Head of Finance Automation" with a team of three. Now inventory what that one person must produce from scratch: connectors to the ERP and banks, an orchestration layer with retries and failure handling, approval workflows, segregation-of-duties enforcement, audit evidence capture, logging and traceability, a testing regime an auditor will accept, documentation, and training. That's not an agent — that's a platform. Companies that assign a platform to a single hire have made a hiring decision, not an architecture decision. When that person leaves (median tenure in tech finance teams is around two years), the automation becomes an unmaintained black box wired into your general ledger. There's a name for that in audit language, and it isn't a compliment.
The market itself is telling you this quietly: Kraken's own JD asks the hire to build "reusable frameworks… so that future Finance team members can safely build on top of the platform without relying on a single specialist." They're asking the specialist to solve the specialist problem.
The third option the binary hides
The real question isn't build vs. buy. It's: which layers should you build, and which should you stand on?
Split the stack honestly:
- The substrate — ledger connectivity, orchestration, approval lanes, human-in-the-loop checkpoints, audit trails, multientity handling, access control. This is 80% of the engineering effort, it's identical across companies, and none of it differentiates you. Building it in-house is rebuilding infrastructure that already exists, one salary at a time.
- The logic — your workflows, your risk thresholds, your vendor quirks, your entity structure, your judgment calls. This is the 20% that is genuinely yours, changes constantly, and is exactly what your in-house person understands better than any vendor ever will.
Buy (or adopt) the substrate. Build the logic. That's the configuration the best postings are groping toward without naming: they want someone who ships agents in weeks, not someone who spends year one building the scaffolding those agents need to be trusted.
The software industry solved this pattern long ago. Nobody writes their own database because their queries are unique; they write queries on Postgres. Nobody builds a CI system because their tests are special; they write tests on existing runners. Finance AI is at the stage where teams are still writing their own Postgres — because the substrate layer for governed finance agents is new enough that many don't know it's a category.
A decision checklist that survives contact with reality
- Per workflow, not per function. Embedded where your vendor has actually shipped (verify production references, not keynotes). Point tool where the workflow is commodity. Build where the process is yours.
- Whatever you build, build on something. If your hire's plan starts with "first I'll build the orchestration and approval framework," you're funding infrastructure, not automation. Months of it.
- Apply the auditor test to all three lanes equally. Who approved, what evidence, where's the trail? Ready-made tools fail this more often than their websites suggest; in-house builds fail it under deadline pressure.
- Price the bus factor. Add the cost of a departed builder to the in-house estimate. Add the cost of a vendor pivot to the ready-made estimate. Now compare honestly.
The teams getting this right in the postings I read aren't ideological about building or buying. They're ruthless about which layer of the problem deserves their only scarce resource: the person who understands both the ledger and the language model.
Part of Finance AI Field Notes. Disclosure: this is the layer I work on — Artifi is a governed substrate for finance agents, so I have a horse in this race; the data above stands on its own either way. Next: The Agent Layer — the new tier quietly appearing in enterprise finance org charts.