EI Hub
implementation5 min read

XRechnung API Integration Guide 2026: How to Generate and Send XRechnung Programmatically

Developer guide to XRechnung API integration in 2026. REST APIs, XML generation, KoSIT validation, and Peppol delivery — with practical code patterns.

By EU E-Invoicing HubPublished: 5 May 2026Updated: 8 May 2026

XRechnung API Integration Guide 2026: Generate and Send XRechnung Programmatically

This guide is for developers building systems that need to generate and deliver XRechnung-compliant invoices — either for their own business or as part of a product serving German customers.

What XRechnung Is (Quick Recap for Developers)

XRechnung is the German national standard for structured electronic invoices. Technically, it is the German CIUS (Core Invoice Usage Specification) applied to the European standard EN 16931.

XRechnung comes in two XML syntax variants:

  • UBL 2.1 (Universal Business Language) — widely supported, recommended for new integrations
  • UN/CEFACT CII — used by some older German government systems

Both variants are functionally equivalent. If you are building a new integration, use UBL 2.1.

Minimum Required Fields (XRechnung 3.0)

XRechnung 3.0 (the current version as of 2026) requires these fields at minimum:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  
  <!-- Required: Business process identifier -->
  <cbc:CustomizationID>
    urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0
  </cbc:CustomizationID>
  
  <!-- Required: Invoice type code (380 = commercial invoice) -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  
  <!-- Required: Unique invoice number -->
  <cbc:ID>INV-2026-001</cbc:ID>
  
  <!-- Required: Issue date (format: YYYY-MM-DD) -->
  <cbc:IssueDate>2026-05-01</cbc:IssueDate>
  
  <!-- Required: Due date -->
  <cbc:DueDate>2026-05-31</cbc:DueDate>
  
  <!-- Required: Document currency code -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  
  <!-- Required in XRechnung 3.0: Buyer reference (BT-10) -->
  <!-- For B2G: this is the Leitweg-ID. For B2B: set to buyer's internal reference. -->
  <cbc:BuyerReference>04011000-12345-03</cbc:BuyerReference>
  
  <!-- ... seller (AccountingSupplierParty), buyer (AccountingCustomerParty), -->
  <!-- line items (InvoiceLine), tax totals (TaxTotal), -->
  <!-- payment means (PaymentMeans) all required -->
</Invoice>

Key Business Rules (XRechnung 3.0)

XRechnung adds German-specific business rules on top of EN 16931. The important ones:

Rule ID Description
BR-DE-1 BuyerReference (BT-10) is mandatory
BR-DE-2 Seller VAT ID or tax number required (at least one)
BR-DE-3 PaymentMeans with IBAN required for bank transfer invoices
BR-DE-16 ContactPoint (name) required for seller
BR-DE-17 ContactPoint (email or phone) required for seller

Validation Before Delivery

Never send an XRechnung without validating it first. Use the official KoSIT validator:

Option 1: KoSIT Online Validator

Upload your XML to the KoSIT Validator for free validation in the browser.

Option 2: KoSIT Validator REST API (for CI/CD integration)

KoSIT publishes a Docker image of the validator that you can run locally or in CI:

# Pull and run the validator service
docker pull itplr-kosit/validationtool:1.5.0
docker run -p 8080:8080 itplr-kosit/validationtool:1.5.0

# Validate an invoice via REST
curl -X POST http://localhost:8080/api/validate \
  -H "Content-Type: application/xml" \
  -d @invoice.xml

The response returns a JSON report with all validation errors and warnings.

Option 3: Java Command-Line (offline validation)

java -jar validationtool-1.5.0-standalone.jar \
  -s scenarios.xml \
  invoice.xml

Delivery Methods

Once validated, XRechnung invoices can be delivered via:

1. Email Attachment (Simplest)

For B2B invoices, email delivery is still valid. Attach the .xml file. Many German businesses also include a PDF alongside the XML for human readability.

invoice-2026-001.xml
invoice-2026-001.pdf  (optional, not mandatory)

2. Peppol Network (Recommended for B2B and B2G)

Peppol delivery provides automatic routing and delivery confirmation. You need a Peppol Access Point subscription from a certified provider:

Popular German Peppol access points:

  • easybill (API-native, per-document pricing)
  • Storecove (API-native, good for developers)
  • Open Peppol (via your accounting software)

Delivery via Peppol access point API (example with Storecove):

POST https://www.storecove.com/api/v2/invoice_submissions
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "document": {
    "document_type": "invoice",
    "invoice": { ... },  // invoice data in their structured format
    "routing": {
      "peppol": {
        "peppol_id": "0088:4012345678901"  // recipient's Peppol ID
      }
    }
  }
}

3. E-Mail Portal (PEPPOL SMP Lookup)

For B2G XRechnung, the routing requires the Leitweg-ID in the BuyerReference field. German public authorities typically receive via:

  • OZG-RE (Online-Zugang-Gesetz Rechnungseingang) — the government Peppol network
  • Or via ZRE (Zentrale Rechnungseingangsplattform des Bundes) for federal agencies

Using an E-Invoicing API Service

For most integrations, using a SaaS API that handles XRechnung generation and validation is faster than building from scratch:

easybill API (Germany-focused, full compliance)

POST https://api.easybill.de/rest/v1/documents
Authorization: Bearer YOUR_EASYBILL_API_KEY
Content-Type: application/json

{
  "type": "INVOICE",
  "customer_id": 12345,
  "document_date": "2026-05-01",
  "due_date": "2026-05-31",
  "title": "Invoice for May 2026 services",
  "items": [
    {
      "type": "POSITION",
      "description": "Software development consulting",
      "quantity": 10,
      "unit": "hours",
      "unit_price": 150.00,
      "vat_percent": 19.0
    }
  ],
  "einvoice": {
    "format": "XRECHNUNG_UBL",
    "version": "3.0",
    "buyer_reference": "04011000-12345-03"
  }
}

The API returns the validated XRechnung XML alongside the invoice record.

Testing Your Integration

  1. Use test Peppol IDs — OpenPeppol provides test environment IDs (format: 0088:test-XXXX)
  2. Validate every invoice — run every generated invoice through the KoSIT validator in your CI pipeline
  3. Test all VAT scenarios — standard rate (19%), reduced rate (7%), zero rate, reverse charge — each has different XML handling
  4. Test rejection handling — simulate what happens when the recipient's Peppol access point is unreachable

Common Errors

Error Code Cause Fix
BR-DE-1 Missing BuyerReference Add BT-10 field
BR-CO-09 VAT amounts don't sum correctly Check rounding logic (round per line, not at total)
BR-E-01 VAT category E (exempt) missing code Add VatExemptionReason code from list
BR-01 Invalid invoice type code Use 380 (commercial), 381 (credit note), 386 (prepayment)

Tools and Libraries

Tool Language Notes
mustangproject Java Open-source ZUGFeRD/XRechnung library
einvoice Python EN 16931 UBL generation
ubl-invoice Node.js UBL 2.1 builder
KoSIT Validator CLI/Docker Official German validation tool
xrechnungapideveloperintegrationgermanyublpeppolkositrest-api
← More ImplementationCompare Software →