Layer 01 — data and ingestion

Every automation on this site starts the same way. A document arrives, and something has to read it.

An invoice as an email attachment. A delivery note photographed in a yard. A tenancy agreement scanned by whoever was nearest the machine. Before a model can reason about any of it, the words, the numbers and the structure have to come off the page and land somewhere a system can use. This is the part nobody demonstrates, because it is the part that breaks — and it is where most of the work in a document project actually is.

Talk through your documents The whole stack

LayerData & ingestion · Systems of recordthe whole stack

What actually happens

Five things happen to a document between arriving and being usable.

These run in order, and each one can fail on its own terms. Most projects that disappoint have skipped the last two, because the first three are the ones that demonstrate well.

Reading the characters, then reading the layout

OCR, layout-aware extraction, bounding boxes, key-value pairing

OCR — optical character recognition — turns the marks on a page into characters. It answers one question only: what does this say? It hands back text, usually in reading order, and it has no idea that the number in the bottom right is a total rather than a page count. Layout-aware extraction is the second, harder step: it looks at where each piece of text sits on the page and what it sits near. Every fragment carries a bounding box — the four coordinates of the rectangle it occupies — so the system can say that this string is directly to the right of the words Invoice Number, that these figures form a column, and that this block is inside the header rather than the body. That spatial reading is what turns loose text into key-value pairs a system can post. OCR alone gives you a transcript. Layout-aware extraction gives you fields.

You get a wall of correct characters in roughly the wrong order, and someone downstream writes a hundred fragile string rules to guess which number was the total — rules that break the first time a supplier moves their address block.

Tables, which are the hardest common case

Row and column detection, merged and spanning cells, multi-page continuation, line-item extraction

A header field appears once and sits in a predictable region. A table is a structure, and the structure is often implied rather than drawn. Rows may be separated by white space instead of rules. One description wraps onto three lines while the quantity beside it does not, so the naive reading produces three rows where there is one. Cells merge and span. A table continues across a page break, and the second page repeats the column headers — or does not. Sub-totals sit inside the body and look exactly like line items. Getting tables right means detecting the grid, assigning every fragment to a cell, deciding what is a continuation and what is a new row, and then knowing which rows are data and which are arithmetic. This is where most of the engineering time in a document project goes, and it is almost never what the demonstration shows.

Header fields are right, the document looks processed, and the line items are quietly wrong — a quantity attached to the wrong description, a wrapped row counted twice. It reconciles at the total and fails at the detail, which is the expensive way round.

Handwriting, stamps and bad photographs

Handwriting recognition, deskew and dewarp, occlusion, glare and low-contrast capture

Printed text on a flat scan is the easy case, and it is not the case most operations actually have. A delivery note is photographed on a phone at an angle, in a yard, in the rain. The page curves, so straight lines are not straight — dewarping flattens that, deskewing rotates it back to square, and both are guesses that can be wrong. A rubber stamp lands across a figure: that is occlusion, and no amount of model quality recovers characters that are physically not visible. Handwriting is a separate problem from print, and a legitimately harder one. Block capitals in a boxed form are close to reliable. Cursive in a free-text field, written quickly by someone holding a clipboard, is not, and any supplier who tells you otherwise has not tried it on your documents. The honest engineering answer to bad capture is usually upstream: better capture beats better models, every time.

The system reads what it can and silently invents the rest, because a model asked to produce a number will produce a number. A partially obscured figure comes back plausible and wrong, and nothing in the output distinguishes it from a figure that was read cleanly.

Confidence scores, and where the human threshold sits

Per-field confidence, thresholding, human-in-the-loop review queues, straight-through processing rate

A confidence score is the extraction system's own estimate, per field, of how likely it is to be right — not a guarantee, and not a probability you should treat as exact. What makes it useful is that it can be thresholded. Above the line, the field passes straight through. Below it, the document goes to a review queue where a person sees the page, the extracted value and the box it came from, and corrects or confirms in a few seconds. That is human-in-the-loop: not a person checking everything, and not a person checking nothing, but a person seeing exactly the cases the machine is unsure about. Where you set the threshold is a business decision, not a technical one. Set it high and more work reaches a human, which costs time but catches more. Set it low and more passes untouched, which is cheaper until the day it is not. The threshold also belongs per field: a supplier name read imperfectly is an annoyance, a bank account number read imperfectly is a fraud incident, and they should not share a line.

Everything is treated as equally trustworthy, so either a person re-keys work the machine did perfectly well or errors post straight into the ledger with nothing marking them as doubtful. Both outcomes destroy trust in the system, and the second one does it quietly.

