Der Thread ist schon etwas älter, aber er taucht bei der Suche nach genau diesen Fragen weit oben auf, deshalb ergänze ich hier mal ein paar Punkte. Die Diskussion ist damals in Richtung DATEV-Buchungsfelder abgebogen, die eigentliche Frage war aber ja: Wo gehört die Angebotsnummer in der XRechnung-XML selbst hin? Und da gibt es durchaus eine Antwort.
Zur Angebotsnummer:
Ein eigenes Feld "Angebotsnummer" hat die EN 16931 tatsächlich nicht. Es gibt aber mehrere Referenzfelder, die dafür in der Praxis genutzt werden:
- BT-14 "Sales order reference", also die Auftrags-/Vorgangsnummer des Verkäufers. Wenn das angenommene Angebot bei Ihnen die Auftragsgrundlage ist, ist das semantisch der naheliegendste Platz. In der CII-Syntax:
<ram:SellerOrderReferencedDocument>
<ram:IssuerAssignedID>AN-2025-0042</ram:IssuerAssignedID>
</ram:SellerOrderReferencedDocument>
- Alternativ BG-24, eine "rechnungsbegründende Unterlage" mit TypeCode 916. Damit referenzieren Sie das Angebot ausdrücklich als eigenes Dokument:
<ram:AdditionalReferencedDocument>
<ram:IssuerAssignedID>Angebot AN-2025-0042</ram:IssuerAssignedID>
<ram:TypeCode>916</ram:TypeCode>
</ram:AdditionalReferencedDocument>
- Und zur Not immer: die Freitext-Bemerkung BT-22.
Ein Stolperstein, weil Sie die XML per Hand aus Access erzeugen: Das volle CII-Datenmodell kennt sogar ein ram:QuotationReferencedDocument, das klingt perfekt. Nur liegt dieses Element außerhalb des EN-16931-Subsets, der KoSIT-Validator lehnt die Datei damit ab. Also nicht verwenden, auch wenn es im Schema auftaucht.
Zum Skonto:
Das gefundene BR-DE-18-Zitat stimmt, aber es fehlt darin der Teil, an dem in der Praxis die meisten Rechnungen scheitern: die exakte Zeichensyntax. Jede Skonto-Zeile in BT-20 beginnt mit einer Raute, die Segmente sind mit Rauten getrennt, die Zeile endet mit Raute und Zeilenumbruch. Prozentwerte ohne Vorzeichen, mit Punkt und genau zwei Nachkommastellen, alles in Großbuchstaben, kein zusätzliches Leerzeichen:
#SKONTO#TAGE=14#PROZENT=2.00#
Geprüft wird das per regulärem Ausdruck, ein einziges Zeichen Abweichung genügt für die Ablehnung. PROZENT=2 statt PROZENT=2.00, ein Komma statt des Punkts oder ein Leerzeichen nach der Raute sind die Klassiker. Der menschenlesbare Satz ("Zahlbar innerhalb von 30 Tagen netto") darf zusätzlich als eigene Zeile im selben Feld stehen. Zwei Skontostufen werden zu zwei Zeilen.
Kurz noch zur Revisionssicherheit, weil das hier auch aufkam: Eine mit WinRAR "geschützte" Datei ist nicht das, was die GoBD unter Unveränderbarkeit versteht. Es geht nicht um Verschlüsselung der einzelnen Datei, sondern um ein Ablageverfahren, bei dem nachträgliche Änderungen ausgeschlossen oder protokolliert sind, plus eine Verfahrensdokumentation, die das beschreibt. Ein selbstgebautes Access-Setup bekommt man da ehrlicherweise nur mit einem ordentlichen DMS oder Archivsystem dahinter sauber.
Falls jemand seine selbst erzeugten Dateien testen will, bevor der erste Empfänger sie ablehnt: Wir haben einen kostenlosen Validator, der gegen das komplette KoSIT-Regelwerk prüft und zu jedem Fehlercode erklärt, was er bedeutet und wie man ihn behebt, inklusive der BR-DE-18-Details mit XML-Beispielen:
https://belegschmied.de/tools/validieren
https://belegschmied.de/e-rechnung-fehler/br-de-18
Ich bin GF bei Belegschmied. Der Validator und das Fehler-Lexikon sind aber ohne Konto und ohne Kosten nutzbar, die Links stehen hier, weil sie die Fragen aus dem Thread direkt beantworten.
