Suche
Suche Warenkorb 0

Veröffentlicht von Markus Wals

Prüfbericht zur E-Rechnung verstehen: Fehler und Warnungen in weclapp beheben

E-Rechnung Prüfbericht weclapp XRechnung ZUGFeRD

KI-generierte Illustration: Prüfprotokoll mit einer rot markierten Zeile, die auf einen Rechnungsbeleg mit Code-Symbol unter einer Lupe zeigt. Überschrift: Prüfbericht zur E-Rechnung

Kurz gesagt: Im Prüfbericht zur E-Rechnung führen nur Fehler zur Empfehlung, die Rechnung zurückzuweisen, Warnungen nicht. Fast jede Meldung geht auf ein Feld in weclapp zurück, etwa Stammdaten der Kund:in, Verkäuferkontakt, Hausbank, Steuer oder Einheit.

Deine Kund:in schickt die E-Rechnung zurück, im Anhang ein Prüfbericht voller Kürzel wie BR-DE-15 oder BR-CO-10. Das sieht nach einem großen technischen Problem aus, ist aber meist ein fehlendes oder falsch gepflegtes Feld. Dieser Artikel zeigt, wie du den Bericht liest und wo du die häufigsten Meldungen in weclapp behebst.

Das Wichtigste in Kürze

  • Fehler zählen, Warnungen weniger. Im Standardbericht des KoSIT-Validators führt nur ein Fehler zur Empfehlung „zurückweisen“. Eine Warnung macht die Rechnung formal „nicht konform“, die Empfehlung lautet trotzdem „annehmen“.
  • Die Regel-ID verrät die Ebene. BR-DE kommt aus den deutschen Regeln der XRechnung, BR-CO, BR-S oder BR-AE aus der europäischen Norm EN 16931, BR-CL aus den Codelisten.
  • Die Ursache liegt fast immer in den Stammdaten. weclapp schreibt ins XML, was in Kund:innen-Stammdaten, Formulargrundeinstellungen, Hausbank, Steuern und Einheiten steht.
  • Korrigieren heißt neu erzeugen. Die schon erzeugte Datei übernimmt spätere Korrekturen in den Stammdaten nicht.
  • Ein sauberer Bericht ist keine Garantie. Manche Empfänger prüfen zusätzlich nach eigenen Regeln.

Wie liest du einen Prüfbericht zur E-Rechnung?

Grafik: Wie der Prüfbericht prüft. Der KoSIT-Validator prüft in drei Schritten. Erstens die Syntax: ist das XML technisch sauber aufgebaut. Zweitens die europäische Norm EN 16931 mit Pflichtfeldern, Summen und Steuerkategorien. Drittens die zusätzlichen deutschen Regeln der XRechnung, deren IDs mit BR-DE beginnen.

Die meisten Prüfberichte, die du von Behörden, Rechnungsportalen oder der Buchhaltung deiner Kund:in bekommst, stammen vom KoSIT-Validator oder einem Programm, das dieselben Regeln verwendet. Die KoSIT ist die Koordinierungsstelle für IT-Standards, die die XRechnung herausgibt. Der Validator prüft eine Rechnung in drei Schritten:

  1. Syntax: Ist das XML technisch sauber aufgebaut?
  2. EN 16931: Hält die Rechnung die Geschäftsregeln der europäischen Norm ein, etwa Pflichtfelder, Summen und Steuerkategorien?
  3. XRechnung: Erfüllt sie die zusätzlichen deutschen Regeln, die mit BR-DE beginnen?

Im Bericht steht je Schritt, ob er bestanden ist, darunter die Meldungen mit Regel-ID, Text und der Stelle im XML. Ganz unten folgen zwei Sätze, die du kennen solltest:

  • Konformität: „Das geprüfte Dokument enthält … Fehler / … Warnungen. Es ist nicht konform zu den formalen Vorgaben.“ Hier zählt jede Warnung mit.
  • Bewertung: „Es wird empfohlen das Dokument anzunehmen und weiter zu verarbeiten.“ oder „Es wird empfohlen das Dokument zurückzuweisen.“ Zurückweisen empfiehlt der Bericht nur, wenn mindestens ein Fehler vorliegt.

So ist es in der Prüfkonfiguration für die XRechnung festgelegt (Release vom 31.08.2026 für XRechnung 3.0). Ob die Eingangssoftware deiner Kund:in Warnungen trotzdem ablehnt, entscheidet sie selbst. Meldet ein Rechnungsportal nur, die „Schematron-Validierung“ sei fehlgeschlagen, steckt dahinter ebenfalls einer dieser Regelverstöße: Schematron ist die Prüfsprache, in der die Regeln geschrieben sind. Lass dir in dem Fall den vollständigen Bericht geben.

