QuoteCashbeta
AnmeldenLoslegen
REST API für Rechnungsprozesse

XRechnung API für Deutschland

Erzeugen Sie XRechnung-XML aus strukturierten Rechnungsdaten und integrieren Sie die Erstellung direkt in ERP-, SaaS- und Abrechnungsprozesse.

QuoteCash prüft den Request, erzeugt UBL-XML und übergibt das Ergebnis vor der Rückgabe an den konfigurierten Validierungsdienst.

UBL-2.1-XMLValidierung vor RückgabeGeschäftsbezogene API-Keys
01QuoteCash

XRechnung erzeugen

POST /api/v1/invoices/xrechnung prüft erforderliche Request-Felder, erzeugt UBL-XML und validiert das Ergebnis vor der Rückgabe.

02QuoteCash

XML validieren

POST /api/v1/validate prüft vorhandenes XML mit demselben konfigurierten Validierungsdienst und liefert strukturierte Fehler und Warnungen.

03QuoteCash

REST API für Integrationen

Geschäftsbezogene API-Keys, dokumentierte Limits und ein einheitliches Zugriffsmodell unterstützen ERP-, SaaS- und Automationsprozesse.

API-Details

Erzeugung und Validierung sind getrennte Schritte

Der Legacy-Generator validiert zuerst den JSON-Request und prüft zusätzliche XRechnung-Felder wie Rechnungsdatum, VAT-IDs, Postanschriften, E-Mail und Telefon des Verkäufers sowie Steuersätze. Danach werden die Daten normalisiert und als UBL 2.1 erzeugt.

Positions-, Steuer- und Zahlbeträge werden aus Menge, Netto-Einzelpreis und Steuersatz mit Rundung auf zwei Dezimalstellen neu berechnet; übermittelte Gesamtsummen werden nicht in das XML übernommen. Anschließend läuft das erzeugte XML durch dieselbe konfigurierte Validierungs-Engine wie POST /api/v1/validate.

Das XML kennzeichnet die XRechnung-3.0-CIUS mit urn:xeinkauf.de:kosit:xrechnung_3.0. Das Repository fixiert kein bestimmtes 3.0.x-KoSIT-Bundle: Die konkrete XSD- und Schematron-Konfiguration liegt beim extern konfigurierten Validierungsdienst. QuoteCash beansprucht deshalb keine verifizierte 3.0.2-Konfiguration.

Zielgruppen

Für wen ist das gedacht?

Softwareprodukte

SaaS- und Abrechnungslösungen können strukturierte Rechnungen im Backend erzeugen, ohne einen eigenen XML-Serializer zu pflegen.

SaaS-Entwickler

Billing-Produkte brauchen deterministische Erzeugung und Validierung im Backend statt manueller Exporte. Die Route passt in Checkout-, Subscription- und ERP-Sync-Flows.

Agenturen und Reseller

Agenturen mit Compliance-Projekten brauchen Kundentrennung und saubere Widerrufspfade. Geschäftsbezogene Schlüssel sind dafür stabiler als geteilte Exportzugänge.

ERP-Integratoren

Integratoren brauchen explizite Validierungsfehler und planbares Quotenverhalten. Das ist betrieblich besser handhabbar als eine eingebettete Einzellösung für XML.

Redaktioneller Hinweis

Zuletzt fachlich geprüft: 24. Juli 2026

Warum QuoteCash zu XRechnung schreibt

QuoteCash ist ein deutsches B2B-SaaS von Luchianenco Labs. Die Anwendung erzeugt Rechnungen, Angebote und strukturierte E-Rechnungsformate über UI und API. Diese Seite erklärt die technischen Anforderungen aus Sicht von Softwareteams, kleinen Unternehmen und Integratoren; sie ersetzt keine Steuer- oder Rechtsberatung.

Praxiswissen

Was XRechnung praktisch bedeutet

XRechnung ist ein strukturiertes XML-Dokument. Ein zusätzlich erzeugtes PDF kann Menschen bei der Ansicht helfen, ersetzt aber nicht den maßgeblichen strukturierten Datensatz. Felder wie Verkäufer, Käufer, Rechnungsnummer, Leistungsdatum, Steuerinformationen, Summen, Zahlungsbedingungen und Buyer Reference werden in einem semantischen Modell beschrieben.

Für Softwareteams ist XRechnung deshalb weniger ein Exportformat als ein Datenqualitätsproblem. Eine Rechnung, die in der UI plausibel aussieht, kann als XML trotzdem scheitern, wenn etwa eine Umsatzsteuer-ID falsch formatiert ist, eine Summe nicht zu den Positionswerten passt oder eine Pflichtangabe für den Empfänger fehlt.

  • XRechnung ist XML-basiert und an EN 16931 ausgerichtet.
  • Eine bildhafte PDF-Datei allein erfüllt nicht die Definition einer strukturierten E-Rechnung; Übergangsregeln und gesetzliche Ausnahmen sind getrennt zu prüfen.
  • Der strukturierte Datenteil ist maßgeblich, nicht die optische Darstellung.
