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).

Wichtige Hinweise zur Übertragung von Mengeneinheiten

Die in den XML-Dateien übertragenen Mengeneinheiten sind für die Empfänger keine reinen Textfelder , sondern werden oft aktiv ausgewertet.

Z.B. bei Rechnungen an öffentliche Auftraggeber (XRechnung) wird besonders genau auf die passenden Codes geachtet!

Für reine Arbeitszeit ist z.B. "HUR" als Mengeneinheit fast immer zwingend erforderlich , da eine Abrechnung von Stunden als "Stück" (H87) in automatisierten Prüfprozessen auf Empfängerseite oft fachlich abgelehnt wird.

Sollten Sie eigene , benutzerdefinierte Mengeneinheiten angelegt haben , kann es vorkommen , dass Sage bei der Erstellung der XML-Datei keinen passenden UN/ECE-Einheitscode ermitteln kann.

Wenn Sage keine Zuordnung aufgrund der aktuellen Mapping-Tabelle in Ihrem System vornehmen kann , wird im XML bei dem wichtigen Feld BT-130 gegebenenfalls von Sage dann automatisch der Code "H87 - piece/Stück" ausgegeben.

Dies kann zu einer Ablehnung der E-Rechnung auf Empfängerseite führen, wenn die Position fachlich keine Stückposition darstellt , beispielsweise bei einer Pauschale oder sonstiges.

In diesem Fall muss:

1. der benötigte UN/ECE-Einheitscode unter

Grundlagen -> Warenwirtschaft -> Mengeneinheiten E-Rechnung

angelegt beziehungsweise geprüft werden,

2. die benutzerdefinierte Mengeneinheit unter

Grundlagen -> Warenwirtschaft -> Mengeneinheiten E-Rechnung Zuordnung

dem passenden UN/ECE-Code zugeordnet werden.

Für eine Pauschale kommt beispielsweise "LS – lump sum" infrage.

Welcher Code verwendet werden soll , sollte im Zweifel vorab mit dem Rechnungsempfänger abgestimmt werden. Wie schon erwähnt sind öffentliche Auftraggeber dabei oft besonders kritisch.

Hier ist eine praxisnahe Übersicht der wichtigsten UN/ECE-Einheitscodes (Recommendation 20) für Dienstleistungen , Pauschalen und Zeitangaben:

Pauschalen und Dienstleistungen:

LS: lump sum (Pauschale)

SET: set (Satz - z.B. für gebündelte Leistungen)

E48: service unit (Leistungseinheit - nützlich für abstrakte Dienstleistungen)

C62: one (Eins / Stück - wird neben H87 im E-Rechnungs-Umfeld sehr häufig als Standard-Zähleinheit verwendet)

H87: piece (Stück - der Klassiker für physische Artikel)

Zeitangaben (wichtig für Beratung, Support oder Dienstleistungen):

HUR: hour (Stunde)

DAY: day (Tag)

WEE: week (Woche)

MON: month (Monat)

ANN: year (Jahr)

Weitere typische Einheiten für Handwerk und Handel:

MTR: metre (Meter)

MTK: square metre (Quadratmeter)

MTQ: cubic metre (Kubikmeter)

KGM: kilogram (Kilogramm)

LTR: litre (Liter)

Sage 100 Beispieldateien

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

UBL-Syntax:

Cross Industry Invoice (CII)-Syntax

Einfache englischsprachige Referenz in Textform

Die folgende Auflistung basiert auf der o.g. Tabelle , beschreibt jedoch alle Felder in Englisch.

(none) | ram:ID (under ExchangedDocumentContext / BusinessProcessSpecifiedDocumentContextParameter; value typically urn:fdc:peppol.eu:2017:poacc:billing:01:1.0) | cbc:ProfileID | Process identifier / Business process type | BT-23 | (Yes) Mandatory for XRechnung

(none) | ram:IncludedNote / ram:SubjectCode | cbc:Note (subject code prefix) | Qualification of the free text for the invoice. Codes used: AAI = General Information, AAR = Terms of delivery, COI = Order Information, ADU = Note, PMT = Payment Information, REG = Regulatory Information... | BT-21 | (none)

Long and dimension text, Intrastat commodity code | ram:IncludedNote / ram:Content (line level) | cac:InvoiceLine / cbc:Note | Free text for the invoice line. Planning: From V9.0.11 these texts are output directly with the article. Text information will then be output here. | BT-127 | (none)

Article description 2 | ram:SpecifiedTradeProduct / ram:Description | cac:Item / cbc:Description | A description of the article. Planning: From V9.0.11, dimension and long texts, as well as Intrastat commodity codes etc., will also be output in the article description. | BT-154 | (none)

