Sage 100 E-Rechnung Feldzuordnungen / E-Invoicing field mappings

In diesem Zusammenhang stellt sich in der Praxis immer wieder die Frage, wie welche Sage 100-Felder wie genau in die XML-Datei überführt werden (Feldzuordnungen).

Syntax

Die aktuelle Syntax der E-Rechnungsdateien der Sage 100 ist "Cross-Industry Invoice" (CII) XML oder , ab Version 9.0.10.x , alternativ das "OASIS Universal Business Language)" (UBL). Letzteres muss gezielt in den Kontokorrent-Einstellungen über einen dortigen Ja/Nein-Schalter aktiviert werden.

Anmerkung: In neueren Versionen ist das Generieren von E-Rechnungen auch im Einkaufsbereich für die Gutschriftenverfahren-Belegart möglich.

⚠️UBL Lizenzvoraussetzungen

Damit die UBL-Option verfügbar ist , muss die Sage 100-Produktlizenz aktualisiert werden. Kunden der "Sage 100 Connected" erhalten inzwischen das "E-Rechnung Pluspaket" bzw. "E-Rechnung Zusatzpaket" kostenlos , dennoch muss das entsprechende Lizenzbit aktiv sein , damit alle neuen Optionen zur Verfügung stehen.

Dies geschieht bei Bestandskunden nicht automatisch! Es ist erforderlich , für die betreffenden Kunden über das Sage Portal eine aktualisierte Lizenz zu generieren und diese beim Kunden zu aktivieren.

Ansicht der Sage E-Rechnung Optionen. Im Bild der Kundenstamm. Im Rahmen des Gutschrift-Verfahrens können in der neusten Sage 100 auch für Lieferanten E-Rechnungen erstellt werden!

Technische Vorgehensweise von Sage für UBL

Interessant ist , dass aus Entwicklersicht Sage einen post-generativen Ansatz für UBL auf der Basis der erzeugten CII-Daten verwendet.

D.h. zuerst wird wie gehabt CII-Syntax generiert. Sollte im Kontokorrent UBL aktiviert sein , dann ruft Sage nachgeschaltet eine hauseigene Konvertierungsroutine auf , die die CII-Syntax in einem separaten Schritt in UBL-Syntax umwandelt.

⚠️Aus Sicht von Techpartnern , die auf Basis der DCM "DcmListId.PrintPrepareBelegZUGFeRDEmbeddedXml" Anpassungen vorgenommen haben , spielt dies keine Rolle , da die DCM die bereits gewandelte UBL-Syntax als Xml-Dokument erhält.
Für umfangreichere Anpassungen , die ein Techpartner ggf. direkt in der PrintEngine von Sage vorgenommen hat , bedeutet die Taktik jedoch einen großen Vorteil. Eigener Techpartner-Code direkt in der PrintEngine , der sich bei Änderung der Xml auf CII gestützt hat , kann somit weiterverwendet werden , sofern dieser an der richtigen Stelle platziert wird (vor der UBL-Konvertierung von Sage). Wobei zu beachten ist , dass natürlich nur das von Sage zuverlässig konvertiert wird , was Sage auch selber im Standard benötigt!

Feldzuordnungen Version 9.0.10.x

Nachfolgend eine Übersicht der wesentlichen Feldzuordnungen.

Die Ziel-Felder ergeben sich durch die "BT" (Business Term) Feldauflistungen in der vorletzten Spalte der Tabelle.

Änderungen gegenüber der wesentlichen Spezifikation der Version 9.0.8.x:

1. Neue Felder für Identifikationsnummern (GLN & EAN)

Die Version 9010 führt spezifische Felder für globale Identifikationsnummern ein, die in der Version 908 nicht explizit aufgeführt waren:

Verkäufer (Seller Trade Party): In der 9010 wurde das Feld GLN Nummer (Global Location Number) hinzugefügt, gemappt auf <ram:SellerTradeParty><ram:GlobalID>.

Käufer (Buyer Trade Party): Ebenso wurde für den Kunden die GLN Nummer ergänzt, gemappt auf <ram:BuyerTradeParty><ram:GlobalID>.

Artikel (Trade Product): Es wurde ein Feld für den EAN Code (GTIN) des Artikels hinzugefügt, gemappt auf <ram:SpecifiedTradeProduct><ram:GlobalID>.

