Receipt & expense capture

Employees and freelancers still collect crumpled till slips, photograph them late and type amounts into expense tools; accountants then check VAT, categories and policy compliance. Document AI reads a receipt photo in seconds, extracts merchant, date, totals and VAT per rate, proposes the category and booking, matches it to the card transaction and flags duplicates or policy breaches. The human only confirms. Receipts are the "small, messy, high-volume" sibling of invoices (DOC-001).

Problem & value

• Today: receipts are paper, thermal print (fades), photos or app screens. Expense reports are compiled at the end of a trip or month; missing receipts, wrong VAT split and unclear business purpose (e.g. for hospitality) create rework and lost input-VAT deduction. Private persons keep shoeboxes for tax returns.
• AI value: capture at the moment of purchase, fewer keying errors, VAT-correct splitting, automatic matching to card feeds, earlier policy and duplicate checks, shorter reimbursement cycles, audit-ready archive.
• Measured data: vendor-neutral, peer-reviewed accuracy figures for production receipt capture are rare; public academic datasets (CORD, SROIE) exist for benchmarking, but they are clean, mostly Asian layouts, so measure on your own receipts (see Getting started). No ROI figures are quoted here because none could be verified from primary sources.
• German specifics: travel expense lump sums for 2026 remain 14 EUR (8 to 24 h absence) and 28 EUR (full day) domestically [7]; AI helps by computing them from trip data, but the receipts remain the evidence for actual costs.

Variants

• Employee expense reports (T&E): mobile app capture, corporate-card matching, approval flow, reimbursement.
• Corporate-card / spend management: receipts attached to card transactions in real time (Moss, Pleo, Spendesk, Payhawk, Circula).
• SMB / freelancer bookkeeping: photo-to-booking in accounting apps (DATEV, Lexware Office, sevDesk, Candis).
• Hospitality receipts (Bewirtungsbelege): extra fields (guests, occasion) and stricter formal rules; AI pre-fills, human completes.
• Multi-currency / cross-border: foreign-language receipts, FX conversion, foreign VAT reclaim.
• Public sector: travel-expense accounting (Reisekostenabrechnung) with statutory rates; mostly on-prem/sovereign hosting.
• Private use: household receipts for tax return (Werbungskosten, Handwerkerleistungen, medical costs) and warranty tracking, see PERS-013.
• Retail / shopping receipts for analytics: line-item extraction for loyalty or household budgeting (consent based).

How it works

1. capture (mobile app photo / e-mail-in / upload / wallet pass / card feed)
2. image quality check (crop, deskew, glare, multi-receipt split, duplicate hash)
3. OCR + layout parsing, or VLM reads page image directly
4. field extraction to schema (merchant, address, tax no., date/time, currency, totals, VAT per rate, tip, payment)
5. validation (net + VAT = gross, VAT rate plausible for country, date in period, currency, VAT ID format)
6. enrichment (category/G/L account, cost centre, per-diem, merchant lookup, FX rate)
7. matching (card/bank transaction, trip, existing receipts) + duplicate & policy check
8. human confirm on low confidence/flags
9. approval workflow
10. export to ERP/accounting
11. GoBD-compliant archive of original image + extracted data + change log

• Extraction: specialised receipt models (prebuilt-receipt, AnalyzeExpense) or general VLMs with a JSON schema; line items optional (needed for mixed VAT rates, split of private/business items, or gift/representation limits).
• Categorisation: LLM or classifier using merchant name plus history; learns from corrections.
• Human-in-the-loop: the submitter confirms the extracted values on the phone (they know the business purpose); approvers decide on flagged exceptions; AI never approves reimbursement or changes tax treatment alone.

Data preparation

Which data: photos and PDFs of receipts, card and bank transactions, travel requests, the expense policy and the cost centre and account structure.

Where it lives: in employees' phones, wallets and mailboxes, in the accounting system or expense tool, in payroll for travel allowances, and in paper folders at the accounting desk.

Typical gaps: blurry photos, receipts without VAT breakdown, missing business purpose, unwritten travel and gift rules, duplicates (same receipt by card feed and photo) and mixed private and business items.

Preparation steps: 1. Write the expense policy as short, checkable rules (limits, per diems, forbidden categories), see PREP-016. 2. Fix the category scheme and account mapping before enabling auto-categorisation (PREP-019). 3. Define one capture route: app photo, forwarding mailbox or card feed. 4. Export history from accounting for suggested categories (PREP-020, PREP-005). 5. Prepare a test set of about 50 typical receipts including bad photos (PREP-018). 6. Clarify what personal data the app stores and for how long (PREP-025).

Tools: the expense app itself, smartphone scanning, accounting export, a spreadsheet for the policy and test set.

Rough share of effort: low, around 10 to 15 percent; most work is policy clarity, not data cleaning. See GUIDE-003.

Implementation paths

Which path for whom