Article net price after deducting all discounts | ram:NetPriceProductTradePrice / ram:ChargeAmount | cac:Price / cbc:PriceAmount | The price of an article excluding VAT after deducting the discount on the article price. Every invoice line must contain the net price of the article. | BT-146 | Yes

Article quantity | ram:SpecifiedLineTradeDelivery / ram:BilledQuantity @unitCode="XXX" | cac:InvoiceLine / cbc:InvoicedQuantity | The quantity of individual items (goods or services) invoiced in the respective line. The invoiced quantity must be specified for each invoice line. | BT-129 | Yes

Unit of measure | ram:SpecifiedLineTradeDelivery / ram:BilledQuantity @unitCode="XXX" | cac:InvoiceLine / cbc:InvoicedQuantity @unitCode | The unit of measurement applicable to the invoiced quantity. The code for the unit of measurement of the invoiced quantity must be specified for an invoice line. The following codes are currently supported: H87 = Piece (default value), C62 = Number, HUR = Hours, MTR = Metres, MIN = Minutes, DAY = Working day, SET = Set, KGM = Kilograms, GRM = Grams, LTR = Litres, MTK = Square metres, TNE = Tonnes, XBO = Bottle, XCT = Carton, XCS = Box, XRO = Roll, XPX = Pallet, XBG = Bag | BT-130 | Yes

Tax code | ram:ApplicableTradeTax / ram:CategoryCode | cac:ClassifiedTaxCategory / cbc:ID | The code of the VAT category applicable to the invoiced item. Every invoice line must be categorised using the VAT category of the invoiced item. The following codes are currently supported: S = Standard rate (normal and reduced), E = Tax exempt, AE = Reverse charge | BT-151 | Yes

Routing ID in customer master data for XRechnung, your reference in document for ZUGFeRD | ram:BuyerReference | cbc:BuyerReference | An identifier assigned by the buyer and used for internal routing. For XRechnung = Routing ID | BT-10 | (Yes) Mandatory for XRechnung

In sales document: 'Your reference' | ram:SellerTradeParty / ram:ID | cac:PartyIdentification / cbc:ID | An identifier of the seller (usually assigned by the purchaser), such as the vendor number for the financial management system or the supplier number for the ordering system. | BT-29 | Yes

Telephone number from client address | ram:SellerTradeParty / ram:DefinedTradeContact / ram:TelephoneUniversalCommunication / ram:CompleteNumber | cac:Contact / cbc:Telephone | Telephone number of the seller. Mandatory for XRechnung. | BT-42 | (Yes) Mandatory for XRechnung

Email address from client address | ram:SellerTradeParty / ram:DefinedTradeContact / ram:EmailURIUniversalCommunication / ram:URIID | cac:Contact / cbc:ElectronicMail | Email address of the seller. Mandatory for XRechnung. | BT-43 | (Yes) Mandatory for XRechnung

Postcode from client address | ram:SellerTradeParty / ram:PostalTradeAddress / ram:PostcodeCode | cac:PostalAddress / cbc:PostalZone | The identifier for a group of properties addressable according to a responsible postal service. To comply with legal requirements, a sufficient number of address components must be entered. | BT-38 | (Yes) Mandatory for XRechnung

Street/PO box from client address | ram:SellerTradeParty / ram:PostalTradeAddress / ram:LineOne | cac:PostalAddress / cbc:StreetName | Usually the street name and house number or the PO box. To comply with legal requirements, a sufficient number of address components must be entered. | BT-35 | (Yes) Mandatory for XRechnung

City from client address | ram:SellerTradeParty / ram:PostalTradeAddress / ram:CityName | cac:PostalAddress / cbc:CityName | To comply with legal requirements, a sufficient number of address components must be entered. The usual name of the city or municipality where the seller's address is located. | BT-37 | (Yes) Mandatory for XRechnung

VAT ID no. from client basic data | ram:SellerTradeParty / ram:SpecifiedTaxRegistration / ram:ID schemeID="VA" | cac:PartyTaxScheme / cbc:CompanyID | To enable the buyer to automatically identify a supplier, the seller's VAT identification number must be provided. | BT-31 | Yes

Street/PO box from customer master data | ram:BuyerTradeParty / ram:PostalTradeAddress / ram:LineOne | cac:PostalAddress / cbc:StreetName | An invoice must contain the postal address of the buyer. Usually the street name and house number or the PO box. | BT-50 | Yes

Alternative delivery address: Postcode | ram:ShipToTradeParty / ram:PostalTradeAddress / ram:PostcodeCode | cac:Delivery / cac:DeliveryLocation / cac:Address / cbc:PostalZone | Detailed information on the address of the goods recipient | BT-75 / BT-77 area | (none)