2. Erweiterung der Codes für Freitexte (BT-21)

Die Liste der unterstützten Codes zur Qualifizierung von Freitexten (<ram:SubjectCode>) wurde in der Version 9010 deutlich erweitert.

Version 908: Listet lediglich $AAl=$ General Information und $PMT=$ Payment Information.

Version 9010: Unterstützt nun zusätzlich Codes wie AAR (Terms of delivery), COI (Order Information), ADU (Note) und REG (Regulatory Information).

3. Technische Hinweise zu Textfeldern (Planung V9.0.11)

Die Version 9010 enthält spezifische Hinweise auf eine Änderung der Logik ab der Software-Version 9.0.11, die in der 908 fehlen:

BT-127 (Positions-Freitext): Es wird angemerkt: "Planung: Ab V9.0.11 werden diese Texte direkt zum Artikel ausgegeben".

BT-154 (Artikelbeschreibung): Es gibt einen neuen Hinweis, dass ab V9.0.11 auch Dimensions- und Langtexte sowie Intrastat-Warennummern in der Artikelbeschreibung ausgegeben werden.

4. Präzisierungen bei bestehenden Feldern

Lieferdatum (BT-72): In der 9010 wurde der Hinweis ergänzt, dass das Lieferdatum "hier [auf Kopfebene] oder auf Positionsebene erfolgen" kann. In der 908 fehlte dieser explizite Hinweis auf die Alternative. Dies ist jedoch im Standard der Version 9.0.10.x insofern nicht relevant , da im Standard Sage nur BT-72 füllt. Der Liefertermin der Positionen wird im Standard von Sage nicht ausgewiesen.

Bestellreferenz (BT-13): Die Version 9010 kennzeichnet dieses Feld expliziter mit dem Text "Für XRechnung Pflichtfeld", während die 908 dies nur durch das (X) andeutete.

⚠️Klarstellung zum BT-72 Liefer-/Leistungsdatum und Abrechnungszeitraum nach Norm (EN 16931)

Die folgenden Infos gelten sowohl für ZUGFeRD als auch X-Rechnung , da beides auf "EN 16931" aufsetzt.

Steuerliche Sicherheit: Das wichtigste Feld für das Finanzamt ist BT-72 (Kopf) oder, falls Positionen unterschiedliche Daten haben, BT-134/135 (Position).

⚠️Vorsicht bei BT-73/74: Nutzen Sie diese Felder für Zeiträume (z.B. "Wartungsvertrag 2026"). Verlassen Sie sich für das steuerliche Leistungsdatum lieber explizit auf BT-72 bzw. BT-134/135 für Positionen!

1. Zusammenfassung: Das Lieferdatum in der E-Rechnung

In der Norm (EN 16931) und der deutschen XRechnung gibt es technisch zwei Ebenen, um das Liefer- oder Leistungsdatum abzubilden.

A. Auf Kopfebene (Die gesamte Rechnung betreffend)

Hier gibt es genau ein Feld für einen konkreten Tag.

Fachlicher Begriff: Lieferdatum / Leistungsdatum

Technisches Feld: BT-72 (Actual delivery date)

Verwendung: Wenn alle Positionen der Rechnung am selben Tag geliefert oder geleistet wurden!

In o.g. Aufstellung: Bezeichnet dies als "VK-Beleg: Lieferdatum" und weist darauf hin, dass dies eine Pflichtangabe ist!

B. Auf Positionsebene (Die einzelne Zeile betreffend)

Hier gibt es kein Feld für einen einzelnen Tag (kein BT-72).

Stattdessen muss(!) zwingend ein Zeitraum angegeben werden.

Fachlicher Begriff: Leistungszeitraum der Position

Technische Felder:

BT-134 (Invoice line period start date)

BT-135 (Invoice line period end date)

⚠️In der aktuellen Sage 100 Version 9.0.10.x gibt Sage im Standard kein Liefertermin-Feld auf Positionsebene aus!

Der "Tages-Workaround": Um einen einzelnen Liefertag auf Positionsebene abzubilden, wird das Startdatum gleich dem Enddatum gesetzt (z. B. Start: 15.01.2024, Ende: 15.01.2024), auch wenn die rein technische Spezfikation das Nennen nur eines Datums erlauben würde. ⚠️Siehe dazu auch wichtige fachliche Hinweise am Ende dieser Seite!

