E-Rechnung API

E-Rechnung API: XRechnung und ZUGFeRD aus Ihren Rechnungsdaten

Senden Sie die Rechnung als JSON und erhalten Sie eine E-Rechnung zurück: Ihr Rechnungs-PDF im eigenen Design als PDF/A-3b mit eingebettetem EN-16931-XML, oder die XRechnung als reines XML. Jede Datei wird vor der Auslieferung nach den offiziellen Regeln geprüft.

  • Geprüft mit KoSIT und veraPDF
  • CII und UBL
  • Gerendert in der EU

Was ist eine E-Rechnung API?

Eine E-Rechnung API macht aus Rechnungsdaten eine Rechnung, die Software lesen kann. Ihre Anwendung sendet Verkäufer, Käufer, Positionen und Umsatzsteuer als JSON; die API erzeugt daraus das strukturierte XML der europäischen Norm EN 16931, prüft es nach den offiziellen Regeln und bettet es entweder in Ihr Rechnungs-PDF ein (ZUGFeRD, Factur-X) oder liefert es einzeln (XRechnung). Die Buchhaltungssoftware des Empfängers liest das XML, Menschen lesen das PDF.

E-Rechnung API: die wichtigsten Fakten
Endpunkteeinvoice bei jedem PDF-Rendering, zum Beispiel POST https://api.dynamicdocumentapi.com/v1/pdf/from-template; POST /v1/einvoices für das XML allein
Hybrid-PDFZUGFeRD / Factur-X: PDF/A-3b mit eingebettetem UN/CEFACT-CII-XML; mit dem Profil XRECHNUNG eine eingebettete XRechnung-3.0-Datei
Nur XMLXRechnung oder EN 16931 in CII (UN/CEFACT D16B) oder UBL 2.1
ProfileMINIMUM, BASIC_WL, BASIC, EN16931, EXTENDED, XRECHNUNG
PrüfungJede Datei vor der Auslieferung: der KoSIT-Validator mit den Regeln für XRechnung, EN 16931 und Factur-X, veraPDF für PDF/A. Der Prüfbericht kommt mit dem Rendering zurück
SummenPositionsbeträge, Steueraufschlüsselung und Gesamtsummen nach den Regeln der EN 16931 berechnet und an Ihre Vorlage übergeben
RenderingIn der EU (Deutschland), aus Ihrer eigenen Vorlage, aus HTML, einer URL oder Markdown
PreisAb dem Tarif Growth: 47 €/Monat bei jährlicher Abrechnung (59 € monatlich) für 15.000 Renderings. Die E-Rechnung im PDF zählt kein zusätzliches Rendering, ein XML-Export zählt eines

Eine ZUGFeRD- oder Factur-X-Rechnung mit einer Anfrage erzeugen

Ergänzen Sie ein normales PDF-Rendering um einvoice. Das Rechnungsmodell steht in Ihren Vorlagendaten, und invoice_path zeigt darauf, sodass Seite und XML dieselben Zahlen verwenden. Die Engine rendert die Seite, erzeugt und prüft das XML, wandelt das PDF in PDF/A-3b um, bettet das XML ein und prüft die fertige Datei mit veraPDF. Ein guter Ausgangspunkt ist die E-Rechnung-Vorlage aus der Galerie: Sie druckt die berechneten Beträge und funktioniert mit jedem Profil.

