GuidesBuying guide8 min read

Build or buy document extraction

When a vendor API is obviously right, when it obviously isn't, and the three questions that decide it. Most teams get this backwards in both directions.

Written for

Do we use a vendor or build our own? Getting this wrong costs a quarter.

We sell building. You should still buy in most of the cases below, and it is worth saying so plainly, because the wrong choice here costs a quarter in either direction.

Three questions that decide it

1. Is your document type standard?

Invoices, receipts, passports, driving licences, W-2s, common bank statements — these are solved. Several vendors have spent years and enormous document volumes on exactly these, and you will not beat them from a standing start.

If your documents are industry-specific — assay reports, shipping manifests, clinical notes, insurance schedules, bespoke supplier formats — vendor accuracy drops sharply, because your documents were not in their training distribution.

Buy where your documents are somebody else's core business. Build where they are yours.

2. Is the extraction the product, or plumbing?

If extraction is a step on the way to the thing you sell, buy it. Your differentiation is downstream, and every week spent on OCR is a week not spent on the part customers pay for.

If the accuracy of the extraction is the product — if customers choose you because you get this right where others do not — then it is your core competency and outsourcing it is outsourcing your moat.

3. What happens when it is wrong?

This is the question that actually decides it, and the one most often skipped.

Vendor APIs return a value and a confidence score. What they do not give you is control over what happens next: the review queue, the routing rules, the audit trail, the ability to explain a specific decision to a regulator eighteen months later.

If wrong answers are cheap — a person spots it, fixes it, moves on — buy. If wrong answers are expensive or must be defensible, you will end up building the surrounding system anyway, and at that point the extraction call is the small part.

The hybrid nobody talks about

The most common good answer is not either.

Use a vendor for the document types it handles well. Build for the ones it does not. Own the confidence scoring, routing, review queue and audit trail regardless — because that layer is yours, it is where the actual product value sits, and it means you can swap the extraction engine later without rewriting anything.

This also gives you a genuine migration path: start entirely on the vendor, keep the surrounding system yours, and replace the engine per document type as volume justifies it.

The cost crossover, honestly

Vendor pricing is typically per page and looks trivial at pilot volume. It stops looking trivial somewhere in the tens of thousands of pages per month.

But do not let cost alone drive this. A build has a large fixed cost and an ongoing maintenance cost that people systematically underestimate — document formats change, and somebody has to notice and respond. Switching to save subscription fees while adding a permanent maintenance obligation is often a bad trade.

Switch when accuracy on your documents justifies it, and treat the cost saving as a bonus rather than the reason.

A short decision procedure

  1. Are the documents standard? → Buy, and stop reading.
  2. Is extraction accuracy your differentiator? → Build.
  3. Do wrong answers have to be defensible? → Own the surrounding system at minimum, whichever engine you use.
  4. Otherwise → Buy the engine, build the layer around it.

Related: OCR vs LLM extraction · what an AI feature costs

Recognise this

the audit is the cheapest way to find out for certain.