Die Dokumenten-Schicht, die dein ERP sowieso irgendwann braucht

Wer hier gemeint ist

Entwickler, die ERP-, Warenwirtschafts- oder Buchhaltungs­systeme bauen oder erweitern — egal ob:

• Eigenentwicklung mit Java/C#/PHP-Stack
• SAP-Erweiterung (ABAP, SAP BTP, CAP)
• Odoo, Xentral, ERPNext, Akeneo-Module
• Integrations-Frühstück per Middleware (MuleSoft, webMethods, Dell Boomi)

Der typische Auslöser: 2025 kommt mit der E-Rechnungs­empfangs­pflicht, 2027 mit der Versand­pflicht — und das eigene System hat heute nur PDF-Druck aus Crystal Reports oder JasperReports. Die Lücke wird sichtbar.

Typische Pain Points

1. PDF-Rendering mit eigener Engine (JasperReports, BIRT, iText) ist dokumentiert, aber langsam in der Weiterentwicklung — Corporate Fonts, neue Format-Varianten und Signaturen sind jedes Mal ein Ticket
2. ZUGFeRD/XRechnung-Erzeugung kostet Wochen mit Mustang oder iText — und wird bei jeder Schema-Aktualisierung wieder zum Thema
3. GoBD-konforme Archivierung erfordert PDF/A plus Zeitstempel — meist nicht nativ im ERP
4. Batch-Druck zum Monats­abschluss stoßen Single-Threaded-Lösungen an Limits (50.000 Rechnungen in einer Nacht)
5. Cross-Country-Varianten (Factur-X für Frankreich, ebInterface für Österreich) multiplizieren den Pflege­aufwand

Vier typische Einsatz-Szenarien

1. Rechnungs­ausgabe im Batch

Monats­abschluss: 20.000 Rechnungen müssen in der Nacht als ZUGFeRD-PDFs und gleichzeitig als reine XRechnung-XML ans Kundenportal:

from dokmatiq import Client
from concurrent.futures import ThreadPoolExecutor

client = Client(api_key=os.environ["DOKMATIQ_KEY"])

def render_invoice(row):
    pdf = client.einvoice.zugferd(
        profile="EN16931",
        invoice=row.to_invoice_dict(),
        output_profile="PDF/A-3b",
        idempotency_key=f"invoice-{row.id}"
    )
    xml = client.einvoice.xrechnung(
        syntax="UBL",
        invoice=row.to_invoice_dict(),
        idempotency_key=f"xrechnung-{row.id}"
    )
    return row.id, pdf, xml

with ThreadPoolExecutor(max_workers=50) as pool:
    for row_id, pdf, xml in pool.map(render_invoice, invoice_rows):
        save_to_archive(row_id, pdf)
        enqueue_for_peppol(row_id, xml)

Die API ist stateless und horizontal skalierbar. 50 parallele Worker sind ein realistischer Startwert; für 50.000+ Rechnungen pro Nacht lohnt sich ein dedizierter Rate-Limit-Bucket.

2. ZUGFeRD aus bestehenden PDF-Rechnungen nachrüsten

Das ERP erzeugt schon Rechnungs-PDFs per JasperReports. Für die neue Pflicht soll der XML-Teil nachträglich eingebettet werden:

curl -X POST https://api.dokmatiq.com/v1/einvoice/embed-cii \
  -H "Authorization: Bearer $DOKMATIQ_KEY" \
  -F "document=@rechnung.pdf" \
  -F 'invoice={"id":"2026-0042","issueDate":"2026-04-18","seller":{...},"buyer":{...},"lines":[...]}' \
  -F "profile=EN16931" \
  -o rechnung-zugferd.pdf

Das bestehende visuelle Layout bleibt 1:1 erhalten, die API bettet das CII-XML als PDF/A-3-Anhang ein und konvertiert das PDF auf Wunsch auf PDF/A-3b. Kein Eingriff in die Report-Engine.

3. GoBD-konforme Archiv­pipeline

Für jeden erzeugten Beleg soll parallel zur Ablage im DMS eine GoBD-taugliche Version entstehen — PDF/A-3 plus qualifizierter Zeitstempel:

pdf_a3 = client.pdf.convert(
    document=source_pdf,
    target_profile="PDF/A-3b"
)
timestamped = client.pdf.timestamp(
    document=pdf_a3,
    tsa="qualified"
)
dms.archive(timestamped, metadata={"invoiceId": row.id, "retentionUntil": "2037-12-31"})

