Anzahlung, Teilrechnung, Schlussrechnung: die drei Rechnungen, an denen E-Rechnungsprojekte hängenbleiben
Es gibt eine Frage, die uns in den letzten Monaten häufiger erreicht hat als jede andere – häufiger als Fragen zu PEPPOL, zu Validierungsfehlern oder zu Anhängen: Wie bilde ich eine Schlussrechnung ab, auf die schon zwei Anzahlungen gezahlt wurden?
Die Frage klingt harmlos. Sie ist es nicht. Wer sie falsch beantwortet, produziert eine Rechnung, die jede Validierung besteht, sauber durch PEPPOL läuft, beim Kunden ohne Klärfall verbucht wird – und trotzdem falsch ist. Der Fehler fällt nicht beim Empfänger auf, sondern in der Betriebsprüfung, drei Jahre später, multipliziert mit der Anzahl der Projekte.
Weil die Frage so oft kommt, haben wir sie einmal vollständig aufgeschrieben: die drei Rechnungsarten, ihre steuerliche Grundlage, die konkrete Modellierung in den BT-Feldern von EN 16931, die XML-Pfade in UBL und CII, und die Fehler, die wir in echten Rechnungen tatsächlich sehen – jeweils mit der Folge, die sie haben. Am Ende der Fall, nach dem gleich danach gefragt wird: Was passiert, wenn mitten in der Anzahlungskette ein Storno liegt?
Die Begriffe zuerst, weil sie ständig vermischt werden
In deutschen ERP-Systemen kursieren fünf Begriffe für drei Sachverhalte. Das ist die Wurzel der meisten Modellierungsfehler.
| Begriff | Was abgerechnet wird | Leistung erbracht? |
|---|---|---|
| Anzahlungs-/Vorausrechnung | Ein Betrag vor der Leistung, ohne Bezug zu einer messbaren Teilleistung | nein |
| Abschlagsrechnung | Zahlungsstand nach Baufortschritt (§ 632a BGB, § 16 VOB/B) | teilweise, aber nicht abgenommen |
| Teil-/Teilschlussrechnung | Eine abgeschlossene, abgrenzbare Teilleistung | ja, für diesen Teil |
| Schluss-/Endrechnung | Die Gesamtleistung, abzüglich der bereits gezahlten Beträge | ja, vollständig |
| Restrechnung | Nur der verbliebene Restbetrag, ohne Ausweis der Vorauszahlungen | ja, vollständig |
Der entscheidende Unterschied verläuft zwischen Teilrechnung und Anzahlungsrechnung: Eine Teilrechnung rechnet eine erbrachte Leistung ab, sie ist eine gewöhnliche Rechnung über einen kleineren Umfang. Eine Anzahlungsrechnung rechnet gar keine Leistung ab, sondern eine Zahlung. Steuerlich und in der Modellierung sind das zwei verschiedene Dinge.
Kurze steuerrechtliche Einordnung
Sie brauchen keine Umsatzsteuerprüfung im Team, um E-Rechnungen richtig zu modellieren, aber vier Normen sollten Sie kennen, weil das Datenmodell sie abbilden muss.
§ 13 Abs. 1 Nr. 1a Satz 4 UStG
Die Steuer entsteht schon mit der Anzahlung – mit Ablauf des Voranmeldungszeitraums der Vereinnahmung, auch bei Sollversteuerung. Sie führen die Steuer ab, bevor Sie geliefert haben.
§ 14 Abs. 5 Satz 1 UStG
Die Anzahlungsrechnung ist eine echte Rechnung. Sie braucht alle Pflichtangaben nach § 14 Abs. 4 UStG und muss erkennen lassen, dass über eine noch nicht erbrachte Leistung abgerechnet wird.
§ 14 Abs. 5 Satz 2 UStG + Abschnitt 14.8 UStAE
Die Endrechnung muss die Anzahlungen absetzen – Teilentgelte und die darauf entfallenden Steuerbeträge. Mehrere Darstellungsformen sind zulässig: im XML, in BT-22 oder als Anhang.
§ 14c Abs. 1 UStG (wenn Sie es falsch machen)
Wer die Absetzung unterlässt, schuldet den in der Endrechnung ausgewiesenen Steuerbetrag vollständig – zusätzlich zur bereits abgeführten Anzahlungssteuer. Bei unserem Beispiel unten: 11.400 € zweimal.
Die Restrechnung ist der Ausweg. Abschnitt 14.8 Abs. 11 UStAE erlaubt ausdrücklich, statt einer Endrechnung eine Rechnung nur über das restliche Entgelt zu erteilen, ohne die im Voraus vereinnahmten Beträge anzugeben. Das ist die technisch sauberste Variante in der E-Rechnung.
Die Modellierung: welches Feld welchen Sachverhalt trägt
1. Die Anzahlungsrechnung
BT-3 (Rechnungsart). UNTDID 1001 kennt für diesen Fall den Code 386 „Prepayment invoice", und die EN-16931-Codeliste enthält ihn. XRechnung enthält ihn nicht. Die Geschäftsregel BR-DE-17 beschränkt BT-3 auf acht Codes:
| Code | Bedeutung |
|---|---|
| 326 | Teilrechnung (Partial invoice) |
| 380 | Handelsrechnung (Commercial invoice) |
| 381 | Gutschrift (Credit note) |
| 384 | Berichtigte Rechnung (Corrected invoice) |
| 389 | Selbstfakturierte Rechnung (Self-billed invoice) |
| 875 | Abschlagsrechnung Bauleistung (Partial construction invoice) |
| 876 | Teilschlussrechnung Bauleistung (Partial final construction invoice) |
| 877 | Schlussrechnung Bauleistung (Final construction invoice) |
Praktische Konsequenz: In einer XRechnung kodieren Sie die Anzahlungsrechnung als 380 – oder bei Bauleistungen als 875. In ZUGFeRD/Factur-X ist 386 zulässig. Wenn Sie beide Formate aus demselben Datensatz erzeugen, brauchen Sie an dieser Stelle eine formatabhängige Abbildung.
BT-72 / BG-14
In ZUGFeRD/Factur-X optional – leer lassen ist korrekt. In XRechnung greift BR-DE-6: entweder BT-72 oder BG-14 muss vorhanden sein. Lösung: BG-14 mit dem geplanten Leistungszeitraum befüllen (z. B. 01.09.2026–31.12.2026). Keinesfalls das Rechnungsdatum als BT-72 eintragen – das behauptet eine erbrachte Leistung.
BT-22 (Bemerkung)
„Anzahlung auf eine noch nicht ausgeführte Leistung. Vertrag 2026-114, Leistungszeitraum ab 09/2026." Pflichtinhalt nach § 14 Abs. 5 UStG – und bei XRechnung das Gegenstück zum befüllten BG-14.
Positionen
Eigene Position über den Anzahlungsbetrag, nicht die Positionen der Gesamtleistung. Netto, Steuersatz, Steuer.
2. Die Teilrechnung
Unspektakulär: Das ist eine normale Rechnung über einen abgeschlossenen Leistungsteil, mit echten Positionen, echtem Leistungsdatum und echter Steuer. BT-3 ist 326, bei Bauleistungen 876. Keine Sonderbehandlung in den Summenfeldern, kein BT-113. Der einzige Fallstrick: Wer eine Anzahlung als Teilrechnung deklariert, weil 326 „irgendwie besser passt", behauptet damit eine erbrachte Leistung – mit allen Folgen für Leistungsdatum, Steuerentstehung und Vorsteuerabzug des Kunden.
3. Die Schlussrechnung – hier liegt die eigentliche Arbeit
Die Schlussrechnung rechnet die volle Leistung ab. Volle Positionen, volle Bemessungsgrundlage, volle Umsatzsteuer. Erst unterhalb der Steuerberechnung werden die bereits gezahlten Bruttobeträge abgezogen. Genau dafür existiert BT-113.
| BT | Bedeutung | Wert im Beispiel |
|---|---|---|
| BT-106 / BT-109 | Summe Positionen / Nettobetrag | 100.000,00 € |
| BT-110 | Umsatzsteuer gesamt | 19.000,00 € |
| BT-112 | Bruttobetrag (inkl. USt) | 119.000,00 € |
| BT-113 | Vorauszahlungsbetrag (brutto!) | 71.400,00 € |
| BT-114 | Rundungsbetrag | 0,00 € |
| BT-115 | Fälliger Betrag | 47.600,00 € |
BR-CO-16: BT-115 = BT-112 − BT-113 + BT-114 — dazu die Referenzen auf die Vorrechnungen in BG-3 mit BT-25 (Nummer) und BT-26 (Datum).
BT-113 ist ein Bruttobetrag. Das ist der häufigste Einzelfehler. Wer 60.000,00 € (netto) statt 71.400,00 € einträgt, produziert einen fälligen Betrag von 59.000,00 € – und eine Rechnung, die formal valide ist und dem Kunden 11.400 € zu viel in Rechnung stellt.
Das Rechenbeispiel
Auftrag über 100.000,00 € netto, 19 % Umsatzsteuer. Zwei Anzahlungen à 30 %, beide vor Leistungserbringung gestellt und bezahlt.
| Dokument | Datum | Netto | USt | Brutto |
|---|---|---|---|---|
| A-2026-0101 (Anzahlung 30 %) | 15.03.2026 | 30.000,00 € | 5.700,00 € | 35.700,00 € |
| A-2026-0142 (Anzahlung 30 %) | 15.05.2026 | 30.000,00 € | 5.700,00 € | 35.700,00 € |
| RE-2026-0815 (Schlussrechnung) | 28.08.2026 | 100.000,00 € | 19.000,00 € | 119.000,00 € |
| ./. bereits gezahlt (BT-113) | — | 60.000,00 € | 11.400,00 € | 71.400,00 € |
| Fälliger Betrag (BT-115) | — | 40.000,00 € | 7.600,00 € | 47.600,00 € |
Die Bemessungsgrundlage der Schlussrechnung ist und bleibt 100.000,00 €. Die ausgewiesene Umsatzsteuer ist und bleibt 19.000,00 €. Abgezogen wird ausschließlich unterhalb des Bruttobetrags.
Das XML
UBL (XRechnung UBL, Peppol BIS 3.0)
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>A-2026-0101</cbc:ID>
<cbc:IssueDate>2026-03-15</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:BillingReference>
<cac:InvoiceDocumentReference>
<cbc:ID>A-2026-0142</cbc:ID>
<cbc:IssueDate>2026-05-15</cbc:IssueDate>
</cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">100000.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">100000.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">119000.00</cbc:TaxInclusiveAmount>
<cbc:PrepaidAmount currencyID="EUR">71400.00</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="EUR">47600.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>CII (XRechnung CII, ZUGFeRD, Factur-X)
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
<ram:ApplicableTradeTax>
<ram:CalculatedAmount>19000.00</ram:CalculatedAmount>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:BasisAmount>100000.00</ram:BasisAmount>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:ApplicableTradeTax>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>100000.00</ram:LineTotalAmount>
<ram:TaxBasisTotalAmount>100000.00</ram:TaxBasisTotalAmount>
<ram:TaxTotalAmount currencyID="EUR">19000.00</ram:TaxTotalAmount>
<ram:GrandTotalAmount>119000.00</ram:GrandTotalAmount>
<ram:TotalPrepaidAmount>71400.00</ram:TotalPrepaidAmount>
<ram:DuePayableAmount>47600.00</ram:DuePayableAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<!-- InvoiceReferencedDocument NACH MonetarySummation – Reihenfolge ist schemagebunden! -->
<ram:InvoiceReferencedDocument>
<ram:IssuerAssignedID>A-2026-0101</ram:IssuerAssignedID>
<ram:FormattedIssueDateTime>
<qdt:DateTimeString format="102">20260315</qdt:DateTimeString>
</ram:FormattedIssueDateTime>
</ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>Achtung Reihenfolge in CII: ram:InvoiceReferencedDocument steht nach ram:SpecifiedTradeSettlementHeaderMonetarySummation, nicht davor. Die Sequenz ist im Schema festgelegt; wer die Referenz intuitiv oben einsortiert, bekommt einen XSD-Fehler, der auf ein völlig anderes Element zeigt.
Was das Kernmodell nicht kann – und was Sie stattdessen tun
BT-113 ist ein einziger Betrag ohne Steueraufteilung. Das Steuerrecht verlangt die Absetzung der Teilentgelte und der darauf entfallenden Steuerbeträge. Das Kernmodell kennt für die Vorauszahlung genau ein Feld: eine Bruttosumme. Bei gemischten Steuersätzen ist die Information schlicht nicht darstellbar.
BG-3 ist je nach Profil auf eine Referenz begrenzt. In EN 16931 ist die Rechnungsreferenz mit 0..n definiert. In ZUGFeRD/Factur-X auf Basis von CII D16B – also den heute verbreiteten Versionen – ist sie auf 0..1 eingeschränkt. Erst Factur-X 1.08 (Dezember 2025, D22B) hebt das auf 0..n.
Restrechnung
Abschnitt 14.8 Abs. 11 UStAE
Nur den Restbetrag abrechnen, mit Hinweis in BT-22. Kein BT-113, keine Absetzungsproblematik, keine § 14c-Falle. Technisch sauberste Variante – sofern Vertrag oder VOB keine Schlussrechnung über die Gesamtleistung verlangen.
Endrechnung + Anhang
14.8 Abs. 8 Nr. 2 UStAE, BMF 23.02.2026
BT-113 mit Gesamtbetrag, Aufstellung der Teilentgelte und Steuerbeträge als Anhang (BG-24), ausdrücklicher Hinweis in BT-22. Frist verlängert bis 30.06.2030.
ZUGFeRD EXTENDED
ram:SpecifiedAdvancePayment (BG-X-45)
Vollständig maschinenlesbar: Betrag, Datum, Steuergruppe, Referenz auf die Anzahlungsrechnung. Nur für Empfänger, die EXTENDED verarbeiten. Zusätzlich zu BT-113 und BG-3, nie anstelle.
ZUGFeRD EXTENDED – SpecifiedAdvancePayment
<ram:SpecifiedAdvancePayment>
<ram:PaidAmount>35700.00</ram:PaidAmount>
<ram:FormattedReceivedDateTime>
<qdt:DateTimeString format="102">20260320</qdt:DateTimeString>
</ram:FormattedReceivedDateTime>
<ram:IncludedTradeTax>
<ram:CalculatedAmount>5700.00</ram:CalculatedAmount>
<ram:TypeCode>VAT</ram:TypeCode>
<ram:CategoryCode>S</ram:CategoryCode>
<ram:RateApplicablePercent>19.00</ram:RateApplicablePercent>
</ram:IncludedTradeTax>
<ram:InvoiceSpecifiedReferencedDocument>
<ram:IssuerAssignedID>A-2026-0101</ram:IssuerAssignedID>
<ram:TypeCode>386</ram:TypeCode>
<ram:FormattedIssueDateTime>
<qdt:DateTimeString format="102">20260315</qdt:DateTimeString>
</ram:FormattedIssueDateTime>
</ram:InvoiceSpecifiedReferencedDocument>
</ram:SpecifiedAdvancePayment>Die Fallstricke – und was sie konkret anrichten
Anzahlung als negative Rechnungsposition
Der häufigste Fehler. Zwei Positionen −30.000,00 € in BT-131 → BT-109 sinkt auf 40.000,00 €, ausgewiesene USt auf 7.600,00 €. Besteht jede Validierung. Die Schlussrechnung dokumentiert eine Gesamtleistung von 40.000,00 €. In der Umsatzsteuer-Sonderprüfung ist das die Rechnung, die den Ordner aufmacht.
Anzahlung als Abschlag auf Dokumentebene (BG-20 / BT-92)
Dieselbe Wirkung mit anderer Technik. Mindert BT-109 vor der Steuerberechnung – noch schwerer zu finden, weil in der Positionsliste nicht sichtbar.
BT-113 netto befüllt
Fälliger Betrag 59.000,00 € statt 47.600,00 €. Oder, wenn BT-115 separat berechnet wird: BR-CO-16 verletzt, Ablehnung. Der Ablehungsfall ist der bessere – er fällt auf.
Anzahlungen gar nicht abgesetzt
Schlussrechnung über 119.000,00 € ohne BT-113. § 14c Abs. 1 UStG: 11.400 € Umsatzsteuer zweimal abführen, bis die Rechnung wirksam berichtigt ist.
Keine Referenz auf Anzahlungsrechnungen (BG-3 leer)
Formal keine Geschäftsregelverletzung, praktisch ein Klärfall: Kreditorenbuchhaltung sieht Abzug von 71.400,00 € ohne Belegzuordnung → Prüfschleife → Skontofrist verbraucht.
BT-3 = 386 in einer XRechnung
BR-DE-17: je nach Empfängersystem Warnung oder Ablehnung. Die Regel greift auch dann, wenn der Rest der Rechnung tadellos ist.
Leistungsdatum auf der Anzahlungsrechnung
BT-72 mit Rechnungsdatum vorbelegt, obwohl Leistung erst in vier Monaten. Kreditorensoftware verarbeitet das als gewöhnliche Rechnung über erbrachte Leistung.
Mehrere Steuersätze in der Anzahlung
19 % und 7 % gemischt, BT-113 als eine Summe. Aufteilung nicht darstellbar. Kein Weg vorbei an Weg 1 (Restrechnung), Weg 2 (Anhang) oder Weg 3 (EXTENDED).
Überzahlung – BT-115 wird negativ
EN 16931 lässt das zu, ein nennenswerter Teil der Empfängersysteme verarbeitet es nicht. Sauberer: Gutschrift (BT-3 = 381) mit Bezug auf die Vorrechnungen.
Rundungsdifferenzen durch Skonto auf Anzahlung
In BT-113 gehört der Betrag, über den abgerechnet wurde, nicht der auf dem Konto eingegangene. Für die Differenz: BT-114 oder Berichtigung nach § 17 UStG – nicht stilles Anpassen von BT-113.
Bauleistungen mit § 13b UStG
Bei Wechsel der Steuerschuldnerschaft ist BT-113 ein Nettobetrag (brutto = netto). Wer für dieselben Kunden mal mit und mal ohne § 13b abrechnet, sollte diese Verzweigung explizit testen.
Praxisbeispiel: wenn ein Storno dazwischenkommt
Der Fall, nach dem am zweithäufigsten gefragt wird. Falsche Konzerngesellschaft, geänderter Leistungsumfang, Zahlendreher: Irgendwann liegt ein Storno in der Kette.
Der Ablauf
| Datum | Beleg | BT-3 | Brutto | Status |
|---|---|---|---|---|
| 15.03.2026 | A-2026-0101, Anzahlung 30 % | 380 | 35.700,00 € | bezahlt 20.03.2026 |
| 15.05.2026 | A-2026-0142, Anzahlung 30 % | 380 | 35.700,00 € | falsche Konzernges., nicht bezahlt |
| 22.05.2026 | G-2026-0007, Storno zu A-2026-0142 | 381 | 35.700,00 € | Storno übermittelt |
| 22.05.2026 | A-2026-0143, Anzahlung 40 % | 380 | 47.600,00 € | bezahlt 30.05.2026 |
| 28.08.2026 | RE-2026-0815, Schlussrechnung | 380 | 119.000,00 € | → BT-115: 35.700,00 € |
Vereinnahmt
83.300,00 €
35.700 + 47.600
BT-113
83.300,00 €
nur vereinnahmte Beträge
BT-115
35.700,00 €
119.000 − 83.300
BG-3 enthält zwei Referenzen: A-2026-0101 und A-2026-0143. Die stornierte Rechnung A-2026-0142 und die Gutschrift G-2026-0007 tauchen nicht auf – sie haben sich neutralisiert, es wurde nie ein Entgelt vereinnahmt. Wer sie mitschickt, produziert beim Empfänger genau den Klärfall, den er vermeiden wollte.
Wenn das Geld schon da war
| Situation | Gezahlt? | Zurückgezahlt? | In BT-113? | In BG-3? |
|---|---|---|---|---|
| storniert vor Zahlung | nein | — | nein | nein |
| storniert, Zahlung bleibt (Verrechnung) | ja | nein | ja | ja + BT-22-Hinweis |
| storniert, Geld zurückgezahlt | ja | ja | nein | nein |
| storniert, teilweise zurückgezahlt | ja | teilweise | verbleibender Betrag | ja + BT-22-Hinweis |
Ein nur intern storniertes Dokument ist nicht storniert. Solange die Berichtigung dem Empfänger nicht zugegangen ist, bleibt die ausgewiesene Steuer nach § 14c Abs. 1 UStG geschuldet, und Ihr Kunde hat einen Beleg, aus dem er Vorsteuer gezogen hat. In Systemen, in denen Stornos nur ein Statusflag im ERP setzen, ist das ein systematischer Fehler.
Wie das Storno selbst aussieht
BT-3 = 381 (Gutschrift), mit positiven Beträgen. Der Dokumenttyp trägt das Vorzeichen.
BG-3 / BT-25 zeigt auf die stornierte Rechnung – nicht optional, sondern das Einzige, was den Beleg zuordenbar macht.
Alternativ BT-3 = 384 (berichtigte Rechnung), wenn Sie das Original korrigieren statt aufheben und neu ausstellen.
Nicht mischen: eine 380 mit negativen Beträgen ist die schlechtere Variante – und in Kombination mit einer 381 zum selben Vorgang die Garantie für eine Doppelverbuchung.
Die Rechnungsnummer der stornierten Rechnung wird nicht wiederverwendet. Neue Nummer für die Ersatzrechnung, sonst verwirft die Dublettenprüfung sie.
Wie es besser wird
Factur-X 1.08 / CII D22B hebt BG-3 auf 0..n und ergänzt in der EXTENDED-Anzahlungsgruppe die Referenz auf die jeweilige Anzahlungsrechnung. Drei Anzahlungen – erstmals vollständig strukturiert darstellbar.
Die Codes 875/876/877 zeigen, dass die deutschen Abrechnungsformen im Standard angekommen sind. Der Weg zu einer allgemeinen Abbildung ist vorgezeichnet.
ViDA und die Meldepflichten machen den Anhang wertlos: Gemeldet werden strukturierte Felder. Das BMF hat die Anhangslösung auf Mitte 2030 verlängert – genau auf den Zeitpunkt, ab dem die Meldepflichten greifen. Danach ist die strukturierte Darstellung keine Option mehr.
Die unbequeme Wahrheit: Die vollständig strukturierte deutsche Schlussrechnung gibt es noch nicht, und wer etwas anderes verspricht, hat entweder das EXTENDED-Profil gemeint oder das Problem nicht verstanden.
Mit rechnungsapi.de
Rechnungsarttyp wird formatabhängig gesetzt (380 für XRechnung, 386 für ZUGFeRD), Leistungsdatum bleibt leer, der Hinweis nach § 14 Abs. 5 UStG steht in der Bemerkung.
Anzahlungsrechnung
{
"invoice": {
"invoiceNumber": "A-2026-0101",
"invoiceIssueDate": "2026-03-15",
"invoiceTypeCode": "380",
"note": "Anzahlung auf eine noch nicht ausgeführte Leistung. Vertrag 2026-114.",
"lines": [
{ "name": "Anzahlung 30 % gemäß Vertrag 2026-114",
"quantity": 1, "netPrice": 30000.00, "vatRate": 19.0 }
]
}
}Schlussrechnung
{
"invoice": {
"invoiceNumber": "RE-2026-0815",
"invoiceIssueDate": "2026-08-28",
"invoiceTypeCode": "380",
"prepaidAmount": 71400.00,
"precedingInvoiceReferences": [
{ "invoiceNumber": "A-2026-0101", "issueDate": "2026-03-15" },
{ "invoiceNumber": "A-2026-0142", "issueDate": "2026-05-15" }
],
"note": "Absetzung der Anzahlungen: 2 × 35.700,00 EUR brutto, darin 11.400,00 EUR USt (19 %)."
}
}BT-115 wird nach BR-CO-16 berechnet, nicht übergeben. Validiert gegen EN 16931 und KoSIT-Regeln vor dem Versand.
Checkliste
Anzahlungsrechnung
- BT-3 formatabhängig: 380 in XRechnung (875 Bau), 386 möglich in ZUGFeRD
- Eigene Position über Anzahlungsbetrag, nicht Positionen der Gesamtleistung
- BT-72 / BG-14: ZUGFeRD → leer; XRechnung (BR-DE-6) → BG-14 mit geplantem Leistungszeitraum
- Hinweis § 14 Abs. 5 UStG in BT-22 mit Vertrags-/Projektbezug
- Umsatzsteuer auf Anzahlungsbetrag ausgewiesen (außer § 13b UStG)
Schlussrechnung
- Volle Leistung in Positionen, volle Bemessungsgrundlage in BT-109
- Anzahlung niemals als negative Position (BT-131) oder Abschlag (BT-92)
- BT-113 = Summe Anzahlungen brutto
- BR-CO-16 prüfen: BT-115 = BT-112 − BT-113 + BT-114
- BG-3 je Anzahlungsrechnung – Kardinalität des Zielprofils prüfen
- Absetzung strukturiert, in BT-22 oder als Anhang (BG-24)
- CII: InvoiceReferencedDocument nach MonetarySummation
- Alternative: Restrechnung nach Abschnitt 14.8 Abs. 11 UStAE
- Bei negativem BT-115: Gutschrift statt Schlussrechnung erwägen
- Testrechnung je Großkunde – kommt fälliger Betrag im Zahllauf an?
Storno in der Kette
- Storno als eigener Beleg BT-3 = 381 mit positiven Beträgen (oder 384)
- BG-3 / BT-25 zeigt auf stornierte Rechnung
- Storno wird dem Empfänger übermittelt, nicht nur im ERP gesetzt
- Neue Rechnungsnummer für Ersatzrechnung
- BT-113 enthält nur vereinnahmte und nicht zurückgezahlte Beträge
- Vereinnahmte Beträge aus stornierten Rechnungen: Klartext in BT-22
- Rückzahlung: § 17 Abs. 2 Nr. 2 UStG im Zeitraum der Rückzahlung
- Stornierte Rechnungen ohne Zahlung: nicht in BG-3 der Schlussrechnung
Trägt Ihre heutige Modellierung?
Sie stellen Anzahlungs- und Schlussrechnungen und wollen wissen, ob Ihre aktuelle Umsetzung trägt – Stornos eingeschlossen? Schicken Sie uns eine echte Schlussrechnung als XML oder ZUGFeRD-PDF – wir sagen Ihnen innerhalb eines Tages, was in BT-109, BT-113 und BG-3 steht und was das steuerlich bedeutet.
Quellen
EN 16931-1 (BT-3, BT-25/BT-26, BT-113, BT-115, BR-CO-16, BR-55); Factur-X 1.08 / ZUGFeRD, Feldliste CII D22B EN16931 und EXTENDED (BG-X-45, BG-X-85); Spezifikation Standard XRechnung 3.0.2, KoSIT; BR-DE-17, Codevorrat BT-3; UNTDID 1001 (Peppol Codeliste); BMF-Schreiben zur Einführung der obligatorischen E-Rechnung vom 15.10.2024 (BStBl I 2024, 1320, Rn. 48) und vom 15.10.2025; Verlängerung der Anhangsregelung auf den 30.06.2030 durch BMF-Schreiben vom 23.02.2026; Abschnitt 14.8 UStAE, Abs. 7 bis 11; § 13 Abs. 1 Nr. 1a Satz 4, § 14 Abs. 4 und 5, § 14c Abs. 1, § 15 Abs. 1 Satz 1 Nr. 1 Satz 3, § 17 Abs. 1 und 2 Nr. 2 UStG; § 632a BGB, § 16 VOB/B.