Invoice processing & accounts-payable automation

Accounts-payable teams still type, check and route a large share of supplier invoices by hand. Modern document AI reads any invoice layout without per-supplier templates, extracts header and line-item data, checks it against purchase orders and tax rules, proposes the booking and routes exceptions to a human. In the EU, mandatory structured e-invoicing is shifting the problem from reading invoices to validating, matching and booking them — AI is needed for both.

Problem & value

• Today: invoices arrive by email, portal and paper in hundreds of layouts. Staff key in data, look up the order, chase approvers and assign G/L accounts. Errors cause duplicate payments, missed early-payment discounts and audit findings.
• AI value: touchless processing of standard invoices, faster cycle times (discount capture), fewer keying errors, better fraud/duplicate checks, staff focus on exceptions.
• Market shift: Germany requires all domestic B2B businesses to be able to receive structured e-invoices since 1 Jan 2025, with mandatory issuing phased in 2027/2028; the EU ViDA package extends digital reporting for cross-border trade from 2030. Structured e-invoices remove OCR errors but still need validation, matching, coding and approval — and paper/PDF invoices from abroad, from small suppliers and for exempt cases remain for years [1][2].

Variants

• SMB / freelancer: capture inside the accounting tool (upload or email-in → booking proposal).
• Mid-market / enterprise: AP automation platform with PO matching, approval workflows and ERP integration (SAP, Microsoft Dynamics, DATEV).
• Public sector: receiving XRechnung via central portals (ZRE/OZG-RE) plus validation and booking.
• Private use: collecting household invoices/receipts for tax returns → see PERS-013, DOC-002.

How it works

1. intake (email/portal/scan/e-invoice)
2. format detection (structured XML?
3. parse directly | PDF/image
4. document AI)
5. OCR + layout parsing + field extraction (header, line items, VAT, IBAN)
6. validation (VAT ID, maths, mandatory fields per §14 UStG, duplicates, IBAN change check)
7. matching (PO, goods receipt; 2/3-way match)
8. coding (G/L account, cost centre, tax code — learned from history)
9. approval workflow (human-in-the-loop on exceptions & thresholds)
10. posting + GoBD-compliant archiving

• Extraction: today usually a vision-language model or a specialised document model that reads the page image directly and returns JSON against a schema; classic OCR + templates is legacy.
• Coding/booking proposals: classifier or LLM with retrieval of past bookings for the same supplier.
• Human-in-the-loop: confidence thresholds per field; anything below → review screen with the source highlighted. Approval of payment always stays with humans per internal controls.

Data preparation

Which data: incoming invoices (PDF, scans, e-invoices as XRechnung/ZUGFeRD), supplier master data, purchase orders, goods receipts and the chart of accounts with cost centres.

Where it lives: ERP or accounting system (DATEV, SAP, Business Central) for master and order data, a shared mailbox for incoming PDFs, the DMS or file shares for archived invoices, and paper stacks for the rest.

Typical gaps: poor scans and photos, duplicate or outdated supplier records, purchase orders without clean item data, inconsistent booking rules that exist only in the heads of accountants, and too broad access rights on the invoice folders.

Preparation steps: 1. Route all invoices into one inbox or portal and switch suppliers to e-invoicing where possible. 2. Clean the supplier master data (duplicates, IBAN, tax IDs) and export it via the ERP interface (see PREP-005). 3. Digitise paper backlog with a scanner and OCR only if historical learning is wanted (PREP-006). 4. Harvest past bookings as examples for booking proposals (PREP-020) and write down the booking rules (PREP-016). 5. Build a small test set of 50-100 real invoices with known correct results (PREP-018). 6. Restrict access to the invoice archive (PREP-023).

Tools: the scanner software, Paperless-ngx, ERP exports, spreadsheet for the test set.

