Of all the feature quotes we send, OCR is the one that most often comes back with a question attached. Founders have seen a cloud provider charge fractions of a penny per page and reasonably conclude that document scanning is close to free. The reading is close to free. The feature is not. For a UK app in 2026, the cost to add OCR scanning lands around £3,000 to £8,000 if you are reading one predictable document type, and around £15,000 to £30,000 if you are building something that handles real documents from real users. This is what sits in between.
The short version of the gap: OCR gives you characters, and your product needs facts. Turning the first into the second, reliably enough that a user trusts the result, is the entire project.
What does it cost to add OCR scanning?
Adding OCR scanning to a UK app costs roughly £3,000 to £8,000 for a narrow case, meaning one document type with a consistent layout, a hosted extraction service, and a user who is willing to check the result. A pipeline handling several document types, with confidence thresholds, correction screens and a human review queue, costs roughly £15,000 to £30,000. On top of either sits a per page API bill that is usually the smallest line in the budget.
The range is wide because “add OCR” describes two different ambitions. One is a convenience feature that saves a user some typing and is allowed to be wrong. The other is an automation feature that replaces a person, and is not.
The three tiers, and what separates them
Tier one: read the text. The user photographs something, you extract the characters, you drop them into a field they can edit. A receipt total, a business card, a serial number, a passport machine readable zone. The layout is predictable or the target is a single obvious string. One hosted API call, one parsing rule, one editable result. This is the £3,000 to £8,000 band and it is genuinely achievable in two to three weeks.
The work that is not obvious even here: image capture is a feature of its own. Users photograph documents at an angle, in bad light, with a thumb over the corner, and the difference between a 70 percent success rate and a 95 percent one is mostly guidance in the camera view, edge detection, deskewing and a retake prompt, not a better model. Budget real time for the capture experience. It is where the quality comes from.
Tier two: understand the structure. Now you want the line items from an invoice, the columns from a statement, the labelled fields from a form. Plain text extraction cannot do this, because a table rendered as a stream of characters has lost the thing that made it a table. You need structured extraction, which the major providers price separately and considerably higher, or a document model you have configured for your layouts.
This is where most budgets break, because structure varies. Twenty suppliers issue twenty invoice layouts. Your extraction has to survive all of them, and each new layout that fails is a support ticket.
Tier three: trust the result. The third tier is not a technical capability, it is an accuracy guarantee, and it is the expensive one. If a number from a scanned document is going to post to an account, trigger a payment, or fill a regulatory return without a person looking at it, you need confidence scores per field, thresholds that route low confidence results to review, a queue for a human to correct them, an audit trail of what was changed, and a feedback path so corrections improve the next run. That is a small internal product, and it is why the top of the range reaches £30,000.
Side by side
| Dimension | Read the text | Understand the structure | Trust the result |
|---|---|---|---|
| Build cost (UK 2026) | £3,000 to £8,000 | £9,000 to £18,000 | £15,000 to £30,000 |
| Typical timeline | 2 to 3 weeks | 4 to 8 weeks | 8 to 14 weeks |
| Document variety | One fixed type | Several known layouts | Anything a user sends |
| Who catches errors | The user, in an editable field | The user, with fields pre-filled | A review queue, before anything posts |
| API cost per page | Lowest tier | Higher structured tier | Higher tier plus reprocessing |
| Ongoing work | Almost none | New layouts as they appear | Review staffing and model tuning |
| Best for | Receipts, cards, serial numbers | Invoices, statements, forms | Onboarding, claims, compliance records |
The API bill is not the problem
Worth stating plainly, because it is the number founders anchor on and it is the wrong one. On Amazon Textract’s published pricing, plain text extraction runs at a fraction of a penny per page in US regions, while structured form and table extraction is priced per page at a rate that is tens of times higher but still measured in pennies. Google prices Cloud Vision per thousand units with a small free monthly allowance. Check both at the time you scope, because these prices move and regional rates differ.
Do the arithmetic on your own volumes before you worry about them. An app processing ten thousand pages a month of plain text extraction is spending a sum you would not notice on an expenses claim. The same app spending three months of engineering time on a correction interface has spent forty times that before it ships a single page.
Two caveats that can change the picture. Structured extraction on high volume genuinely adds up, so if you are processing hundreds of thousands of pages a month, model it properly. And reprocessing is real: every retry after a failed capture, every document run twice because a threshold was tightened, is another billable page. Neither turns the API into the dominant cost for most products, but both belong in the spreadsheet.
The same pattern shows up in our breakdown of what it costs to add file uploads and document handling, where the storage is cheap and the system around it is not. Features that lean on a metered service are almost always priced by the software you write around the meter.
Accuracy is the real cost driver
Here is the number that decides your budget, and it is not a price. It is the accuracy you need.
Modern OCR on a clean printed page is very good at characters. Field level accuracy on real user photographs of real documents is a different measure, and it is the one that matters, because your product cares whether the total was read correctly, not whether 98 percent of the characters on the page were. Handwriting, faded thermal receipts, phone photographs at an angle, stamps and overlapping text all pull that number down.
Now translate accuracy into build cost. At 95 percent field accuracy, one field in twenty is wrong. If the user sees the result and can correct it, that is a mild annoyance and costs you a good editing screen. If nobody sees it, one transaction in twenty is wrong, and you have built a machine that generates errors at scale. Closing that gap is not a better API, it is confidence thresholds, a review queue, and a person. Decide which side of that line your feature sits on before anyone quotes it, because it is the single largest swing factor in the price.
The honest framing we give clients: OCR does not remove the human, it moves them. Instead of typing every document, someone checks the exceptions. That is a genuine and often large saving, and it is a different promise from full automation. The same distinction runs through our guide to where UK founders go wrong with AI features.
Scanning identity documents changes what your app is
If the documents being scanned are identity documents, the compliance position shifts and the budget shifts with it.
An image of a passport or driving licence is high risk personal data in its own right. It is not automatically special category data. But the moment you compare the face on that document to a selfie to confirm the same person, you are processing biometric data for the purpose of unique identification, which is special category data under Article 9 of the UK GDPR. The ICO’s biometric recognition guidance sets out the consequences: you need an Article 6 lawful basis and a separate Article 9 condition, explicit consent is usually the realistic one, and a Data Protection Impact Assessment is very likely required.
Three build costs follow. You need a retention rule that deletes the document image once verification is complete, because keeping identity scans indefinitely is the most common finding in this area and the easiest to avoid. You need deletion that reaches the file, every derived thumbnail, every cached copy at the extraction provider, and your backups. And you need to know where processing happens, because sending an identity document to a service in another jurisdiction is a transfer decision you will be asked about by every enterprise customer you ever sell to.
For most consumer products the sensible answer is to use a regulated identity verification provider rather than build this yourself. They carry the compliance surface, and the per check price will almost certainly be less than the cost of getting it wrong once. Our write up on GDPR in a UK consumer app covers the wider set of decisions this sits inside.
When you should not build it
The section that saves people money.
If the data already exists in a system you can connect to, connect to it. Bank feeds beat scanning statements. Supplier portals beat scanning invoices. A payroll integration beats reading payslips. Scanning is what you do when there is no API, and a surprising number of projects reach for OCR before checking whether an API exists.
If the volume is low, do the maths on the manual alternative honestly. Fifty documents a month is about an hour of someone’s time. A £20,000 pipeline to save that hour takes many years to pay back, and meanwhile it is code you maintain.
And if the user has to check every result anyway, ask what OCR is actually buying. Sometimes the answer is a lot: pre-filling nine fields out of ten is a real improvement even when the tenth needs a correction. Sometimes the answer is that a well designed form with sensible defaults would have been faster than photographing a document and fixing what came back.
The test we apply: does OCR remove a step, or does it move the step somewhere less visible? Only the first is worth the build. This is the same scoping discipline that keeps a project predictable in what an app costs to build in the UK in 2026.
What to do next
The cost to add OCR scanning is decided by one question, and it is not which provider you pick. It is whether a wrong answer is allowed to reach a user unchecked. If it is, you are building an editable field with a helpful pre-fill, and £3,000 to £8,000 is a realistic number. If it is not, you are building a review pipeline with confidence thresholds and a human in the loop, and £15,000 to £30,000 is a realistic number. Price the capture experience properly either way, because it does more for your accuracy than any model choice. And if identity documents are involved, price a compliance review in from the start rather than discovering it during a security questionnaire.
If you want a straight number for your own documents, including whether an existing API would remove the need to scan anything at all, send us a project brief and we will scope it with the review cost shown rather than hidden.
.webp)
.webp)