Praxiswissen

Welche Version und Syntax QuoteCash erzeugt

QuoteCash erzeugt UBL 2.1 und setzt die CustomizationID urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. CII-Ausgabe ist für XRechnung derzeit nicht implementiert. Die Profilkennung ist auf den Peppol-Billing-Geschäftsprozess festgelegt; ein frei wählbarer BT-23-Wert gehört nicht zum Request.

Die API unterstützt Buyer Reference sowie elektronische Verkäufer- und Käuferadressen mit schemeID. Fehlen explizite endpoint_id-Werte, nutzt der Generator VAT-ID oder E-Mail als Fallback. Ob ein Dokument die aktuellen XRechnung-Regeln erfüllt, entscheidet der konfigurierte externe Validator; dessen konkrete 3.0.x-Konfiguration ist nicht im Repository versioniert.

Praxiswissen

XRechnung statt PDF: der entscheidende Unterschied

Ein PDF beschreibt vor allem ein Layout. Menschen können es lesen, aber Software muss Inhalte häufig erraten oder per OCR extrahieren. XRechnung beschreibt die Rechnung als Datenmodell. Eine Buchhaltung kann daraus Beträge, Steuerkategorien, Fälligkeit, IBAN, Käuferdaten und Referenzen ohne Medienbruch auslesen.

Der Nachteil: XML verzeiht weniger. Ein fehlender Ländercode, eine Rundungsdifferenz oder ein falscher Steuercode kann den gesamten Export ungültig machen. Deshalb sollte XRechnung-Erzeugung immer mit Validierung gekoppelt werden, bevor Dokumente an Kunden, Portale oder Archive gehen.

Praxiswissen

Häufige Validierungsfehler

Viele Fehler entstehen nicht im XML-Generator, sondern in vorgelagerten Stammdaten. Typische Fälle sind fehlende Käuferreferenz bei öffentlichen Empfängern, unvollständige Anschriften, nicht passende Umsatzsteuerlogik, falsche Währungscodes oder Summen, die nach Rundung nicht mehr exakt zu den Positionen passen.

QuoteCash prüft Pflichtfelder vor der Erzeugung und validiert das erzeugte XML anschließend über den konfigurierten Dienst. Bei einem normativen Fehler antwortet der Legacy-Endpunkt mit HTTP 422 und liefert XML sowie strukturierte Validierungsdetails zur Diagnose zurück.

  • Buyer Reference oder Leitweg-ID fehlt.
  • Elektronische Verkäufer- oder Käuferadresse beziehungsweise schemeID ist falsch.
  • VAT-ID, Steuerkategorie oder Steuersatz passt nicht zur Position.
  • Brutto-, Netto- und Steuerbeträge stimmen nach Rundung nicht überein.
  • Pflichtfelder für Verkäufer, Käufer, Datum oder Zahlungsweg fehlen.
Beispiel

API-Beispiel: XRechnung aus Rechnungsdaten erzeugen

Der Endpoint prüft den Request, erzeugt UBL-XML und validiert das Ergebnis vor der Rückgabe. Dieses Payload entspricht dem veröffentlichten Request-Schema.

POST /api/v1/invoices/xrechnung
Authorization: Bearer <api_key>
Content-Type: application/json

{
  "schema_version": "1",
  "invoice_number": "RE-2026-1042",
  "issue_date": "2026-07-24",
  "due_date": "2026-08-07",
  "currency": "EUR",
  "buyer_reference": "04011000-12345-03",
  "seller": {
    "name": "Muster GmbH",
    "vat_id": "DE123456789",
    "street": "Musterstraße 1",
    "city": "Berlin",
    "postal_code": "10115",
    "country": "DE",
    "email": "rechnung@muster.example",
    "phone": "+49 30 123456",
    "endpoint_id": "rechnung@muster.example",
    "endpoint_scheme": "EM"
  },
  "buyer": {
    "name": "Beispielkunde GmbH",
    "vat_id": "DE987654321",
    "street": "Kundenweg 2",
    "city": "Hamburg",
    "postal_code": "20095",
    "country": "DE",
    "endpoint_id": "buchhaltung@kunde.example",
    "endpoint_scheme": "EM"
  },
  "line_items": [
    {
      "description": "Implementierung E-Rechnung",
      "quantity": 1,
      "price": 1200,
      "total": 1200,
      "vatRate": 19,
      "unitCode": "C62"
    }
  ],
  "totals": {
    "net": 1200,
    "tax": 228,
    "gross": 1428
  },
  "payment": {
    "iban": "DE02120300000000202051",
    "bic": "BYLADEM1001"
  }
}
  • Die Buyer Reference ist besonders wichtig, wenn der Empfänger sie für Routing oder Freigabe verlangt.
  • Positionssummen, Steuerbeträge und Gesamtbeträge sollten vor dem Versand automatisch geprüft werden.
