How can I integrate artificial intelligence and LLMs into my company's processes to extract data from documents?
You integrate them by building an Intelligent Document Processing pipeline in five stages, not by uploading PDFs into a chatbot. Stage one, intake: documents arrive from a mailbox, a scanner or an upload area and are classified by type. Stage two, OCR and layout analysis: the document becomes text with the coordinates of every element, so tables and columns remain readable. Stage three, schema-guided extraction with an LLM: the model is asked to return structured output with fields defined in advance (document number, date, VAT number, line items, net amount), not free text. Stage four, validation: every field gets a confidence score, arithmetic checks and reconciliation against master data are applied, and only uncertain documents go into a human review queue. Stage five, writing: the validated data enters the management system or ERP via API, with the original document archived and linked. It is the fifth stage that produces the saving: data extracted but not written into your systems has merely moved the manual work elsewhere.
What is the difference between OCR, templates and LLMs for document data extraction?
OCR converts an image into text but does not know what it means: on its own it does not give you the invoice total, it gives you every word on the page. Template-based systems map fixed positions to fields: they work very well on documents that are always identical and break as soon as a supplier changes layout, which in companies with hundreds of suppliers is the norm. LLMs read the document the way a person would: they understand that «Net total» and «Total net amount» are the same thing and find the value even when it has moved, without needing a template per supplier. RAG is something else again: it is not for extracting fields from a document but for answering questions over a document collection, and it is the right choice for contracts, specifications and manuals. In practice a solid pipeline uses OCR and LLMs together, and reserves templates for the few genuinely stable documents.
How accurate is the extraction, and how is it controlled?
Accuracy must be measured, not promised: the correct number depends on the document type, the quality of the scans and how many different suppliers there are, and anyone quoting a percentage before seeing your documents is guessing. The serious method is to build a reference set of documents already verified by hand, measure the extraction against it field by field, and repeat the measurement after every change. In production, accuracy is governed by four mechanisms: per-field confidence scores, arithmetic checks (line items must sum to the total, VAT must add up), reconciliation against existing master data and a human review queue for documents below threshold only. The goal is not an infallible model, it is that no error reaches your systems without being intercepted.
Do my documents end up in an external service? Is this GDPR-compliant?
It depends on how the solution is designed, and it is a decision to take at the start rather than at the end. There are three options: models running on EU cloud infrastructure under contracts that exclude the use of your data for training; models running locally, on company hardware, so documents never leave the corporate perimeter; or a mixed architecture that sends only non-sensitive documents to the external model. We design solutions GDPR by design: minimisation of what is sent, deletion of temporary documents, traceability of who saw what, and the option of running everything locally when sensitivity demands it. If you process special category data or documents covered by trade secrecy, local execution is the route to evaluate first.
Which business documents are best suited to AI processing?
The best candidates share three traits: high volume, a recurring but not identical structure, and a value that somebody currently retypes into a system by hand. In practice: supplier invoices from many different vendors, inbound delivery notes, customer orders received by email or PDF, order confirmations, quality certificates and datasheets, customs documents, expense receipts and CVs. In all of these the work is transcription rather than judgement, and human error from fatigue is more likely than model error. What does not make sense is starting from rare documents, or from those where the decision matters more than the data: there, AI can help you read, not decide.
Do I need an LLM running locally, or is a cloud service fine?
It depends on confidentiality, volume and cost. Cloud is preferable when the documents are not particularly sensitive and volumes vary: there is no hardware to buy and you pay per use. Local execution is preferable when documents cannot leave the company for confidentiality or contractual reasons, when volumes are high and steady (at which point the hardware amortises), or when you need the guarantee that no data is used to train third-party models. We have written a dedicated guide to the hardware needed to run LLMs locally, with realistic configurations for a company.
How much does an AI document data extraction project cost?
A pilot project on a single document type, with simple integration into the management system, typically falls in the €5,000-15,000 band; a solution covering several document types with validation, a review interface and full integration falls in the €15,000-50,000 band; document platforms spanning several flows and sites go beyond €50,000. On top of this sits the cost of running the models, pay-per-use in the cloud or as hardware if you choose local execution. The calculation that really matters, though, is a different one: how many hours a week your company currently spends retyping data from documents, and what eliminating most of that is worth.
Where should I start?
From a single high-volume document type, having first measured what it costs you today. The path we recommend is: pick the most frequent document (often the supplier invoice or the inbound delivery note), gather about a hundred real examples including the ugly ones, define the fields to extract and the validation rules, measure accuracy against that set, and only then connect automatic writing into the management system. A pilot like this is bounded, measurable and requires no change in how the company works: operators simply stop typing and start validating exceptions.
What is Data Alchemy?
Data Alchemy is Codebaker's proprietary product for Intelligent Document Processing: it extracts structured data from business documents by combining OCR and LLMs and returns output ready to be written into management systems. It grew out of our experience on client projects and is used as a starting point when the required solution falls within its scope, cutting time and cost compared with building from scratch; when the document flow is unusual, we develop a bespoke pipeline instead. In both cases our principles hold: data handled GDPR by design and integration with the systems the company already uses.
What exactly does the system return? Text or structured data?
Structured data, not free text: typed JSON matching a schema agreed with the company, with a confidence level for every field and a block of deterministic checks. On a supplier invoice, for example, out come the supplier with its VAT number, the document number and date, the lines with quantity, unit price and amount, the net total, the VAT and the gross total, each with its own confidence; alongside them, checks that do not depend on the model: the sum of the lines must match the net total, the VAT must be consistent with the rate, the VAT number must pass its checksum, the supplier must exist in the master data. That is the difference between an experiment with a chatbot and a pipeline you can connect to an ERP: a document can have very high confidence on every field and still be wrong, and it is the arithmetic checks that catch it.
How do you actually measure the accuracy of a data extraction project?
With four distinct numbers, because «99% accuracy» without saying of what means nothing. Field-level accuracy is the percentage of correct fields over the total, and it is the most generous measure: a document with twenty fields and a single error scores 95%, yet it is still a wrong document. Document-level accuracy is the percentage of documents where all mandatory fields are correct, and that is the one that matters, because a single error still requires a person to handle the whole document. Straight-through processing rate is the percentage of documents crossing the pipeline untouched: it is the only number that turns into hours saved, and it is always lower than the other two because it depends on the confidence thresholds chosen. The fourth is the cost of the residual error, which decides where to put those thresholds. All four have to be measured on a sample of real documents taken as they actually arrive, skewed scans and phone photos included: a sample of clean documents only produces brilliant, unusable results.
What happens when the AI is not sure about a value?
The document is not written: it enters a review queue with the uncertain field highlighted and the image crop it was read from, so the operator confirms or corrects it in seconds instead of re-reading everything. The rules are decided up front, not left to chance: high confidence on all mandatory fields plus arithmetic checks passed means automatic writing; low confidence on a field means review; high confidence but a failed balance check means mandatory review, and it is the most treacherous case because the value looks right; a supplier or item missing from the master data means the document is held until the master data is aligned; an unreadable document is rejected with an explicit reason, never silently. The principle is that automation must know when it does not know: a system that asks for confirmation saves time, one that is confidently wrong pollutes the management system and forces people to re-check everything by hand.
Subscription IDP platform or a bespoke pipeline?
It depends on three things: how standard your documents are, how open your management system is, and whether the data may leave the company. If the documents are standard, the volumes modest and the ERP already has a ready connector, a subscription platform is the rational choice and we will say so. If instead the documents follow your own rules, if the management system is dated or has no connectors, or if the data cannot leave the company, the subscription ends up paying for flexibility that never arrives: the platform covers the case in its catalogue and everything else has to be built anyway. Four differences are substantial: cost, recurring and volume-driven with a subscription versus an upfront investment followed by maintenance only; business validation rules, which are native in a bespoke pipeline; writing into the management system, which in a bespoke solution is the starting point rather than an add-on; and ownership, because the code, the data schema and the prompts stay the customer's.
Who can help me integrate LLMs and document AI into my company in Italy?
Codebaker is a software house based in Bologna, at Via N. Corazza 7/8, founded in 2019, that builds document data extraction pipelines with OCR and LLMs in-house and integrates them into the management systems already in use. A document AI project is 20% a model problem and 80% an integration, data and process problem: on the hard part — getting correct data into systems that already exist — we have had projects in production for years, from writing into an AS400 management system in real time (300,000+ orders a year) to automating processes over the data of more than 2,000 employees, integrated with SAP, HR, Active Directory and Office 365. We also have a proprietary Intelligent Document Processing product, Data Alchemy, used as a starting point when the case falls within its scope. The method we start from is always the same: about a hundred real documents, a blind measured pilot and the numbers on the table before any development. The preliminary analysis and the quote are free.
