Documents and data entry

In many offices there is a person — often more than one — whose daily work is to look at a document and retype its contents somewhere else: invoices into the accounts system, orders into the warehouse, forms into the CRM, expense receipts into the monthly spreadsheet. It is the work that automates best today, and the work where a retyping error costs most.

What the system does

It reads the incoming document — PDF, scan, photograph, email attachment — and extracts the data you need in structured form: headers, line items, amounts, dates, references. It then verifies the data and enters it where it has to go, in the format your system expects. Three properties set it apart from traditional OCR:

• It tolerates varying layouts. A language model does not need every supplier's invoice to be laid out the same way: it finds the data even when the document changes shape, which is exactly where template-based systems break down.
• It checks before it writes. Every extraction passes consistency checks: totals must reconcile with the lines, codes must exist, dates must be plausible. Data that fails the checks does not enter your system: it goes to a person, with the original document alongside.
• It leaves a trail. For every document there is a record of what was read, what was written and who approved the doubtful cases. If a figure looks odd six months later, you trace it back to the document in a minute.

Typical cases

• Purchase cycle: supplier invoices and delivery notes posted to the accounts system, reconciled against orders.
• Incoming orders: orders arriving by email or PDF in assorted formats, turned into lines ready for the warehouse system.
• Forms and applications: client or user requests — registrations, applications, complaints — converted from paper or PDF into workable records.
• Expenses and receipts: receipts matched to trips and filed under the right headings.

What suits this well, and what does not

Recurring flows with verifiable data suit it well: where a total has to add up, or a code has to exist in a master record, the system can check itself and the human review rate falls week by week. It suits badly the documents where data has to be interpreted rather than read — an unusual contract, an expert report, a letter — and flows so small the project never pays for itself. Both get said at the analysis stage, not afterwards.

Frequently asked questions

Does it work with scanned or photographed documents?

In most cases, yes: current models read ordinary-quality scans and photographs well, stamps and annotations included. Cursive handwriting and degraded scans remain the least certain ground: they are measured on your real sample during the prototype, not promised sight unseen.

Our management software has no API — is it still possible?

Almost always. Where no integration interface exists, the route runs through the import formats the software already accepts, through its database where the vendor permits it, or as a last resort through automation of the user interface. These routes differ in robustness, and the choice is made deliberately at the analysis stage.

How many documents do we need to get started?

A representative sample is enough for the prototype: a few dozen documents covering your most frequent suppliers or forms, plus the anomalies you remember. Nothing special needs preparing — what is needed is the documents as they actually arrive, ugly ones included.

Who notices the errors?

The system first: every extracted document passes consistency checks — totals that must add up, valid VAT numbers, plausible dates, comparison with history — and whatever fails them lands in a review queue with the original document alongside. The goal is not infallibility: it is that errors surface before they enter your systems, rather than at year end.