curl https://api.dynamicdocumentapi.com/v1/pdf/from-template \
  -H "Authorization: Bearer $DYNAMIC_DOCUMENT_API_KEY" \
  -H "Idempotency-Key: R-2026-0042" \
  -H "Content-Type: application/json" \
  -d '{
    "template_id": "tpl_einvoice",
    "data": {
      "invoice": {
        "number": "R-2026-0042",
        "issue_date": "2026-09-23",
        "due_date": "2026-10-23",
        "currency": "EUR",
        "buyer_reference": "PO-4711",
        "delivery": { "date": "2026-09-22" },
        "seller": {
          "name": "Example GmbH", "vat_id": "DE123456789",
          "electronic_address": { "id": "invoices@example.com", "scheme": "EM" },
          "address": { "line1": "Beispielstraße 1", "city": "Berlin", "postcode": "10115", "country": "DE" }
        },
        "buyer": {
          "name": "Customer AG", "vat_id": "DE987654321",
          "electronic_address": { "id": "ap@customer.example", "scheme": "EM" },
          "address": { "line1": "Marktplatz 5", "city": "München", "postcode": "80331", "country": "DE" }
        },
        "payment": { "means_code": "58", "credit_transfers": [{ "account_id": "DE02120300000000202051" }] },
        "lines": [
          { "quantity": "10", "unit": "HUR", "price": { "net": "100.00" },
            "tax": { "category": "S", "rate": "19" }, "item": { "name": "Beratung" } }
        ]
      }
    },
    "einvoice": { "profile": "EN16931", "invoice_path": "invoice" },
    "filename": "{{ data.invoice.number }}.pdf",
    "delivery": "binary"
  }' \
  --output R-2026-0042.pdf