Umsetzung

Implementierungs-Checkliste für XRechnung

  1. 1Pflichtfelder im eigenen Rechnungsmodell markieren.
  2. 2Kundenstammdaten um Buyer Reference, Leitweg-ID und VAT-ID erweitern.
  3. 3Rundungsregeln für Positionen, Steuerbeträge und Gesamtsummen festlegen.
  4. 4XML-Erzeugung und XML-Validierung im selben Workflow ausführen.
  5. 5Fehlermeldungen in verständliche Hinweise für Support oder Buchhaltung übersetzen.
  6. 6Empfangene und versendete strukturierte Originaldateien im eigenen Archiv unverändert aufbewahren; QuoteCash ersetzt keine vollständige revisionssichere Archivlösung.

Weiterführende QuoteCash-Seiten

XRechnung XML online validierenBestehendes XML vor Versand oder Archivierung prüfen.ZUGFeRD APIHybrides PDF mit eingebettetem CII-XML für Empfänger, die Lesbarkeit und strukturierte Daten brauchen.Fristen der deutschen E-RechnungFristen, Vorbereitung und Entscheidung zwischen XRechnung und ZUGFeRD.XRechnung API-DokumentationRequest-Felder, Antworten und Beispiele für die Integration nachlesen.Zahlungseingangsprognose APIGespeicherte Rechnungen und erwartete Zahlungseingänge per REST API auswerten.

Offizielle Quellen und Standards

BMF: FAQ zur verpflichtenden E-RechnungDas BMF beschreibt die seit 2025 geltende Definition der E-Rechnung, Übergangsregelungen und Ausnahmen.KoSIT/XStandards Einkauf: XRechnungKoSIT veröffentlicht Spezifikation, Validator-Konfiguration, Testsuite und technische Komponenten rund um XRechnung.KoSIT/XStandards: Vorbereitung auf XRechnung 4.0KoSIT erklärt, dass die Vorabversion von XRechnung 4.0 noch nicht für den produktiven Einsatz vorgesehen ist.

Häufige Fragen

Ist XRechnung für kleine Unternehmen in Deutschland verpflichtend?
Unternehmen mit mehr als 800.000 Euro Vorjahresumsatz müssen grundsätzlich ab 2027 E-Rechnungen ausstellen. Für Rechnungsaussteller bis zu dieser Umsatzgrenze kann die Übergangsregelung unter den gesetzlichen Voraussetzungen bis Ende 2027 gelten. Ab 2028 gelten die Anforderungen grundsätzlich für betroffene inländische B2B-Umsätze; gesetzliche Ausnahmen bleiben bestehen.
Was ändert sich mit XRechnung 4.0?
XRechnung 4.0 befindet sich noch in Vorbereitung. Laut KoSIT ist die Vorabversion nicht für den produktiven Einsatz vorgesehen. QuoteCash erzeugt derzeit den XRechnung-3.0-Identifier und beansprucht keine produktive Unterstützung für 4.0.
Kann ich bestehendes XRechnung-XML vor dem Versand validieren?
Ja. QuoteCash stellt POST /api/v1/validate bereit, damit XML vor Versand oder Archivierung mit strukturierter Rückmeldung geprüft werden kann.
Wie lange müssen elektronische Rechnungen in Deutschland aufbewahrt werden?
Ein- und Ausgangsrechnungen müssen umsatzsteuerlich grundsätzlich acht Jahre aufbewahrt werden. Bei einer E-Rechnung muss zumindest der strukturierte Teil während dieser Frist unversehrt in seiner ursprünglichen Form erhalten bleiben.
Kann ich XRechnung zusätzlich als PDF anzeigen?
Ja. Ein zusätzlich erzeugtes PDF kann Menschen bei der Ansicht helfen, ersetzt aber nicht den maßgeblichen strukturierten Datensatz.
Ist XRechnung immer besser als ZUGFeRD?
Nein. XRechnung ist ideal für strikt strukturierte Empfänger und öffentliche Auftraggeber. ZUGFeRD ist oft besser, wenn ein Kunde zusätzlich ein lesbares PDF im gleichen Dokument erwartet.
Warum akzeptiert ein Portal mein XML nicht, obwohl alle sichtbaren Rechnungsdaten stimmen?
Portale prüfen technische Geschäftsregeln. Häufig fehlen Referenzen, Codes, korrekte Steuerzuordnung oder exakt passende Summen. Deshalb ist Validierung vor dem Versand wichtig.