The barrier collapsed
Something genuinely remarkable happened to finance teams over the last two years, and it has not been fully absorbed yet.
A single finance professional with AI assistance can now build things that used to require a development team and a budget line. Dashboards that pull from three systems. Automated reporting that runs on a schedule. Data pipelines. Forecasting models with real logic behind them. Variance analysis that used to be assembled by hand. Internal applications. AI assistants trained on the company's own documents. Custom integrations between systems that were never designed to talk.
None of that required a software engineer. In many cases it did not require anyone outside the finance team at all.
Let me be direct about how I see this. It is a good development. Finance professionals understand the business logic better than anyone who could be hired to build these tools on their behalf, and collapsing the distance between the person who knows what the report should say and the person who builds it removes a translation layer that has cost finance teams enormous time. Anyone arguing that Finance should stop building things is not paying attention.
But there is a second question hiding behind the first one, and it is the one that actually matters.
Experimentation got cheap. Infrastructure did not.
AI dramatically reduced the cost of building software. It did not reduce the cost of operating software.
Those are different activities with different economics. Building is a burst of effort that produces a working thing. Operating is a permanent obligation that begins the moment other people start depending on that thing.
The gap between them is where finance teams get into trouble, because the first one now takes an afternoon and the second one lasts for years.
I have spent a good part of my career on the operating side of that equation, building reporting systems, automation, and data processes and then living with them. The build is the fun part and it is a small fraction of the total work. What follows is the part nobody demos.
The moment a tool becomes infrastructure
Here is the line worth watching for.
A tool you built to answer a question is an analysis. A tool that runs every month and feeds the close, the forecast, the management package, or the board deck is infrastructure. Nobody announces the transition. It happens quietly, usually because the thing worked well enough that people started relying on it.
Once that line is crossed, you own something. And what you own is considerably more than the code.
Source systems change underneath you. Someone in RevOps renames a picklist value in Salesforce. The ERP adds a subsidiary. An account structure gets reorganized during a cleanup project. The billing platform deprecates an API version and gives you ninety days. None of those people know your pipeline exists. Every one of those events can silently break a number that goes into a board package.
Definitions drift. Sales decides mid-year that a segment means something slightly different. Nobody tells Finance, because it was a sales decision. Your model keeps calculating on the old logic and stays internally consistent while quietly diverging from how the business now talks about itself.
Exceptions accumulate. The first version handles the normal case. Then there is a mid-term contract amendment, a currency you had not accounted for, a customer who pays annually but was booked monthly, a credit memo that lands in the wrong period. Each one is a small patch, and after two years the logic has thirty small patches nobody has documented.
Then there is everything around it. Permissions, because not everyone should see compensation data. Security, because you are now moving financial data between systems. Validation, so failures surface loudly rather than producing a plausible wrong number. Testing, so a change does not break something upstream of the audit committee. Documentation written for someone who is not you. And continuity, so the whole thing survives a vacation.
None of that is difficult in isolation. All of it is permanent.
The person who becomes the system
This is the risk I would flag hardest, because it is the most common and the least discussed.
In a lot of finance organizations there is one person, usually talented and usually junior enough to still enjoy this kind of work, who built the reporting automation. They understand how it fits together. They know which step fails when the file arrives late, which field cannot be trusted, and why that one workbook has a hardcoded override from a period two years ago.
Everyone else uses the output.
That person is now infrastructure. And the company's monthly reporting has a dependency on someone who is one promotion, one competing offer, or one leave of absence away from being unavailable.
I want to be careful not to make this sound like a criticism of the person. It is usually the opposite. They solved a real problem that nobody else was solving, and they made the team better. The failure is organizational: nobody made a deliberate decision that this system would become critical, so nobody funded the documentation, redundancy, or handoff plan that critical systems require.
AI makes this pattern more likely, not less, because the barrier to one person building something significant just dropped through the floor.
The stakes depend on where the output goes
Not every internally built tool carries the same risk, and the differentiator is not technical sophistication. It is audience.
A model that helps you think through a pricing question is low stakes. If it is wrong, you find out and adjust.
A pipeline that calculates the ARR number in the investor update is a different category entirely. So is anything feeding the lender covenant calculation, the audit workpapers, the board package, or the metrics in a diligence data room. Those outputs go to people who will make decisions with real consequences and who will reasonably assume the number has been through a controlled process.
When an auditor asks how a figure was derived, "our FP&A analyst built a script" is an answer that invites a great deal more scrutiny. Not because the script is wrong, but because there is no evidence trail demonstrating that it is right, consistently, over time.
A framework worth using
The question is not build or buy in general. It is which things to build and which things to own permanently.
Good candidates for building internally: exploratory analysis, one-time deep dives, prototypes that help you figure out what you actually need, workflows genuinely specific to how your company operates, and thin analytical layers built on top of data that is already governed. Anything where the value is in the thinking rather than in the plumbing. Build these enthusiastically. AI has made this category dramatically more accessible and that is a real gain.
A much higher bar applies when: the thing will run every period for years, people outside Finance depend on it, it feeds external stakeholders, it requires maintained integrations across multiple systems, it needs permissions and an audit trail, or it would create a single point of human dependency.
Four questions settle most cases. Will this still need to run in three years? Does anyone outside Finance depend on it? Does it touch numbers that leave the company? And if the person who built it were unreachable during close week, what happens?
If the answers are yes, yes, yes, and we would be in trouble, you are not building a tool. You are taking on infrastructure, and that decision deserves the same rigor as any other operating commitment.
Own the rules. Not the plumbing.
The framing above sets up a false choice, so let me close it.
The historical trade-off was ugly. Build it yourself and own everything, including the maintenance and the risk. Or buy something and accept a vendor's definitions of your business, which for finance teams with genuinely specific metric logic has often been unacceptable.
That trade-off is what configurable software is meant to dissolve. The right split is that Finance defines the rules and the vendor operates the infrastructure.
Finance should absolutely own its own metric definitions, methodologies, hierarchies, business rules, and workflows. Those encode how your company understands itself, and no vendor can supply them. But Finance should not have to own the pipeline maintenance, the security patching, the API version migrations, the uptime, and the documentation burden in order to get them.
That is also the sensible way to think about what a finance operating system is. A layer that connects and governs financial and operational data across the systems a company already runs, applies the finance logic that the company itself defines, and stays maintained by someone whose full-time job is maintaining it. Finance keeps the judgment. Somebody else keeps the plumbing running at 2am during close. We wrote more about how those layers stack up in why AI versus automation is the wrong question.
Two different questions
The democratization of software creation is one of the better things to happen to finance teams in a long time. More finance professionals should be building. The people closest to the business logic should be able to make things without filing a ticket.
But the ability to build something and the decision to own it permanently are two entirely different questions, and the first one getting easier does not answer the second one.
Build the experiment. Think much harder before you build the infrastructure.
SMPL.ai builds trusted financial infrastructure and intelligence for growing SaaS companies, so finance teams can define their own rules without owning the plumbing underneath them. Learn more at www.smpl-ai.com.