Alternative delivery address: Country | ram:ShipToTradeParty / ram:PostalTradeAddress / ram:CountryID | cac:Delivery / cac:DeliveryLocation / cac:Address / cac:Country / cbc:IdentificationCode | Detailed information on the address of the goods recipient | BT-80 | (none)

Sales document: Delivery date | ram:ApplicableHeaderTradeDelivery / ram:OccurrenceDateTime / udt:DateTimeString format="102" (or ActualDeliverySupplyChainEvent) | cac:Delivery / cbc:ActualDeliveryDate | In Germany, the delivery and service date is a mandatory specification on invoices. This can be provided here or at the line item level. | BT-72 | Yes

Collection types: Cash on delivery and shop collection types are not supported | ram:SpecifiedTradeSettlementPaymentMeans / ram:TypeCode | cac:PaymentMeans / cbc:PaymentMeansCode | A payment instruction must specify the code of the payment method type. Codes used: Transfers = 58, SEPA direct debit = 59, Credit card = 48 | BT-81 | Yes

Payment method in free text | ram:SpecifiedTradeSettlementPaymentMeans / ram:Information | cac:PaymentMeans / cbc:PaymentMeansCode @name | The expected or used payment method expressed in text form. The following designations are used: Transfer, SEPA direct debit, Credit card | BT-82 | (none)

Credit card number | ram:ApplicableTradeSettlementFinancialCard / ram:ID | cac:PaymentMeans / cac:CardAccount / cbc:PrimaryAccountNumberID | If information on the payment card used is specified in the invoice, the last 4 to 6 digits of the payment card number must be displayed. | BT-87 | (Yes)

Mandate reference number | (under ApplicableHeaderTradeSettlement / payment terms or direct debit) | cac:PaymentMeans / cbc:PaymentID or related mandate | Unique identifier assigned by the payee for referencing the direct debit authorisation (mandate reference number). | BT-89 | (Yes)

Seller's IBAN | ram:PayeePartyCreditorFinancialAccount / ram:IBANID | cac:PaymentMeans / cac:PayeeFinancialAccount / cbc:ID | A unique identifier for the financial account held with a payment service provider, to which the payment should be made. | BT-84 | (Yes)

Seller's or buyer's BIC | ram:SpecifiedTradeSettlementPaymentMeans / ram:PayeeSpecifiedCreditorFinancialInstitution / ram:BICID | cac:PaymentMeans / cac:PayeeFinancialAccount / cac:FinancialInstitutionBranch / cbc:ID | An identifier for the payment service provider where the payment account is held. | BT-86 | (none)

Surcharge tax type | ram:CategoryTradeTax / ram:TypeCode | cac:AllowanceCharge / cac:TaxCategory / cac:TaxScheme / cbc:ID | Detailed information on tax details for surcharges. Only the tax type "Value added tax" with the code "VAT" is supported. | BT-102 area | (none)

Total net amount | ram:SpecifiedTradeSettlementHeaderMonetarySummation / ram:LineTotalAmount | cac:LegalMonetaryTotal / cbc:LineExtensionAmount | Sum of all invoice line net amounts of the invoice. An invoice must display the sum of the net amounts of all invoice lines. | BT-106 | Yes

(Total deductions net) is not shown separately, as all deductions are calculated into the line item | ram:SpecifiedTradeSettlementHeaderMonetarySummation / ram:AllowanceTotalAmount | cac:LegalMonetaryTotal / cbc:AllowanceTotalAmount | Sum of all deductions at document level contained in the invoice | BT-107 | (none)

Total tax base amount | ram:SpecifiedTradeSettlementHeaderMonetarySummation / ram:TaxBasisTotalAmount | cac:LegalMonetaryTotal / cbc:TaxExclusiveAmount | The invoice total amount excluding VAT is the sum of the invoice line net amounts minus the sum of the surcharges at document level plus the sum of the deductions at document level. An invoice must display the invoice total amount excluding VAT. | BT-109 | Yes

Gross total amount | ram:SpecifiedTradeSettlementHeaderMonetarySummation / ram:GrandTotalAmount | cac:LegalMonetaryTotal / cbc:TaxInclusiveAmount | The total amount of the invoice including VAT. An invoice must display the invoice total amount including VAT. | BT-112 | Yes

Reference to preceding invoice (e.g., for credit notes or cancellation invoices) | ram:InvoiceReferencedDocument / ram:IssuerID (or IssuerAssignedID) | cac:BillingReference / cac:InvoiceDocumentReference / cbc:ID | Reference to the preceding invoice. | BT-25 | (none)

Reference to preceding invoice (e.g., for credit notes or cancellation invoices) | ram:InvoiceReferencedDocument / ram:FormattedIssueDateTime | cac:BillingReference / cac:InvoiceDocumentReference / cbc:IssueDate | Invoice date of the preceding invoice. | BT-26 | (none)

OFFICIUM INSERVIO IT