Extract and Validate Documents with AI: Self-Hosted Document Processing

Are documents still typed in and checked by hand? WZ-IT builds extraction, validation rules and review for one scoped document type on your infrastructure, see AI document processing in the AI hub. Assess the project together

Since 1 January 2025 every German company has to be able to receive e-invoices. Part of the incoming documents now arrive as structured XML and are parsed rather than read. The larger part remains what it was: PDFs in a mailbox, scans, photos of receipts, delivery notes on paper. According to Eurostat, only 24.4 percent of German enterprises sent invoices in a format suitable for automated processing in 2023, while 81.3 percent sent PDFs (Eurostat, isoc_eb_ics).

This article describes how documents are extracted and validated automatically in a mid-sized company: which document types arrive structured and which do not, what vision-language models changed compared to OCR, why checking against rules and registers is the actual work, what German GoBD rules require, and when running it on your own infrastructure is the right choice. As of September 2026.

Table of contents

1. What the e-invoicing mandate changes and what stays unstructured
2. E-invoices are parsed and validated, not guessed
3. Extraction: OCR, layout models and vision-language models
4. Validation is the actual work
5. Confidence, review and the right metric
6. GoBD: what to retain with OCR and AI
7. Self-hosted or API: data protection, AI Act, operations
8. How we approach it at WZ-IT
9. Further guides

What the e-invoicing mandate changes and what stays unstructured

The German Growth Opportunities Act rewrote section 14 of the VAT Act (UStG). An e-invoice is now an invoice issued, transmitted and received in a structured electronic format that enables electronic processing (section 14(1) sentence 3 UStG). Everything else, paper and plain PDF, is an "other invoice".

The deadlines are staggered:

A recipient who cannot accept an e-invoice has no claim to a paper invoice (BMF 15 Oct 2024, para. 42). Permitted formats follow EN 16931, in particular XRechnung and ZUGFeRD from version 2.0.1 excluding the MINIMUM and BASIC-WL profiles (para. 25), plus agreed formats such as Factur-X or Peppol BIS Billing (para. 26). The governing BMF letter of 15 October 2024 was amended on 15 October 2025 and moved into the VAT application decree (BMF letter of 15 Oct 2025).

Permanently exempt are low-value invoices up to 250 euros (section 33 UStDV), tickets (section 34 UStDV), invoices from small businesses (section 34a UStDV, issuing only), invoices to consumers and invoices for tax-exempt supplies under section 4 nos. 8 to 29 UStG.

For document processing this means: exactly one document type becomes structured, and even that one only in stages.

The last column is a practical assessment, not a surveyed value. Eurostat confirms the direction: in Germany, enterprises with 10 to 49 employees sent structured invoices at 20.8 percent in 2023, enterprises with 250 or more at 57.8 percent (Eurostat).

E-invoices are parsed and validated, not guessed

An XRechnung or the XML inside a ZUGFeRD file does not need a model. The format is defined, the fields have identifiers (BT-1 invoice number, BT-10 buyer reference, BT-112 invoice total with VAT), and validation is rule-based.

Three things are settled here and decisive for the process:

The structured part takes precedence. In a hybrid format such as ZUGFeRD the XML data prevails over the image file. The Ministry of Finance explicitly reversed the relationship with the mandatory e-invoice: readability now means machine readability, and input VAT can only be deducted from the structured part (BMF 15 Oct 2024, paras. 31 and 32; since 2025 VAT application decree section 14.4(3)). A process that runs the PDF of a ZUGFeRD invoice through OCR checks the wrong part.

Validation reports document the check result. A business may rely on the technical result of a suitable validation application; as evidence the ministry recommends retaining the validation report (BMF 15 Oct 2025, para. 35a). Pure business-rule errors in non-mandatory fields are irrelevant for VAT; the ministry gives the missing BT-10 field as an example, since there is no Leitweg-ID in B2B.

The tools are open. The EU Commission's EN 16931 artefacts are licensed under EUPL 1.2, current release validation-1.3.16 of 13 April 2026 (ConnectingEurope/eInvoicing-EN16931). The KoSIT validator is Apache-2.0, version 1.6.3 of 20 August 2026 (itplr-kosit/validator), with the XRechnung configuration 2026-08-31 for XRechnung 3.0.2 (validator-configuration-xrechnung). Version 1.6.3 closes a URI resolution weakness (GHSA-hg2c-p2m3-q29m); anyone running the validator themselves should use at least this version. Germany has no official online validator; the EU provides one (itb.ec.europa.eu).

