Every company verification starts the same way. A document arrives — a certificate of incorporation, a register extract, a set of articles — and somebody opens it, finds the registration number, checks the directors against a second document, and types the result into a third system.
We have done this several hundred times. It is not difficult work. It is repetitive, and repetitive work performed under time pressure is where errors come from.
This article sets out what document intelligence can realistically take off that person's desk, and, just as importantly, what it should not.
What "document intelligence" actually means here
The term gets used loosely, so it is worth being precise. In the context of company verification, document intelligence means a pipeline that takes an unstructured document and produces structured, checkable data. It usually has these stages:
- Ingestion. Accept the file, normalise it, and make it machine-readable. Scanned documents need OCR; digitally generated PDFs often carry a text layer already.
- Classification. Decide what the document is. A certificate of incorporation and a confirmation statement contain different fields and warrant different handling.
- Extraction. Pull the specific values that matter: company name, registration number, incorporation date, registered office, directors, beneficial owners.
- Scoring. Attach a confidence value to each extracted field.
- Referencing. Record where in the document each value came from, down to the page.
- Review. Put the result in front of a person, with the low-confidence fields flagged.
The first five stages are automation. The sixth is the one that makes the other five safe.
Why classification comes before extraction
A common mistake is to build one extractor and point it at everything. It works in a demo and degrades badly in production, because the same words mean different things in different documents.
"Date of incorporation" on a certificate is a fact about the company. A date in the header of a register extract is the date the extract was produced. An extractor that does not know which document it is reading will happily confuse the two, and it will do so confidently.
Classifying first lets you apply a narrower, better-specified extraction pass per document type. It also gives you a useful failure mode: if the classifier cannot identify the document, the correct behaviour is to stop and ask a person, not to guess.
Confidence scores are only useful if they change behaviour
Attaching a confidence score to an extracted field is easy. Making it mean something is harder.
A score is only worth computing if it routes the work. In practice that means picking thresholds and committing to them:
- High confidence — the value populates the record, and the reviewer sees it pre-filled.
- Medium confidence — the value is shown, but flagged, and the reviewer must confirm it before it is accepted.
- Low confidence, or nothing extracted — the field stays empty and is routed for manual entry.
If every field lands in the same queue regardless of score, the score is decoration.
Source references are what make review fast
The single feature that most improves a reviewer's speed is not better extraction accuracy. It is showing them where the value came from.
A reviewer presented with "Registration number: 15104126" has to go and find that number in the document to trust it. A reviewer presented with the same value, plus a link to page 1 with the relevant region highlighted, can confirm it in about a second.
This changes the economics of the whole pipeline. It means an 85%-accurate extractor with good source references can be more useful than a 95%-accurate extractor without them, because the reviewer's cost of checking is so much lower.
Discrepancy detection is where the real value is
The tasks above speed up an existing process. Discrepancy detection does something the manual process does badly.
When you hold several documents about the same company, you can compare them against each other:
- Does the company name on the register extract match the name in the articles?
- Does the director list match across both documents?
- Does the registered office in the most recent filing match the one on file?
- Does the registration number match the official register?
A person doing this by hand, across four documents, at the end of a working day, will miss things. A system that does it every time does not get tired. This is the part of the pipeline that finds problems rather than just processing faster.
What should not be automated
Some steps should stay with a person, and it is worth saying why rather than treating it as a hedge.
The final accept decision. An extraction pipeline produces evidence. Whether that evidence is sufficient is a judgement call with consequences, and it should have a named human attached to it.
Anything that looks unusual. Automation is good at the common case. The value of a human reviewer is precisely in the uncommon one — the document that does not fit the template, the name that is nearly but not exactly right, the date that is technically valid but implausible.
Anything the system is not confident about. This sounds obvious, and systems break it constantly by treating a low-confidence extraction as a value rather than as a question.
The design principle we work to is simple: automation reduces the amount of reading a person has to do; it does not reduce the number of decisions a person has to make.
Where this sits at Dorsko
Dorsko is developing document-intelligence workflows under the name DorskoVerify. It is in development and not available to customers, and the capabilities described above are the design targets rather than shipped features.
The reason we are building it is straightforward: we ran the manual version of this process often enough, across enough jurisdictions, to know exactly which parts of it are worth encoding — and which parts should stay exactly where they are, with a person looking at them.