Der qualifizierte Zeitstempel (siehe Zeitstempel-Glossar) ist eIDAS-konform und erfüllt die GoBD-Anforderung an nachweislich unveränderte Aufbewahrung.

4. Cross-Country-Rechnung

Ein deutsches Unternehmen mit französischen Tochterfirmen braucht drei Formate parallel:

• Deutsche B2B-Rechnung: ZUGFeRD 2.x im Profil EN 16931
• Französische B2B-Rechnung ab 09/2026: Factur-X + Peppol-Transport
• Österreichische B2G: ebInterface 6.1 über USP

Statt drei Bibliotheken ein API:

client.einvoice.zugferd(profile="EN16931", ...)    # DE
client.einvoice.factur_x(profile="EN16931", ...)    # FR
client.einvoice.ebinterface(version="6.1", ...)     # AT

Alle drei Endpunkte sprechen intern dasselbe EN-16931-Datenmodell — das ERP liefert einmal die Invoice-Daten, der Rest ist Format-Wahl.

Welche Features besonders relevant sind

• E-Rechnungen — ZUGFeRD, XRechnung, Factur-X, ebInterface, Peppol BIS aus einem API
• Dokumentgenerierung — wenn eigene Report-Engine zu starr wird
• Excel-Generierung — für Auswertungen, DATEV-Exports, Listen
• PDF-Werkzeuge — Merge, Split, PDF/A-Konvertierung, Formulare ausfüllen
• Digitale Signaturen — PAdES per API, qualifizierte Zertifikate

Compliance-Kontext

Für deutsche ERPs sind mindestens diese Termine relevant:

• E-Rechnungspflicht Deutschland 2025 — Empfang ist Pflicht
• E-Rechnungspflicht Deutschland 2027 — Versand ab 800.000 € Umsatz
• E-Rechnungspflicht Frankreich 2026 — Y-Modell, PDPs, Factur-X

Die API deckt alle diese Termine technisch ab — die organisatorische Umsetzung bleibt beim ERP-Team.

Performance-Profil

Szenario	Durchsatz pro Node	Bemerkung
ZUGFeRD-Erzeugung (einfache Rechnung)	~40 docs/s	Limit meist CPU für Schematron-Validierung
Word zu PDF/A-3 (10 Seiten)	~8 docs/s	OpenXML-Parsing ist hungriger
PDF/A-Konvertierung (20-Seiten-PDF)	~12 docs/s	Font-Embedding dominiert
PAdES-Signatur mit TSA-Roundtrip	~5 docs/s	TSA-Round-Trip limitiert

Alle Zahlen sind horizontal skalierbar — mehr Parallelität bedeutet mehr Durchsatz. Für Batch-Läufe mit > 10k Dokumenten ist ein dedizierter Rate-Limit-Bucket sinnvoll (Enterprise-Plan).

Deployment-Optionen

• Managed API (Default) — gehostet in Deutschland, DSGVO, ISO 27001
• Self-Hosted per Docker-Container — für Szenarien mit regulatorischen Vorgaben (Gesundheits­sektor, öffentliche Hand)
• Hybrid: Steuerung managed, Dokumenten­erzeugung on-prem

Self-Hosting ist ausdrücklich unterstützt — kein versteckter Lock-in.

Wann Dokmatiq nicht die richtige Wahl ist

• Wenn du JasperReports schon beherrscht und keine E-Rechnungs-Pflicht hast — dann ist der Wechsel überflüssig
• Bei sehr speziellen Branchen­formaten ohne EN-16931-Mapping (manche EDI-Dialekte) — braucht Custom-Entwicklung
• Für rein interne Formular­generierung ohne Briefpapier — eine einfachere Library reicht

Häufige Stolpersteine

1. Batch-Größen zu konservativ — die API skaliert; 50 parallele Requests sind ein normales Start-Szenario
2. TSA-Timeouts bei Signaturen — die externe Zeitstempel-Autorität kann 1–3 s brauchen; im Client entsprechend großzügig timen
3. PDF/A-Konvertierung auf bestehenden PDFs — unembedded Fonts machen häufig Probleme; die API meldet sie präzise
4. Leitweg-ID fehlt im ERP-Stammsatz — muss je Behörden-Empfänger gepflegt werden; ein Pflichtfeld im Kunden­stamm vermeidet Überraschungen