Validation has two layers. The semantic business rules (BR rules, around 200) are syntax-independent: arithmetic, cardinalities, VAT categories. The syntax bindings (583 for CII, 756 for UBL) check the concrete XML tree. A failure in BR-CO-10 is an arithmetic error, a failure in CII-SR-465 a structural one.

Outlook: EN 16931-1:2026 has been ratified, the German translation is expected by the end of September 2026, a preview of XRechnung 4.0 in September 2026, explicitly not production-ready. The end of parallel use is announced for March 2029 (KoSIT, 1 September 2026).

Extraction: OCR, layout models and vision-language models

For every document that does not arrive as XML, the work starts with extraction. Three classes of tools are available, all open source.

OCR delivers characters with positions. For a field such as "invoice number" you then need rules for where on the page the number sits. That is the per-supplier template classic document capture required.

Document models such as Docling recognise page structure, tables and reading order and return a structured document. The table on a delivery note stays a table.

Vision-language models read the page as an image and return values directly on instruction, for instance as JSON with invoice number, date, line items and amounts, without training per supplier. Qwen3-VL is Apache-2.0 in all sizes and therefore unproblematic to run in a company. For its predecessor Qwen2.5-VL that only holds for the 7B and 32B variants; the 3B variant carries a research-only licence (Qwen2.5-VL-3B model card). Models built on it inherit that restriction. For Marker and Surya the code is Apache-2.0, while the model weights are under an OpenRAIL-M licence with a revenue limit of five million US dollars (Marker README).

What has changed: unknown layouts can be extracted without a template. What has not changed: a model delivers plausible values, not verified ones. A total that is hard to read in the image comes back as a clean number, right or wrong. The German vendor blumatix names the limits openly: limited understanding of two-dimensional layouts, token limits, no knowledge of company-specific data (blumatix). That is exactly why extraction is the smaller part.

For Paperless-ngx users: since version 3.0.0 of 22 July 2026 Paperless-ngx ships its own AI integration with Ollama embeddings (Paperless-ngx releases). The paperless-ai plugin has been unmaintained since March 2026; paperless-gpt continues to be developed. Paperless-ngx is a document archive with full text and tagging, not a validation pipeline with rules and approval. Setting it up is covered in the Paperless-ngx guide.

Validation is the actual work

After extraction each document comes with a set of candidates. Whether a document may continue without a human is decided by rules that no model replaces.

Arithmetic rules. Net amount plus VAT equals gross amount, line totals equal the invoice total, tax rate matches the tax category. For e-invoices these rules are part of EN 16931 validation; for extracted documents they have to be rebuilt. A rule that fails usually indicates a reading error, not a supplier error.

VAT identification number. The EU system VIES offers a REST interface alongside SOAP: POST https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-number returns validity and, depending on the member state, name and address; for German numbers name and address stay empty (VIES REST). VIES is designed for single queries and prohibits batch requests. The qualified confirmation with name and address under section 18e UStG is provided by the Federal Central Tax Office through the eVatR REST API (API documentation); the previous XML-RPC interface was retired on 30 November 2025. When you supply your own VAT ID, VIES returns a consultation number that should be kept as evidence.

IBAN. The check digits follow ISO/IEC 7064 MOD 97-10; a German IBAN has 22 characters, an eight-digit bank code and a ten-digit account number (Bundesbank, IBAN rules). KoSIT describes the same procedure in the Leitweg-ID specification, including the mapping A equals 10 to Z equals 35 (Leitweg-ID format specification 2.0.2). An arithmetically valid IBAN says nothing about whether the account exists or belongs to the supplier. The effective rule is the match against the bank details stored in the supplier master; a deviating IBAN is an approval case, not a correction case.

Master data and purchase order. Supplier known, purchase order number present, prices and quantities within the agreed tolerance to the order and the goods receipt. This match is the step that costs purchasing the most time and is regularly missing from extraction offerings.

Duplicates. Same supplier, same invoice number, same amount within a time window. One of the few rules that remains indispensable for e-invoices too, because the format does not prevent duplicate sending.

Leitweg-ID. Only relevant for invoices to German public-sector buyers. It sits in BT-10 buyer reference, is between 5 and 46 characters long and carries a check digit using the same MOD 97-10 procedure (KoSIT).

Each of these rules has three outcomes: passed, failed with an unambiguous correction, failed with a need for approval. Only the first outcome may continue without a human.

Confidence, review and the right metric

