Forem: MaKriRich

E-Invoicing in Germany: What Developers Need to Know (2027 Deadline)

MaKriRich — Mon, 13 Apr 2026 18:38:47 +0000

If you build software for the German market, you need to know about e-invoicing. Germany is rolling out mandatory electronic invoicing for all B2B transactions, and the deadlines are closer than you think.

This article covers the technical side: what formats you need to support, how they work, and what tools are available.

The Timeline

Date	Requirement
Jan 1, 2025	All businesses must be able to receive e-invoices
Jan 1, 2027	Businesses with >800K EUR revenue must send e-invoices
Jan 1, 2028	All businesses must send e-invoices

"E-invoice" means structured, machine-readable data. A PDF attached to an email is NOT an e-invoice, even if it looks like one.

The Two Formats

XRechnung

Standard: CIUS (Core Invoice Usage Specification) based on EN 16931
Syntax: UBL 2.1 (Universal Business Language) or CII
Use case: Primarily B2G (business to government), increasingly B2B
Current version: 3.0.2

An XRechnung is a pure XML file. No visual representation -- just data. Government portals (ZRE, OZG-RE) require this format.

Example structure (simplified):

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <ID>RE-2026-0042</ID>
  <IssueDate>2026-03-18</IssueDate>
  <InvoiceTypeCode>380</InvoiceTypeCode>
  <DocumentCurrencyCode>EUR</DocumentCurrencyCode>
  <BuyerReference>04011000-12345-67</BuyerReference>
  <AccountingSupplierParty>
    <Party>
      <PartyName><Name>Beispiel GmbH</Name></PartyName>
    </Party>
  </AccountingSupplierParty>
  <LegalMonetaryTotal>
    <TaxExclusiveAmount currencyID="EUR">1500.00</TaxExclusiveAmount>
    <TaxInclusiveAmount currencyID="EUR">1785.00</TaxInclusiveAmount>
    <PayableAmount currencyID="EUR">1785.00</PayableAmount>
  </LegalMonetaryTotal>
</Invoice>

ZUGFeRD / Factur-X

Standard: Based on EN 16931, using CII (Cross Industry Invoice) syntax
Container: PDF/A-3 with embedded XML
Use case: B2B (universal), human-readable AND machine-readable
Current version: 2.3

ZUGFeRD is the pragmatic format. It looks like a normal PDF to humans (you can print it, email it, archive it), but it contains a hidden XML file (factur-x.xml) with all the structured data. Software can extract and process the XML automatically.

Profiles (from least to most data):

Minimum -- Invoice number, date, amounts only
Basic WL -- Basic without line items
Basic -- With line items
EN16931 -- Full EN 16931 compliance (recommended)
Extended -- Additional fields beyond the standard

Factur-X is the French name for the same standard. ZUGFeRD 2.3 = Factur-X 1.0.06.

Key Technical Challenges

Different XML Trees for the Same Data

UBL and CII represent the same invoice data in completely different XML structures. If you need to support both, you need separate builders/parsers or an internal format that maps to both.

Example -- Seller name:

UBL: Invoice > AccountingSupplierParty > Party > PartyName > Name
CII: CrossIndustryInvoice > SupplyChainTradeTransaction > ApplicableHeaderTradeAgreement > SellerTradeParty > Name

German Business Rules (BR-DE)

On top of EN 16931, Germany adds its own rules. The important ones:

Rule	What it checks
BR-DE-01	Payment instructions must be present
BR-DE-02	Bank account required for bank transfers
BR-DE-03	Seller must have email
BR-DE-07	Seller must have VAT ID or tax number
BR-DE-13	Buyer Reference (BT-10) is mandatory
BR-DE-14	Tax rate must be > 0 for standard category
BR-DE-17	German VAT ID format validation
BR-DE-18	IBAN format validation

Full list: KoSIT XRechnung Schematron rules

PDF/A-3 for ZUGFeRD

Creating a ZUGFeRD PDF means:

Generate a visual PDF (the human-readable invoice)
Convert it to PDF/A-3 (add ICC color profile, XMP metadata)
Embed the CII XML as a file attachment named factur-x.xml
Add Factur-X metadata to the XMP

This is harder than it sounds. Many PDF libraries don't support PDF/A-3 properly. In JavaScript, pdf-lib handles it but requires manual metadata management.

Validation

The official validation tool is the KoSIT Validator (Java). For production use, you might want:

XML well-formedness check
XSD schema validation
Schematron business rule validation (the BR-DE rules)