Stufe im Bericht Bedeutung Was du tust
Fehler Eine Muss-Regel ist verletzt. Der Bericht empfiehlt, die Rechnung zurückzuweisen. Ursache in weclapp beheben, Rechnung neu erzeugen und erneut senden.
Warnung Eine Soll-Regel ist verletzt. Der Bericht empfiehlt trotzdem die Annahme. Beim nächsten Beleg beheben. Sofort nur, wenn deine Kund:in Warnungen ablehnt.
Information Ein Hinweis, zum Beispiel auf ein fehlendes Lieferdatum. Prüfen, ob die Angabe fachlich fehlt.

Fazit: Sortier den Bericht zuerst nach Fehlern, die Warnungen kommen danach.

Welche Meldung behebst du wo in weclapp?

Grafik: Welche Meldung du wo behebst. Bei Pflichtangaben prüfst du Leitweg-ID, Kontakt des Verkäufers und USt-IdNr. mit Ländercode. Bei der Zahlung hinterlegst du die Standard-Hausbank, das SEPA-Mandat und das feste Skonto-Muster. Bei der Steuer setzt du die Steuer an allen Positionen und den Befreiungsgrund. Bei den Summen berechnest du den Beleg in weclapp neu und vergleichst XML und PDF.

Die folgenden Regeln tauchen bei Rechnungen aus einem ERP besonders oft auf. Die Wortlaute stammen aus dem XRechnung-Schematron der KoSIT und den Regeln zur EN 16931, die Menüpfade aus der weclapp-Hilfe, abgerufen am 07.11.2026.

Pflichtangaben zu dir und zur Kund:in

Regel Was fehlt Stufe Wo in weclapp
BR-DE-15 Käuferreferenz: bei Behörden die Leitweg-ID, bei Firmenkund:innen die Referenz, die sie vorgeben, etwa ihre Bestellnummer Fehler Kund:in öffnen, Bereich Finanzdaten, Feld Leitweg-ID; bei Firmenkund:innen nachfragen, welche Referenz sie erwarten
BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7 Kontakt des Verkäufers: Name, Telefon, E-Mail Fehler Formulargrundeinstellungen; sind sie leer, nimmt weclapp die Daten des Benutzers, der die Rechnung erzeugt
BR-DE-27, BR-DE-28 Telefonnummer mit weniger als drei Ziffern, E-Mail-Adresse mit falschem Aufbau Warnung dieselben Felder, mit echter Durchwahl und vollständiger Adresse
BR-DE-3, BR-DE-4, BR-DE-8, BR-DE-9 Ort oder Postleitzahl von dir oder der Kund:in Fehler Firmenadresse in den Stammdaten, Rechnungsadresse der Kund:in
BR-CO-26, BR-DE-16 Eine Kennung von dir als Verkäufer, also USt-IdNr., Steuernummer oder eine andere Kennung; BR-DE-16 verlangt USt-IdNr. oder Steuernummer Fehler eigene Firmenstammdaten
BR-CO-09 USt-IdNr. ohne Ländercode, zum Beispiel ohne „DE“ Fehler USt-IdNr. bei dir oder der Kund:in mit Ländercode erfassen

Die XRechnung verlangt laut weclapp-Hilfe zur XRechnung außerdem eine E-Mail-Adresse der Kund:in im Feld E-Mail unter den Adress- und Kontaktdaten. Für Firmenkund:innen ohne Leitweg-ID ist oft ZUGFeRD der einfachere Weg; welches Format passt, steht in XRechnung oder ZUGFeRD.

Zahlung und Bankverbindung

Regel Was fehlt Stufe Wo in weclapp
BR-DE-1, BR-DE-23-a Zahlungsanweisung oder Bankverbindung bei Überweisung Fehler Globale Einstellungen > Finanzen > Hausbanken: eine Standard-Hausbank hinterlegen
BR-DE-19 keine gültige IBAN bei SEPA-Überweisung Warnung IBAN der Standard-Hausbank prüfen
BR-DE-25, BR-DE-30, BR-DE-31 Lastschrift ohne Mandatsdaten Fehler SEPA-Mandat der Kund:in an der Rechnung
BR-DE-18 Skonto-Zeile nicht im vorgeschriebenen Muster Fehler Zahlungsbedingung prüfen, im XML die Zahlungsbedingungen ansehen