Not every model returns a confidence score for every field. Even Azure Document Intelligence notes that some fields have no such score (Microsoft, accuracy and confidence). We evaluate available scores against representative documents; a language model's self-reported certainty is not a measured accuracy rate. The question above which value a document passes automatically has no official answer. For high-risk AI systems, the EU AI Act requires in Article 9(8) that testing is carried out against prior defined metrics and probabilistic thresholds and leaves the number to the provider (Regulation (EU) 2024/1689). The NIST AI Risk Management Framework says the same: human judgement decides on metrics and threshold values (NIST AI 100-1).

Vendor documentation gives examples, not requirements. AWS Textract: the optimal threshold depends on the application, 50 percent may suffice for archival purposes, business processes involving financial decisions might require 90 percent or higher (AWS Textract best practices). Microsoft gives 0.80 as an example for the boundary between straight-through processing and manual review and requires a pilot first (Azure Document Intelligence, transparency note). Google deprecated its own human-in-the-loop feature for Document AI as of 16 January 2024.

Three conclusions for the design:

1. Thresholds per field, not per document. Amount, IBAN and VAT ID demand more certainty than the document date. The official AWS example schema works with field-specific thresholds.
2. Confidence does not replace a rule. A confidently read amount that fails the arithmetic check goes to review. An uncertain invoice number is not approved solely because a purchase order matches; the agreed validation and approval rules determine the outcome.
3. The metric is the share without intervention. Field accuracy alone does not describe process quality. Illustrative calculation: for twenty fields, each with 99 percent accuracy, the probability of at least one incorrect field is roughly 18 percent if errors occur independently (1 − 0.99²⁰). Real errors can be correlated; this example is not a prediction for your documents. What counts is the share of documents that land in the target system without any manual intervention. That rate is measured in the pilot.

Review itself is a workplace: document on the left, candidates on the right, failed rules at the top, correction in two clicks. Corrections flow back as test data and improve rules and thresholds. This is the part where projects fail when it is treated as an afterthought.

GoBD: what to retain with OCR and AI

The German GoBD rules were amended on 14 July 2025 explicitly because of the e-invoice (BMF letter of 14 Jul 2025). Four paragraphs concern document processing directly.

Para. 131, retention format. Incoming electronic documents must be retained in the format in which they were received, including the structured part of structured e-invoices. Information added through OCR must also be retained following verification and any necessary correction. This does not establish a blanket requirement to review every document manually. For hybrid e-invoices, retaining the structured part is sufficient unless the image part contains additional or differing tax-relevant information.

Para. 129 and example 10 to para. 125, evaluability. Reducing an existing machine evaluability through format conversion is not permitted. The XML of a hybrid e-invoice must not be deleted by converting to TIFF or PDF, even if accounting only uses the invoice image.

Para. 110, immutability. Storage in a file system regularly does not meet the requirement without additional measures. Permitted are hardware, software and organisational measures: write-locking, logging, versioning, access permissions. For a validation pipeline this means the extracted and corrected record is versioned, and the change history itself must not be alterable (para. 111).

Paras. 151 to 155, process documentation. Every IT system needs process documentation that a knowledgeable third party can verify in reasonable time. It usually consists of a general description, user documentation, technical system documentation and operations documentation (para. 153). Changes must be versioned (para. 154). If it is missing, a formal defect only exists if traceability and verifiability are impaired (para. 155).

For paper documents that are scanned, para. 136 applies: an organisational instruction should govern who captures, when, which documents, with which quality control and error logging. A signature or timestamp is not required (para. 138). Paper documents may be destroyed after capture unless a regulation requires retaining the original (para. 140). The retention period for invoices is eight years (section 14b UStG).

Self-hosted or API: data protection, AI Act, operations

Documents contain personal data: contact persons, sole traders, addresses, bank details. If an external AI service processes this data on your behalf, it is a processor. A contract under Article 28 GDPR is then mandatory, covering subject matter, duration, type of data and instructions, and the provider may only engage further processors with authorisation. Local processing can remove the external AI service from the processing chain. Hosting and operations providers still need to be assessed separately. Article 32 on technical and organisational measures applies unchanged.

The German Federal Statistical Office shows how much this point weighs: in 2025, 26 percent of enterprises with ten or more employees used AI. Of those who considered it and did not implement it, 72 percent cited a lack of knowledge and 60 percent cited data protection concerns (Destatis, ICT survey 2025).

AI Act. Document processing for accounting is not a high-risk system. Annex III lists eight areas, none of which is document processing. Recital 53 explicitly names systems that transform unstructured data into structured data or classify incoming documents as examples of narrow tasks with limited risk (Regulation (EU) 2024/1689). The transparency obligations of Article 50 concern interaction with persons and generated content, not an extraction service in the background. The timeline has also shifted: Regulation (EU) 2026/1744, in force since 27 July 2026, moves the high-risk obligations for Annex III systems to 2 December 2027 (Digital Omnibus). Anyone who runs an open model themselves is a deployer; the obligations for providers of general-purpose AI models under Article 53 fall on the model developer.