Reconciliation against the system of record

Matching to the ERP or finance system, purchase-order and goods-receipt matching, tolerance rules, exception codes

Extraction produces a claim about what a document says. Reconciliation asks whether that claim agrees with what you already know. The supplier name is matched to a real account, not accepted as typed. The purchase order number is looked up, and the quantities and prices are compared against what was ordered and what was received, within whatever tolerance the business allows. The line items are summed and checked against the stated total. Dates are checked for being possible. This step is where most genuine errors are caught, because your own records are a far stronger check on a document than the document is on itself — and it is the step that turns an extraction tool into something the finance team will actually let near the ledger. Where a match fails, the right output is not a correction but a named exception: this invoice references a purchase order that does not exist, and here is the page it came from.

A well-read document is posted against the wrong account, or a duplicate invoice is processed twice because nothing looked. The extraction was accurate and the outcome was still wrong, which is the failure mode nobody budgets for.

Worked cases

Two awkward documents, followed all the way through.

Both start with something a demonstration would not choose: a photograph taken outdoors, and a supplier who has never sent the same layout twice.

Logistics

A signed delivery note, photographed on a phone in a yard

What arrivesA phone photograph of a signed proof of delivery

What leavesA confirmed delivery against the right consignment, or a named exception

01CaptureThe driver photographs the note in the app rather than emailing it later. The capture step checks the image before accepting it — corners visible, in focus, not badly under-exposed — and asks for a retake on the spot. Thirty seconds spent here removes a category of failure that no downstream model can undo.
02Rectify and readThe page is deskewed and dewarped so the curve of the paper is flattened and the text sits square. OCR reads the printed fields; the consignment number is read as printed text, and the delivery date and any handwritten note are treated as a separate, lower-confidence class of field.
03Locate the structureLayout-aware extraction finds the consignment number by where it sits relative to its label rather than by position on the page, because this carrier prints two versions of the form. The pallet count table is read as rows, and rows that wrap are joined rather than counted twice.
04Split by confidenceThe consignment number and pallet count carry a high threshold, because a wrong consignment number attaches a delivery to the wrong customer. The handwritten damage note carries a low one, because it is read by a person anyway. Anything below its threshold appears in a review queue with the photograph and the highlighted box beside it.
05Reconcile and postThe consignment is matched against the transport system. Pallet counts are compared with what was loaded; a mismatch does not get corrected, it gets raised as a short-delivery exception with the image attached. Only a clean match confirms the delivery automatically.

Finance operations

A supplier whose invoices arrive in four different layouts

What arrivesA PDF invoice attached to an email, layout unknown

What leavesA matched invoice ready to post, or an exception with a reason and a page reference

01Classify firstBefore anything is extracted, the document is classified: is this an invoice, a credit note, a statement or a remittance advice? Statements processed as invoices are one of the most common and most expensive ingestion errors, because they contain plausible totals that nothing has ordered.
02Extract without a templateNo per-layout template is built, because this supplier changes theirs and there are six hundred other suppliers behind them. Extraction works from labels and spatial relationships, so the invoice number is found next to whatever this layout calls it, in whichever corner it has been moved to this quarter.
03Read the table properlyLine items are extracted as rows with quantity, description, unit price and line total. Sub-totals inside the body are identified and excluded. The extracted lines are summed and compared against the stated total — where they disagree, the table has been read wrongly even though every individual figure may look right.
04Match against the recordThe invoice is matched to its purchase order and to the goods receipt, within the tolerances finance has set for quantity and price. Bank details on the document are compared against the details held on the supplier account, and a change is never accepted from the document itself — it is raised for verification through a separate channel.
05Post or queueFully matched invoices within tolerance post without a person. Everything else lands in an exception queue grouped by reason — no purchase order, price variance, quantity variance, low-confidence field — with the page and the highlighted region beside the query, so a clerk resolves in seconds what previously meant opening three systems.

Why it is harder than it looks

The demonstration uses a clean invoice. You do not have clean invoices.

Every document product demonstrates well, because a demonstration is run on a document the demonstrator chose. The gap between that and an operating business is not a gap in model quality. It is that real document flows are a long tail of awkwardness, and the tail is where the cost is. The same supplier sends four layouts, because they migrated finance systems, kept a legacy template for one division, and let a regional office invent its own. None of them is wrong. All of them have to work.