2. Die "große Verwirrung": Abrechnungszeitraum vs. Leistungszeitraum

Ein häufiges Missverständnis entsteht durch die Vermischung von wann geleistet wurde (Steuerrecht) und welcher Zeitraum abgerechnet wird (Vertragsrecht).

Die o.g. von Sage bereitgestellte Tabelle ist diesbezüglich nicht eindeutig genug.

Begriff 1: Der Abrechnungszeitraum (Billing Period)

Dies beschreibt den Zeitraum, den die Rechnung abdeckt (z. B. Miete für Januar, Wartung für Q1).

Technische Felder: BT-73 (Start) und BT-74 (Ende).

In Bezug auf die o.g. von Sage bereitgestellte Liste:

Die Datei nennt die Felder in der linken Spalte "Leistungszeitraum von/bis" , beschreibt sie aber rechts korrekt als "Anfangsdatum des Rechnungszeitraums" bzw. "Enddatum".

⚠️Die offizielle E-Rechnung Spezifikation spricht an dieser Stelle offiziell bei den Belegfeldern im Kopf BT-73 und BT-74 vom "Abrechnungszeitraum", nicht "Leistungszeitraum".

Problem: Steuerrechtlich ist der Rechnungszeitraum (z.B. 01.01. bis 31.01.) oft identisch mit dem Leistungszeitraum.

Technisch sind BT-73/74 aber reine Informationsfelder darüber, welcher Zeitraum "in Rechnung gestellt" wird.

Sie ersetzen streng genommen nicht das steuerliche Lieferdatum (BT-72) , werden aber in der Praxis oft synonym verstanden.

Begriff 2: Das Liefer-/Leistungsdatum (Actual Delivery Date)

Dies beschreibt den Zeitpunkt der Steuerentstehung (Lieferung ausgeführt / Dienstleistung beendet).

Technisches Feld: BT-72.

Unterschied: Eine Rechnung kann den "Rechnungszeitraum Januar" (BT-73/74) haben, aber das "Lieferdatum 31.01." (BT-72), an dem die Leistung abgeschlossen wurde.

Klarstellung Fälligkeit Umsatzsteuer gemäß Steuerrecht

Die Dokumentationspflicht ist nach § 14 Abs. 4 Nr. 6 UStG klar:

Das Gesetz fordert, dass der Leistungszeitraum auf der Rechnung stehen muss.

Bei E-Rechnung auf Positionsebene z.B. BT-134 (Start) und BT-135 (Ende).

Der Zeitpunkt der Leistung wird klar durch UStAE 13.1 Abs. 3 bestimmt:

Dieser USt-Anwendungserlass definiert verbindlich:

Eine Dienstleistung, die sich über einen Zeitraum erstreckt, gilt erst mit ihrer Vollendung (Beendigung des Zeitraums) als ausgeführt.

Die Entstehung der Steuer wird in § 13 Abs. 1 Nr. 1 Buchst. a UStG beschrieben:

Das Gesetz besagt, dass die Umsatzsteuer mit Ablauf des Monats entsteht , in dem die Leistung ausgeführt worden ist.

Auf E-Rechnung bezogen , die längere Zeiträume abrechnen , bedeutet dies:

Startdatum im Vorjahr (BT-134) ist eine formale Pflichtangabe , die den Anfang der Leistung definiert.

Der einzige steuerrechtliche Auslöser ist das Enddatum der Dienstleistung , welches für Positionen mit BT-135 angegeben werden sollte.

Konkretres Beispiel:

Wenn ein größeres Projekt mit Dienstleistung z.B. im Dezember eines Jahres begonnen , aber erst im Januar des Folgejahres vollendet wurde , hat die Umsatzsteuer komplett im Januar des Folgejahres mit Abrechnung zu entstehen.

Was macht Sage im Standard der aktuellen Version 9.0.10.x?

Lauf Auflistung der BT-Felder von Sage unterstützt Sage nicht(!) die Positionsfelder "Leistungszeitraum von" , Feld BT-134 und "Leistungszeitraum bis" , Feld BT-135.

Somit ist ausschließlich das Kopf-Feld für den "Leistungszeitpunkt" , Feld BT-72 "OccurrenceDateTime" , relevant.