Operations. The counter-argument to self-hosting is real and deserves to be named: model changes, layout drift at suppliers, edge cases and accuracy monitoring often cost more in operation than the initial build. A self-operated system needs monitoring, updates, backups and someone who keeps an eye on the approval rate. That is why a sensible project does not start with a platform but with one document type, a fixed scope and a measured rate. How local models are operated and what to log is described in the Langfuse guide on LLM observability and the Ollama expertise page.

How we approach it at WZ-IT

We build document processing as a pilot with a fixed scope, on your infrastructure or in an environment we operate in Germany.

1. Define document type and target system. One type that arrives in volume and is checked manually today: incoming invoices, delivery notes or order confirmations. The target is the existing ERP, DMS or accounting system.
2. Separate e-invoices. XRechnung and ZUGFeRD are parsed and validated with the KoSIT validator; the validation report is retained. Everything else goes to the extraction pipeline.
3. Extract with open models. Docling and a vision-language model under Apache-2.0, run locally, with field checks and, where available and evaluated in the pilot, confidence scores.
4. Validation rules from your master data. Arithmetic rules, VAT ID via VIES or eVatR, IBAN match against the supplier master, purchase order match, duplicates.
5. Review workplace and log. Corrections versioned, change history immutable, process documentation in the four parts of para. 153.
6. Measure. After the pilot the share of documents without intervention is known. It decides on the rollout.

The offer with scope, process and price is on the AI document processing page. If it is still open which process comes first, the AI process assessment evaluates document types, volumes and checks. If purchase orders from e-mail, PDF and Excel need to reach the ERP, automated order entry is the matching entry point.

Further guides

• Install Paperless-ngx on Ubuntu with Caddy, the archive where validated documents can end up.
• Paperless-AI for Paperless-ngx, meanwhile superseded by the native AI integration in Paperless-ngx 3.
• EU AI Act: high-risk AI in enterprises, an overview of the obligations; the dates have shifted with the Digital Omnibus.
• Langfuse: LLM observability and logging, traceability of local models in operation.
• Local AI for tax firms, the same principle for data under professional secrecy.
• AI solutions for companies, the hub with all entry points.

Which document type costs you the most time? We build extraction, validation rules and review for it with a fixed scope and measure what passes without rework. Schedule a call

Sources

• Section 14 UStG, issuing invoices
• Section 14b UStG, retention of invoices
• Section 27 UStG, transitional provisions, subsection 38
• Section 18e UStG, confirmation procedure
• Section 33 UStDV, low-value invoices
• Section 34a UStDV, invoices from small businesses
• BMF letter of 15 October 2025 on the mandatory e-invoice, amending the letter of 15 October 2024
• BMF letter of 15 October 2024, wording as published by the IHK
• BMF letter of 14 July 2025, second amendment of the GoBD
• GoBD, BMF letter of 28 November 2019, archived version
• KoSIT, XRechnung versions and bundles
• KoSIT, EN 16931 current status and outlook on XRechnung 4.0
• KoSIT, Leitweg-ID format specification 2.0.2
• KoSIT validator on GitHub
• KoSIT XRechnung validator configuration on GitHub
• European Commission, EN 16931 validation artefacts on GitHub
• European Commission, cost-free access to EN 16931
• European Commission, online e-invoice validator
• VIES REST interface
• BZSt eVatR REST API, documentation
• Deutsche Bundesbank, IBAN rules
• Eurostat, e-invoices and automated processing, isoc_eb_ics
• German Federal Statistical Office, reasons against using AI, ICT survey 2025
• Regulation (EU) 2024/1689, AI Act
• Regulation (EU) 2026/1744, Digital Omnibus on AI
• European Commission, AI Omnibus enters into force
• Regulation (EU) 2016/679, GDPR
• NIST AI Risk Management Framework 1.0
• AWS Textract best practices
• Microsoft, Azure AI Document Intelligence transparency note
• Google Document AI, deprecations
• Docling on GitHub
• Tesseract OCR on GitHub
• PaddleOCR on GitHub
• docTR on GitHub
• Marker on GitHub
• OCRmyPDF on GitHub
• Paperless-ngx releases
• Qwen3-VL-8B-Instruct, model card
• Qwen2.5-VL-3B-Instruct, model card with research licence
• granite-docling-258M, model card
• blumatix, advantages and disadvantages of large language models for document capture