You Can Build It. But Do You Want to Own It?

With AI, building your own tooling is easier than ever. But is it better?

Your team probably has a spreadsheet that's tracking all of your commission data: it's cobbled together, has a few filters that can't be touched, and every click takes a few seconds because the file is genuinely enormous.

But it works! Just as long as you don't jostle it around too much.

Now, with AI building tools like Claude Code, the same teams who hold on to one, if not many, of these spreadsheets are entranced. They see the building potential and naturally, questions start to arise: How much software do we really need? Why can't we start to build our own tooling for everything?

CFOs everywhere will be coming to these realizations and asking these questions for all of 2026. Our response?

The real build vs. buy question is no longer "can I build this?" It's now "do I want to own this?"

The Complex, Build vs. Buy Decision in the AI Era

For most of software history, the build vs. buy calculus was relatively stable. Building meant hiring engineers, writing a spec, spending months in development, and so on. Buying meant evaluating vendors, negotiating contracts, and living with whatever the product could and couldn't do. The costs of each were legible. The tradeoffs were well understood.

AI coding tools have scrambled both sides of the equation.

The Complexity of Building

Ben Sheridan, a Product Manager at Numeric and a CPA who helped to build Snowflake's internal revenue engine, admits that feasibility is no longer the bottleneck. But the infrastructure required to make software run reliably is easy to underestimate:

"What we think about is the fact that [software] needs to run perfectly and consistently for every person who purchases it, things get infinitely more challenging. It needs to be secure, meet audit requirements, and do all of these things not just for one person, but many people."

For an accounting team doing this on the side of their actual responsibilities, the math gets worse quickly. The initial build is the cheapest part. The expensive part is what happens when your close process changes in month three — a new entity, a new currency, a different accrual method — and someone has to update the logic. That someone is you. And you're also the person doing the close.

The Complexity of Buying

Still, the allure of vibe-coding's ROI is hard for any exec to ignore. And as teams navigate their AI mandates, the pressure to build with AI – as both evidence of smart AI usage and cost-savings – is steep.

Today, teams are asking themselves:

• "Should we just try the AI-first approach before buying any external software?"
• "What if we just have some engineers help us build and maintain our tools — isn't that cheaper than a vendor?"

More specifically: why spend $50,000/year on a dedicated tool for something like commissions when you can spend anywhere from $20-$200 for a tool that promises to do the same job? Or leverage that and some internal engineering resources?

Fair questions. But the debates of build vs. buy ROI predate AI by years, even decades.

Adam Heeger, a Solutions Manager at Numeric and CPA frames this as the open source paradox. "There's always been open source software. That sounds great, you're trying to save money. But there's a lot of open source companies that have been very successful giving away the software and charging a lot for service. Because the world changes. These products adapt and evolve. And there's experts out there that you're willing to pay to answer questions."

In essence, a SaaS product is just as much an insurance policy as it is a software purchase.

Francisco Meyo, Controller at Abridge, echoes this from the practitioner side: "We're not going to try to build a full end-to-end integration that we then have to deal with security and redundancies for. We're not software engineers. We wanna still go and look for the best product out there."

The Framework: What to Build and What to Buy

To figure out where the line should be, we talked to practitioners building automations inside their accounting functions (Kenny Kha and Francisco Meyo at Abridge), product builders who live inside these tradeoffs at Numeric (Ben Sheridan, Alec Schon, and Adam Heeger), and consultants who've seen it play out across dozens of companies (Drew Armanino and Dean Quiambao at Armanino LLP).

They converged on a framework built around two axes, and neither is "feasibility."

The X-axis: Total cost of ownership. This isn't just the cost to build. It's the cost to build, maintain, debug, document, onboard new team members, update when your processes change, and eventually deprecate or replace. It includes the fraction of engineering time that quietly goes to keeping it running. It includes the opportunity cost of whoever owns it, because that person's attention is finite, and every hour spent maintaining your homegrown tool is an hour not spent on something else.

