Zum Hauptinhalt springen
Integrationspaket erhalten

Integrationspaket · kostenlos

Stripe behalten. XRechnung bauen, die der Validator annimmt.

Von 34 Angaben im Feldplan liefert Stripe 11. Das Integrationspaket zeigt, woher die übrigen 23 kommen, mit einem von KoSIT akzeptierten UBL-Beispiel, drei Fehlerfällen samt Prüfbericht und einem sechsseitigen PDF-Leitfaden für Engineering und Finance.

kontier-stripe-xrechnung-integrationspaket.zip 20 Dateien · 130 KB
Frist 1.1.2027 Ab dann stellen Unternehmen mit mehr als 800.000 € Vorjahresumsatz B2B-Rechnungen in Deutschland elektronisch aus. Ab 2028 gilt das für alle (§ 27 Abs. 38 UStG).
  • XRechnung 3.0.2
  • UBL 2.1
  • KoSIT 1.6.3
  • geprüft 6.9.2026

field-map.csv

Stripe kennt 11 von 34 Angaben.

Rechnungsnummer, Kunde, Positionen und Beträge stehen in Stripe. Die Käuferreferenz (bei Behörden die Leitweg-ID), die elektronische Adresse des Empfängers, Ihre USt-IdNr. und der Zahlungsmittelcode stehen dort nicht. Der Feldplan ordnet jede Zeile ihrer Quelle zu, mit BT-Nummer, UBL-Pfad und einem Prüfhinweis.

Die Spalte „Prüfung/Grenze“ mit einem Hinweis je Zeile steht in der CSV im Paket, zum Beispiel: „customer_email nicht ungeprüft als Endpunkt einsetzen.“

field-map.csv · 34 ZeilenTestdaten
  1. BT-24 SpezifikationskennungCustomizationID Konfiguration ergänzen
  2. BT-23 GeschäftsprozessProfileID Empfänger ergänzen
  3. BT-1 RechnungsnummerID number aus Stripe
  4. BT-2 AusstellungsdatumIssueDate effective_at aus Stripe
  5. BT-9 FälligkeitDueDate due_date aus Stripe
  6. BT-5 WährungDocumentCurrencyCode currency aus Stripe
  7. BT-10 KäuferreferenzBuyerReference Empfänger ergänzen
  8. BT-27 VerkäufernameAccountingSupplierParty/Party/PartyLegalEntity/RegistrationName Stammdaten ergänzen
  9. BT-31 Verkäufer-USt-IdNr.AccountingSupplierParty/Party/PartyTaxScheme/CompanyID Stammdaten ergänzen
  10. BT-35/37/38/40 VerkäuferanschriftAccountingSupplierParty/Party/PostalAddress Stammdaten ergänzen
  11. BT-34 Elektronischer Verkäufer-EndpunktAccountingSupplierParty/Party/EndpointID Endpunkt ergänzen
  12. BT-41/42/43 VerkäuferkontaktAccountingSupplierParty/Party/Contact Stammdaten ergänzen
  13. BT-44 KäufernameAccountingCustomerParty/Party/PartyLegalEntity/RegistrationName customer_name aus Stripe
  14. BT-50/52/53/55 KäuferanschriftAccountingCustomerParty/Party/PostalAddress customer_address aus Stripe
  15. BT-48 Käufer-USt-IdNr.AccountingCustomerParty/Party/PartyTaxScheme/CompanyID customer_tax_ids aus Stripe
  16. BT-49 Elektronischer Käufer-EndpunktAccountingCustomerParty/Party/EndpointID EmpfängerFehlerfall 02 ergänzen
  17. BT-81 ZahlungsmittelcodePaymentMeans/PaymentMeansCode Vereinbarung ergänzen
  18. BT-84 ZahlungskontoPaymentMeans/PayeeFinancialAccount/ID Stammdaten ergänzen
  19. BT-126 PositionskennungInvoiceLine/ID Integration ergänzen
  20. BT-129 MengeInvoiceLine/InvoicedQuantity quantity_decimal aus Stripe
  21. BT-130 MengeneinheitInvoiceLine/InvoicedQuantity/@unitCode Produkt ergänzen
  22. BT-153 PositionsnameInvoiceLine/Item/Name line.description aus Stripe
  23. BT-146 NettopreisInvoiceLine/Price/PriceAmount unit_amount_decimal aus Stripe
  24. BT-149/150 Preisbasismenge/-einheitInvoiceLine/Price/BaseQuantity Preismodell ergänzen
  25. BT-131 PositionsnettoInvoiceLine/LineExtensionAmount Menge × Nettopreis berechnen
  26. BT-134/135 LeistungszeitraumInvoiceLine/InvoicePeriod/StartDate; EndDate line.period aus Stripe
  27. BT-151/152 Steuerkategorie/-satzInvoiceLine/Item/ClassifiedTaxCategory Steuerprüfung ergänzen
  28. BT-116/117/118/119 SteueraufschlüsselungTaxTotal/TaxSubtotal je Kategorie und Satz berechnen
  29. BT-106 Summe PositionsnettoLegalMonetaryTotal/LineExtensionAmount Σ Positionsnetto berechnen
  30. BT-109 RechnungsnettoLegalMonetaryTotal/TaxExclusiveAmount Abgleich total_excluding_tax berechnen
  31. BT-110 SteuersummeTaxTotal/TaxAmount Σ Steueraufschlüsselung berechnen
  32. BT-112 RechnungsbruttoLegalMonetaryTotal/TaxInclusiveAmount BT-109 + BT-110Fehlerfall 03 berechnen
  33. BT-113/114 Gezahlt/RundungLegalMonetaryTotal/PrepaidAmount; PayableRoundingAmount Zahlungen, Rundung berechnen
  34. BT-115 ZahlbetragLegalMonetaryTotal/PayableAmount BT-112 − BT-113 + BT-114Fehlerfall 03 berechnen

failures/

Drei Fehlerfälle. Den dritten findet kein Validator.

Zwei XML-Dateien sind absichtlich beschädigte Kopien des gültigen Beispiels. KoSIT lehnt beide ab, der Prüfbericht nennt die Regel. Der dritte Fall ist eine doppelt zugestellte Stripe-Ereignisfolge: jedes einzelne XML wäre gültig, und trotzdem geht eine Rechnung zu viel hinaus, wenn Ihre Integration nicht dedupliziert.

failures/03-wrong-tax-inclusive-total.xml Beispieldaten
KoSIT 1.6.3 · XRechnung 3.0.2 · Schema bestanden Schematron REJECT korrigiert ACCEPTABLE 
<cac:LegalMonetaryTotal>  <cbc:LineExtensionAmount>100.00</…>BT-106  <cbc:TaxExclusiveAmount>100.00</…>BT-109  <cbc:TaxInclusiveAmount>118.99</…>BT-112  <cbc:TaxInclusiveAmount>119.00</…>BT-112  <cbc:PayableAmount>119.00</…>BT-115</cac:LegalMonetaryTotal>

BT-109 + BT-110100,00 + 19,00 = 119,00 ≠ 118,99100,00 + 19,00 = 119,00 = BT-112

  • [BR-CO-15] Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). Fehler behoben
  • [BR-CO-16] Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) −Paid amount (BT-113) +Rounding amount (BT-114). Fehler behoben

Korrigiert entspricht die Datei examples/01-saas-standard-ubl.xml. Gleicher Lauf: keine Fehler, keine Warnungen.

Ein Cent in BT-112 genügt für die Ablehnung.

TaxInclusiveAmount wurde von 119,00 auf 118,99 EUR geändert. Netto, Steuer und Zahlbetrag stimmen weiter. Das XML-Schema besteht, die Rechenregeln nicht.

So reagiert Ihre Integration

Nicht nur das eine Summenfeld korrigieren. Berechnungsweg, Rabatte, Steuer-Aufschlüsselung und Rundung nachvollziehen, dann alle abhängigen Summen gemeinsam neu erzeugen. Den fehlerhaften Datensatz bis zur Klärung aufbewahren.

failures/02-missing-buyer-endpoint.xml Beispieldaten
KoSIT 1.6.3 · XRechnung 3.0.2 · Schema bestanden Schematron REJECT korrigiert ACCEPTABLE 
<cac:AccountingCustomerParty>  <cac:Party>    (EndpointID fehlt)BT-49    <cbc:EndpointID schemeID="EM">rechnung@buyer.example</…>BT-49    <cac:PostalAddress>BT-50      <cbc:CityName>Hamburg</…>BT-52    …
  • [PEPPOL-EN16931-R010] Buyer electronic address MUST be provided Fehler behoben

Korrigiert entspricht die Datei examples/01-saas-standard-ubl.xml. Gleicher Lauf: keine Fehler, keine Warnungen.

