Data extraction: the first building block of document control
Quotes, invoices, BPUs, DPGFs, framework agreements, price lists. Pulling a unit price, a discount, a quantity, a due date out of a document that was never designed to be read by a machine. This step is the silent foundation of procurement, finance and accounting control. When it is done poorly, everything that follows (matching, anomaly detection, decision-making) becomes unreliable.
Most organisations invest in sophisticated analysis and reporting tools, yet neglect the link that feeds them. But a poorly extracted piece of data does not produce a degraded analysis: it produces a false one, with the same appearance of reliability as a correct one. That is precisely what makes data extraction both technical and strategic.
Data extraction: what are we really talking about?
Data extraction consists of transforming an unstructured document (a PDF, a spreadsheet, a scan, a summary e-mail) into structured, usable and comparable information. Concretely, it means identifying the decisive elements within a document (nature of the service, quantities, unit prices, discounts, payment terms, due dates, contractual references) and returning them in a logical form, ready to be cross-checked with other sources.
Extraction must be distinguished from its neighbouring steps. Capture consists of retrieving the document. Classification consists of identifying its type (is it a quote, an invoice, a BPU?). Matching consists of comparing the extracted data with the reference documents. Extraction is the pivotal step between the raw document and intelligence: it determines the quality of everything that comes next. A perfect match on poorly extracted data remains a false match.
Why extraction is a harder problem than it seems
The first intuition is to think that reading a document is trivial. A human does it in a few seconds. That is precisely what masks the real difficulty of the problem at scale.
Format heterogeneity: there is no legal standard imposing the structure of a supplier quote or invoice. Each issuer applies its own layout, its own labels, its own item codes. The same product can appear under three different names across three suppliers. A quote can be a PDF generated by an ERP, an Excel table laid out by hand, or a simple e-mail. Before two documents can be compared, they must therefore be translated into a common language, something the human eye does without thinking but that a system must learn to reproduce reliably and repeatably.
Documentary density and variability: a BPU (Bordereau de Prix Unitaires) can contain several hundred lines, each with its own code, unit of measure and price. A DPGF (Décomposition du Prix Global et Forfaitaire) applies its own logic to each contract. Cleanly extracting four hundred service lines, without missing a single one and without confusing a quantity with an amount, quickly exceeds the capacity of careful manual processing, especially under time pressure.
Unstructured data: most of the information that flows between a supplier and a procurement department is not filed into neat boxes. It is buried in free text, borderless tables, annotations, and specific conditions expressed in natural language. A discount may appear in a clause rather than in a column. Incidental charges may appear under a label that corresponds to nothing in the original quote. Extraction is therefore not limited to copying figures: you have to understand the context to know which figure matters.
Not all documents are equal: the complexity scale
Understanding why extraction resists automation requires accepting that documents are not all at the same level of difficulty. The more variable a document is in its form and the richer it is in its content, the more demanding extraction becomes. This reality can be represented as a scale of increasing complexity. The general context does not work in companies' favour: according to IDC, nearly 90% of enterprise data is unstructured, an order of magnitude confirmed by other industry players such as Databricks, which place it between 80% and 90%.
At the first level are simple, structured documents, such as a standardised purchase order or a normalised spreadsheet. Their form is predictable, their extraction relatively straightforward. At the second level, semi-structured documents (invoices, forms) offer some structural markers, but each issuer applies its own presentation. At the third level, unstructured documents (free-format quotes, price lists, financial statements) mix text and figures with no common logic from one supplier to another. At the top, highly complex documents (framework agreements, BPU, DPGF, CCTP) combine hundreds of lines, natural-language clauses and indexed conditions.
The decisive point for the procurement, finance and accounting functions is this: the bulk of the documents they handle every day is concentrated at the top of this scale. It is not the easy cases that dominate, but the complex ones. That is precisely why extraction designed for simple documents collapses on real-world documents.
From OCR to agentic AI: the long trajectory of document extraction
Automatic data extraction was not born with recent artificial intelligence. It follows a long trajectory, in which each step pushed back a little further the rigidity of the template.
As far back as the 1950s, the first optical readings (OCR) converted typewritten documents into machine data. In the 1970s came omni-font OCR, able to recognise characters regardless of the typeface. From the 1980s, computer vision algorithms made it possible to handle more varied layouts. In the 2010s, a first generation of document processing tools emerged, layering user-friendly interfaces over OCR and beginning to draw on machine learning and natural language processing (NLP) to gain flexibility.
The thread running through this history is clear: each generation sought to break free from the constraint of the predefined model, that fragility whereby a simple change in layout breaks the extraction. The current breakthrough, driven by the combination of NLP, vision models (VLM) and agentic AI, extends this trajectory by crossing a threshold: reading a document without a template, by understanding its content rather than tracing it.
Classic approaches and their glass ceiling
Faced with this challenge, organisations have historically relied on three recourses, each hitting the same limit.
Manual data entry: this is still the norm in many departments. It is flexible but costly and fallible. Between 40% and 70% of a buyer's time can be absorbed by document processing, a significant share of which is re-keying. Every entry is an opportunity to introduce an inaccuracy (a mis-coded reference, a rounded discount, a misplaced decimal) that will then contaminate all downstream analyses.
Classic OCR: Optical character recognition digitises a document and extracts text from it. It is a useful first step, but it stops at the surface. OCR based on rigid models works as long as the document exactly matches the expected template. The slightest change in layout breaks the extraction. Above all, OCR reads without understanding: it does not know that the price per kilo it has just read must be matched against a price list negotiated six months earlier, nor that a different label refers to the same service. It shifts the problem to a spreadsheet; it does not solve it.
The spreadsheet: Excel remains the universal refuge. It compares cells, not contexts. It does not detect that a line reading "handling included" corresponds to "free shipping" on another document, and a simple formula error propagates silently through all the calculations that depend on it. At low volume, it does the job. As soon as the number of documents and the complexity of the conditions increase, it reaches its structural limits.
What these three approaches have in common: they treat extraction as a mechanical operation, when it is an operation of interpretation.
The business stakes: what reliable extraction really wins
Focusing attention on extraction is not a technical refinement. It is where a concrete share of the margin is decided.
Time given back to teams: automating extraction means freeing up the hours currently spent reading, re-keying and normalising documents. This time is not strategic time: it is mechanical verification time paid at the price of an expert. By recovering it, procurement and finance teams can reallocate it to negotiation, supplier relationships and analysis, that is, to what really creates value.
Reliability of decisions: reliable extraction produces a comparable database. Without it, structuring purchasing decisions (renewing a contract, consolidating volumes, renegotiating a price grid) are made on partial data or data reconstructed by hand. With it, each decision is based on what the documents actually contain, and not on what they are assumed to contain.
Downstream detection: extraction mechanically determines the quality of discrepancy detection. A discount that is not extracted is a discount that will never be checked. A misinterpreted line of charges is a discrepancy that will slip under the radar. And the margins of error stand between 3% and 5%. It is precisely because extraction is made reliable upstream that the detection of documentary discrepancies can reach a high level of precision downstream. Today, one supplier document in two still escapes control, and faulty extraction is often the primary cause.
Conclusion
Data extraction is the most discreet building block of procurement and finance control, and yet the one that decides everything else. It is not visible in dashboards, it is not the subject of dedicated strategic projects, and that is precisely why it constitutes a costly blind spot. As long as data enters the system through fallible manual entry or blind scanning, no downstream analysis tool can compensate for this foundational flaw.
Making extraction reliable means refusing to build decisions on uncertain data. It is also the first condition for recovering time, securing the margin and giving teams the visibility they have never had into what their documents really contain.
Discover ZYLIO!
