Why expense-management SaaS stop building their own OCR

Why v1 always looks deceptively easy

A general-purpose OCR API — Tesseract, a cloud vision endpoint, an early version of Textract — will genuinely read text off a clean receipt with reasonable accuracy in an afternoon of engineering work. That early success is exactly what makes the long-term cost invisible at the start: the remaining 20% of the problem, not the first 80%, is where the real cost lives.

The remaining 20% is: receipts photographed at an angle, on curled or faded thermal paper, in a dozen languages and currencies, from merchants whose printed layout has no consistent structure at all. It's the difference between "reading text off an image" and "reliably extracting a merchant name, a total and individual line items from any receipt a real user might submit" — a categorically harder problem than the first version made it look.

The real first-year cost, line by line

Put concrete numbers on it rather than leaving it abstract. A first-year build, from a standing start to a production-usable pipeline, typically breaks down like this:

This figure is a range, not a guarantee — a smaller scope with a narrower receipt-format target can land lower, and a broader international scope with many currencies and languages can land meaningfully higher. What's consistent across most real accounts of this build is that it's a genuine, multi-person, multi-quarter engineering project, not a sprint.

It's also worth naming what this figure buys, specifically: a v1 that handles the common case reasonably well. It doesn't, on its own, buy the accuracy on unusual formats, the multi-language support, or the statement-extraction capability a full expense platform typically also needs — each is closer to its own project than a feature bolted onto the first one, which is part of why the real figure so often lands at the high end of the range rather than the low end.

The cost that doesn't show up on the invoice: maintenance

The build cost is the part most teams estimate reasonably well going in. The part that's consistently underestimated is what happens after v1 ships: accuracy doesn't stay static. New merchants appear with layouts the model has never seen. A bank redesigns its statement format. International expansion introduces receipts in a language the training set barely covered. Someone has to keep watching for this drift and correcting for it — commonly $40,000 to $70,000 a year in ongoing engineering time, indefinitely, for as long as the in-house pipeline stays in production.

That's the number that turns a one-time $120K–160K project into a permanent budget line, and it's the number most build-vs-buy comparisons done early — before anyone has lived with an in-house pipeline for a year — tend to leave out entirely.

The accuracy plateau every in-house team hits

There's a well-known pattern in applied ML: getting from 0% to roughly 85% accuracy on a reasonably well-scoped extraction problem is comparatively fast, because the easy, common cases dominate the data. Getting from 85% to 95% takes disproportionately more effort, because what remains is exactly the long tail of unusual formats, edge cases and genuinely ambiguous receipts — the cases that matter most to a finance team relying on the data, and the hardest ones to fix with incremental engineering.

Most in-house teams building this for the first time hit that plateau around the one-year mark, right when the initial excitement of "we built this ourselves" runs into the reality that the next accuracy gain costs as much engineering time as the entire first version did.

flowparse.io

Opportunity cost: what the team could be building instead

The dollar figures above are only half the argument. The other half is what an engineering team spends its time on instead of OCR maintenance: policy-rule engines, approval workflows, integrations with accounting systems, mobile UX, analytics — the parts of an expense platform that actually differentiate it from a competitor. Receipt OCR, however well executed, is rarely the reason a customer chooses one spend platform over another; it's table stakes, expected to simply work.

Spending a senior engineer's year on a capability that's functionally identical to what a €0.035-per-page API already provides is, in most cases, time not spent on the capability a customer would actually notice and value.

A composite example: two years of an in-house build

Composite, not a single named company — this pattern shows up consistently enough across conversations with expense-platform engineering teams to be worth walking through concretely. A Series A expense-management startup hires a founding ML engineer specifically to build receipt OCR, six months before their Series B fundraise. Months one through four go into data labeling and a first model; months five and six into a review UI once real users start hitting cases the model handles badly. The team ships a v1 around month seven, roughly on the low end of the $120K–$160K range for a lean, one-person build.

Month nine, international expansion adds receipts in three new languages the training set barely covered — accuracy on that segment lands around 60%, well below what launched originally. Month fourteen, a major bank redesigns its statement layout and the extraction pipeline's statement path breaks silently for two weeks before anyone notices the reconciliation numbers look wrong. By month eighteen, the original ML engineer is spending roughly 60% of their time on maintenance rather than new capability, and the company is quietly recruiting a second person to help carry the load — the unplanned second year of the $40K–$70K annual maintenance figure, arriving exactly as the earlier sections of this article predicted.

None of this reflects poor execution. It reflects the actual shape of the problem: a receipt-OCR pipeline doesn't stay solved once it's built, and the ongoing cost of keeping it solved is the part almost every team underestimates at the start.