Rough share of effort: about 30 percent of the project, mostly master data and process clean-up rather than the AI itself. See GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: mature EU-hostable AP products (e.g. DATEV-integrated or ERP-add-on tools) exist at SMB prices and the invoice process is standard.
• Enterprise — Path B: AP is a high-volume core process, so per-document fees add up and integration with the own ERP, approval rules and tax logic favours cloud APIs plus own orchestration.
• Developer — Path C: open-source OCR/VLM stacks (e.g. Docling, Paperless-ngx with an LLM step) run on HW2 and give full control for product builders.
• Public — Path C: invoices carry supplier and procurement data and procurement rules favour sovereign, self-operated or German-cloud hosting.

Path A — Buy (recommended for most SMBs)

• Built into accounting software: DATEV (Unternehmen online), Lexware Office, sevDesk, Candis, Xero, QuickBooks — enough for small volumes.
• AP automation platforms: e.g. Candis, Yokoy, Rossum, Hypatos, Klippa, Mindee, ABBYY Vantage, plus ECM/DMS vendors such as DocuWare and d.velop. Check: EU hosting, GoBD/IDW-compliant archive, native ERP connector, e-invoice (XRechnung/ZUGFeRD) support, line-item extraction.
• Choose A when: standard processes, < several 100k invoices/year, ERP connector exists.

Path B — Build on cloud APIs

• Specialised invoice APIs: Azure AI Document Intelligence (prebuilt invoice model, EU regions), Google Document AI Invoice Parser (EU location), AWS Textract AnalyzeExpense (Frankfurt region), Mistral OCR / document AI (EU provider).
• General VLM extraction: send page images + JSON schema to a frontier multimodal model (Claude, Gemini, GPT, Mistral) with structured outputs; good for long-tail layouts and line items.
• Orchestration: n8n / Power Automate / custom service; e-invoice parsing with open libraries (e.g. Mustang for ZUGFeRD/XRechnung, KoSIT validator).
• Choose B when: you need custom logic or integration but no on-prem constraint.

Path C — Self-host (open source)

• Document parsing: Docling (IBM, incl. Granite-Docling), PaddleOCR / PaddleOCR-VL, MinerU, olmOCR, Marker.
• Extraction with open VLMs: Qwen-VL family (e.g. Qwen2.5-VL / Qwen3-VL), served via vLLM or Ollama; constrained JSON decoding (e.g. vLLM structured outputs, Outlines).
• Workflow: n8n (self-hosted) or Camunda; archive in a GoBD-compliant DMS.
• Hardware: HW2 (one 24–32 GB GPU) handles thousands of pages/day with a ~7–8B VLM; HW3 for larger VLMs and higher accuracy on complex line items.

Path D — Custom training

Rarely needed. Fine-tune a small VLM or a layout model (LayoutLM-family/Donut-style) only for very high volumes with unusual documents, or to cut inference cost. Requires a few hundred to a few thousand labelled invoices; corrections from the review screen are the natural training data.

State of the art (2026)

• Template-free extraction by VLMs is standard; document-understanding benchmarks (e.g. DocVQA, OmniDocBench, olmOCR-Bench) are dominated by VLM-based parsers. Header fields reach very high accuracy on clean documents; line items, multi-page tables, poor scans and handwritten notes remain the main error sources.
• Structured outputs (schema-constrained decoding) eliminate malformed JSON.
• Agentic AP: LLM agents handle exceptions — e.g. writing to suppliers about missing PO numbers, resolving price variances — see AGENT-004/AGENT-006.
• E-invoicing (EN 16931: XRechnung, ZUGFeRD/Factur-X, Peppol) moves value from OCR to validation, matching and coding.
• Limits: VLMs can hallucinate plausible values — always cross-check maths (net + VAT = gross), VAT ID and IBAN against master data; never auto-change bank details.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-002 receipts, DOC-003 forms, DOC-006 logistics documents, DOC-008 mailroom classification, DOC-014 document parsing for RAG, DOC-017 bank statements — one self-hosted VLM server (HW2/HW3) can serve all of them.
• Downstream: ANOM-009 / ANOM-006 (fraud & duplicate detection on the extracted data), AGENT-006 (reconciliation & close), PRED-016 (cash-flow forecasting from open payables).
• Workflow engine shared with AGENT-002 back-office automation.

