XRechnung XML Beispiel: So ist das Format XRechnung im XML aufgebaut
Wer nach einem XRechnung XML Beispiel sucht, will in der Regel drei Dinge: die Blockstruktur verstehen, typische Pflichtfelder finden und das Format XRechnung so umsetzen, dass Validatoren nicht sofort Fehler melden. XRechnung ist eine deutsche Spezifikation auf Basis EN 16931. Technisch wird sie als XML in einer zugelassenen Syntax abgebildet, in der Praxis häufig UN CEFACT CII, teils auch UBL. Wichtig für dein Projekt ist weniger die Theorie, sondern eine robuste Struktur: eindeutige Identitäten, saubere Party Daten, konsistente Summen, korrekte Steuercodes, und eine Guideline Kennung, die zu XRechnung passt.
Dieses Beispiel ist bewusst modular. Jeder Abschnitt bildet einen typischen XML Block ab. Genau diese Blöcke eignen sich gut als Überschriften und als Screenshot Ausschnitte, weil Leser die Datei schneller “scannen” können.
ExchangedDocumentContext: Profil und Guideline im xml xrechnung
Der DocumentContext sagt dem Empfänger, nach welchem Regelwerk die Datei zu prüfen ist. Im xml xrechnung ist das der erste Block, der über Akzeptanz entscheidet. Wenn hier ein falsches Profil steht, helfen korrekte Inhalte oft nicht mehr.
<rsm:ExchangedDocumentContext> <ram:BusinessProcessSpecifiedDocumentContextParameter> <ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID> </ram:BusinessProcessSpecifiedDocumentContextParameter> <ram:GuidelineSpecifiedDocumentContextParameter> <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID> </ram:GuidelineSpecifiedDocumentContextParameter> </rsm:ExchangedDocumentContext>
Praxispunkt: In Konzernen mit mehreren Ländern ist genau dieser Wert häufig der erste Stolperstein, weil Profile je Land abweichen. Das gilt auch dann, wenn du “nur” das gleiche Datenmodell wiederverwendest.
ExchangedDocument: Rechnungsnummer, Datum, Typcode im XRechnung XML Beispiel
Hier steht die Dokumentidentität. Für jedes XRechnung XML Beispiel sind mindestens ID, TypeCode und IssueDateTime relevant. TypeCode 380 steht typischerweise für Rechnung, 381 für Gutschrift. Der Rest folgt euren Prozessen, muss aber formal sauber sein.
<rsm:ExchangedDocument>
<ram:ID>RE-2026-000123</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20251215</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>SellerTradeParty: Verkäuferdaten als Block im Format XRechnung
SellerTradeParty ist der Verkäufer. Typische Pflichtinhalte: Name, Postanschrift, mindestens ein Identifikator, sowie optional Kontakt. In der Praxis werden Fehler oft durch unvollständige Adressen oder unklare Steuernummern verursacht.
<ram:SellerTradeParty>
<ram:Name>Muster GmbH</ram:Name>
<ram:PostalTradeAddress>
<ram:PostcodeCode>10115</ram:PostcodeCode>
<ram:LineOne>Musterstrasse 1</ram:LineOne>
<ram:CityName>Berlin</ram:CityName>
<ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>
<ram:SpecifiedTaxRegistration>
<ram:ID schemeID="VA">DE123456789</ram:ID>
</ram:SpecifiedTaxRegistration>
</ram:SellerTradeParty>Kritischer Punkt: Nutze keine “Freitext IDs” ohne klares schemeID Konzept. Das ist einer der häufigsten Gründe für Rückfragen, auch wenn die Rechnung formal durchläuft.
BuyerTradeParty: Empfänger und Leitweg ID im xml xrechnung
BuyerTradeParty ist beim B2G Versand entscheidend. Häufig wird eine Routing Kennung benötigt, etwa eine Leitweg ID. Technisch hängt die genaue Platzierung von Profilregeln ab, aber der Empfänger muss jedenfalls eindeutig identifizierbar sein.
<ram:BuyerTradeParty>
<ram:Name>Beispiel Behoerde</ram:Name>
<ram:ID>991-1234567890</ram:ID>
<ram:PostalTradeAddress>
<ram:PostcodeCode>50667</ram:PostcodeCode>
<ram:LineOne>Am Platz 2</ram:LineOne>
<ram:CityName>Koeln</ram:CityName>
<ram:CountryID>DE</ram:CountryID>
</ram:PostalTradeAddress>
</ram:BuyerTradeParty>Praxispunkt: Wenn eure Datenquelle Leitweg ID und Debitor ID vermischt, entstehen schnell falsche Zuordnungen. Trenne “Routing” von “Kunde” in eurem Mapping. Das reduziert Ablehnungen und Supportaufwand.
ApplicableHeaderTradeAgreement: Referenzen, Bestellnummern, Vertragsbezug
Dieser Block ist relevant, wenn ihr Bestellreferenzen, Auftragsnummern oder Vertragsdaten sauber transportieren müsst. Im öffentlichen Bereich ist eine Bestellreferenz oft ein Pflichtpunkt.
<ram:ApplicableHeaderTradeAgreement>
<ram:BuyerReference>Leitweg-ID-oder-Referenz</ram:BuyerReference>
<ram:SellerOrderReferencedDocument>
<ram:IssuerAssignedID>SO-7788</ram:IssuerAssignedID>
</ram:SellerOrderReferencedDocument>
</ram:ApplicableHeaderTradeAgreement>IncludedSupplyChainTradeLineItem: Positionen im XRechnung XML Beispiel
Positionen sind Pflicht, sobald du nicht nur Summen ohne Leistungsbezug senden willst. Wichtig: LineID, Produktname, Menge, Einheit, Preise, Steuerkategorie. Die Details sind umfangreich, daher hier ein kompaktes Beispiel.
<ram:IncludedSupplyChainTradeLineItem>
<ram:AssociatedDocumentLineDocument>
<ram:LineID>1</ram:LineID>
</ram:AssociatedDocumentLineDocument
<ram:SpecifiedTradeProduct>
<ram:Name>Beratungsleistung</ram:Name>
</ram:SpecifiedTradeProduct>
<ram:SpecifiedLineTradeDelivery>
<ram:BilledQuantity unitCode="HUR">10</ram:BilledQuantity>
</ram:SpecifiedLineTradeDelivery>
<ram:SpecifiedLineTradeSettlement>
<ram:SpecifiedTradeSettlementLineMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
</ram:SpecifiedTradeSettlementLineMonetarySummation>
</ram:SpecifiedLineTradeSettlement>
</ram:IncludedSupplyChainTradeLineItem>Kritischer Punkt: Einheitencodes und Rundung sind nicht “nice to have”. Wenn ihr aus Quellsystemen mit drei Dezimalen kommt, braucht ihr definierte Rundungsregeln, sonst passen Positionen und Summen nicht zusammen.
ApplicableHeaderTradeSettlement: Steuer, Zahlungsdaten und Summen im Format XRechnung
Das ist der Block, in dem Validatoren am häufigsten meckern. Grund: Summen müssen exakt zu Positionen und Steuersätzen passen. Außerdem müssen Steuerkategorien korrekt codiert sein. Wenn ihr eine automatisierte Verarbeitung wollt, ist dieser Block der wichtigste Qualitätshebel.
<ram:ApplicableHeaderTradeSettlement> <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
<ram:ApplicableTradeTax>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19</ram:RateApplicablePercent>
<ram:CalculatedAmount>190.00</ram:CalculatedAmount>
<ram:BasisAmount>1000.00</ram:BasisAmount>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
<ram:TaxTotalAmount>190.00</ram:TaxTotalAmount>
<ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
<ram:DuePayableAmount>1190.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
Empfehlung: Implementiere im Prozess eine “Summenbruecke” als technische Prüfung, bevor du das XML erzeugst. Das ist deutlich billiger als Fehlersuche nach Ablehnung.
Checkliste: So wird dein xml xrechnung in der Praxis akzeptiert
Guideline ID passt exakt zum Zielprofil.
Rechnungsnummer ist eindeutig und stabil.
TypeCode passt zur Belegart.
Seller und Buyer sind vollständig, inklusive CountryID und Postcode.
Referenzen wie BuyerReference oder OrderReference sind gemappt und nicht leer.
Jede Position hat LineID, Menge mit unitCode, Betrag.
Steuer: CategoryCode und Prozentsatz sind korrekt.
Summen: LineTotal, TaxTotal, GrandTotal, DuePayable sind rechnerisch konsistent.
Dezimalregeln sind fest definiert und technisch enforced.
Validierung läuft automatisiert gegen Schema und Business Rules, vor dem Versand.
Diese Checkliste ist genau der Inhalt, den Leser erwarten, wenn sie “XRechnung xml Beispiel” oder “format XRechnung” suchen. Sie reduziert Rückfragen und erhöht direkte Umsetzbarkeit.
FAQ zu XRechnung XML, xml xrechnung und Format XRechnung
Was ist der Unterschied zwischen XRechnung und „normalem“ XML?
XRechnung ist nicht nur XML, sondern ein Regelwerk mit Pflichtfeldern, Codes und Prüfregeln. XML ist nur die Transportsyntax.
Kann ich ein XRechnung XML Beispiel einfach kopieren und versenden?
Nein. Ohne korrekte Identifikatoren, Referenzen, Steuermapping und Summenkonsistenz scheitert es in der Validierung oder beim Empfängerprozess.