• SMB — Path A: expense and receipt apps with DATEV or accounting connectors are mature, EU-hosted and cheap per user, and the process is standard.
• Enterprise — Path A: expense capture is a commodity function and the established travel and expense platforms already cover policy checks and ERP posting.
• Developer — Path C: open-source OCR and small VLMs on HW2 let product builders embed receipt extraction without per-document fees.
• Private — Path A: consumer apps for receipt scanning or tax organisation are simple, cheap and sufficient for households.
• Public — Path B: travel expense data of civil servants and procurement rules favour EU or German cloud APIs integrated into the existing financial system.

Path A — Buy (recommended for SMBs and enterprises)

• Accounting / bookkeeping suites with receipt capture: DATEV (Unternehmen online / Belege), Lexware Office, sevDesk, Candis (DE); Xero, QuickBooks, Zoho Expense (non-EU).
• Expense and spend management: Circula (DE), Moss (DE), Spendesk (FR), Pleo (DK), Payhawk (BG), Yokoy (CH); Expensify, SAP Concur, Navan, Ramp (US vendors, check EU hosting and DPA). Verify current product lines and ownership before purchase, as this market consolidates.
• Capture APIs/OEM: Klippa (NL), Mindee (FR), Veryfi (US), Rossum, ABBYY Vantage.
• Choose A when: standard receipts, existing accounting/ERP connector, no need to own the model. Check: EU hosting, GoBD-compliant archive (original image retained, unchangeable, procedural documentation), DATEV/ERP export, handling of VAT per rate, mileage and per-diem rules, data deletion.

Path B — Build on cloud APIs

• Receipt-specific: Azure AI Document Intelligence prebuilt-receipt (v4.0 GA, extracts merchant, date, totals, tax, TaxDetails with rate and net amount, CountryRegion, hotel VAT tables) [1]; AWS Textract AnalyzeExpense (standard fields incl. vendor VAT number, subtotal, tax, line items with EXPENSE_ROW) [2]; Google Document AI Expense Parser.
• General VLM: Mistral OCR (EU provider; mistral-ocr-latest, markdown plus bounding blocks and annotation-based structured output) [5], or a frontier multimodal model (Claude, Gemini, GPT) with structured outputs and a schema; good for long-tail layouts, crumpled slips and foreign languages.
• Orchestration: n8n / Power Automate / small service; accounting API write-back; key stored in a vault; EU region or EU provider; zero-retention settings.
• Choose B when: you embed capture into your own app, ERP or portal.

Path C — Self-host (open source)

• Parsing: Docling (MIT) with Granite-Docling-258M (Apache 2.0, runs even on CPU) [3][4]; PaddleOCR, MinerU, olmOCR.
• VLM extraction: Qwen3-VL (2B, 4B, 8B, 32B dense and MoE variants, Apache 2.0, OCR in 32 languages with robustness to blur, low light and tilt) [6], served via vLLM or Ollama with constrained JSON decoding.
• Stack: n8n, a rules/validation layer in code, Postgres, object storage plus a GoBD-compliant DMS.
• Hardware: HW2 (one 24 GB GPU) handles typical SMB/department volumes with a 4B to 8B VLM; Granite-Docling alone fits HW1. Needed for public sector or sensitive receipts (medical, union, political donations).

Path D — Custom training

Rarely needed. Worth it only for very high volumes, special receipt types (fuel pumps, tolls, local transit tickets) or on-device models. Fine-tune a small VLM or layout model on a few hundred to a few thousand receipts; user corrections in the confirm screen are the natural label source. CORD (CC BY 4.0) [7a] is useful for pre-training/benchmarking but not representative of German Kassenbons.

State of the art (2026)

• Template-free VLM reading is standard; small open VLMs (2B to 8B) read most clean receipts, and specialised OCR models are tiny (Granite-Docling 258M). Differences between vendors now lie in validation, matching and workflow, not raw reading.
• Structured/constrained outputs remove malformed JSON; confidence scores per field (Textract, Azure, Mistral OCR page confidence) drive review routing.
• Failure modes: faded thermal paper, crumpled or partially cropped slips, long receipts photographed in parts, handwritten tips and annotations, mixed VAT rates without per-line tax codes, receipts in several languages, QR/TSE fields misread as totals, and VLM "plausible" hallucinations. Always check maths (net + VAT = gross), date and currency.
• Authenticity: image generators can produce realistic fake receipts, so image-only evidence is weaker than before. Mitigations: match to card/bank transactions, merchant and tax-ID checks, duplicate hashes, metadata and anomaly checks (see ANOM-009), rather than relying on visual inspection. No reliable public statistic on prevalence was verified.
• Trend: receipts increasingly arrive digitally (e-receipts, wallet passes, e-tickets); card-feed-first products attach the receipt to a transaction instead of creating the expense from the receipt.

Shared resources & combinations

• Same stack (ocr-docparse + vlm + llm-general): DOC-001 invoices, DOC-003 forms, DOC-004 ID documents, DOC-006 logistics documents, DOC-008 mailroom classification, DOC-014 document parsing, DOC-017 bank statements; one self-hosted VLM server (HW2/HW3) can serve all of them.
• Downstream: ANOM-009 (expense fraud and policy detection), AGENT-006 (reconciliation and close), AGENT-002 (back-office workflow for approvals and reminders for missing receipts).
• Private: PERS-013 (tax return assistant) reuses extraction for household receipts.
• Building blocks: mobile capture SDK, accounting export (DATEV), merchant master data, category/G/L mapping, GoBD archive, FX rates, per-diem rule table.