Running full Schematron validation in JavaScript is non-trivial. Pragmatic approach: implement the 20 most common rules as code, defer full Schematron to Phase 2.

Tools and Libraries

For JavaScript/TypeScript

fast-xml-parser -- Parse and build XML without native dependencies
pdf-lib -- Create and modify PDFs (including PDF/A-3), pure JavaScript
einvoice-mcp -- MCP server with 6 tools for XRechnung/ZUGFeRD (MIT, npm)

For Python

factur-x -- Official Factur-X library (ZUGFeRD PDF creation)
xrechnung-python -- XRechnung generation

For Java

KoSIT Validator -- Official validation tool
mustangproject -- ZUGFeRD/Factur-X library

Official Resources

What You Should Do Now

If you're building invoicing software for the German market:

Start with receiving: Parse incoming XRechnung (UBL) and ZUGFeRD (CII + PDF) -- extract the structured data
Add validation: At minimum, check the BR-DE rules
Build sending: Generate valid XML, test against the KoSIT test suite
Prepare for PDF/A-3: If you need ZUGFeRD, budget time for PDF/A compliance

The 2027 deadline is 9 months away. If your software handles German invoices, this isn't optional anymore.

I built einvoice-mcp to make this easier. It's an open-source MCP server that handles XRechnung and ZUGFeRD creation, validation, and conversion. MIT licensed, no native dependencies, runs anywhere Node.js runs.

Questions? Find me on GitHub.

Automate sevDesk & Lexoffice with n8n -- A Complete Guide

MaKriRich — Mon, 13 Apr 2026 18:30:14 +0000

If you run a business in Germany, Austria, or Switzerland, you probably use sevDesk for invoicing or Lexoffice for bookkeeping -- maybe both. They're good tools, but they don't talk to each other. And every manual sync between them is time you're not spending on actual work.

This guide shows you how to automate three common workflows using n8n and the BuchPilot community nodes.

Prerequisites

n8n (self-hosted or cloud). If you don't have it yet: n8n.io
sevDesk account with API token (Settings > Users > API Token)
Lexoffice account with API key (app.lexoffice.de/addons/public-api)

Step 1: Install BuchPilot Nodes

In n8n, go to Settings > Community Nodes > Install a community node and enter:

n8n-nodes-buchpilot

Click Install. Done. You now have four new nodes:

sevDesk (actions)
sevDesk Trigger (polling)
Lexoffice (actions)
Lexoffice Trigger (webhook)

Step 2: Set Up Credentials

sevDesk

In n8n: Credentials > New > "sevDesk API"
Paste your API token
Save

Lexoffice

In n8n: Credentials > New > "Lexoffice API"
Paste your API key
Save

Workflow 1: Contact Sync (sevDesk to Lexoffice)

The problem: You create a new client in sevDesk, then have to manually re-enter them in Lexoffice.

The solution: A workflow that runs every minute and syncs new contacts automatically.

How to build it