Then there is the physical reality of how documents reach you. A scan taken at an angle, so the rows are not horizontal and a table detector sees a parallelogram. A page photographed against a dark surface so the edges are ambiguous. A rubber stamp landing squarely across the payment reference — and a stamp is not noise that can be filtered, it is ink on top of ink, and the characters underneath are gone. A staple hole through a digit. A fax that has been printed and rescanned twice and now has a texture rather than a font.

The most instructive failure is the arithmetic one, because it is the one that looks fine. The total is read correctly. Every line item is read correctly as a string. And the line items do not sum to the total. Something has been missed, or double-counted, or a wrapped description has been split into a phantom row with an inherited quantity. Nothing about the individual readings is wrong; the structure is wrong. This is exactly why a document system needs internal consistency checks and an external system of record to argue with. A number that agrees with itself proves very little.

None of this is an argument against automating documents. It is an argument for measuring the thing honestly before promising anything, on your documents rather than anyone's samples — including the crumpled ones, the foreign-language ones and the ones from the supplier everybody in the accounts team already complains about.

A number that has been read perfectly and matched against nothing is not data. It is a rumour with a decimal point.

Be honest about scope

Some documents are ready for this today. Some should not be automated at all.

The credibility of a document programme comes from what you exclude at the start. A pilot that covers the easy sixty per cent of your volume and openly leaves the rest with people will survive contact with reality. One that promises everything will not.

Documents this handles well today

High-volume structured business documents — invoices, purchase orders, remittance advices, delivery notes — where the fields are named and a system of record exists to check them against
Forms with a fixed set of fields, especially where capture happens in an app you control and quality can be enforced at the point of photography
Printed documents that arrive as digital PDFs rather than scans, where the text layer is already present and the work is structural rather than visual
Anything where the correct answer can be confirmed by matching against data you already hold, so extraction errors are caught by reconciliation rather than by trust
Repetitive documents with genuine volume, where a review queue for the uncertain minority is cheaper than a person opening every one

Documents that will still need a person

Negotiated contracts where the meaning turns on the interaction between clauses, and extracting a date is easy while extracting an obligation is not
Handwritten free text at any volume — clinical notes, engineers' job sheets, margin annotations — where the failure is not misreading a word but confidently misreading it
Low-volume, high-consequence documents: a handful of legal instruments a year is a bad automation candidate and a fine reason to keep a competent person, because there is no volume to amortise the build and no error budget to spend
Documents where the important content is a signature, a stamp's authenticity or a physical security feature — that is verification, not extraction, and treating it as extraction is how forgeries pass
Anything where no two examples agree on what a correct extraction would even be, because until people can write the answer down, a system will only automate the disagreement

Asked often

The questions finance and operations ask before signing anything off.

What accuracy can we expect?: Any single number offered in answer to that question is meaningless, and you should be suspicious of one. Accuracy is not a property of a system; it is a property of a field on a document type under a capture condition. Invoice number on a clean supplier PDF and handwritten damage notes on a rain-spotted phone photograph are not the same measurement, and averaging them produces a figure that describes neither. The useful version of the question is: for each field we care about, on our own documents, what proportion is extracted correctly, what proportion is flagged as uncertain, and what proportion is wrong while looking confident — that last one being the only category that actually hurts. We answer it by running a sample of your real documents, including the difficult ones, against a set a person has keyed by hand, and reporting per field. That takes days rather than weeks, it happens before anyone commits to a build, and it is the only number worth putting in a business case.
What about multiple languages and mixed scripts?: Most modern extraction handles the major Latin-script languages without special work, and reasonable coverage exists well beyond that. Two things genuinely complicate it. The first is mixed scripts on one page — a document with an English template and Arabic or Devanagari values in the fields, or Chinese addresses inside a Latin-script form — where reading order and column detection get harder, because the page has more than one direction. The second is that downstream matching is a separate problem from reading: correctly extracting a supplier name in one script and matching it to an account held in another is a transliteration question, not an OCR one, and it is usually solved by matching on a stable identifier such as a tax number instead. As with accuracy, this is answered by testing on your own documents rather than by a list of supported languages.
Do we need to label training data?: Usually far less than people expect, and sometimes none. Modern extraction models arrive already able to find common business fields, so the first pass on invoices or delivery notes needs no labelling at all. Labelling earns its cost in two situations: a field specific to your organisation that no general model has a concept of, such as an internal site code or a contract reference with a shape only you use; and a document type unusual enough that general models perform poorly on it. Even then the volume is modest, and the cheapest source is work people are doing anyway — every correction made in the review queue is a labelled example, provided the system was built to keep them. The expensive version is commissioning a labelling exercise from scratch before you have measured whether you need one.
How does it handle a layout we have never seen before?: This is the reason not to build per-supplier templates, however tempting they are early on. A template matches a layout, so a new layout means either a new template or a silent failure — and with several hundred suppliers, template maintenance quietly becomes a permanent job. Layout-aware extraction instead finds fields by their labels and their spatial relationships, so an invoice number is found next to whatever the document calls it, wherever it has been moved to. A genuinely novel layout will produce lower confidence rather than a confident error, which routes it to a person: the first one costs a few seconds of review, and the correction can improve subsequent handling. The right measure to watch is not whether unseen layouts occur but what the system does when they do — degrade into the review queue, or fail silently.
What happens to the documents afterwards?: They stay, and the link back to them is part of the design. Every extracted field keeps a reference to the page and the region it came from, so a query two years later resolves by looking at the original rather than by trusting a database row. That matters for audit, for disputes with suppliers and for the moment somebody asks where a number came from. Where the documents themselves live is your decision and should be settled before the build rather than after: in your existing document store, in the finance system, or in the platform we build, with the retention period, the deletion schedule and the access rules stated explicitly. Where documents contain personal data, the retention rule is a legal question and not a technical one, and the system should be capable of deleting on schedule rather than accumulating by default.