Die Kontaktadresse ersetzt die elektronische Adresse nicht.

AccountingCustomerParty/Party/EndpointID wurde entfernt (BT-49). Stripe liefert dieses Feld nicht, customer_email ist kein geprüfter Endpunkt. Das Schema besteht, Schematron lehnt ab.

So reagiert Ihre Integration

Ausgabe und Versand blockieren und den fehlenden Käufer-Endpunkt mit Kennungsschema benennen. Quelle sind der Käufer oder die gepflegten Rechnungsstammdaten, nie ein Login oder eine Stripe-ID.

failures/04-duplicate-event-sequence.json Beispieldaten
kein XML-Befund · invoice.finalized · in_TEST_EXAMPLE_0001 Testvorgabe NICHT AUSGEFÜHRT
  1. evt_TEST_Aerste Zustellung ohne Schutz: Dokument 1 Dokument 1 · Versandauftrag 1
  2. evt_TEST_Adieselbe Ereignis-ID erneut ohne Schutz: Dokument 2 verworfen: Ereignis-ID bekannt
  3. evt_TEST_Bneue ID, gleiche Rechnung ohne Schutz: Dokument 3 kein zweiter Versand: Dokument-ID bekannt

3 Dokumente · 3 Versandaufträge erwartet: 1 Dokument · 1 Versandauftrag

Gültiges XML, trotzdem eine Rechnung zu viel.

Dasselbe invoice.finalized-Ereignis kommt zweimal, danach eine neue Ereignis-ID für dieselbe Rechnung. Stripe stellt Ereignisse mindestens einmal zu, nicht genau einmal. Die Datei ist ein Testvertrag für Ihre Anwendung, keine signierte Stripe-Nutzlast.

So reagiert Ihre Integration

Ereignis-ID deduplizieren und die Dokument- und Versandidentität zusätzlich dauerhaft absichern. Auch mit parallelen Workern und einem Abbruch zwischen Erzeugung und Queue-Bestätigung testen. Eine legitime neue Revision darf dabei nicht unterdrückt werden.

validation/

Jede Aussage im Paket hat einen Prüfbericht.

Das Beispiel und beide Fehlerfälle wurden am 6. September 2026 mit dem offiziellen KoSIT Validator geprüft. Die Berichte liegen als HTML und XML im Ordner validation/, die geprüften Dateien sind per SHA-256 festgehalten. Ihr Team kann den Lauf mit einem Befehl wiederholen. Ebenso deutlich steht im Paket, was diese Prüfung nicht beweist.

examples/01-saas-standard-ubl.xmlBeispieldaten

TEST-2026-0001Leistung 1.–30.9.2026

2 × SaaS-Zugang à 50,00100,00
Netto BT-109100,00
USt 19 % BT-11019,00
Zahlbar BT-115119,00 EUR
ACCEPTABLEXML-Schema und Schematron bestanden, keine Fehler, keine Warnungen
Prüflauf6.9.2026
Validator
KoSIT 1.6.3
Konfiguration
XRechnung v2026-08-31
Szenario
EN16931 XRechnung (UBL Invoice)
Standard
XRechnung 3.0.2 · UBL 2.1
java -jar validator-1.6.3-standalone.jar \  -s config/scenarios.xml -r config -h \  -o …/validation \  …/examples/01-saas-standard-ubl.xml
manifest.jsonSHA-256
  • 01-saas-standard-ubl.xml 7ec26383e8eb2244…3857335 ACCEPTABLE
  • 02-missing-buyer-endpoint.xml df86fadcfea666e3…093737f REJECT
  • 03-wrong-tax-inclusive-total.xml 062ed5bd29aa99b8…1c8a1a8 REJECT

not_tested

  • Vertrag mit der Live-Stripe-API
  • echte Identitäten und Steuerbehandlung
  • Zustellung an den Empfänger
  • Idempotenz in Ihrer Anwendung
  • Ihre produktive Integration

Feldplan, Beispiele, Fehlerfälle und Prüfberichte liegen auch offen auf GitHub, ohne Anmeldung. Den PDF-Leitfaden gibt es nur im Paket. github.com/Frontier-Algorithmics/stripe-xrechnung

Sechs Seiten, die Engineering und Finance an einen Tisch bringen.