Technisch sind die Sage Felder "Leistungszeitraum von/bis" BT-73/BT-74 "BillingSpecifiedPeriod" im Belegkopf , und dies sind reine Informationsfelder darüber, welcher Zeitraum "in Rechnung gestellt" wird , wie schon erwähnt.

Diese Felder ersetzen streng genommen nicht das steuerliche Lieferdatum (BT-72 sowie BT-134 und BT-135 auf Positionsebene) , werden aber in der Praxis oft synonym verstanden.

⚠️Es hängt somit von der Empfänger-Seite ab , wie die Felder für den Abrechnungszeitraum interpretiert werden.

Die "BillingSpecifiedPeriod" wird in der Praxis bei der XML-Erstellung von Sage nur deshalb zu den Feldern BT-73 und BT-74 , weil diese seitens Sage im Kopf ausgegeben werden , im "ApplicableHeaderTradeSettlement"-Bereich.

Würde Sage die Felder im Bereich "SpecifiedLineTradeSettlement" der Positionen ausgeben (was Sage aktuell im Standard nicht! macht) , dann wären es die Felder BT-134/135.

Ausschließlich die Felder "BillingSpecifiedPeriod" auf Positionsebene(!) hätten dann einen steuerlich relevanten Lieferzeitraum-Charakter.

Von Sage wird aktuell im Standard ausgegeben:

Belegkopf-Kontext (ApplicableHeaderTradeSettlement/BillingSpecifiedPeriod) -> BT-73/BT-74.

Von Sage wird aktuell nicht ausgegeben:

Belegposition-Kontext (SpecifiedLineTradeSettlement/BillingSpecifiedPeriod) -> BT-134/BT-135.

Somit ist ausschließlich das Kopf-Feld für den Leistungstermin , Feld BT-72 "OccurrenceDateTime" , relevant.

⚠️BT-73/74 ersetzen niemals BT-72 !

BT-73 und BT-74 könnten steuerlich nur dann genügen , wenn es sich um eine Dauerleistung handelt und kein(!) Einzeldatum übergeben würde.

Dies sieht Sage aber nicht vor , somit ist das Weglassen von BT-72 auf keinen Fall möglich.

BT-72 muss aus unserer Sicht immer erhalten bleiben , was im Sage Standard auch der Fall ist und somit ist dieses Feld BT-72 im Sage Standard das steuerlich relevante Feld.

Wenn BT-73 und BT-74 (oder BT-134 und BT-135 durch eine Anpassung) ausgegeben werden , kann man nur eines der beiden BT-Felder angeben?

Die Antwort ist: Jein! 😁

Aus Sicht der technischen Validierung wäre dies möglich.

Das Validierungsschema für eine Prüfung einer XML-Datei nach CII oder UBL sagt bei Regel "BR-CO-20" eindeutig , dass die Felder mit Entweder/Oder vorab validiert werden , d.h. rein technisch gesehen könnte nur eines der beiden Felder auf Positionsebene gesetzt sein.

Nachfolgend die Schema-Validierungen von der offiziellen Webseite https://xeinkauf.de/dokumente/.

⚠️Da ist jedoch fachlich äußerste Vorsicht geboten!

Auch wenn es technisch erlaubt ist (Validierung okay), ändert sich die fachliche Bedeutung:

Wenn nur ein Feld gefüllt ist , wäre die Aussage: “Die Leistung hat am 20.05.2024 begonnen (oder geendet).“

Der Zeitraum ist offen oder nicht definiert.
Besser ist es in solchen Fällen , beide Felder gleich zu setzen , um eine fachliche Eindeutigkeit zu erreichen.

Begründetes "steuerliches Risiko" ( =fachliche Ebene):

Für die Entstehung der Umsatzsteuer ist der Zeitpunkt der Leistungserbringung , bei Zeiträumen das Ende/Abschluss der Leistung , maßgeblich.

Wenn man somit nun nur ein Startdatum liefert und kein Enddatum , dann fehlt dem Empfänger streng genommen die Information, wann die Leistung final abgeschlossen wurde (Stichwort: endgültiges Leistungsdatum).

Sage 100 Beispieldateien

Generiert mit "OLDemoReWeAbfD"-Datenbank in Version 9.0.10.4.x.:

UBL-Syntax:

Cross Industry Invoice (CII)-Syntax

OFFICIUM INSERVIO IT