Gutschrift in UBL: zwei Varianten und wann Sie welche wählen

Zwei Möglichkeiten, eine Gutschrift in UBL zu versenden: das CreditNote-Dokument und die negative Invoice.

Manchmal muss eine Rechnung korrigiert werden. Ein zu hoher Betrag, ein falscher MwSt.-Satz, eine Retoure: Die Lösung ist eine Gutschrift. Im UBL-Standard gibt es zwei Möglichkeiten, eine Gutschrift zu versenden. Sie sind technisch sehr unterschiedlich, dienen aber demselben Zweck. Welche Variante Sie wählen, hängt von Ihrer Software, Ihrem Empfänger und dem verwendeten Peppol-Profil ab.

Variante 1: das CreditNote-Dokument

Die erste Variante ist ein separater UBL-Dokumenttyp: CreditNote. Dieses Dokument verwendet ein eigenes XML-Schema (CreditNote-2) und hat eigene Elementnamen. Statt InvoiceLine heißt es CreditNoteLine, und statt InvoicedQuantity steht CreditedQuantity.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- Parteien, MwSt.-Summen, etc. -->
  <cac:CreditNoteLine>
    <cbc:ID>1</cbc:ID>
    <cbc:CreditedQuantity unitCode="EA">5</cbc:CreditedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">125.00</cbc:LineExtensionAmount>
    <!-- Artikel und Preis -->
  </cac:CreditNoteLine>
</CreditNote>

Alle Beträge in einer CreditNote sind positiv. Die Tatsache, dass es sich um ein CreditNote-Dokument handelt, macht implizit klar, dass es sich um eine Korrektur handelt. Das BillingReference-Element verweist auf die ursprüngliche Rechnung, die gutgeschrieben wird.

Merkmale des CreditNote-Dokuments
  • Eigener XML-Stammknoten (CreditNote statt Invoice)
  • Eigene Elementnamen (CreditNoteLine, CreditedQuantity)
  • Alle Beträge sind positiv
  • Breit unterstützt von Peppol-Empfängern
  • TypeCode ist 381 (Gutschrift bezogen auf Rechnungen)
Variante 2: die negative Invoice

Die zweite Variante verwendet das reguläre Invoice-Dokument, jedoch mit negativen Beträgen. Der InvoiceTypeCode bleibt 380 (Handelsrechnung). Technisch ist es eine reguläre Rechnung, aber durch die negativen Beträge fungiert sie als Gutschrift. Dies ist die niederländische Konvention, die im UBL Kettentest des Forschungsbüros GBNED beschrieben wird.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ID>CN-2026-0001</cbc:ID>
  <cbc:IssueDate>2026-03-08</cbc:IssueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>F-2026-00042</cbc:ID>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- Parteien, MwSt.-Summen, etc. -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="EA">-5</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">-125.00</cbc:LineExtensionAmount>
    <!-- Artikel und Preis -->
  </cac:InvoiceLine>
</Invoice>

Bei dieser Variante sind Mengen und Beträge negativ. Der MwSt.-Betrag und der zahlbare Betrag sind ebenfalls negativ. Die Struktur ist ansonsten identisch mit einer regulären Rechnung.

Merkmale der negativen Invoice
  • Selber XML-Stammknoten wie eine reguläre Rechnung (Invoice)
  • Selbe Elementnamen (InvoiceLine, InvoicedQuantity)
  • Beträge und Mengen sind negativ
  • InvoiceTypeCode ist 380 (reguläre Rechnung), das negative Vorzeichen zeigt an, dass es sich um eine Gutschrift handelt
  • Einfacher zu implementieren für sendende Software (kein separater Dokumenttyp erforderlich)
  • Wird im GBNED/UBL Kettentest als Standard-Verfahren in den Niederlanden beschrieben
Welche Variante sollten Sie wählen?

Die Wahl hängt von drei Faktoren ab:

Was unterstützt Ihre Software? Manche Buchhaltungssoftware erzeugt standardmäßig ein CreditNote-Dokument, andere eine negative Invoice. Wenn Ihre Software nur eine Variante unterstützt, ist die Wahl getroffen.

Was erwartet der Empfänger? Innerhalb von Peppol werden beide Varianten vom BIS Billing 3.0-Profil unterstützt. In der Praxis können empfangende Systeme jedoch eine Präferenz haben. Im Zweifelsfall ist das CreditNote-Dokument die sicherste Wahl, da es die expliziteste Variante ist.

Welches Peppol-Profil verwenden Sie? Das Standard-Profil BIS Billing 3.0 akzeptiert sowohl das CreditNote-Schema (381) als auch das Invoice-Schema mit negativen Beträgen (380). Nicht alle Profile unterstützen beide Varianten. Prüfen Sie dies, wenn Sie ein branchenspezifisches Profil verwenden.

Tipp: Bei eConnect können Sie beide Varianten einreichen. Die Plattform erkennt automatisch, ob es sich um ein CreditNote-Dokument oder eine negative Invoice handelt, und verarbeitet sie auf die gleiche Weise. Wenn der Empfänger ein bestimmtes Format erwartet, transformiert die PSB das Dokument automatisch.

Vorzeichenkonventionen im Vergleich

Die zwei Varianten verwenden entgegengesetzte Vorzeichenkonventionen. Diese Übersicht zeigt, wie dieselbe Gutschrift (5 Stück à 25 Euro) in beiden Varianten aussieht:

ElementCreditNote (TypeCode 381)Negative Invoice (TypeCode 380)XML-SchemaCreditNoteInvoicePriceAmount25,00 (positiv)25,00 (positiv, erforderlich per BR-27)CreditedQuantity / InvoicedQuantity5 (positiv)-5 (negativ)LineExtensionAmount125,00 (positiv)-125,00 (negativ)AllowanceCharge-BeträgepositivnegativTaxAmountpositivnegativPayableAmountpositivnegativ

Der entscheidende Unterschied liegt in der Interpretation. Bei einer CreditNote ist das umgekehrte Vorzeichen implizit: Alle Beträge sind positiv, aber der Dokumenttyp macht klar, dass es sich um eine Gutschrift handelt. Bei einer negativen Invoice sind die negativen Beträge selbst der Indikator.

Der PriceAmount (Stückpreis) ist in beiden Varianten positiv. Dies ist in der Validierungsregel BR-27 festgelegt. Bei der negativen Invoice machen Sie den Betrag über die Menge oder über den LineExtensionAmount negativ, nicht über den Stückpreis.

Parteirollen wechseln nicht bei einer Gutschrift (Supplier/Customer/Payee)

Suchvarianten: "Gutschrift Payee eigene Organisation", "Kreditnota Empfänger Lieferant", "Payee statt Lieferant bei Gutschrift", "Supplier Customer tauschen bei Gutschrift", "zahlbar vs. zu empfangen PayableAmount".

Soll und Haben ist kein Parteitausch. AccountingSupplierParty bleibt der Lieferant und AccountingCustomerParty bleibt der Abnehmer, auch auf einer Gutschrift. Ob der Abnehmer zahlen oder erhalten muss, ergibt sich aus dem Dokumenttyp und dem Vorzeichen von PayableAmount (siehe Tabelle oben): Bei einer negativen Invoice (380) ist PayableAmount negativ, also erhält der Abnehmer; bei einer CreditNote (381) sind die Beträge positiv und die Gutschrift steckt im Dokumenttyp.

Die optionale PayeeParty ist nur relevant, wenn der Betrag an eine andere Partei überwiesen werden soll, z. B. beim Factoring. Das ist nicht dasselbe wie „Empfänger der Gutschrift" im informellen Sinne. Steht die eigene Organisation in einem Payee- oder Empfängerfeld, obwohl Supplier und Customer bereits korrekt sind, prüfen Sie zuerst, ob es sich um optionale PayeeParty/PaymentMeans-Daten handelt, bevor Sie eine Korrektur anfordern.

eConnect überschreibt Parteirollen beim Empfang nicht und wendet eine frühere Payee-Korrektur nicht automatisch erneut an, wenn die Quell-UBL bereits korrekt ist. Rechnungen werden so verarbeitet, wie sie eingereicht wurden; fehlerhafte Parteidaten müssen vom Absender in der Quell-UBL korrigiert werden. Siehe auch UBL-Verarbeitung.

Stiller Vorzeichenwechsel Preis/Menge (BIS3 / BR-27)

Suchvarianten: "silent price/quantity sign change during BIS3 transformation", "negative unit price mapping", "negativer Stückpreis", "Vorzeichenwechsel Preis Menge", BR-27 PriceAmount.

Der Nettopreis der Position (BT-146 / PriceAmount) darf nicht negativ sein (BR-27). Bei einer negativen Invoice (TypeCode 380) bleibt der Stückpreis positiv; das Minuszeichen liegt auf der Menge (BT-129) sowie auf Positions- und Gesamtbeträgen. CreditNote (381) hält Preis und Menge positiv; die Gutschrift steckt im Dokumenttyp. Bei Normalisierung oder Transformation zwischen CreditNote- und negativem-Invoice-Schema (unter anderem durch die PSB) ist eine stille Vorzeichenverlagerung zwischen Preis und Menge erwartetes Verhalten, um BR-27 einzuhalten — kein Plugin-Bug. Quelldaten mit negativen Stückpreisen: auf Integrationsseite auf positiven Preis plus Vorzeichen auf Menge oder Dokumenttyp mappen, gemäß der Tabelle oben.

Niederländische Konvention und Peppol

Der UBL Kettentest des Forschungsbüros GBNED beschreibt ausschließlich die 380-Variante (negative Invoice) für Gutschriften. Viele niederländische Buchhaltungspakete, die "UBL Ready" zertifiziert sind, erzeugen daher standardmäßig eine negative Invoice. Peppol BIS 3.0 verwendet dagegen standardmäßig das CreditNote-Schema (381) mit positiven Beträgen.

Empfangende Software muss beide Varianten unterstützen. Die PSB transformiert bei Bedarf automatisch zwischen den beiden Schemas, sodass der Empfänger das Dokument in dem Format erhält, das seine Software erwartet.

Was immer enthalten sein muss

Unabhängig davon, welche Variante Sie wählen, enthält eine gültige Gutschrift immer:

  • Einen Verweis auf die Originalrechnung über BillingReference / InvoiceDocumentReference
  • Den richtigen TypeCode: 381 beim CreditNote-Schema, 380 bei der negativen Invoice
  • Korrekte MwSt.-Berechnung (übereinstimmend mit der Originalrechnung)
  • Dieselbe Währung wie die Originalrechnung

Eine Gutschrift ohne Verweis auf die Originalrechnung wird von vielen empfangenden Systemen nicht akzeptiert. Dieser Verweis wird auch für die MwSt.-Verwaltung benötigt: Bei einer Prüfung muss nachvollziehbar sein, welche Rechnung gutgeschrieben wurde.

Korrektur einer bereits versendeten Rechnung

Suchvarianten: "Hilfe Gutschrift", "Gutschrift erstellen", "Gutschrift Portal", "Gutschrift bereits versendete Rechnung", "Korrekturrechnung erstellen Invoice Portal", "doppelte Rechnung gutschreiben", "Duplikatrechnung Gutschrift", "zweimal gleiche Rechnung gesendet gutschreiben", "wie erstelle ich eine Gutschrift".

Eine bereits per Peppol (oder einem anderen Kanal) versendete Rechnung kann nicht mehr bearbeitet werden -- nur Rechnungen, die noch als Entwurf gespeichert sind, sind noch änderbar. Ein Fehler in einer versendeten Rechnung wird immer mit einem neuen Dokument korrigiert, nicht durch Änderung des Originals. Im Portal gibt es keine separate Schaltflaeche Gutschrift; waehlen Sie den Rechnungstyp Korrekturrechnung (UI-Bezeichnung). Der übliche buchhalterische Ablauf:

Schritt 1: Gutschreiben Sie die ursprüngliche Rechnung

Senden Sie eine Korrekturrechnung oder Gutschrift, die auf die ursprüngliche Rechnungsnummer über BillingReference/InvoiceDocumentReference verweist. In der Plattform: Wählen Sie beim Erstellen einer Rechnung den Rechnungstyp Korrekturrechnung und geben Sie die ursprüngliche Rechnungsnummer in das Referenzfeld ein.

Schritt 2: Erstellen Sie eine neue, korrekte Rechnung

Erstellen Sie eine neue Rechnung mit einer neuen, eindeutigen Rechnungsnummer. Eine Rechnungsnummer, die identisch mit dem Original ist, kann durch die Duplikaterkennung blockiert werden.

Hinweis zu Vorzeichenkonventionen: Bei einer Korrekturrechnung mit dem CreditNote-Schema (381) müssen die Beträge positiv sein -- der Dokumententyp drückt die Gutschrift aus. Beim negativen Invoice (380) machen Sie die Menge negativ und halten den Stückpreis positiv (BR-27). Werden die Mengen versehentlich positiv belassen, entsteht eine positive "Gutschriftsrechnung", die nicht als Gutschrift verarbeitet werden kann.

Neue Rechnungsnummer erforderlich: Wenn Sie eine neue Rechnung als Kopie des Originals erstellen, vergeben Sie immer eine neue Rechnungsnummer. Siehe auch Doppelte Rechnungserkennung.

TypeCode 384: Korrekturrechnung

Neben TypeCode 380 und 381 gibt es TypeCode 384 (Korrekturrechnung). Dieser Dokumententyp kann sowohl positive als auch negative Beträge im selben Dokument enthalten und ist für Dokumente vorgesehen, bei denen sowohl gutgeschrieben als auch nachberechnet wird. NLCIUS empfiehlt 384 aus Lesbarkeitsgründen gegenüber Gutschriften. Hinweis: TypeCode 384 ist nicht in allen Profilen verfügbar -- er wird beispielsweise im Standard-BIS-Billing-V3-Profil nicht unterstützt.

Übersicht häufig verwendeter InvoiceTypeCodes
CodeBedeutungKontext380HandelsrechnungStandardrechnung381GutschriftStandard-Gutschrift383BelastungsanzeigeKorrektur mit Zusatzbetrag384KorrekturrechnungPositiv und negativ in einem Dokument386VorauszahlungsrechnungVorauszahlungsszenario389Self-Billing-RechnungRechnung durch den Käufer ausgestellt261Self-Billing-GutschriftGutschrift im Self-Billing-Kontext
Teilgutschrift

Es ist nicht erforderlich, eine Rechnung vollständig gutzuschreiben. Sie können auch eine Teilgutschrift versenden, die nur einen Teil der Originalrechnung korrigiert. Wenn Sie beispielsweise zwei von zehn fakturierten Artikeln gutschreiben, enthält die Gutschrift nur diese zwei Positionen mit den entsprechenden Beträgen.

Tipp: Beim Versand von Rechnungen über die PSB API können Sie beim Herunterladen eines Dokuments über den Parameter targetDocumentTypeId angeben, ob Sie eine CreditNote- oder Invoice-Variante erhalten möchten. Die PSB kann on-the-fly zwischen den beiden Varianten transformieren.

Gutschrift validieren