Finance workflow
E-invoice workflow automation for German companies
A practical operating model for XRechnung and ZUGFeRD: receive, validate, review, approve, post, archive, and route exceptions without turning tax judgement into a black box.
Direct answer
- German businesses have had to be able to receive an E-Rechnung since 1 January 2025. An email inbox is enough for receipt, but it is not an automated operating process.
- The issuance transition runs through the end of 2026 for all issuers. Businesses with prior-year turnover up to €800,000 can use the extended transition through the end of 2027. Confirm applicability with your tax adviser.
- A reliable workflow has eight stages: intake, malware and format checks, visualisation, business validation, approval, accounting transfer, original-file retention, and exception or correction handling.
- Parse structured XML deterministically. Do not send XRechnung through OCR or an LLM to rediscover fields that already exist in the document.
- Keep human approval for payment release, supplier bank-detail changes, duplicate or mismatch decisions, and tax questions the system cannot resolve from agreed rules.
The legal floor and the operational opportunity
Being able to receive an E-Rechnung is not the same as processing it safely.
The German Federal Ministry of Finance FAQ says a German business must be able to receive E-Rechnungen from 1 January 2025 and that an email inbox can satisfy the receipt requirement. It also says the recipient is not required to automate further processing. That distinction matters: the law sets a receipt floor, while operations decides whether invoices still wait in mailboxes and spreadsheets.
The BMF transition guidance permits other invoice forms through 31 December 2026. Issuers with prior-year turnover up to €800,000 have an extension through 31 December 2027. The dates govern issuance while intake readiness remains a separate operational decision. The IHK and DATEV practical guide maps receipt, validation, visualisation, approval, archive, and downstream processing as one chain.
This page explains technical workflow design. Tax and legal advice sit outside its scope. Your tax adviser should confirm scope, exceptions, retention practice, and the treatment of unusual transactions. Your implementation partner should make those decisions visible in rules, queues, logs, and access controls.
An inbox proves that a file arrived. A workflow proves what happened next, who approved it, and what the accounting system received.
Reference workflow
Eight stages from receipt to evidence.
| Stage | Automated action | Human or system control | Evidence retained |
|---|---|---|---|
| 1. Intake | Collect dedicated mailbox, portal, API, Peppol, and approved upload sources into one queue | Reject unapproved channels or route them for manual intake | Original message, transport metadata, attachment hash, received time |
| 2. Security and format | Scan attachments, identify XRechnung, ZUGFeRD, PDF, image, or unsupported file, then quarantine failures | Never parse an unsafe attachment inside the accounting workflow | Scan result, detected format and version, quarantine reason |
| 3. Technical validation | Validate structured data against the supported EN 16931 profile and required fields | Technical validity does not certify tax correctness or business approval | Validator version, errors, warnings, and raw result |
| 4. Visualisation | Render XML for a readable review and compare hybrid document representations where relevant | For ZUGFeRD differences, current BMF guidance makes the structured part authoritative | Viewer version and the structured source used for review |
| 5. Business checks | Match supplier, purchase order, delivery, amount, tax identifiers, currency, and duplicate signals | Route mismatches and supplier-master changes to an authorised person | Rules applied, match result, exception code, source records |
| 6. Approval | Assign approver by entity, cost centre, project, amount, and substitution rules; send reminders | A person approves payment-relevant exceptions and ambiguous coding | Approver, decision, timestamp, comment, delegation |
| 7. Accounting and payment | Create a draft posting or export to DATEV or ERP after approval | Separate posting approval from bank payment release and enforce role boundaries | Export ID, destination record, reconciliation status |
| 8. Archive and correction | Retain the original structured component, link corrections, and preserve the processing history | Tax adviser confirms retention and correction treatment for the business | Immutable original, correction relationship, access and change log |
Where AI helps and where it does not
Use deterministic rules first. Add AI only for the unstructured edge.
Structured XML: parse it
XRechnung and the structured part of ZUGFeRD already contain machine-readable fields. Use a supported parser and validator. Sending that XML through OCR or asking a language model to infer totals adds cost and uncertainty without adding information.
PDF and scans: extract with confidence
Legacy PDF and scanned invoices may need OCR or document extraction during the transition. Store field-level confidence, route low-confidence values to review, and keep the original document. Do not silently convert an uncertain extraction into an approved accounting record.
Coding suggestions: propose, do not conceal
AI can suggest cost centre, project, or account from prior approved invoices. Show the source and confidence, let an authorised person correct it, and log the final decision. A suggestion is useful; an unexplained posting is an audit problem.
Exceptions: make a queue
Unknown supplier, changed IBAN, duplicate number, purchase-order mismatch, unsupported format, and validation error should become explicit exception types. Each type needs an owner, deadline, next action, and escalation route.
Approval boundary
What can run automatically and what should stop.
| Decision | Safe default | Reason |
|---|---|---|
| Receive, fingerprint, classify, and archive the original | Automate | Deterministic and reversible when logs are retained |
| Validate supported XML profile and required fields | Automate | Use a versioned validator and keep its result |
| Match known supplier, PO, amount, and duplicate rules | Automate, then route exceptions | Rules are testable; exceptions carry business risk |
| Create an accounting draft from approved data | Automate with reconciliation | The destination record can be compared with the source |
| Accept a new or changed supplier bank account | Human approval and independent verification | Payment redirection has high fraud impact |
| Approve a mismatch, unusual tax treatment, or missing evidence | Human approval | Requires accountable business or tax judgement |
| Release payment | Separate authorised approval | Maintain segregation between processing and payment |
| Delete or replace the original structured invoice | Do not automate | The original and its integrity are part of the evidence trail |
Compliance next step
Get a compliance check on: E-invoice workflow automation Germany
Send us where your site stands today. We reply with the risks that carry real exposure, not a generic checklist.
Implementation brief
Questions to answer before choosing a connector or invoice platform.
✓
List every intake channel: mailbox, portal, API, Peppol, scanner, shared drive, and manual download.
✓
Name supported formats and versions, plus the owner for unsupported files.
✓
Confirm which validator is used, how it is versioned, and where errors and warnings are retained.
✓
Define supplier, PO, delivery, amount, currency, duplicate, and bank-detail checks.
✓
Write approval rules for entity, cost centre, project, amount, substitution, absence, and escalation.
✓
Separate technical validation, business approval, tax review, posting, and payment permissions.
✓
Map DATEV or ERP fields, idempotency keys, retry behavior, duplicate protection, and reconciliation.
✓
Define retention with the tax adviser, including the original structured component and correction links.
✓
Test known-good invoices, malformed files, duplicates, changed bank details, missing PO, and destination outage.
✓
Assign an operational owner and measure queue age, exception rate, failed exports, and time to approval.
How Some Tech Work approaches it
Integrate the workflow around your accounting system, not around an AI demo.
We start with the actual invoice channels, approval policy, accounting destination, exceptions, and evidence requirements. Then we decide what belongs in standard software, what needs an integration, and whether any unstructured step benefits from document extraction. The build can connect mailboxes, validation services, review queues, DATEV or ERP APIs, and monitoring without replacing the accounting system.
Use the free AI automation opportunity scorecard to test volume, economics, data boundaries, failure cost, and ownership. If the workflow is ready, see workflow automation and integrations and APIs.
Questions from German finance and operations teams
E-Rechnung workflow answers before implementation.
Does every German business need to receive E-Rechnungen?
The BMF says domestic businesses have needed the ability to receive an E-Rechnung since 1 January 2025, including small businesses that may be exempt from issuing one. An email inbox can satisfy receipt. Confirm how the rule applies to your entity and transactions with a qualified adviser. BMF source.
When does issuing an E-Rechnung become mandatory in Germany?
The general transition for other invoice forms runs through 31 December 2026. Issuers with prior-year turnover up to €800,000 have an extension through 31 December 2027, and certain EDI arrangements also have a transition through 2027. The exact obligation depends on the transaction and exceptions. BMF transition guidance.
Is a PDF invoice an E-Rechnung?
A normal PDF lacks the structured data required for automated E-Rechnung processing. ZUGFeRD is a hybrid format with structured data attached to a readable PDF. XRechnung is structured XML and may need a viewer.
Do we need AI to process XRechnung?
No. XRechnung is structured XML. Use deterministic parsing and a supported validator. AI or OCR may help with legacy PDFs, scans, coding suggestions, or exception summaries, but it should not replace reliable parsing of fields already present in XML.
Can an automated workflow release invoice payments?
The system can prepare records and route approvals, but payment release should remain behind separate, authorised controls. New bank details, mismatches, unusual tax treatment, and missing evidence should stop for review. The exact segregation policy belongs to finance, security, and the tax adviser.
What should be stored for an E-Rechnung?
The BMF says at least the structured part must be retained intact in its original form and currently states an eight-year retention period for VAT purposes. Retention and GoBD implementation need adviser confirmation for your situation. Keep the original, validation result, approvals, export reference, corrections, and access history. BMF retention guidance.
Written by
Vineet Talwar
Co-founder, Tech & Operations at Some Tech Work. WordCamp speaker across Europe and Asia, and host of the WP Shoutout podcast.
Start here
Ready to talk.Book a short diagnostic.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.