Document data extraction (OCR and language models)
Document data extraction turns an invoice, a delivery note, a CMR consignment note or an order from a PDF or a photo into fields the system understands: number, counterparty, dates, line items, amounts. OCR reads the characters, and a language model works out what each part of the document is.
Reading used to rely on templates: for every supplier someone had to point out where on the page the invoice number and the total sit, and a change of layout broke the reading until the configuration was fixed. A language model reads the content together with the layout, so it copes with a document from a supplier it has never seen. It still makes mistakes, most often on poor scans, stamps and tables that run across several pages.
That is why the output is a proposal, not a posting. The operator sees the document next to the extracted fields, corrects what needs correcting and approves it. The system adds the rules the model does not invent: the tax ID has to be in the customer file, line items have to add up to the document total, the item code has to come from the catalogue. Matching against the purchase order and the delivery highlights a difference in price or quantity before the document goes for approval.
Accuracy depends mostly on the input: a phone photo taken at an angle, a copy of a copy, a driver's handwritten note on a CMR. Measure from the first week what share of documents goes through without a correction, and treat that as an implementation metric rather than a promise in a proposal. If the documents contain personal data, the same questions apply as with any use of a model: where the content goes and on what legal basis.
You will recognise the problem when someone re-keys cost invoices, delivery notes or orders into the system every day and the pile grows towards month-end. In Poland, KSeF takes part of that work away for domestic invoices, but receipts, documents from foreign suppliers, contracts and transport paperwork still arrive as scans.