Barzahlung ist mit XRechnung nicht möglich. Bei allen anderen Zahlungsarten außer Lastschrift setzt weclapp eine Überweisung mit den Daten der Standard-Hausbank ins XML, so die weclapp-Hilfe. Für Skonto schreibt die XRechnung ein festes Muster vor, zum Beispiel #SKONTO#TAGE=10#PROZENT=2.00#, in Großbuchstaben, mit Punkt und zwei Nachkommastellen. Frei formulierter Text wie „2 % Skonto bei Zahlung in 10 Tagen“ verletzt in einer Skonto-Zeile die Regel. Zahlungsbedingungen pflegst du unter Globale Einstellungen > Zahlungsbedingungen. Wie weclapp Skonto ins XML schreibt, beschreibt die Hilfe nicht; prüf es an einer Testrechnung mit Skonto.

Steuer

Regel Was nicht passt Stufe Wo in weclapp
BR-E-10, BR-AE-10 Steuerfreie Leistung oder Reverse Charge ohne Befreiungsgrund Fehler Befreiungsgrund je Steuer in den E-Rechnungseinstellungen (laut weclapp-Support)
BR-AE-02 Reverse Charge ohne USt-IdNr. der Kund:in Fehler USt-IdNr. in den Stammdaten der Kund:in
BR-S-05, BR-E-05, BR-AE-05 Steuersatz passt nicht zur Kategorie, etwa 0 % bei Regelsteuersatz Fehler Steuer am Artikel und Steuerregeln prüfen
BR-DE-14 Steuersatz der Kategorie fehlt Fehler Steuer an allen Positionen gesetzt?

Jede Steuer in weclapp wird im XML einer Steuerkategorie zugeordnet: S für den Regelsatz, E für steuerbefreit, AE für Reverse Charge, K für die innergemeinschaftliche Lieferung. Diese Zuordnung und den Befreiungsgrund pflegst du laut weclapp-Support in den globalen Einstellungen unter E-Rechnung, Bereich E-Rechnungseinstellungen, dort auch die ZUGFeRD-Steuerbefreiungsinformationen. Die öffentliche weclapp-Hilfe nennt an dieser Stelle bisher nur die XML-Einstellungen. Die Meldung „Keine Zugferd Steuerbefreiungsinformationen gefunden“ beim Erzeugen weist genau dorthin. Das Feld „Spezielle Eigenschaft“ unter Globale Einstellungen > Grundeinstellungen > Steuern steuert dagegen den Hinweistext auf dem gedruckten Beleg (weclapp-Hilfe). Welche Kategorie für deinen Umsatz richtig ist, klärst du mit deiner Steuerberatung.

Summen und Rundung

Regel Was nicht aufgeht Stufe
BR-CO-10 Summe der Positionen weicht von der Netto-Summe ab Fehler
BR-CO-13 Netto-Gesamtbetrag passt nicht zu Positionen, Nachlässen und Zuschlägen Fehler
BR-CO-14, BR-CO-15 Steuer- oder Bruttosumme passt nicht zur Aufschlüsselung Fehler
BR-S-08 Bemessungsgrundlage je Steuersatz passt nicht zur Summe der Positionen, Nachlässe und Zuschläge mit diesem Satz Fehler
BR-CO-17, BR-S-09 Steuerbetrag je Kategorie passt nicht zu Bemessungsgrundlage und Satz Fehler

Kleine Rundungsdifferenzen lösen BR-CO-17, BR-S-08 und BR-S-09 nicht aus: Diese Prüfungen lassen eine Abweichung unter einem Euro zu. Schlägt eine Summenregel an, steckt meist mehr dahinter, etwa ein von Hand überschriebener Betrag, ein Zu- oder Abschlag mit anderer Steuer als die Positionen oder eine Rechnung, die außerhalb von weclapp nachbearbeitet wurde. Lass den Beleg in weclapp neu berechnen und vergleiche die Summen im XML mit dem PDF.

Codelisten und Format

Regel Was nicht passt Stufe Wo in weclapp
BR-CL-23 Einheitencode unbekannt Warnung (in der XRechnung-Prüfung herabgestuft) Grundeinstellungen > Grundeinheiten > ZUGFeRD-Daten Mengeneinheits-Code
BR-CL-14 Ländercode nicht nach ISO Fehler Land in der Adresse
BR-DE-21 Kennung passt nicht zur XRechnung Warnung Format für die Kund:in prüfen
BR-DE-17, BR-DE-26 ungewöhnliche Rechnungsart, Korrektur ohne Bezug auf die Ursprungsrechnung Warnung Gutschrift oder Korrektur mit Bezug zur Ursprungsrechnung erzeugen

Für Stück passen die Codes H87 oder C62. Selbst angelegte Einheiten bekommen ihren Code laut weclapp-Hilfe zu ZUGFeRD nicht automatisch, du trägst ihn selbst ein. BR-DE-21 siehst du typischerweise, wenn eine ZUGFeRD-Datei gegen die XRechnung-Regeln geprüft wird. weclapp erzeugt ZUGFeRD im Profil EN16931 Comfort. Verlangt die Kund:in ausdrücklich eine XRechnung, nimm die XRechnung-Workflow-Aktion.

Fazit: Jede Meldung hat eine Regel-ID, die dich zu den betroffenen Feldern in weclapp führt. Rechenregeln betreffen oft mehrere Felder auf einmal.

Warum lehnt deine Kund:in ab, obwohl der Bericht sauber ist?

Grafik: Sauberer Bericht, trotzdem abgelehnt. Ein KoSIT-Bericht arbeitet mit Standardregeln, erkennbar an Regel-IDs wie BR-DE und BR-CO. Manche Empfänger prüfen zusätzlich mit eigenen Regeln, ihr Protokoll hat keine BR-Kürzel und verlangt etwa zusätzliche Angaben wie eine Bestellreferenz. Dann klärst du mit der Kund:in, welche Regeln gelten.

Weil manche Empfänger nicht nur mit dem KoSIT-Validator prüfen, sondern zusätzlich mit eigenen Regeln. Das Prüfprotokoll sieht dann anders aus: keine BR-Kürzel, sondern Meldungen in der Sprache einer Plattform oder eines eigenen Datenformats. Diese Muster begegnen uns in der Praxis immer wieder:

Symptom Was dahintersteckt Wo du in weclapp prüfst
Empfänger verlangt zusätzliche Angaben Er prüft Felder, die der Standard nicht vorschreibt, etwa eine Bestell- oder Lieferreferenz. Welche Angaben gefordert sind, mit der Kund:in klären; dann prüfen, ob weclapp sie aus Auftrag oder Kund:innen-Stammdaten ins XML schreibt.
Steuerkategorie wird abgelehnt Der Empfänger kennt die verwendete Kategorie nicht oder erwartet eine andere. Zuordnung der Steuer in den E-Rechnungseinstellungen (laut weclapp-Support); die Kategorie mit deiner Steuerberatung abstimmen.
Mengeneinheit im PDF weicht vom XML ab Der Empfänger vergleicht PDF und XML und findet unterschiedliche Mengen oder Einheiten. Einheit am Artikel und ZUGFeRD-Daten Mengeneinheits-Code der Grundeinheit; PDF und XML einer Testrechnung nebeneinanderlegen.
Summen im PDF und XML weichen ab Die Rechnung wurde nach dem Erzeugen geändert oder außerhalb von weclapp nachbearbeitet. Beleg in weclapp neu berechnen und neu erzeugen, nicht nachträglich bearbeiten.
Falsches Format Die Kund:in erwartet XRechnung und bekommt ZUGFeRD oder umgekehrt. Workflow-Aktion für das gewünschte Format, siehe XRechnung oder ZUGFeRD.

Wie du die Formate und Workflow-Aktionen in weclapp grundsätzlich einrichtest, steht in E-Rechnung in weclapp einrichten.

Fazit: Frag bei einer Ablehnung nach dem Prüfprotokoll und danach, mit welchen Regeln geprüft wurde.

So gehst du bei einem Prüfbericht vor

Grafik: So gehst du bei einem Prüfbericht vor. Erst lesen: den vollständigen Bericht anfordern und klären, ob es ein KoSIT-Bericht ist, dann Fehler vor Warnungen. Dann beheben: das Feld je Regel-ID in weclapp korrigieren und die Rechnung neu erzeugen. Dann senden: die neue Datei selbst prüfen und erst danach versenden.

  1. Den vollständigen Bericht anfordern, nicht nur die Ablehnungsmail.
  2. Klären, ob es ein KoSIT-Bericht ist (Regel-IDs wie BR-DE, BR-CO) oder ein Protokoll mit eigenen Regeln der Kund:in.
  3. Nach Stufe sortieren: Fehler zuerst, Warnungen danach.
  4. Je Regel-ID das Feld in weclapp suchen und korrigieren, mit der Tabelle oben.
  5. Die Rechnung neu erzeugen, denn die schon erzeugte Datei übernimmt die Korrektur nicht. Ob du dafür stornierst oder korrigierst, stimmst du mit deiner Buchhaltung ab.
  6. Die neue Datei selbst prüfen, etwa mit dem KoSIT-Validator, bevor sie rausgeht.
  7. Bei Stammdatenfehlern alle betroffenen Kund:innen gleich mit prüfen, nicht nur diese eine.

Wie du eine E-Rechnung lesbar machst und mit einem Validator prüfst, zeigt E-Rechnungen empfangen und prüfen. Ab wann du E-Rechnungen ausstellen musst, steht im Ratgeber zur E-Rechnungspflicht.

Fazit: Erst die Ursache in weclapp beheben, dann neu erzeugen, dann selbst prüfen, dann senden.

Quellen und Grenzen

Transparenz: wals.pro ist weclapp-Partner und richtet weclapp für Händler ein. Die Regeln stammen aus den Prüfdateien der KoSIT und der EN 16931, die Menüpfade aus der weclapp-Hilfe, die Muster zu Ablehnungen aus der Praxis von wals.pro, ohne Bezug auf einzelne Projekte. Stand: 07.11.2026.

Die E-Rechnungseinstellungen mit Steuer-Zuordnung und Befreiungsgründen beschreibt die weclapp-Hilfe bisher nicht; die Angaben dazu stehen hier laut weclapp-Support (nicht öffentlich dokumentiert). Menüpfade können sich mit neuen weclapp-Releases ändern. Die Tabelle nennt typische Ursachen, keine vollständige Liste aller Regeln. Der Validator prüft Form und Geschäftsregeln, nicht, ob die Rechnung steuerlich richtig ist. Wie Formatfehler und Fehler bei Pflichtangaben steuerlich einzuordnen sind, steht in E-Rechnungen empfangen und prüfen. Das ersetzt keine Steuerberatung.

Häufige Fragen

Muss ich eine E-Rechnung mit Warnungen neu schicken?

Nicht zwingend. Im KoSIT-Standardbericht führt nur ein Fehler zur Empfehlung, die Rechnung zurückzuweisen; bei reinen Warnungen lautet die Empfehlung „annehmen“. Manche Eingangssysteme lehnen trotzdem ab. Behebe Warnungen deshalb beim nächsten Beleg und frag bei der Kund:in nach, ob sie die Rechnung angenommen hat.

Was bedeutet BR-DE-15 im Prüfbericht?

Die Käuferreferenz fehlt. Bei Behörden ist das die Leitweg-ID, die du in weclapp bei der Kund:in im Bereich Finanzdaten einträgst; Firmenkund:innen geben oft eine eigene Referenz wie ihre Bestellnummer vor. Danach erzeugst du die XRechnung neu, weil die alte Datei die Angabe nicht nachträglich bekommt.

Warum findet weclapp keinen Fehler, die Kund:in aber schon?

Weil manche Kund:innen zusätzlich nach eigenen Regeln prüfen, etwa zu Steuerkategorien, Referenzen oder Mengeneinheiten. Frag nach dem Prüfprotokoll und danach, nach welchen Regeln geprüft wurde.

Wie korrigiere ich eine abgelehnte E-Rechnung in weclapp?

Ursache in den Stammdaten oder Einstellungen beheben und die Rechnung neu erzeugen, denn die schon erzeugte Datei übernimmt die Korrektur nicht. Prüf die neue Datei vor dem Versand selbst mit einem Validator. Ob eine Korrektur oder eine neue Rechnung steuerlich richtig ist, klärst du mit deiner Steuerberatung.

Wo stelle ich die Einheitencodes für die E-Rechnung ein?

Unter Grundeinstellungen, Grundeinheiten, im Feld ZUGFeRD-Daten Mengeneinheits-Code. Für Stück passen H87 oder C62. Selbst angelegte Einheiten brauchen einen Code, den du selbst einträgst.

Was heißt „Schematron-Validierung fehlgeschlagen“?

Die Rechnung hat mindestens eine Prüfregel der XRechnung oder der EN 16931 verletzt. Schematron ist die Sprache, in der diese Regeln geschrieben sind. Lass dir den vollständigen Prüfbericht geben: Dort steht je Meldung eine Regel-ID wie BR-DE-15, die dich zum Feld in weclapp führt.