The Y-axis: Defensibility stakes. How much does this need to withstand scrutiny? Is an auditor going to look at this? Is it a system of record — meaning, is it where the data lives, not just where data passes through? Does getting it wrong have serious consequences — financial, legal, reputational? Is this output something you'll be asked to explain and stand behind?

Map any accounting process onto these axes and the right quadrant becomes much clearer:

• Low cost, low stakes → Build freely. A commissions calculator for internal use, a renewal tracker, a one-off data transformation script. They solve real pain, the blast radius of failure is contained, and the maintenance burden is manageable.
• High cost, low stakes → Custom data pipelines, subledger prototypes. The risk isn't audit failure — it's maintenance creep. Ask yourself: who owns this in a year? If you can't name the person, reconsider.
• Low cost, high stakes → Buy, but pressure-test the vendor. The tool might seem simple, but if its output appears in your financials or audit trail, you want professional accountability behind it.
• High cost, high stakes → CRMs, payroll, ERP, revenue recognition, close management. Ben puts it directly: "People have joked about trying to build Salesforce. That is way more complex than you realize." Payroll is even clearer: "Deeply entrenched in legal stuff. You could get sued into oblivion."
  ‍

So, What Should You Build?

The answer isn't always "buy." There are real places where building pays off — even scrappy, vibe-coded builds. Everything below sits on top of your systems of record rather than trying to replace them. That's the line.

Data Transformation Scripts

Ben Sheridan puts it simply: "Wherever you need to take your raw data and turn it into inputs for your accounting model — AI is awesome at that."

If you're writing formulas to clean or reshape data before it hits your GL, build it:

• Revenue data cleanup — pulling usage or consumption data out of Snowflake and shaping it into revenue model inputs
• Chart of accounts mapping between systems (translating a subsidiary's local COA into the parent's structure)
• CSV normalization for bank feeds or credit card transactions
• Intercompany elimination prep — pulling balances across entities, formatting them for elimination entries
• Vendor or customer master data deduplication
• FX rate ingestion and standardization across sources

Operational Calculators

Again, you know the spreadsheet. Fourteen tabs, formulas no one wants to touch, takes a few seconds every time you click. Rebuilding these as lightweight tools is a good use of vibe coding — as long as one person owns it, a small team uses it, and failure is recoverable.

• Commissions calculator
• Custom accrual estimator (e.g., modeling bonus accruals against targets mid-quarter)
• Renewal and ARR tracker
• Headcount cost allocator across departments or projects
• Bonus and variable comp modeler

System-to-System Connectors

Francisco calls these "micro-automations that fill the gaps among integrations." Not replacing your tools — just making them talk to each other. A script that pulls data from one system, cleans it, pushes it into another.

• HRIS to GL headcount sync for payroll allocation
• Billing or subscription platform to revenue model bridge
• Expense management system to department-level cost allocation
• Bank statement auto-import and formatting for reconciliation
• Procurement system to accrual generation at month-end

The common thread: you're automating or improving an operational process that runs on top of your systems of record, not replacing the systems themselves.

The Auditability Problem

There's a wrinkle specific to accounting that applies to both sides of the decision: knowing a tool works isn't enough. You have to show that it works — and right now, the audit world hasn't figured out how to evaluate AI-touched outputs.

This matters whether you're building your own automation or evaluating a vendor's AI features.

The practitioners we talked to are navigating this in real time, and their instincts converge on a few hard-won principles:

