Intelligent document processing UK buyers have a genuinely better market than they did two years ago: commercial extraction products now handle invoices, purchase orders and standard forms well enough that building your own would be wasteful. The decision has therefore moved. It is no longer whether the technology works, it is whether your documents look like the ones the products were built for. For expert-led businesses, they often do not.

Part of our guide to custom software development.

What off-the-shelf products do well

High-volume, standardised document types with a common structure and a well-understood set of fields. Invoices are the canonical case: millions of examples, a small stable field set, and a clear right answer. The same applies to purchase orders, delivery notes, standard application forms and identity documents. If your process is dominated by documents like these, buy. Configuration will take days, accuracy will be high, and the ongoing cost is a subscription rather than a maintenance liability.

Modern products also handle moderate variation in layout well, so the old objection that every supplier's invoice looks different has largely dissolved.

Where they struggle, and why it matters to specialists

Four situations reliably defeat generic tools. Documents where meaning depends on domain context: a test certificate where whether a result passes depends on which standard applies and which revision of it. Documents where the extraction is really an assessment: pulling the effective obligations out of a contract or a consent, which is judgement wearing the costume of data entry. Long technical documents where the field you want appears in different sections with different phrasing, so position offers no help. And documents where the required output is not a set of fields at all but a comparison, such as whether this revision differs materially from the last.

Expert-led businesses run on exactly these document types: specifications, standards, test reports, survey records, regulatory submissions and consents. That is why the generic evaluation so often ends at a promising demo and a disappointing pilot, a pattern we have written about in why generic platforms fall short.

The honest build-or-buy test

Run the products against fifty of your real documents, deliberately including the awkward ones, and score field-level accuracy yourself rather than accepting a vendor summary. Set acceptance criteria for each critical field before comparing products. Include the cost of wrong or missed values, the required human review and the full cost of running the workflow. Choose a product if it meets those criteria on representative documents. If it does not, inspect the errors before deciding whether configuration, a custom layer or a different approach is needed. A low average score alone does not establish that a full custom build is the right choice.

Weigh the ongoing cost honestly on both sides. A subscription priced per page can become the dominant cost at volume, while a custom system trades that for a maintenance obligation that never quite disappears. Neither is free.

What a custom build looks like

Less exotic than it sounds. Commercial models do the reading; the custom work is the domain layer around them: your document taxonomy, your validation rules, the standards and thresholds that decide whether an extracted value is acceptable, and a review interface where a specialist corrects the small proportion of cases the system is unsure about. Those corrections should feed back so the system improves rather than repeating the same misreads. Our property document AI work followed that shape, and the differentiator was the domain rules rather than the extraction.

Where the process is repeatable and the bottleneck is document handling rather than judgement, that is our AI Workflow Automation work: the extraction, the checks and the exception routing built into the process you already run, without a platform migration. The wider view of what we build for document-heavy operations sits on our document-heavy operations page.

Frequently asked questions

How accurate is intelligent document processing?

There is no single accuracy figure that applies across products and document types. Measure each critical field on representative documents against a checked reference. Record missed values and review effort as well as incorrect values. A model's confidence score is not the same as accuracy measured on that test.

Should we build or buy document processing?

Test candidate products on representative documents, including difficult cases, and score each critical field against a checked reference. Compare error types, review effort and the whole cost of running the workflow. Investigate failed criteria before choosing configuration, a custom layer or a full build. High overall accuracy does not by itself establish that critical fields are safe to use without review.

Can AI check documents as well as extract from them?

Yes, and checking is often the larger prize. Comparing extracted values against limits, standards or previous revisions catches the errors that cost money, and it has a verifiable right answer. Businesses frequently underestimate checking because extraction is the more familiar pitch.

What about confidential client documents?

Ask any supplier where documents are processed, how long they are retained, and whether their contents may be used to improve a shared model. For sensitive or personal material a system that processes within your own infrastructure removes the question entirely, and that requirement alone sometimes decides build over buy.

Need the software built, not just scoped?

Custom Software Development delivers the copilot, dashboard or portal your team uses daily, built for your domain in 8–12 weeks and then maintained. Scoping from £5,000.

See the custom software service Talk to a co-founder →

Not sure where AI fits in your business?

The AI Opportunity Finder maps your highest-value starting point in a few minutes, with no sales call required.

Find your best starting point