A predictable arc, repeated across a lot of teams
Ask around at enough AP automation and procure-to-pay startups and a familiar shape starts to emerge: the platform launches with its own invoice extraction, built on top of a general document AI service, works reasonably well for the first cohort of customers, and then — somewhere between six months and two years later — an engineer proposes switching to a dedicated invoice extraction API instead. The proposal usually meets some internal resistance, since it can feel like admitting the original build was a mistake. It usually wasn't. It was simply the reasonable choice at the time, given what the team knew and needed then.
This article traces that arc in detail — not to argue nobody should ever build their own extraction, but because understanding the pattern in advance makes it much easier to recognize early, and to decide deliberately rather than reactively when it finally forces the question.
Why nearly everyone starts by building
At the earliest stage, building makes sense for reasons that have nothing to do with long-term cost economics. A small team wants full control over the exact data shape their product consumes, is naturally wary of an external dependency for something so central to the product, and — most practically — the initial proof of concept genuinely doesn't take that long to get working against a handful of test invoices. All of that is real, and none of it is wrong at the seed stage.
What changes isn't the initial reasoning — it's the assumptions that reasoning was built on, as the platform grows past the small, curated set of invoices the original build was tested against.
There's also a genuine cultural pull toward building in early-stage engineering teams — shipping your own core infrastructure feels more like "real" product work than wiring up someone else's API, and that instinct, while not always the economically optimal one, isn't irrational either. A team that has never seen the maintenance tail described later in this article has no first-hand reason yet to weigh it properly.
Phase one: the demo that works
The first version reads a dozen or two sample invoices — usually clean, machine-generated PDFs from well-known suppliers — with genuinely good accuracy. It's enough to close the first few design partners and start onboarding real customers. At this stage, the decision to build looks completely validated: the team shipped something that works, on schedule, without the cost of an external vendor.
Phase two: the long tail arrives
Every new customer brings their own suppliers, and most of those suppliers weren't in the original test set. A scanned invoice from a regional distributor. A layout with a merged description-and-SKU column the parser wasn't built to split. A multi-page line-item table that gets silently truncated at the page break. None of these individually looks like a crisis — each shows up as a single bug report, fixed with a targeted patch. Collectively, they start to define the actual shape of the maintenance burden nobody budgeted for at launch.
Phase three: the maintenance tax
By the time a platform has a meaningfully diverse customer base, the pattern from phase two has compounded into something structural rather than occasional: a standing, ongoing share of engineering time devoted to fixing extraction bugs from new supplier layouts, rather than shipping new product features. It rarely shows up as a single alarming number — it's a slow, steady accumulation, one supplier-specific fix at a time, that's easy to underestimate until someone actually tallies the sprints it's consumed over the past year.
This is the phase where the original build-vs-buy math, made honestly at launch with the information available then, has quietly changed — not because the team made a mistake, but because the inputs to that calculation (supplier diversity, engineering opportunity cost, actual production accuracy needs) were genuinely different a year or two into real customer usage than they were on day one.
The specific moment teams usually reconsider
It's rarely a calm, scheduled architecture review. More often it's a specific, uncomfortable incident — a large customer's onboarding stalls because their supplier base breaks the parser repeatedly, or a sales deal is at risk because a prospect's pilot invoices came back with enough extraction errors to worry them, or an engineer finally does the math on how many sprints went to extraction maintenance last quarter and brings the number to a planning meeting.
Whatever the specific trigger, the underlying question it forces is the same one covered in the build vs. buy decision framework— except now it's being asked under real production pressure, with a specific customer or deal on the line, rather than as a calm hypothetical at the planning stage.
This isn't a story about a failed engineering effort
It's worth saying directly: none of this means the original engineering team did anything wrong. Building the first version was, in nearly every case, the correct decision given what the team knew and needed at the time — it got a real product in front of real customers faster than waiting to evaluate every alternative first would have. The reconsideration described here is a sign of a platform maturing and its priorities shifting, not a sign the initial choice was mistaken.
It's worth remembering, too, that hindsight makes this look more obvious than it ever was in the moment. At launch, the team genuinely didn't know how diverse their eventual supplier base would become, how much engineering time maintenance would actually consume, or how good a dedicated invoice API would be a year or two later. Judging the original decision against information that simply wasn't available at the time isn't a fair comparison.
What actually gets compared during the reconsideration
| What gets measured | What it usually shows |
|---|---|
| Sprints spent on extraction bugs, trailing 12 months | A meaningfully larger number than anyone expected before tallying it |
| Line-item accuracy on a random sample of recent invoices | Lower than the original demo's accuracy, once diverse suppliers are included |
| Per-page API pricing vs. fully-loaded in-house cost | Often close, or in the API's favor, once engineering time is properly costed |
| Integration effort estimate for a switch | Smaller than the team initially assumes, if extraction was reasonably decoupled |
What the comparison usually looks like
A Series A AP platform tallies its extraction-related engineering time over the prior two quarters before deciding whether to switch.
| Finding | Detail |
|---|---|
| Engineering time on extraction bugs | Roughly 30% of one engineer's time over two quarters |
| Line-item accuracy on new-customer invoices | 6-8 points lower than on original test suppliers |
| Estimated API integration effort | About two weeks, including review-queue rewiring |
| Decision | Switched, freeing the equivalent of a third of a headcount for product work |
None of these figures involved anything dramatic — no catastrophic outage, no lost customer over extraction errors alone. It was the accumulated, unglamorous cost of routine maintenance that made the case, once someone actually measured it instead of just sensing it was "more than it should be."
The eight-point accuracy gap on new-customer invoices is worth calling out specifically — it's exactly the kind of number that's invisible in aggregate reporting, since it only shows up when new-customer invoices are measured separately from the established, well-tested supplier base the platform has processed for years.
The rough math behind the decision
A fully-loaded engineer, at a typical fully-burdened cost, spending even a third of their time on extraction maintenance represents a meaningful ongoing spend once it's converted into a dollar figure rather than left as an abstract "some of an engineer's time." Compared against usage-based API pricing measured in cents per page, the crossover point where continuing to build in-house is cheaper requires genuinely high, sustained volume — often higher than most AP platforms below Series B actually process.
This is the calculation worth running explicitly, with your own team's real numbers, rather than relying on a general sense that "we already built it, so it must be free now." The initial build cost is sunk either way — what matters for a forward-looking decision is the marginal cost of continuing to maintain the in-house system versus the marginal cost of switching, and the two are rarely as close as intuition suggests once actually measured.
It's also worth accounting for the cost that doesn't show up on any spreadsheet at all — the product features that didn't ship because the engineer who would have built them was fixing a supplier-specific parsing bug instead. That opportunity cost is real, even though it never appears as a line item anyone budgets for directly.
What happens to the team that built it
In most cases, nothing dramatic — the engineers who built the original parser don't disappear from the roadmap, they get reassigned to the parts of the product genuinely worth their attention. The in-house extraction effort typically isn't wasted work either; it usually leaves behind a clearer internal understanding of what accuracy actually requires, which makes evaluating and integrating a replacement API considerably faster than doing the same evaluation cold.
The bigger shift is usually cultural rather than technical — a team that spent a year or two thinking of extraction as core, differentiating infrastructure has to recalibrate to thinking of it as a dependency, similar to how most SaaS products think about their payments provider or their email delivery service.
Some of the internal tooling built during the in-house phase survives the switch too — a supplier metadata table, an internal accuracy dashboard, a set of known-good test invoices used for regression testing. None of that goes away just because the extraction call itself now points at an external API instead of internal code.
Teams for whom building keeps making sense
This pattern isn't universal, and it's worth being specific about who it doesn't apply to. A platform serving one narrow, well-understood vertical — construction subcontractor invoices, say, or freight bills of lading — with a genuinely predictable, recurring supplier base, can build a narrowly-tuned in-house parser that stays accurate without the long-tail problem a horizontal platform faces. A team with deep existing OCR or ML expertise, looking to apply it somewhere with a real business case, is in a different position than a typical AP platform engineering team learning document extraction from scratch.
For these teams, the arc described above simply doesn't play out the same way — the long tail that drives phases two and three never really materializes, because the supplier base was deliberately kept narrow from the start.
It's worth noting, too, that a platform can start broad and later narrow its focus deliberately — a horizontal AP platform that discovers most of its traction comes from one specific vertical can choose to lean into that concentration, and at that point the counter-example above starts applying to a team that didn't begin there. The relevant question isn't which category a platform started in, but which category its current, real supplier base actually falls into today.
Myths worth retiring
"Switching to an API means the in-house build failed"
It usually means the platform's supplier base grew beyond what the original build was designed for — a sign of growth, not failure.
"An API can't match the accuracy of a purpose-built in-house parser"
A dedicated invoice extraction API's entire product is extraction accuracy, continuously improved — for most teams it ends up more accurate on a diverse supplier base than an internally-maintained parser with limited engineering attention.
"Building is always cheaper once you already have the infrastructure"
The infrastructure cost was never the expensive part — the ongoing engineering time to maintain accuracy against new supplier layouts is, and that cost doesn't go away just because the initial build is done.
"This only happens to poorly run engineering teams"
It happens to well-run teams too — it's a structural consequence of customer diversity growing faster than a narrow in-house parser was ever designed to handle, not a sign of poor engineering.
Early signals worth watching for
A rising count of supplier-specific parsing bug reports, month over month, well before it's dominating a sprint. An engineer's calendar increasingly full of extraction-fix tickets rather than new feature work. A new-customer onboarding process that quietly slows down whenever a customer's supplier base is unusually diverse. Any one of these, tracked deliberately rather than felt informally, gives a team the option to have the build-vs-buy conversation on its own schedule, rather than during a specific customer crisis.
What the switch itself actually costs
For a platform that kept extraction reasonably decoupled from its downstream matching and approval logic, the switch itself is usually the smaller part of the project — days to a couple of weeks of integration work, mapping the API's response shape onto whatever internal data model the platform already uses. The larger, more variable cost is unwinding anything that was tightly coupled to the in-house parser's specific quirks — a downstream matching rule that quietly compensated for a known extraction bug, for instance, which needs to be found and removed rather than carried forward unnecessarily.
What to check before picking who to switch to
Once a team decides to switch, the next mistake to avoid is picking a vendor based on a general accuracy claim alone. Run the candidate's API against a real sample of your own supplier invoices — not a curated demo set — and check line-item accuracy specifically, since that's the number a header-focused accuracy claim tends to quietly skip over.
Beyond accuracy, confirm the pricing model actually fits your volume shape rather than penalizing growth, check what happens to your documents after processing, and confirm the vendor's infrastructure has documented, verifiable security controls rather than a general assurance. A fifteen-minute integration test against real invoices answers most of these questions faster than a sales call would.
How to avoid ending up here unprepared
None of this argues against building in the first place, when the reasoning in the decision framework genuinely supports it. What it argues for is building with the possibility of this arc in mind — keeping extraction logic behind a clean internal interface from day one, and periodically measuring the actual engineering time it consumes rather than relying on a general sense that it's "probably fine." A team that does both is in a strong position either way: ready to keep building confidently if the numbers still support it, or ready to switch quickly and cheaply if they don't.
A concrete habit worth adopting: a brief, recurring check-in — quarterly is usually often enough — that asks two questions directly. How much engineering time went to extraction maintenance last quarter, and has the supplier-base diversity changed meaningfully since the last check-in. Neither question takes long to answer, and together they turn a decision that's otherwise easy to defer indefinitely into one revisited on a predictable schedule.
Put this check-in on the same calendar as any other recurring engineering review — a quarterly planning meeting is often the natural place for it — so it happens as a matter of routine rather than depending on someone remembering to bring it up.
Does platform size change this pattern
The arc plays out at every stage, but the stakes scale with it. A three-person seed-stage team reconsidering its extraction approach is a relatively low-stakes conversation — a couple of weeks of integration work, minimal downstream coupling to unwind. A hundred-person platform with years of accumulated logic built around its in-house parser's specific quirks faces a genuinely larger migration, which is exactly why catching the signals in the earlier sections sooner, rather than later, matters more the larger a platform gets.
There's a specific window worth being aware of — the period between "the maintenance burden is clearly growing" and "switching now would require a genuinely disruptive migration" tends to be narrower than teams expect, since coupling between extraction logic and downstream code accumulates gradually and often invisibly until someone actually tries to untangle it. Reconsidering the decision while that window is still open is considerably less painful than doing it once the window has closed.
What might change as invoice APIs mature further
As dedicated invoice extraction APIs continue to mature, the calculus described throughout this article is likely to keep shifting further toward "buy" for most AP platforms — a specialized API's accuracy on a diverse supplier base improves continuously and independently of any one AP platform's own engineering bandwidth, which is a structural advantage that's hard for an in-house team, focused primarily on its own product, to match over a long enough time horizon.
That doesn't mean building disappears as an option — the counter-examples in this article remain genuinely valid — but it does mean the bar for building continues to rise as the alternative keeps getting better.
In short
Most AP platforms start by building their own invoice extraction, and that's usually the right call at the time. What changes isn't the wisdom of that original decision — it's the supplier diversity, the accumulated maintenance cost, and the opportunity cost of engineering time that a growing platform eventually has to weigh against it. Recognizing the arc early, measuring the real cost rather than sensing it informally, and keeping extraction decoupled from the rest of the platform, turns an eventual reconsideration into a deliberate choice instead of a reactive scramble.
None of this requires a dramatic pivot — it requires the same discipline as any other infrastructure decision: measure it, compare it honestly against the alternative, and be willing to change course when the numbers say so, on your own schedule rather than a customer's or a deal's.
If any part of this pattern sounds familiar from your own platform's last few sprints, the build vs. buy decision framework is the practical next step — the same eight questions this article describes teams eventually answering under pressure, worked through calmly instead.