• Keep scope small enough to understand end-to-end. Kenny Kha, Financial Operations & Systems Lead at Abridge is candid: "The speed at which I can get automations done now is a lot faster. But me hitting 'OK' constantly — I'm like, it works, but I have no clue exactly what's happening." His solution: reserve automations for processes that are important but not audit-critical.
• Build control structures around AI outputs, not into them. Francisco's team runs all their micro-automations through a GitHub repo with version control and restricted access — deliberately designed to satisfy Big Four auditors. But he draws a firm line: "We're not going to try to build a full end-to-end integration that we then have to deal with security and redundancies for. We're not software engineers."
• If AI prepares it, you need two reviewers, not one. One corporate controller and former auditor we spoke with is blunt about the controls math: if AI replaces your preparer, you can't get away with saying one person reviewed it. You need two human reviewers on everything AI touches. It still saves time — but the savings aren't as dramatic as the demos suggest, and teams that skip this step are building a controls gap they'll have to close later.
• Treat plausible-looking outputs as the highest-risk failure mode. One of Numeric's solutions engineers recently connected an AI tool to an ERP and built multi-entity, multi-currency reports. The outputs looked completely normal — no errors, no warnings. Then he went line by line and discovered the system had been silently mixing local and consolidated currency throughout, producing incorrect numbers that looked right. A broken tool gets fixed. A tool that produces plausible-looking wrong numbers might never get caught.
• Drew Armanino, Consulting Operation Lead at Armanino LLP, puts it bluntly from the consulting side: "Everything demos great now. What we're finding is once clients have bought or built something and it's actually delivered, it's not always delivering on the value prop that was shown in the demo." The same skepticism should apply to things you build yourself — perhaps even more so, because there's no adversarial party whose job is to prove the product works.

That same Controller frames the broader landscape this way: the audit profession is likely the furthest behind on being able to support clients through the AI transition, because they haven't figured out how to audit it yet. That's not their fault — it's genuinely new. But it means the burden falls on controllers to build defensible processes around AI, regardless of whether the AI came from a vendor or from a Tuesday afternoon with Claude Code.

Note: Your Vendors Are Building, Too

There's one more dimension that most build vs. buy discussions miss: your vendors are building with the same AI tools you now have access to — and they're doing it full-time. What takes your team two weeks of side-of-desk effort, a dedicated product team is shipping in hours. That's not a knock on your team. It's a structural reality: building software is their entire job, not a project wedged between close and month-end reporting.

Before you spend six weeks vibe-coding a solution, ask one question: is this a known gap in a product you already pay for? If so, a fifteen-minute conversation with your account rep about their roadmap might save you the effort — and the eventual cost of deprecating a homegrown tool that gets made redundant anyway.

The Importance of Clean Data: How Numeric Helps

Every build — every script, calculator, and connector — is only as reliable as the data feeding it. And every tool you buy is only as useful as the GL data it's reading.

For many teams, the highest-ROI investment isn't the flashiest AI build or the most feature-rich vendor — it's the tool that gives you ongoing clarity into your financial data. Get that right and everything downstream works better: your close, your reporting, your automations, and whatever you build next with Claude Code.

Numeric is that tool for accounting teams at companies like OpenAI, Anthropic, Brex, Asana, and Riskified. Our platform sits on top of your ERP and gives your team real-time visibility into GL data — so the foundation underneath your close process, your controls, and your AI builds stays clean.

Here's how:

→ Set up ongoing transaction monitoring. With Monitors, you can build flexible, always-on checks against your GL — flagging miscoded expenses, missing department tags, duplicate entries, or anything else that would quietly break a downstream process. Think of them as saved searches that actually run themselves.

→ Sync your ERP for real-time transaction clarity. Numeric pulls in your chart of accounts and every transaction that hits your GL through a continuous sync — not a nightly batch, not a manual export. When you're investigating a variance or prepping a rec, you're working with live data, not a stale spreadsheet snapshot.

→ Use AI to get a headstart on flux analysis. Numeric can surface drivers of variance in your accounts instantly — flagging period-over-period changes and suggesting explanations before you've started digging. It's like having someone do the first pass on your flux before you sit down to review.

→ Build flexible, CFO-ready reports without the Excel gymnastics. Numeric's reporting tools let you slice and pivot your GL data in real-time — by department, vendor, account, period — without exporting to a spreadsheet. The logic is deterministic and auditable, so you're not worrying about fat-fingered formulas or broken pivot tables.