Der PDF-Praxisleitfaden ist der Teil, den es nur im Paket gibt. Er führt vom Datenvertrag über die Verarbeitung von Stripe-Ereignissen bis zur Abnahme vor dem ersten echten Beleg. Jede Seite verweist auf die Datei im ZIP, mit der Ihr Team die Aussage selbst nachprüft.

  1. S. 1Der Weg durch das Paket

  2. S. 2Herkunft jeder Angabe

  3. S. 3Sechs Schritte vom Webhook zum Versand

  4. S. 4100,00 + 19,00 = 119,00 EUR

  5. S. 5Arbeitsliste Engineering und Finance

  6. S. 6Architekturentscheidung und Quellen

Was das Paket beweist und was Ihr Team noch beweisen muss.

ENTSCHEIDUNGEN-UND-ABNAHME.md ist eine ausfüllbare Arbeitsvorlage mit Entscheidung, Zuständigkeit, Testnachweis und Freigabe. Drei Szenarien sind im Paket geprüft, nur für genau diese Dateien. Die übrigen sind Testvorgaben für Ihre Anwendung.

„Eine leere Ergebniszelle bedeutet nicht bestanden.“

ENTSCHEIDUNGEN-UND-ABNAHME.md · Abschnitt 2Auszug
  • Standardbeispiel des Pakets XML und Regeln akzeptieren den Beleg geprüft im Paket geprüft
  • Fehlender Käufer-Endpunkt Ablehnung, keine Freigabe zum Versand geprüft PEPPOL-EN16931-R010
  • Bruttosumme 118,99 statt 119,00 EUR Ablehnung der widersprüchlichen Summen geprüft BR-CO-15, BR-CO-16
  • Gleiches Ereignis zweimal Ein Dokument, ein Versandauftrag offen Ihr Lauf
  • Zwei Ereignis-IDs, eine Rechnung Dokumentidentität verhindert Doppelausgabe offen Ihr Lauf
  • Zwei parallele Worker Eindeutig auch unter Konkurrenz offen Ihr Lauf

Erst das Paket. Dann entscheiden.

Das Paket setzt keine Entscheidung für Kontier voraus. Wenn Stripe Ihre Rechnungsquelle bleibt, bauen Sie mit dem Feldplan und den Fehlerfällen Ihre eigene Ausgabe. Wenn neben der E-Rechnung auch Abos, Verbrauchsabrechnung und der Monatsabschluss zusammenkommen müssen, prüfen Sie Kontier als Billing-Schicht über Stripe.

  1. ZahlungStripeoder GoCardless, bleibt
  2. AbrechnungKontierAbos, Usage, USt, E-Rechnung
  3. ÜbergabeXRechnung · DATEVan Empfänger und Buchhaltung
Stripe bleibt Ihr Zahlungsanbieter. Kontier verbindet darüber Abos, Verbrauchsabrechnung, Umsatzsteuer, E-Rechnung und die Übergabe an die Buchhaltung. Billing-Workflow mit Stripe ansehen →

Was Sie wofür bekommen

Integrationspaket
Mit dem Newsletter-Abo nach Bestätigung Ihrer E-Mail-Adresse. Ohne Testkonto, ohne Kreditkarte.
Öffentlicher Test
14 Tage, Start über die Preisseite mit Kreditkarte. Läuft im gewählten Plan weiter, wenn Sie nicht vor Tag 14 kündigen.
Persönliche Einladung
Unabhängig vom Newsletter können Sie eine persönliche Einladung zum 30-Tage-Test anfragen: ohne Kreditkarte, mit automatischem Testende. Die Einladung folgt innerhalb von 48 Stunden.
Paket anfordern Pläne ansehen

Technischer Leitfaden, keine Steuer- oder Rechtsberatung. Der Prüfnachweis gilt für die mitgelieferten XML-Dateien. Ihre eigenen Rechnungen und Abläufe prüfen Sie separat.

Demo vereinbaren

Technische Demo, 15 Minuten mit einem Engineer: zu Ihrem Preismodell und Ihren Steueranforderungen.

Wie wir Ihre Angaben verarbeiten: Datenschutzerklärung.

Lieber per E-Mail? contact@frontieralgorithmics.com

Nachricht an Kontier

Schreiben Sie uns direkt hier. Wir antworten per E-Mail, in der Regel innerhalb eines Werktags.

Wie wir Ihre Angaben verarbeiten: Datenschutzerklärung.

Schritt 1 von 3

Womit rechnen Sie heute ab?

Lieber per E-Mail? contact@frontieralgorithmics.com