Add sevDesk Trigger node
- Event: New Contact
- Polling interval: Every 1 minute (default)
Add a Set node (data mapping)
- sevDesk uses surename for last name (yes, that's the actual field name)
- Lexoffice uses lastName
- Map: {{ $json.surename }} -> lastName
- If name2 (company name) exists: set contactType to company, otherwise person
Add Lexoffice node
- Resource: Contact
- Operation: Create
- Role: Customer
Activate the workflow

From now on, every new sevDesk contact appears in Lexoffice within a minute.

Handling duplicates

Lexoffice doesn't reject duplicates by default. Add an IF node before the Lexoffice node that checks if a contact with the same name/email already exists using Lexoffice > List Contacts with a filter.

Workflow 2: Invoice Booking (sevDesk to Lexoffice)

The problem: Every invoice you write in sevDesk needs to be manually booked as a voucher in Lexoffice.

The solution: Automatic booking whenever a new invoice appears.

How to build it

Add sevDesk Trigger node
- Event: New Invoice
Add sevDesk node (fetch full details)
- Resource: Invoice
- Operation: Get
- ID: {{ $json.id }}
Add a Set node (mapping)
- totalNet -> Lexoffice totalNetAmount
- taxRate -> Lexoffice taxRatePercentage
- totalGross -> Lexoffice totalGrossAmount
Add Lexoffice node
- Resource: Voucher
- Operation: Create
- Voucher Type: Purchase Invoice
Activate

Important: Tax handling

sevDesk invoices can have multiple line items with different tax rates (19%, 7%, 0%). The simple mapping above works for single-rate invoices. For multi-rate invoices, you'd need a loop that creates one voucher line per tax rate.

Workflow 3: Weekly Overdue Invoice Report

The problem: You forget to follow up on unpaid invoices.

The solution: An automated email every Monday listing all open and overdue invoices.

How to build it

Add Schedule Trigger node
- Cron: 0 8 * * 1 (Monday 8:00 AM)
Add sevDesk node
- Resource: Invoice
- Operation: Get Many
- Filter: Status = Open (200)
Add IF node
- Condition: invoiceDate + timeToPay days < today
- True branch = overdue, False branch = open but not yet due
Add Set node (formatting)
- Create a readable summary: invoice number, client name, amount, due date
Add Send Email node
- To: your email
- Subject: "Weekly Invoice Report"
- Body: the formatted summary
Activate

You'll never miss an overdue invoice again.

Tips & Gotchas

Polling vs Webhook: The sevDesk Trigger uses polling (checks the API periodically). It works behind firewalls and NATs -- no public URL needed. The Lexoffice Trigger uses webhooks (Lexoffice sends events to your n8n). This needs a public URL.

Rate limits: Lexoffice allows max 2 requests per second. The BuchPilot nodes handle this with a built-in 500ms delay. You don't need to add Wait nodes.

Error handling: Add an Error Branch to each workflow. If a Lexoffice or sevDesk API call fails, catch the error and send yourself a notification instead of losing the data silently.

Next Steps

These three workflows cover the most common use cases. Once they're running, you can extend them:

Add Slack/Telegram notifications instead of email
Create credit notes automatically when invoices are cancelled
Sync payments between the two systems
Add XRechnung/ZUGFeRD e-invoice generation (using einvoice-mcp)

How I Built an MCP Server for German Accounting (XRechnung/ZUGFeRD)

MaKriRich — Mon, 13 Apr 2026 18:28:44 +0000

Germany just made electronic invoicing mandatory. Starting January 2027, businesses with more than 800,000 EUR in annual revenue must send invoices in structured XML formats -- XRechnung or ZUGFeRD. By January 2028, every single business in Germany has to comply.

That's millions of businesses that need to produce machine-readable invoices instead of PDFs. And most of them have no idea how.

I decided to build a tool that solves this -- not as a SaaS, but as an open-source MCP server that any AI agent can use.

What is MCP?

Model Context Protocol (MCP) is an open standard by Anthropic that lets AI agents (like Claude, GPT, or local models) use external tools. Think of it as "function calling, but standardized." An MCP server exposes tools with JSON schemas, and any MCP-compatible client can discover and call them.

This matters because accounting is exactly the kind of task AI agents can help with: structured data, well-defined rules, repetitive operations.

The E-Invoice Landscape in Germany

Two formats dominate:

XRechnung -- Pure XML based on UBL 2.1 (Universal Business Language). Required for invoices to German government agencies. Increasingly used in B2B.

ZUGFeRD -- A CII (Cross Industry Invoice) XML embedded inside a PDF/A-3 file. The visual PDF looks normal to humans, but the embedded XML makes it machine-readable. Compatible with the French standard Factur-X.

Both follow the European standard EN 16931. Germany adds its own business rules on top (prefixed BR-DE-*).

Architecture Decisions

I had to make several key decisions early on:

Standalone package, not a plugin

I'm also building BuchPilot -- n8n nodes and an MCP server for Lexoffice (a popular German accounting tool). Initially, I considered adding e-invoice support there. But the dependencies are different (PDF libraries add ~50MB), and the audience is broader. Anyone who sends invoices in Germany needs e-invoicing -- not just Lexoffice users.

So einvoice-mcp is its own npm package. But it exports a registerEInvoiceTools() function, so BuchPilot can add its 6 tools in two lines of code.

No native dependencies

XML validation libraries like libxmljs2 require native compilation (node-gyp). That's a nightmare for cross-platform distribution. Instead, I went with fast-xml-parser for XML handling and implemented the 20 most important German business rules as TypeScript functions.

Is it 100% spec-compliant? No. Does it catch 95% of real-world errors? Yes. And it runs everywhere without a C compiler.

UBL for XRechnung, CII for ZUGFeRD

The German coordination body (KoSIT) recommends UBL 2.1 for XRechnung. Government portals expect UBL. So XRechnung output is UBL.

ZUGFeRD is based on CII (Cross Industry Invoice), a completely different XML structure. Same data, different tree. The internal data model is format-agnostic, and mapping functions handle the conversion.

The 6 Tools

validate_invoice

Takes XML or PDF, runs three levels of checks:

Syntax: Is the XML well-formed?
Schema: Are all required fields present with correct types?
Business Rules: 20 BR-DE rules -- IBAN format, VAT ID format, mandatory buyer reference, etc.

create_xrechnung

Takes structured data (seller, buyer, line items, payment info) and generates valid UBL 2.1 XML. Conforms to XRechnung 3.0.2.

The hardest part was getting the tax calculation right. German invoices have different tax categories (Standard 19%, Reduced 7%, Zero-rated, Reverse Charge, Intra-community), and each has different rules for what fields are required.

create_zugferd

Same input data, but outputs a PDF/A-3 with embedded CII XML. Uses pdf-lib (pure JavaScript, no Puppeteer) for PDF generation.

convert_format

Converts between UBL, CII, and JSON. Useful when you receive a ZUGFeRD invoice (CII) but need to forward it as XRechnung (UBL).

extract_data

Reads XML or ZUGFeRD PDF and returns structured JSON. Handy for importing invoices into accounting systems.

get_format_info

A reference tool that helps AI agents understand the format requirements -- required fields, tax categories, unit codes (UN/ECE Rec 20), and the legal deadlines.

Implementation Highlights

German Business Rules as Code

The BR-DE rules are implemented as simple TypeScript functions:

function checkBRDE07(invoice: InvoiceData): ValidationIssue | null {
  const seller = invoice.seller;
  if (!seller.vatId && !seller.taxNumber) {
    return {
      rule: "BR-DE-07",
      level: "error",
      location: "/Invoice/AccountingSupplierParty",
      message: "Seller must have either VAT ID (USt-IdNr.) or tax number (Steuernummer)"
    };
  }
  return null;
}

20 of these cover the most common validation failures. They're modular -- when XRechnung 3.1 comes out (it always does, yearly), I can update individual rules without touching the rest.

The Plugin Pattern

// Standalone:
npx einvoice-mcp

// As plugin in another MCP server:
import { registerEInvoiceTools } from "einvoice-mcp";
registerEInvoiceTools(yourMcpServer);

This works because MCP tools are just name + schema + handler. Registering them on another server is trivial.

What's Next

Full XSD validation (probably via WASM-based XML validator)
More ZUGFeRD profiles (currently EN16931, adding Basic and Extended)
Automated testing against KoSIT's official XRechnung test suite
Integration with BuchPilot MCP (Lexoffice creates invoice -> einvoice-mcp creates XRechnung)

Try It

npx einvoice-mcp

Or install it permanently:

npm install -g einvoice-mcp

Source: github.com/makririch/einvoice-mcp

MIT licensed. Contributions welcome.

If you're building tools for the German market and need e-invoice support -- feel free to use the package or the plugin pattern. The 2027 deadline is coming faster than you think.

Forem: MaKriRich

E-Invoicing in Germany: What Developers Need to Know (2027 Deadline)

The Timeline

The Two Formats

XRechnung

ZUGFeRD / Factur-X

Key Technical Challenges

Different XML Trees for the Same Data

German Business Rules (BR-DE)

PDF/A-3 for ZUGFeRD

Validation

Tools and Libraries

For JavaScript/TypeScript

For Python

For Java

Official Resources

What You Should Do Now

Automate sevDesk & Lexoffice with n8n -- A Complete Guide

Prerequisites

Step 1: Install BuchPilot Nodes

Step 2: Set Up Credentials

sevDesk

Lexoffice

Workflow 1: Contact Sync (sevDesk to Lexoffice)

How to build it

Handling duplicates

Workflow 2: Invoice Booking (sevDesk to Lexoffice)

How to build it

Important: Tax handling

Workflow 3: Weekly Overdue Invoice Report

How to build it

Tips & Gotchas

Next Steps

Links

How I Built an MCP Server for German Accounting (XRechnung/ZUGFeRD)

What is MCP?

The E-Invoice Landscape in Germany

Architecture Decisions

Standalone package, not a plugin

No native dependencies

UBL for XRechnung, CII for ZUGFeRD

The 6 Tools

validate_invoice

create_xrechnung

create_zugferd

convert_format

extract_data

get_format_info

Implementation Highlights

German Business Rules as Code

The Plugin Pattern

What's Next

Try It