// Node.js 18+: render the invoice as a Factur-X / ZUGFeRD PDF
export async function renderEInvoice(invoice) {
  const res = await fetch("https://api.dynamicdocumentapi.com/v1/pdf/from-template", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.DYNAMIC_DOCUMENT_API_KEY}`,
      "Idempotency-Key": invoice.number, // safe to retry
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      template_id: "tpl_einvoice",
      data: { invoice },
      einvoice: { profile: "EN16931", invoice_path: "invoice" },
      filename: `${invoice.number}.pdf`,
      delivery: "binary",
    }),
  });
  if (!res.ok) throw new Error(await res.text());
  return Buffer.from(await res.arrayBuffer());
}
import os
import requests

def render_einvoice(invoice: dict) -> bytes:
    res = requests.post(
        "https://api.dynamicdocumentapi.com/v1/pdf/from-template",
        headers={
            "Authorization": f"Bearer {os.environ['DYNAMIC_DOCUMENT_API_KEY']}",
            "Idempotency-Key": invoice["number"],  # safe to retry
        },
        json={
            "template_id": "tpl_einvoice",
            "data": {"invoice": invoice},
            "einvoice": {"profile": "EN16931", "invoice_path": "invoice"},
            "filename": f"{invoice['number']}.pdf",
            "delivery": "binary",
        },
        timeout=130,
    )
    res.raise_for_status()
    return res.content
<?php
function renderEInvoice(array $invoice): string
{
    $ch = curl_init('https://api.dynamicdocumentapi.com/v1/pdf/from-template');
    curl_setopt_array($ch, [
        CURLOPT_POST           => true,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_HTTPHEADER     => [
            'Authorization: Bearer ' . getenv('DYNAMIC_DOCUMENT_API_KEY'),
            'Idempotency-Key: ' . $invoice['number'], // safe to retry
            'Content-Type: application/json',
        ],
        CURLOPT_POSTFIELDS     => json_encode([
            'template_id' => 'tpl_einvoice',
            'data'        => ['invoice' => $invoice],
            'einvoice'    => ['profile' => 'EN16931', 'invoice_path' => 'invoice'],
            'filename'    => $invoice['number'] . '.pdf',
            'delivery'    => 'binary',
        ]),
    ]);
    return curl_exec($ch); // PDF/A-3b with the XML embedded
}

Die Summen stehen nicht in der Anfrage, die Engine berechnet sie. Verstößt die Rechnung gegen eine Regel des Profils, schlägt die Anfrage mit 422 einvoice_invalid oder einvoice_validation_failed fehl, mit einer Liste von Befunden, die auf das Feld in Ihrer Rechnung zeigen, zum Beispiel invoice.seller.contact. Fehlgeschlagene Renderings werden nicht berechnet. Eine Vorlage kann die E-Rechnung auch als Standard speichern; dann senden Aufrufer nur noch die Daten.

XRechnung für öffentliche Auftraggeber

Die XRechnung ist das Standardformat für Rechnungen an deutsche Behörden. Welche anderen Formate nach EN 16931 ein Rechnungsportal annimmt, unterscheidet sich zwischen Bund, Ländern und Kommunen; fragen Sie im Zweifel beim Auftraggeber nach. Nutzen Sie das Profil XRECHNUNG: als einzelne XML-Datei in CII oder UBL oder eingebettet in Ihr PDF als xrechnung.xml. Das Profil verlangt eigene Pflichtfelder, die die API prüft, bevor überhaupt XML entsteht:

  • buyer_reference (BT-10): die Leitweg-ID des Auftraggebers
  • seller.contact mit Name, Telefon und E-Mail
  • electronic_address für Verkäufer und Käufer, zum Beispiel mit dem Schema 0204 für eine Leitweg-ID
  • payment mit einem Zahlungsartcode, etwa 58 für eine SEPA-Überweisung, und dem Konto
# invoice shortened here; the complete model is linked below
curl https://api.dynamicdocumentapi.com/v1/einvoices \
  -H "Authorization: Bearer $DYNAMIC_DOCUMENT_API_KEY" \
  -H "Idempotency-Key: xrechnung-XR-2026-0007" \
  -H "Content-Type: application/json" \
  -d '{
    "profile": "XRECHNUNG",
    "syntax": "ubl",
    "invoice": { "number": "XR-2026-0007", "buyer_reference": "04011000-12345-34", "…": "…" },
    "delivery": { "type": "binary" }
  }' \
  -o XR-2026-0007.xml

Das vollständige Rechnungsmodell in der Doku ist eine gültige XRechnung an eine Bundesbehörde, mit jedem Feld erklärt. In UBL verwenden Gutschriften (Rechnungsart 381) das Wurzelelement CreditNote.

Das Profil wählen, das Ihr Empfänger verlangt

ProfilWas es enthältSyntax
EN16931Die vollständige Rechnung. Der richtige Standard für B2B-Rechnungen in der EUCII, UBL
XRECHNUNGDie vollständige Rechnung plus die deutschen Regeln der XRechnung 3.0; der Standard für öffentliche Auftraggeber in DeutschlandCII, UBL
EXTENDEDDie vollständige Rechnung mit den zusätzlichen Feldern des erweiterten Factur-X-ProfilsCII
BASICEine Grundauswahl der RechnungspositionenCII
BASIC_WL, MINIMUMNur Kopfdaten und Summen, keine Positionen. Nach den deutschen B2B-Regeln keine E-Rechnung; nur dort sinnvoll, wo eine Buchungshilfe genügtCII

Hybrid-PDFs betten immer CII ein; UBL gibt es für das einzelne XML.

Ein Rechnungsmodell, die Beträge berechnet die API

Das Rechnungsmodell ist JSON für das semantische Modell der EN 16931, mit einem Feld pro Geschäftsbegriff. Sie beschreiben, was verkauft wurde; die Engine rechnet so, wie die Norm es vorschreibt. Seite und XML können sich deshalb nicht widersprechen.

Summen, die auf den Cent zum XML passen

Positionsbeträge, die Aufschlüsselung nach Steuerkategorie und Steuersatz und die Gesamtsummen berechnet die Engine nach der EN 16931 und übergibt sie Ihrer Vorlage als render.invoice. Drucken Sie diese Werte, statt in der Vorlage zu rechnen.

{{ render.invoice.totals.due_payable
   | format_currency("EUR", "de-DE") }}
→ 1.190,00 €

Alle Steuerfälle der Norm

Regelsteuersatz und Nullsatz, Steuerbefreiung, Reverse Charge, innergemeinschaftliche Lieferungen, Ausfuhren und nicht steuerbare Umsätze, jeweils mit dem Befreiungsgrund, den die Regeln verlangen.

"tax": { "category": "AE", "rate": "0" }
Reverse Charge, mit USt-IdNr. beider Seiten

Gutschriften und Korrekturen

Rechnungsart setzen, die ursprüngliche Rechnung angeben, Mengen und Preise positiv lassen: Die Rechnungsart macht das Dokument zur Gutschrift.

"type_code": "381",
"preceding_invoices": [{ "number": "R-2026-0042" }]

E-Rechnung als Standard der Vorlage

Speichern Sie Profil und Datenpfad in den Optionen der Vorlage, im Dashboard oder per API. Dann ist jedes Rendering dieser Vorlage ein ZUGFeRD-/Factur-X-PDF, und Aufrufer senden nur die Daten. Jede Rechnungsvorlage der Galerie ist so eingerichtet.

Monatsabschluss in einem Stapel

In einem Stapel trägt jeder Eintrag seine eigene Rechnung in seinen Daten. Eine Anfrage ergibt so je Kunde eine geprüfte E-Rechnung.

Ein Testmodus, der es auch sagt

Test-Renderings sind kostenlos und werden geprüft wie echte. Test-PDFs tragen ein TEST-Wasserzeichen, Test-XML den Hinweis, dass es keine gültige Rechnung ist. So kann nichts, was Sie ausprobieren, mit einer echten Rechnung verwechselt werden.

Ein Prüfbericht zu jedem Rendering

Jedes E-Rechnungs-Rendering bringt einen Konformitätsbericht der unveränderten offiziellen Prüfwerkzeuge mit: veraPDF für die PDF/A-Datei und den KoSIT-Validator für das XML. Schlägt eine Regel fehl, nennt der Befund die Regel und zeigt auf das Feld in Ihrer Rechnung:

{
  "conformance": {
    "pdfa":     { "level": "3b", "status": "passed", "validator": "veraPDF 1.30.2" },
    "einvoice": { "profile": "XRECHNUNG", "syntax": "cii", "status": "passed",
                  "validator": "KoSIT Validator 1.6.3", "errors": [], "warnings": [] }
  }
}
// a failed rule: { "rule": "BR-DE-2", "location": "invoice.seller.contact", … }

Antwortet ein Prüfwerkzeug nicht rechtzeitig, wird das Rendering trotzdem fertig: Der Status im Bericht lautet dann unavailable, und eine Warnung sagt, dass die Datei ungeprüft ist. Das Dashboard zeigt denselben Bericht auf der Seite des Renderings. Alle Felder erklärt der Abschnitt zum Prüfbericht.

E-Rechnungspflicht: wer betroffen ist und was wir übernehmen

  • Empfangen seit 2025. Seit dem 1. Januar 2025 müssen alle Unternehmen in Deutschland E-Rechnungen im inländischen B2B-Geschäft empfangen können.
  • Ausstellen ab 2027 und 2028. Ab dem 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 € Vorjahresumsatz E-Rechnungen ausstellen, ab dem 1. Januar 2028 grundsätzlich alle. Ausgenommen sind unter anderem Kleinbetragsrechnungen bis 250 €, Fahrausweise und Kleinunternehmer nach § 19 UStG. Als E-Rechnung gelten die XRechnung und ZUGFeRD ab Version 2.0.1, nicht aber dessen Profile MINIMUM und BASIC WL; ein einfaches PDF ist keine E-Rechnung.
  • Öffentliche Auftraggeber. Behörden in der EU nehmen Rechnungen nach der EN 16931 an; für deutsche Behörden ist die XRechnung der Standard.
  • Was wir garantieren. Die technische Konformität des Formats, vor der Auslieferung gegen die offiziellen Schemas und Schematron-Regeln geprüft.
  • Was bei Ihnen bleibt. Inhalt und steuerliche Richtigkeit jeder Rechnung und ihre Übermittlung: Mit Peppol und den Rechnungsportalen der Behörden sind wir nicht verbunden, das XML geben Sie an Ihren Peppol-Zugangspunkt oder das Portal weiter. Das PDF liefern Sie aus Ihrem System aus, oder es geht ab Growth über Ihr eigenes Konto bei Ihrem E-Mail-Anbieter an die Kundschaft (E-Mail-Versand). Fristen und Ausnahmen im Einzelfall klären Sie mit Ihrer Steuerberatung.

Was eine E-Rechnung kostet

Growth

47 € / Monat

15.000 Renderings im Monat bei jährlicher Abrechnung (59 € bei monatlicher). E-Rechnung, PDF/A und E-Mail-Versand inklusive.

Pro Rechnung

+0

Die E-Rechnung im PDF zählt kein zusätzliches Rendering. Ein XML-Export mit /v1/einvoices ist ein Rendering; Test- und fehlgeschlagene Renderings sind kostenlos.

Free und Starter enthalten keine E-Rechnung, aber Sie können dort das Rechnungslayout gestalten und rendern: Vorlagen mit hinterlegter E-Rechnung bekommen die berechneten Beträge in jedem Tarif. Alle Tarife finden Sie in den Preisen.

FAQ

E-Rechnung API: häufige Fragen

Ist ZUGFeRD dasselbe wie Factur-X?

Technisch ja. Seit ZUGFeRD 2.1 beschreiben ZUGFeRD und Factur-X dasselbe hybride Format: eine Rechnung als PDF/A-3 mit eingebettetem UN/CEFACT-CII-XML. Die API erzeugt es mit dem Profil, das Sie wählen; das Profil XRECHNUNG bettet stattdessen eine XRechnung-3.0-Datei ein.

Berechnet die API Umsatzsteuer und Summen?

Bei E-Rechnungen ja. Sie senden Positionen, Nachlässe und Zuschläge; die Engine berechnet Positionsbeträge, die Aufschlüsselung nach Steuersätzen und die Gesamtsummen nach den Regeln der EN 16931 und gibt sie an Ihre Vorlage weiter. So stimmt die sichtbare Rechnung auf den Cent mit dem XML überein. Steuersätze, Steuerkategorien und Rechnungsnummern kommen weiterhin aus Ihrem System.

Verschickt die API die E-Rechnungen an meine Kunden?

Ab dem Growth-Tarif kann sie das PDF über Ihr eigenes Konto bei Ihrem E-Mail-Anbieter verschicken, oder sie gibt es als Datei oder signierten Link an Ihr System zurück. Mit Peppol oder den Rechnungsportalen von Behörden ist sie nicht verbunden: Die Übermittlung, etwa an die Portale von Bund und Ländern, bleibt bei Ihnen.

Kann ich E-Rechnungen testen, bevor ich echte verschicke?

Ja. Renderings mit einem Test-Schlüssel sind kostenlos und werden geprüft wie echte. Test-PDFs tragen ein TEST-Wasserzeichen, Test-XML einen Hinweis, der sie als Testrechnung kennzeichnet. Dafür brauchen Sie einen Tarif mit E-Rechnung; Vorlagen mit hinterlegter E-Rechnung, etwa die Rechnungsvorlagen der Galerie, bekommen die berechneten Beträge aber in jedem Tarif, sodass Sie das Rechnungslayout vorher bauen können.

Wer ist für den Inhalt der Rechnung verantwortlich?

Sie. Wir garantieren die technische Konformität des Formats, geprüft gegen die offiziellen Schemas und Schematron-Regeln. Inhalt, steuerliche Richtigkeit und Übermittlung der Rechnung liegen bei Ihnen.

In welchen Tarifen ist die E-Rechnung enthalten?

In Growth, Pro, Scale und Enterprise. Growth kostet 47 € im Monat bei jährlicher Abrechnung (59 € bei monatlicher) für 15.000 Renderings. Eine in ein PDF eingebettete E-Rechnung zählt kein zusätzliches Rendering, ein reiner XML-Export zählt eines, Test- und fehlgeschlagene Renderings sind kostenlos.

Bauen Sie Ihre E-Rechnungs-Vorlage

Das Rechnungslayout gestalten und rendern Sie im Free-Tarif; E-Rechnungen einbetten können Sie ab Growth.

Kostenlos starten