Everyone Is Asking Whether to Build AI Themselves. Here Is How We Think About It.
A year ago, the question we heard most from finance leaders was whether AI could actually read an invoice and code it correctly.
That question is settled. The new one is harder.
Should we build the AI ourselves?
We hear that question constantly now, at every stage of an evaluation, and we have started to notice it is really four questions wearing the same clothes.
The same question from four different rooms
The CIO asks about capability. Their team has usually already built something: a prototype, put together in a few weeks by one engineer, that reads a folder of invoice PDFs and returns the vendor, the amount, and the line items. The prototype works. The CIO wants to know what is genuinely hard beyond extraction, and what is merely packaged.
The CFO asks about cost. A software line item sits next to an engineering budget, and the comparison looks straightforward. The trouble is that the two figures are different kinds of numbers. One is a recurring cost that someone else operates. The other is a build estimate, which prices version one and goes quiet about years two through five. The arithmetic is usually sound. The inputs are usually incomplete.
The Controller asks about risk. The controller is the person who will explain to an auditor why an invoice was coded to a particular account. Controllers tend to ask the sharpest questions in the room, and they ask about the parts nobody demoed.
In PE-backed companies, the sponsor asks about speed. Sponsors want to know which path produces measurable margin improvement inside the hold period, which is a clarifying way to frame the choice.
Four different conversations, and they usually happen separately. That is part of why build decisions so often get made on partial information.
Building is a fair question
We are an AI company, so the expected move is to explain why building is naive. We are not going to make that argument, for two reasons.
The first reason is that we built the AI ourselves, so we know the work is possible. Vic.ai spent two years on the AI alone, training on hundreds of millions of accounting transactions, before shipping a product anyone could log into.
We are careful about what our own history entitles us to say. Building AI was not one function we evaluated among others. Building AI was the whole company, and the work still took years. For the companies asking us the build question, autonomous AP is one function inside a business that earns its living somewhere else.
So our history does not prove that anyone can build this. Our history proves how large the commitment is, and that we could only sustain the commitment because sustaining it was the entire job.
The second reason is that the CIO's prototype genuinely works. Point a current model at an invoice it has never seen, from a vendor whose layout exists in no template library, and ask for the vendor, the invoice number, the totals, and the line items. The model will usually return them correctly. That was not true a few years ago, when reading an unfamiliar invoice format meant building a template for that format first, which is why the previous generation of AP automation needed such long onboarding. Anyone still telling finance leaders that reading the document is the hard part is describing a problem that has largely been solved.
So when a company tells us they are considering a build, we do not treat the statement as an objection to overcome. We treat the build question as the correct question, asked at the correct time.
Where the build decision usually goes wrong
In our experience, the conversation around build vs. buy usually fails in two directions.
Building because the prototype was impressive. The prototype proves a model can perform a task once, under observation, on a clean example. A production platform has to perform the same task forty thousand times a month, in front of an auditor, with nobody watching, while vendors change their invoice templates and nobody tells you. Those are different engineering problems, and most build proposals we see are scoped against the first one.
Buying to avoid the conversation entirely. This failure gets less attention but it is just as costly. Some companies should build. If a workflow is genuinely where you compete, or you hold data no platform can see, outsourcing it means renting your own advantage.
Gartner found that by the end of last year, at least half of generative AI projects were abandoned after the proof of concept stage, citing poor data quality, inadequate risk controls, escalating costs, and unclear business value. Worth noticing what is absent from that list. None of those four causes is model capability. Every one of them is operational.
That matches what we see. The projects that stall rarely stall because the AI could not do the task. They stall on the surrounding system: the integration work, the audit trail, the exception handling, the ownership question nobody answered.
How we view the decision as a company
Here is our actual position, as succinctly as we can state.
Build where you compete. Buy where you operate. Very few organizations win their market because of how they code invoices. Plenty win because of how fast their finance function moves, which is a different claim and worth examining honestly. That distinction, more than any cost comparison, is usually what resolves the decision.
The honest comparison is not license cost against salaries. It is total scope against total scope. On one side, a subscription. On the other, a permanent product team, infrastructure, security review, monitoring, retraining, and an operational owner who is on call during close. Every year, not once.
Time is the variable most teams undercount. Deployment takes weeks. An internal build that reaches production reliability takes years. Whatever autonomous AP is worth annually, buying starts collecting that value now and building defers most of it.
We would rather lose a deal to a well-reasoned internal build than win one where we are the wrong fit. A customer who buys without understanding the scope of what they bought churns in year two. The companies who interrogate the build decision hardest become our best customers, whichever way they land.
What we will not claim is that the decision is simple. Choosing how AI enters a finance function is one of the more consequential technology decisions a finance organization will make this decade, and the choice deserves more than a build estimate and a vendor comparison sheet.
Where this conversation goes next
We are spending the next few weeks on the build versus buy question properly.
Our co-founder and CEO, Alexander Hagerup, will weigh in on the question with his take, and our product team will provide some perspective, as well.. Alex has been on the build side of this for nearly a decade and has a specific view on what the prototypes miss and get right. That perspective is helpful no matter where you ultimately land in the build vs. buy decision.
After that, we are running a webinar on the decision itself: how to scope a build, what to ask an internal team before greenlighting one, and what we have learned from customers who ran the evaluation and reached different conclusions.
If your organization is having this conversation right now, come have it with us.
.svg)