The vendor landscape: Veryfi, Textract, Document AI, FlowParse

Buying instead of building doesn't mean there's only one option. Four vendors come up consistently in this evaluation, each with a genuinely different shape:

Pricing models compared, side by side

Published third-party pricing changes over time and varies by contract and volume — treat these as approximate, directional figures for comparison rather than a quote, and confirm current numbers directly with each vendor before budgeting.

When building in-house genuinely still makes sense

This isn't a universal argument against ever building OCR in-house. A handful of situations still favor it: a company whose actual product IS document AI, where extraction quality is the core differentiator rather than a supporting feature; a genuinely unusual document type no vendor supports well; or a regulatory environment that specifically prohibits sending documents to a third-party processor at all. Outside those cases, the economics in this article apply to most expense-management and spend-platform companies.

The case for a flat, page-based rate specifically

Beyond the build-vs-buy question, the specific pricing model of the vendor you choose matters for budgeting. A per-receipt rate that varies by plan tier, or a per-page rate that varies by document complexity, reintroduces exactly the estimation uncertainty that made the in-house cost hard to forecast in the first place. A flat rate — the same figure for a receipt, a statement or an invoice, at any volume — is what actually restores the predictability a finance team needs to approve a budget line with confidence. The feature page on flat-rate per-page pricing covers the mechanics of this in full.

What a real migration away from in-house OCR looks like

Teams migrating off an already-working in-house pipeline rarely do it in one cutover. The common pattern: run the new API in parallel against a sample of live traffic, compare extracted fields against the in-house pipeline's output on the same documents, and once accuracy is confirmed equal or better, redirect new traffic while letting the in-house system wind down rather than ripping it out immediately. The guide how to embed receipt OCR in an expense app covers the technical integration steps this migration follows.

A decision framework you can actually use

A worked comparison at three volume tiers

The in-house build cost is largely fixed regardless of volume — it doesn't meaningfully change whether you're processing 10,800 pages a month or 1.8 million. That's exactly why the comparison favors buying most heavily for earlier-stage companies, where the fixed build cost is a far larger fraction of a smaller total budget — and why even at meaningful scale, the API cost often stays well under the annual maintenance line alone of an in-house alternative.

Worth noting explicitly: these figures assume a single flat rate applies uniformly, which is specifically true for FlowParse's pricing model and not necessarily true of every vendor — a per-receipt vendor with volume-tiered pricing can look cheaper at low volume and more expensive at high volume than the numbers above suggest, so a real comparison should always be run against the specific vendor's current published rates at your actual expected volume, not against a generic industry figure.

The honest counterargument: vendor lock-in risk

A fair objection to all of this: depending on a third-party API for a core piece of product functionality creates a dependency you don't fully control. If a vendor raises prices, degrades service, or shuts down, an integration built entirely around their specific response shape can be expensive to migrate away from on short notice. This is a real risk, not a strawman, and worth naming directly rather than glossing over.

How to mitigate that risk without building in-house

An underrated factor: what your ML team actually wants to work on

Rarely discussed in a cost spreadsheet, but real: maintaining a receipt-OCR pipeline is not, for most ML engineers, the most interesting problem available to them. It's a solved-shape problem with a long tail of unglamorous edge cases — the kind of work that's easy to lose good people over if it becomes their entire job. Redirecting that talent toward a problem more specific to your product tends to be better for retention as well as for the roadmap.

How this decision reads to an investor or board

Engineering decisions rarely make it into a board deck directly, but this one has a way of surfacing there anyway — usually as a line item in burn-rate review, or as a question about why a "done" feature keeps consuming engineering time a year after it shipped. An investor who has seen this pattern across a portfolio tends to react well to a team that made a deliberate, numbers-backed decision to buy rather than build a commodity capability, and reacts less well to discovering a team is quietly staffing an OCR-maintenance function that was never on any roadmap presented to them.

Framed this way, the build-vs-buy decision in this article isn't just an engineering-efficiency question — it's a capital-efficiency one, and it's one of the more legible examples of that tradeoff a technical founder can point to when explaining how the team allocates its scarcest resource.

The short version

Building receipt-and-statement OCR in-house is a genuine, expensive, ongoing engineering commitment — commonly $120,000–$160,000 to reach a usable v1, and $40,000–$70,000 a year after that just to maintain it. For most expense-management and spend-platform companies, that money and that engineering time buys more value spent on the product's actual differentiators, with a flat per-page API handling the extraction layer underneath.

Frequently asked questions

Keep reading