Effort, cost & KPIs

• Path A: days to weeks; typically per-user or per-report SaaS pricing (check current price lists).
• Path B: 1 to 2 months for app/portal integration, validation rules and ERP export; API cost per page is small relative to manual handling.
• Path C: 1 to 3 months; one GPU server (or CPU for small parser), plus ops and GoBD archive work.
• Path D: additional months and labelled data; usually not cost-effective.
• KPIs: field-level accuracy (total, date, VAT) on own samples; share of receipts confirmed without edits; time from purchase to submission; reimbursement cycle time; missing-receipt rate; duplicate or policy-breach findings; accountant minutes per report.

People & change

Involve early: management for policy and budget, accounting and HR as owners, IT for accounting integration, and the DPO because receipts and card data reveal travel, health and private habits (GUIDE-005). Every employee is an end user, so involve a few of them from the start.

Works council: yes, in practice. The system records per-person spending, locations and behaviour and is objectively suited to monitor employees, so §87(1) no. 6 BetrVG applies, and §90(1) no. 3 requires information about the AI-supported process. Conclude a works agreement on purpose limitation, retention and no use for performance evaluation (GUIDE-004). Public bodies involve the Personalrat.

DPIA/AVV: a DPIA is usually not needed for plain capture, but check it if anomaly scoring on individuals is added; always sign an AVV with the vendor (GUIDE-010).

AI literacy: Art. 4 AI Act requires measures that support staff's AI literacy; a 30-minute introduction on how the app reads receipts and where to correct is enough (GUIDE-006).

Communication and pilot: emphasise less manual typing and faster reimbursement; pilot with one department and frequent travellers for one expense cycle (GUIDE-008).

Typical concerns: surveillance (state the exact checks and that flags are no sanctions), privacy of private purchases (policy excludes them), and errors (user always confirms the extraction).

Humans in control: flagged items go to a human reviewer; no automatic rejection.

Risks, regulation & compliance

• EU AI Act: minimal risk for capture itself (not an Annex III use). Becomes sensitive if expense data is used to score or discipline employees (Annex III no. 4 on employment and worker management can then apply, e.g. automated flagging that drives dismissal decisions). Keep flags advisory, human decision, document purpose. AI literacy duty (Art. 4) applies [8].
• GDPR: receipts reveal personal data and can reveal special categories (pharmacy, medical, union dues, religious or political donations, meals indicating health or religion); location and time patterns of employees. Need lawful basis, data minimisation, retention limits, DPA with processors, EU hosting, works council (Betriebsrat) involvement in Germany for expense apps. Private-use apps: purpose limitation, no resale of line-item data.
• Tax and bookkeeping (DE): GoBD and AO require unchangeable, traceable archiving; paper originals may be destroyed after compliant scanning if procedural documentation (Verfahrensdokumentation) exists; input VAT deduction requires formally correct invoice data (section 14 UStG; small-amount invoices have reduced mandatory fields), hospitality needs specific information. Tax treatment must be verified with the tax adviser; this is not legal advice. Check current BMF letters.
• Security: photo uploads of cards or IBANs, prompt injection in text on receipts or PDFs (never let extracted text drive tool actions), forged receipts.
• Mitigations: human confirm on mobile, confidence thresholds, validation rules, matching to transaction, audit log of AI value vs. final value, role-based access.

Getting started

1. Collect 100 to 200 real receipts from your own employees (thermal, hotel, foreign, hospitality), label totals/VAT/date to create a test set.
2. Try two or three Path A tools and one VLM/API (Path B) on that set; compare field accuracy and confirm-rate.
3. Define policy: categories, per-diem, limits, who approves, hospitality fields, and which fields humans must always confirm.
4. Clarify GoBD (Verfahrensdokumentation), retention, DPA and works-council agreement before go-live.
5. Roll out to a pilot team with card-feed matching, measure KPIs monthly and feed corrections back into category rules.

Sources

1. Microsoft Learn — Document Intelligence receipt model (v4.0) — https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/receipt
2. AWS — Amazon Textract, Analyzing invoices and receipts — https://docs.aws.amazon.com/textract/latest/dg/invoices-receipts.html
3. Docling project (MIT, LF AI & Data) — https://github.com/docling-project/docling
4. IBM Granite-Docling-258M model card — https://huggingface.co/ibm-granite/granite-docling-258M
5. Mistral AI — Document AI / OCR docs — https://docs.mistral.ai/capabilities/document_ai/basic_ocr/
6. Qwen3-VL repository (models, license, OCR) — https://github.com/QwenLM/Qwen3-VL
7. Taxmaro — Reisekostenpauschalen 2026 (per-diem rates) — https://www.taxmaro.com/post/reisekostenpauschalen-2026 7a. CORD receipt dataset (clovaai) — https://github.com/clovaai/cord
8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj