PEPPOL-EN16931-R041: Der Bezugsbetrag zum Rabatt oder Zuschlag fehlt

Deine E-Rechnung wird abgewiesen, obwohl der Rabatt im Rechnungsprogramm richtig aussieht? Der Fehlercode PEPPOL-EN16931-R041 bedeutet: Im betroffenen XML-Abschnitt steht ein Prozentsatz für einen Nachlass oder Zuschlag, aber der dazugehörige Bezugsbetrag fehlt. Suche zuerst genau diesen Abschnitt. Ein anderer Rechnungsbetrag an einer anderen Stelle ersetzt die fehlende Angabe nicht. Q2 Q3

Diese Anleitung hilft dir, die beanstandete Stelle zu finden, die zugrunde liegende Berechnung zu prüfen und einen korrigierten Export gezielt abzunehmen.

Welche Situation passt zu diesem Fehler?

Ein belegter Mustang-Bericht beschreibt einen prozentualen Nachlass auf Belegebene: Der Export mit Version 2.26.0 enthält Prozentwert und Nachlassbetrag, jedoch keinen Basisbetrag. Der Meldende berichtet deshalb eine Zurückweisung durch den Validator. Der Fall ist ein konkretes Beispiel für R041; er beweist nicht, dass jeder gleichlautende Fehler von Mustang verursacht wird. Q1

Der offizielle UBL-Regelkontext umfasst Beleg- und Zeilenebene, jeweils für Invoice und CreditNote. Deshalb kann die Meldung auch einen einzelnen Posten oder eine Gutschrift betreffen. Prüfe den im Fehlerbericht genannten Pfad, statt ausschließlich nach einem Gesamtrabatt zu suchen. Q2

Die drei Angaben verständlich auseinanderhalten

Stell dir einen vereinbarten Nachlass von 10 Prozent auf einen Nettobetrag von 100 Euro vor. Dann sind 100 Euro die Berechnungsbasis, 10 der Prozentsatz und 10 Euro der Nachlassbetrag. Diese Werte haben verschiedene Aufgaben. R041 fragt zunächst nach dem fehlenden Basisfeld; die passende Höhe der Werte muss ebenfalls geprüft werden.

Die Zuordnung folgt den veröffentlichten Syntax- und Regelquellen. Bei UBL wird beispielsweise ein Satz von zehn Prozent als 10 angegeben. Die CII-Regel prüft die entsprechende Kombination aus CalculationPercent und BasisAmount. Q2 Q3

Ersthilfe: Sechs Schritte bis zum überprüfbaren neuen Export

1. Sichere die zurückgewiesene Datei und den vollständigen Prüfbericht. Notiere Rechnungssoftware, Exportversion, Format, Profil und Validator-Konfiguration. Arbeite mit einer Kopie. Halte fest, ob der Bericht zur tatsächlich versendeten Datei gehört oder zu einem früheren Export. Eine Korrektur am falschen Dateistand ist später kaum nachvollziehbar.

2. Öffne den maschinenlesbaren Inhalt. Verwende die exportierte XML-Datei beziehungsweise den tatsächlich geprüften XML-Inhalt. Die sichtbare Rechnungsansicht eignet sich für den Vergleich mit der Vereinbarung, ersetzt aber nicht die Suche nach dem im Bericht bezeichneten Element. Wenn dein Werkzeug nur eine Zusammenfassung anzeigt, lass dir den konkreten XML-Pfad oder den betreffenden Abschnitt ausgeben.

3. Bestimme genau einen beanstandeten Nachlass oder Zuschlag. Handelt es sich um den gesamten Beleg oder eine einzelne Zeile? Gibt es mehrere ähnliche Abschnitte? Ordne jeden Fehler seiner Stelle zu. Notiere Prozentwert, vorhandenen Betrag und fehlende Basis. Kontrolliere auch den Dokumenttyp. Die Fehlermeldung kann an mehreren passenden Stellen desselben Dokuments ausgelöst werden. Q2

4. Ermittle die fachlich richtige Basis. Nimm sie aus der ursprünglichen Preis- und Rabattberechnung. Kläre, auf welche Positionen sich die Vereinbarung bezieht. Verwende nicht vorschnell den Bruttogesamtbetrag oder irgendeine passende Summe. Halte bei unterschiedlich behandelten Positionen die fachliche Zuordnung ausdrücklich fest, bevor du einen Wert ergänzt.

5. Korrigiere die Erzeugung und exportiere erneut. Prüfe zunächst, ob die Rechnungssoftware ein passendes Eingabefeld, eine Exportoption oder eine dokumentierte Korrektur bietet. Bei eigener Integration muss die Übergabe an die Exportbibliothek mitgeprüft werden. Bevorzuge eine nachvollziehbare Korrektur an der Quelle, damit derselbe Fehler bei der nächsten Rechnung nicht wieder erscheint. Eine manuelle Änderung der XML-Datei allein repariert den zugrunde liegenden Ablauf noch nicht.

6. Prüfe die komplette neue Rechnung. Vergleiche den neuen Export mit dem gesicherten Original und führe die für den Empfänger passende Validierung aus. Prüfe neben R041 auch die umgekehrte Paarprüfung R042 und die Rechenbeziehung R040. Diese Regeln betreffen unterschiedliche Aussagen; das Verschwinden eines einzelnen Codes bestätigt noch nicht das gesamte Dokument. Q2 Q3

Ein kleines UBL-Beispiel zum Vergleichen

Der folgende selbst erstellte Ausschnitt illustriert einen Belegrabatt: 10 Prozent von 100 Euro ergeben 10 Euro Nachlass, zugeordnet zu einer angenommenen Steuerkategorie mit 19 Prozent. Die Elementstruktur orientiert sich an der offiziellen UBL-Syntax. Es ist ein Beispielabschnitt, keine vollständige oder als Ganzes validierte Rechnung. Übernimm die Zahlen nur, wenn sie deiner tatsächlichen Berechnung entsprechen. Q2

<cac:AllowanceCharge
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReason>Rabatt</cbc:AllowanceChargeReason>
  <cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
  <cbc:Amount currencyID="EUR">10.00</cbc:Amount>
  <cbc:BaseAmount currencyID="EUR">100.00</cbc:BaseAmount>
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>19</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>

Entscheidend für die gezeigte R041-Situation ist, dass der Prozentsatz seinen Bezugsbetrag im selben Nachlassabschnitt erhält. Ob die Basis betriebswirtschaftlich richtig gewählt wurde, musst du anhand der Vereinbarung und Ursprungsdaten beurteilen. Ein Validator kann dir diese Entscheidung nicht vollständig abnehmen.

Woran erkennst du eine belastbare Korrektur?

Lege vor der Änderung fest, was gleich bleiben soll: die vereinbarte Leistung, die Zuordnung des Nachlasses und die beabsichtigten Rechnungsbeträge. Dokumentiere jede notwendige Betragsänderung bewusst.

Für die technische Abnahme empfehlen wir drei Nachweise: Der neue Export enthält die beabsichtigten Angaben. Der vollständige Prüfbericht zum passenden Profil enthält den beanstandeten R041-Fehler nicht mehr und wird auch auf weitere Befunde geprüft. Schließlich ist geklärt, ob das Zielsystem genau diesen Dateistand technisch annimmt.

Eine erfolgreiche technische Prüfung ist keine Zusage über Zahlungsfreigabe, vertragliche Anerkennung oder rechtliche Vollständigkeit.

Häufige Fragen

Im PDF steht „10 % Rabatt“. Warum reicht das nicht?

Die Fehlermeldung bezieht sich auf eine bestimmte Struktur im XML. Eine sichtbare Prozentangabe ergänzt dort kein fehlendes BaseAmount beziehungsweise BasisAmount. Prüfe daher den maschinenlesbaren Inhalt. Q2 Q3

Gilt R041 nur für einen Rabatt auf die Gesamtrechnung?

Nein. Die UBL-Regel erfasst Nachlässe und Zuschläge sowohl am Beleg als auch an Zeilen von Invoice und CreditNote. Der hier untersuchte Mustang-Fall betrifft speziell die Belegebene. Q1 Q2

Kann ich einfach eine Null als Basis einsetzen?

Ein vorhandenes Feld beantwortet zunächst die Frage nach seiner Anwesenheit. Es beantwortet nicht die Frage, ob der Betrag zur Berechnung passt. Verwende den fachlich richtigen Wert und prüfe die Rechnung erneut. Q2 Q3

Kann ich stattdessen den Prozentsatz entfernen?

Ein Export kann eine passende Darstellung ohne Prozent-Basis-Paar benötigen; die aktuelle Mustang-Historie beschreibt eine Änderung an dessen gemeinsamer Ausgabe. Daraus folgt keine pauschale Löschanweisung. Kläre zuerst, welche Darstellung dein Profil und die vereinbarte Rechnung erfordern. Q5

Kann der Basisbetrag aus Betrag und Prozent zurückgerechnet werden?

Das kann eine Rechenkontrolle liefern, aber keine sichere Rekonstruktion der ursprünglichen Vereinbarung. Rundung, mehrere Nachlässe oder unterschiedlich behandelte Positionen müssen verstanden werden. Die automatisch errechnete Zahl sollte deshalb nie ungeprüft in die Rechnung geschrieben werden.

Ist der Fehler mit einem Mustang-Update sicher erledigt?

Das ist für deine Installation zu prüfen. Die Änderungshistorie nennt den Fall unter 2.27.0; die am Recherchetag geöffnete GitHub-Releaseübersicht führte noch 2.26.0 als aktuellste Veröffentlichung. Ein Vermerk im Projekt ersetzt daher weder die Prüfung des verfügbaren Pakets noch den erneuten Export- und Validierungstest. Q5

Beschreibe deinen Fall

Hilfreich sind der vollständige Fehlercode, Format und Profil, Softwareversion, Validator-Version sowie ein geschwärzter XML-Ausschnitt des betroffenen Nachlasses oder Zuschlags. Ergänze, ob es um Beleg- oder Zeilenebene geht und wie die Basis fachlich berechnet werden sollte.