Build or Buy Document Data Extraction? The 2026 Math

Buy, unless you process more than roughly half a million pages a month or a contract forbids documents leaving your network. Below that volume the arithmetic is not close: a GPU capable of running an open document model costs $587.50 a month on AWS and bills every hour whether it reads a page or not, so at 50,000 pages a month it works out to $11.75 per 1,000 pages against $1.50 from a managed API.

That is the short version, and it surprises people because the model itself is free. The confusion comes from comparing the wrong two things. The published cost of an open OCR model is what a saturated GPU fleet costs per page. What you will actually pay is that same fixed monthly bill divided by the pages you genuinely run, which for most finance and operations teams is a much smaller number on the bottom of the fraction.

Below is how to run the decision properly, with the real 2026 rates on both sides.

What does it cost to build document data extraction in house?

Four things, and only the first one shows up in most estimates.

The GPU line is the one worth internalizing. AWS charges $0.8048 an hour for a g6.xlarge with a single NVIDIA L4, which is the cheapest card that comfortably runs a small document vision model. At 730 hours a month that is $587.50, and it arrives on the invoice in a month where you processed nothing at all. A per-page API charges zero that month. That asymmetry, not the model license, is what decides build against buy.

What is the break-even volume?

About 391,700 pages a month against the $1.50 per 1,000 pages that AWS Textract Detect Document Text, Azure AI Document Intelligence Read and Google Enterprise Document OCR all charge. That is the point where a $587.50 monthly bill equals what the API would have billed for the same work.

Read the break-even row carefully. It is the point where the hardware alone matches the API, with nobody paid to operate it. Add one engineer's partial attention and the real crossing point moves well past a million pages a month. The full per-card version of this table, including A10G, L40S, A100 and H100 instances, is on our self hosted OCR cost reference.

Has the cost advantage of open models changed?

Yes, dramatically, and this is the part most build-versus-buy discussions have not caught up with. The olmOCR paper, the most cited source on open OCR economics, compared $176 per million pages against $6,240 per million for GPT-4o. A 35 times gap is a compelling reason to build something.

That gap has closed from the other side. GPT-5.4-nano reads a scanned letter page for about $1.67 per 1,000 pages at list, and roughly $0.84 through the Batch API, which is $840 per million. Against the paper's $176 that is 4.8 times, and against the same throughput repriced at AWS on-demand rates it is about 1.9 times. A saving under two times does not usually survive one engineer's salary. We worked the whole comparison through on the olmOCR pricing page.

What do you actually have to build, beyond the model?

This is where estimates go wrong by the largest margin, because the model is the interesting part and the rest is the work.

• Classification. Real mail arrives mixed. Something has to decide that page 4 starts a new document and that this one is a remittance advice rather than an invoice.
• Field extraction, not text. Open models return the page as clean text and markdown. Turning that into an invoice number, a total and a due date is a second system, and it is the one that breaks on a layout it has not seen.
• Per-field confidence. Managed APIs return a confidence value per field so you can route the doubtful ones. Open models return a string with no signal about which parts to trust. Building that signal is the single largest hidden line item.
• A review queue. Somewhere a person fixes what the model got wrong, with permissions, an audit trail and an export. Every production pipeline needs this and nobody budgets for it.
• Operations. Someone keeps the inference server patched, sizes the batch, handles the out-of-memory error at 2am and re-benchmarks every time a better model ships. Six credible open document models arrived in a single quarter recently, so this is not a one-time cost.

None of that is exotic engineering. It is just months of it, and it is months spent on infrastructure rather than on whatever your company actually sells. Teams that already provision and operate their own servers as a matter of course absorb this far more easily than teams reaching for their first GPU instance, which is a genuine input to the decision rather than a dodge.

When is building genuinely the right call?

There are real cases, and they are narrower than the enthusiasm suggests.

• Documents cannot leave your network. When a contract, a regulator or a classification level says so, price stops being the question. That decision is laid out in full on our on premise OCR software page, including which vendors actually ship something you can run yourself.
• Very large, sustained, predictable volume. Millions of pages a month with a solid floor, not a projection.
• Plain page-to-text. Converting a static corpus for search or training, where you need reading order and not fields. This is exactly what open models were built for and they are excellent at it.
• You already run GPU inference. If the cluster and the on-call rotation exist for another workload, the marginal cost of adding OCR is scheduling, and most of this article stops applying.

When should you buy instead?

Buy when volume is under a few hundred thousand pages a month, when it is spiky rather than steady, when you need structured fields with confidence rather than a wall of text, and when the engineering hours would otherwise go into your own product. That covers the large majority of accounts payable, lending, insurance and back-office teams.

It is worth being straight about where a document processing product sits on the same scale. DocuOCR runs about $14 to $20 per 1,000 pages depending on plan, which is more than a raw cloud OCR call and far more than a saturated GPU. What it covers is the entire third bullet list above, already built and already running: classification, field-level extraction with confidence values, validation rules, a review queue for the pages that fail them, and export. Comparing that against a text API on price alone compares two different products, which is the same mistake as comparing a free model against a managed service.

How to actually decide, in an afternoon

Write down four numbers before you write any code. The pages you processed last month, not the forecast. The floor across the last twelve months. Whether you need fields or text. And whether anything in a signed agreement prevents a vendor from touching the documents.

If the volume floor is under 400,000 pages and nothing forbids a vendor, buy, and spend the saved quarter on something your customers will notice. If it is over a million and steady and you need text rather than fields, building is defensible and the numbers above tell you what it will cost. Everything in between is a judgment call that turns on how much operational appetite your team has, which is the one variable no article can size for you.

The fastest way to make it concrete is to run your own documents through a managed product first, look at the fields and the confidence scores, and use that as the specification for what you would otherwise be building. Extract a document free and compare it against what an open model returns on the same page. If the gap is small and your volume is enormous, build. Most of the time it is neither.