In practice

Measure it on your documents, including the difficult ones.

Layer 01 is unglamorous and it is where projects are won or lost. Everything above it — retrieval, agents, the systems that act on the result — inherits whatever quality the ingestion produced, and no amount of capability further up recovers a line item that was read into the wrong row. The work that pays is boring: classify before extracting, read tables as structures rather than text, set a threshold per field rather than per document, and argue every extraction against a record you already hold.

The first honest step is small. Send us a sample of real documents — the awkward ones, not the tidy ones — and we will measure field by field what comes out, what gets flagged and what would need a person. That tells you whether there is a project here before anyone has committed to building one, and we would rather tell you that half your document types are not worth automating than sell you all of them.

Send us a sample How we run an engagement

How a machine answers from your own documents

How does a language model answer from your documents, and where does that go wrong?

Read

The last mile into your systems

What has to be true for a system to write into your ERP, HRMS or CRM — and why this is the layer that decides whether any of it was worth building.

Read

How you know it works

How anyone can tell whether an AI system is actually working, rather than merely looking like it did in the demonstration.

Read

Loading…

FAQs

Frequently Asked Questions

Industrial AI, robotics conversion and adoption, Industry 4.0 automation and test automation, and the software those systems run inside: enterprise systems (ERP, HRMS, CRM, inventory and production management), web applications, AI agents and automation, and native mobile apps for iOS and Android.

A focused first release typically ships in 8–12 weeks. Multi-module enterprise platforms run 4–9 months, delivered module by module so you are using working software long before the final release rather than waiting on a single big-bang launch.

Both. A well-defined scope gets a fixed price against a signed specification. Longer or evolving builds run as a dedicated team on a monthly retainer. Either way you get a written estimate with every assumption listed before a contract exists, so you can see exactly what moves the number.

Discovery and scoping, then UI/UX design, then two-week build sprints that each end in a working demo. You get a staging environment from the first week, and QA, security review and deployment run inside the sprint instead of being bolted on at the end.

You do, in full, on final payment. Source code, design files, infrastructure and documentation are handed over in your own repositories and cloud accounts. We keep no licence over your product and there is no lock-in to our hosting.

Yes. We connect to MES and the equipment already on the line, accounting, HR and CRM platforms, payment gateways, WhatsApp Business, and legacy in-house databases. Where no API exists we build a sync layer and migrate historical records with reconciliation reports your finance team can check line by line.

Every project closes with a handover: documentation, team training, and a warranty period covering defects at no cost. After that you can run support in-house or keep us on a monthly plan covering monitoring, security patches, and an agreed block of enhancement hours.

We sign your NDA before the first technical conversation. Builds ship with role-based access, encryption in transit and at rest, and audit logging as standard. Production data stays inside your infrastructure and access is limited to the engineers assigned to your project.

Start a project

Didn’t find what you were looking for?

Tell us what you are building. You get scope, a timeline and a realistic cost — not a brochure.

Tools

The stack we build on

We design, build, and evaluate with a modern AI stack—LLMs, vector search, orchestration, and observability—so your features are fast, reliable, and secure.

OpenAI

Anthropic

Gemini

xAI

Hugging Face

Kimi

LangChain

NVIDIA

Pinecone

Databricks