Effort, cost & KPIs

• Path A: days to a few weeks; SaaS pricing typically per document or per user.
• Path B: 1–3 months for a production pipeline incl. ERP integration; API cost per page is usually small compared to manual handling cost.
• Path C: 2–4 months; one GPU server plus operations effort.
• KPIs: touchless rate (straight-through processing %), field-level accuracy, cost per invoice, cycle time receipt→approval, early-payment discount capture, duplicate payments avoided.

People & change

Involve early: management (budget, scope) and the head of accounting as process owner; add IT for the ERP interface and the data owners of supplier and order data. The DPO joins before supplier contact data and employee approval data are processed; invoices rarely need a full DPIA, but an AVV (Art. 28 GDPR) with the vendor is required (GUIDE-005, GUIDE-010).

Works council: depends. If a works council exists, the workflow logs who approves, books and corrects what and when, which makes it objectively suited to monitor performance under §87(1) no. 6 BetrVG. §90(1) no. 3 additionally requires timely information about AI-supported work processes. Public bodies involve the Personalrat. A short works agreement that excludes individual performance evaluation usually settles it (GUIDE-004).

AI literacy: Art. 4 AI Act requires measures that support staff's AI literacy; give accountants a short training on confidence scores, typical misreads and how to correct (GUIDE-006).

Communication and pilot: present the tool as relief from typing, not as headcount reduction; start with one team and 3-5 suppliers, run in parallel with manual entry for two to four weeks, and name one AI champion (GUIDE-008, GUIDE-009).

Typical concerns: fear of job loss (shift to exception handling and controlling), fear of errors (four-eyes check on low confidence and on payments), tax-audit proof (keep original and audit trail).

Humans in control: no payment or posting without release rules; humans decide exceptions.

Risks, regulation & compliance

• EU AI Act: minimal risk — no Annex III category; AI literacy duty (Art. 4) applies to staff.
• GDPR: invoices from sole traders and freelancers contain personal data; data processing agreement with vendor; EU hosting preferred; retention per tax law.
• Tax / bookkeeping: German GoBD (traceable processing, unchangeable archiving, procedural documentation/Verfahrensdokumentation), §14 UStG mandatory fields, 8–10-year retention.
• Fraud: invoice/payment-diversion fraud (changed IBAN) — mandatory master-data checks and four-eyes principle on bank detail changes.
• Mitigations: confidence thresholds, human approval, audit log of AI suggestions vs. final booking.

Getting started

1. Measure the baseline: volume, channels, share of e-invoices, cost and cycle time per invoice.
2. Make sure you can receive and validate XRechnung/ZUGFeRD (legal requirement in DE since 2025).
3. Test 2–3 tools from Path A with 100 of your own real invoices, including the hard ones.
4. Define confidence thresholds and exception handling, then integrate with ERP/accounting.
5. Track touchless rate monthly; use reviewer corrections to improve booking rules.

Sources

1. German Federal Ministry of Finance — FAQ on mandatory e-invoicing (E-Rechnung) — https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html
2. European Commission — VAT in the Digital Age (ViDA) — https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en
3. Microsoft — Azure AI Document Intelligence invoice model — https://learn.microsoft.com/azure/ai-services/document-intelligence/prebuilt/invoice
4. Google Cloud — Document AI Invoice Parser — https://cloud.google.com/document-ai/docs/processors-list
5. AWS — Amazon Textract AnalyzeExpense — https://docs.aws.amazon.com/textract/latest/dg/invoices-receipts.html
6. Docling project — https://github.com/docling-project/docling
7. PaddleOCR — https://github.com/PaddlePaddle/PaddleOCR
8. KoSIT XRechnung validator — https://github.com/itplr-kosit/validator
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj