Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

Aufgrund zahlreicher Anfragen fassen wir den aktuellen Stand der eRechnung für Deutschland in Microsoft D365 for Finance zusammen. Dieser Bericht erhebt keinen Anspruch auf Vollständigkeit, Richtigkeit oder Unvoreingenommenheit. Er basiert auf praktischen Erfahrungen und bezieht sich auf die Auslegung der BDO: https://www.bdo.de/de-de/insights/weitere-veroffentlichungen/tax-legal/die-erechnung-in-deutschland.

E-Rechnungen einlesen

Der Import von elektronischen Rechnungen wird ab dem 01.01.2025 für alle Unternehmen im B2B-Bereich in Deutschland Pflicht. Microsoft hat kürzlich eine teilweise Lösung veröffentlicht. Hier ein Auszug:

05.09.2024: Wir möchten Sie darüber informieren, dass Microsoft das länderspezifische Update für Deutschland veröffentlicht hat, um den Import von elektronischen Rechnungen zu unterstützen. Die Funktion ermöglicht es, eingehende Lieferantenrechnungen im „xRechnung“-Format in ausstehende Lieferantenrechnungen (Anm.: „Pending invoice“) in Microsoft D365 Finance zu importieren. Die Änderungen wurden nur in den Konfigurationen für das Elektronische Berichterstattung (Electronic Reporting) implementiert, das heißt, sie passen zu allen aktiven Versionen von Microsoft D365 Finance gleichzeitig. Es müssen keine Qualitätsupdates installiert werden. Um die Änderungen zu aktivieren, müssen Sie die folgenden (oder neueren) Versionen der Konfigurationen importieren:
Invoice model version 280, Vendor Invoice Mapping to Destination version 280.46, Vendor Invoice Import version 280.7.
Weiteres erfahren Sie aus der Dokumentation: Import vendor electronic invoices – Finance | Dynamics 365 | Microsoft Learn

Der Import funktioniert grundsätzlich wie beschrieben und übernimmt die wichtigsten Datenfelder aus der Rechnung::

Kopf: Rechnungsnummer, Rechnungsdatum, Fälligkeitsdatum, Lieferantennummer, Währungscode und eine Kopfzeilenbemerkung, PO-Nummer (Bestellnummer)
Zeilen: Zeilennummer, Artikelnummer, Menge, Verkaufspreis, Rabatt (Prozentrabatte werden in absolute Beträge umgerechnet, da das XML-Schema keine Prozentsätze unterstützt), Preiseinheit, Name, Beschreibung und Betrag (ohne USt.)

Die Maßeinheiten werden über die Externen Codes aus den Standardwerten UNECE Rec 20 („Codes for Units of Measure Used in International Trade“) umgeschlüsselt (analog dem UBL-Export, siehe auch Austrian Peppol-UBL e-invoice). Die gängigen Einheiten in D365 sind:

Artikel	UNECE Rec 20 Code
Stücke	H87
Undefinierte Einheiten („ea“)	C62
Kilogramm	KGM
Meter	MTR
Liter	LTR
Tonnen	TNE
Zentimeter	CMT
Stunden	HUR
Tage	DAY
Gramm	GRM
Minuten	MIN
Monate	MON
Wochen	WEE
Millimeter	MMT
Sekunden	SEC
Millisekunden	C26
Yards	YRD
Troy-Unzen	APZ
Füße	FOT
Gallonen	GLL
Zoll	INH
Unzen	ONZ

Die Zuordnung zum Lieferanten erfolgt über die Umsatzsteuer-ID. Die externe Artikelnummer des Lieferanten muss vorhanden sein. Die vom Lieferanten möglicherweise gesendete Käufer-Artikelnummer wird ignoriert, und die Umwandlung in die interne Artikelnummer erfolgt stets über die externen Artikelnummern. Unter diesen Voraussetrzungen wird die Rechnung auch der Bestellung zugeordnet, sofern die XML-Datei die Bestellnummer beinhaltet und die Rechnungspositionen auf Bestellpositionen verweisen. Microsoft hat hierzu gerade ein leicht zugängliches Video veröffentlicht: Import vendor electronic invoices – Video.

Zuschläge oder Rechnungsrabatte werden im Moment nicht berücksichtigt. Beschaffungskategorien – ob mit einer PO-Nummer oder ohne PO – werden seltsamerweise nicht unterstützt. Der Bruttobetrag inklusive MwSt. wird nicht verarbeitet, was als Einschränkung angesehen werden könnte. Partner in Europa arbeiten zusammen mit Microsoft an Verbesserungen.

Zwei Varianten der XRechnung

In der oben beschriebenen Lösung von Microsoft wird ausschließlich die XML-Datei verarbeitet. Dies bedeutet, dass der XML-Anhang bei Hybridrechnungen wie ZUGFeRD manuell (z. B. mit Adobe Reader oder Adobe Acrobat) extrahiert werden muss. Es gibt allerdings Agenten für Power Automate, die diesen Prozess automatisieren können: Extract Attachments from PDF. Bei dieser UK-Firma Encodian kostet die Verarbeitung einer Rechnung 1 „Credit“. Sie beginnen mit einem 30-tägigen Testabonnement mit 500 Credits; im Endeffekt kostet eine Rechnung zwischen €0,00 und €0,08.

Die XRechnung ist allerdings nicht ein einziges Format, sondern besteht aus zwei Varianten: UBL (‚Universal Business Language‘ wie sie auch im PEPPOL-Netzwerk verwendet wird) und CII (‚Cross-Industry Invoice‘, besser bekannt als ZUGFeRD). Microsoft unterstützt derzeit nur das UBL-Schema. Leider dürfen Unternehmen eine CII-Rechnung nicht ablehnen, wenn sich der Lieferant für diese Version entscheidet („Technologieoffenheit“).

Wir bei ER-Consult haben die Microsoft-Lösung so ausgebaut, dass auch das CII-Schema importiert werden kann: ZUGFeRD 2.2 import for Dynamics 365 for Finance – ER-Consult (erconsult.eu). Die Konfiguration fürs Electronic Reporting-Modul kann über Microsoft bezogen werden: ZUGFeRD CII import (microsoft.com).

Der Prozess kann am Ende folgendermaßen aussehen:

Der Lieferant sendet eine hybride PDF/XML-Rechnung per E-Mail an rechnung@unser-unternehmen.de.
Über Power Automate trennt der Encodian-Agent die Rechnung und leitet den XML-Anhang (UBL oder CII) in das eine oder andere SharePoint-Verzeichnis weiter.
D365 liest die Verzeichnisse aus und erstellt einen Eintrag in der Liste ausstehender Rechnungen.
Der Buchhalter nimmt die PDF aus dem Outlook-Posteingang, findet den vorgefertigten Eintrag und vergleicht die Gesamtsummen in D365 mit denen in der PDF.
Falls Abweichungen bestehen, korrigiert der Buchhalter die Rechnung manuell mithilfe der PDF-Visualisierung, bis die Werte übereinstimmen. Dann wird der 3-Wege-Abgleich angewandt.
Schließlich wird die Rechnung gebucht oder zur Genehmigung vorgelegt.

Bei rein elektronischen xRechnungen (XML-Dateien) könnte ein Visualisierungstool nötig werden, z.B. eine spezielle XSLT-Transformation für die Umwandlung in HTML für die Anzeige auf dem Bildschirm (GitHub – itplr-kosit/xrechnung-visualization: XSL transformators for web and pdf rendering of German CIUS XRechnung or EN16931-1:2017).

Vorteile der E-Rechnung

Ein positiver Aspekt: Mit der Einführung der eingehenden E-Rechnung werden kostenpflichtige Add-Ons wie Ax*******, Ex**** oder Microsofts Invoice Capture obsolet – vorausgesetzt, Ihre Lieferanten stellen die elektronischen Rechnungen bereits aus. Bis 2027 sind sie jedoch paradoxerweise noch nicht dazu verpflichtet:

E-Rechnungen ausstellen

Für die meisten Unternehmen gibt es eine zweijährige Übergangsfrist. Die Version XRechnung-UBL (also die XML-Datei im ‚Universal Business Language‘-Syntax) wird von Microsoft angeboten. Die ER-Konfigurationen müssen vom Dataverse/RCS heruntergeladen und unter Debitorenkonten > Einstellungen > Debitorenkontenparameter, Elektronische Dokumente verknüpft werden: UBL Sales invoice, UBL Sales Credit Note, UBL Project Invoice, UBL Project Credit Note, siehe hierzu: E-Invoice in D365FO for Norway – Part 1 (Intro) – DynFOTech.

Die aktuellen UBL-Formate werden wahrscheinlich wegen bekannter kleiner Fehler nicht sofort einsatzbereit sein; Partner in Europa und Microsoft arbeiten an Korrekturen.

Am Kunden muss das Kontrollkästchen „eInvoice“ gesetzt werden. Bei jeder Rechnungsbuchung mit gleichzeitiger Druckausgabe wird automatisch ein Stapellaufvorgang in der Elektronischen Berichterstellung ausgelöst. Mithilfe der „ER destinations“ (Organisationsverwaltung > Elektronische Berichterstellung > Zielort) kann die resultierende Datei an die E-Mail-Adresse des Kunden oder in ein SharePoint-Verzeichnis weitergeleitet werden. Ein erneuter Versand ist über die Funktion „Versenden/Kopie“ (Send/Copy gleich unter Print…) an der Rechnung möglich. Nota bene: ist die Funktion „Electronic invoicing“ (siehe unten) von Microsoft aktiviert, verschwindet die Option Versenden.

Außerdem kann D365 for Finance mit dem „Electronic invoicing“-Add-On direkt an das PEPPOL-Netzwerk angebunden werden: Supported electronic invoicing countries and regions – Finance | Dynamics 365 | Microsoft Learn. Die Teilnahme am PEPPOL-Netzwerk ist jedoch kostenpflichtig, die Endpoint-ID wird von dem PEPPOL-Konsortium vergeben, und diese Art der e-Rechnung ist nur bei öffentlichen Ausschreibugen sinnvoll (und obligatorisch), weil ein Kunde aus der Privatwirtschaft nicht zur Teilnahme verpflichtet werden kann. Im CII-Schema entspricht unsere Endpoint-ID übrigens der eigenen Umsatzsteuer-ID.

CII-Variante der XRechung

Die CII-Variante der XRechnung (XML-Datei im Syntax ‚Cross-Industry Invoice‘) wird von Microsoft nicht unterstützt. Unsere „Light“-Lösung hingegen bietet Ihnen diese Möglichkeit: ZUGFeRD 2.2/ Factur-X 1.0 for Dynamics 365 FO – ER-Consult (erconsult.eu). Die Lösung kann über Microsoft bezogen werden: ZUGFeRD Light, Light+, Heavy (microsoft.com)

D365-Kunden, die auf Microsofts Electronic Reporting / Configurable Business Documents anstatt ******line, *****net oder ****2 gesetzt haben, profitieren davon: die XML-Datei im CII-Format wird mithilfe der Gruppierfunktion (Email ER destination type – Finance & Operations | Dynamics 365 | Microsoft Learn) als zweiter Anhang neben der gewohnten PDF-Rechnung an den Kunden versandt. Um sowohl die XML- als auch die PDF-Datei zu senden, muss das ER-Format diese zwei Knoten unter derselben „Root“ enthalten. Aus diesen Grund setzt unsere Lösung auf dasselbe ER-Modell wie die Sales invoice (Excel) von Microsoft, siehe Screenshot.

ZUGFeRD: CII-Hybridformat

Unsere ZUGFeRD „Heavy“-Version ist eine [rudimentäre] Implementierung vom ZUGFeRD-Hybridformat (menschlich lesbare PDF mit einer eingebetteten XML-Datei in der Syntax ‚Cross-Industry Invoice‘). Meiner Einschätzung nach wird Microsoft diese Version in naher Zukunft nicht anbieten können, da erhebliche technische Herausforderungen bestehen.

Zusammenfassung

Ab dem 1. Januar 2025 wird der elektronische Rechnungsimport für Unternehmen im B2B-Bereich in Deutschland verpflichtend. Der Vorteil der E-Rechnung liegt darin, dass kostenpflichtige Add-ons für Rechnungsverarbeitung überflüssig werden. Microsoft hat ein länderspezifisches Update für Deutschland in D365 Finance veröffentlicht, das den Import von elektronischen Rechnungen im „xRechnung“-Format ermöglicht. Microsoft unterstützt jedoch nur die UBL-Syntax. ER-Consult hat eine Lösung auch für den Import von CII-Rechnungen parat.

Für die Umstellung auf den elektronischen Rechnungsversand haben Unternehmen eine zweijährige Frist, wobei Microsoft E2E-Lösungen für die XRechnung-UBL bereitstellt. Auch hier bietet ER-Consult eine Erweiterung für die elektronischen CII- und ZUGFeRD-Hybridrechnungen.

E-invoice and configurable business documents blog series

WIP in der Bilanz

Die Aufgabe in Dynamics 365 for Finance and SCM lautet: Abbildung der Ware in Arbeit (WIP) in der Bilanz bei [lang] laufenden Produktionsaufträgen, wobei jede Bewegung auf einem Bilanzkonto (Bestand) mit einer G&V-Buchung einhergehen soll (Bestandveränderung). Der Verbrauch der Ware soll der WIP-Bestand aufbauen, die zwischenzeitliche [Teil-]Fertigmeldung vom Fabrikat oder Halbfabrikat soll den WIP-Bestand abbauen und in den Bestand vom fertigen Produkt „umwandeln“.

Das Problem dabei: der Materialverbrauch in Dynamics 365 macht nur 2 Sachkontenbuchungen (z.B. Soll Bestand – Haben Bestand oder Soll Bestand – Haben Aufwand),

und die Fertigmeldung ebenfalls 2 (Soll Bestand – Haben Bestandsveränderung).

Ich versuche diese Aufgabe mit der Zuteilung (en: Allocation) zu lösen, indem eine Buchung vom Materialverbrauch zwei zusätzliche Buchungen auslöst (+100% WIP-Bestand, -100% Bestandsveränderung) und die Ware in Arbeit aufbaut.

Die Zuteilung sollen wir am besten an die GuV-Konten („Vorkalkulierte Kosten für verbrauchte Materialien, RIF“, „Vorkalkulierte Fertigungskosten, RIF“) anhängen, da diese in der Regel mehr Dimensionen als die entsprechenden Bilanzkonten aufweisen. Die abgeleitete Buchung kann nämlich nur Dimensionen von der Ursprungsbuchung erben, nicht vom Quelldokument.

Die Buchung vom fertigen Produkt (Fertigmeldung) bringt ebenfalls 2 zusätzliche Buchungen hervor (+100% Bestandsveränderung, -100% WIP-Bestand) und die Ware in Arbeit abbaut:

Die ganze Geschichte lässt sich auf den T-Konten wie folgt abbilden (die Maschinenstundesätze sind einfachheitshalber ausgenommen):

Bei einer Abweichung der tatsächlichen von vorkalkulierten Kosten (z.B. bei Mehrverbrauch von Materialien, oder bei einem gemeldetem Ausschuss, oder bei einer „Unterlieferung“ des Produktionsauftrags) ist der Saldo auf dem WIP-Konto nach der letzten Fertigmeldung größer Null (der Wareneinsatz > als die Ausbeute). Diese Differenz wird im Zuge der Nachkalkulation ausgebucht, weil der Nachkalkulationsvorgang die Buchungen „Vorkalkulierte Kosten für verbrauchte Materialien, RIF“ und „Vorkalkulierte Fertigungskosten, RIF“ zwingend aufhebt, was zugleich für die vollständige Umkehr die Zuteilung sorgt. Das Aufwandskonto „Kosten für verbrauchte Materialien, RIF“, und das Bestandveränderungskonto „Fertigungskosten, RIF“ dürfen keine Zuteilung auslösen und müssen sich demnach von den Konten „Vorkalkulierte Kosten für verbrauchte Materialien, RIF“, „Vorkalkulierte Fertigungskosten, RIF“ unterscheiden.

Zusammenfassung

In Dynamics 365 for Finance and SCM soll der WIP-Bestand (Ware in Arbeit) bei laufenden Produktionsaufträgen in der Bilanz abgebildet werden, wobei jede Bestandsbewegung mit einer G&V-Buchung verknüpft ist. Das System erstellt jedoch standardmäßig nur zwei Buchungen pro Materialverbrauch oder Fertigmeldung. Um dies zu lösen, wird eine zusätzliche Zuteilung verwendet, die zwei weitere Buchungen auslöst, um den WIP-Bestand aufzubauen oder abzubauen und die Bestandsveränderungen korrekt abzubilden.

Austrian VAT declaration / Umsatzsteuervoranmeldung 2020

Unkategorisiert

Following up on my latest blog, let me continue with the specific setup for the VAT return in Austria. This electronic VAT declaration called Umsatzsteuervoranmeldung „UVA“ must be uploaded monthly or quarterly (depending on the company’s turnover) in a proprietary XML format to the web site FinanzOnline of BMF, the Austrian Ministry of Finance. The interface is well maintained by the DACH support team for Dynamics, but there was nowhere on the Internet a description of the barebone setup. Well, up until now.

The only documentation is the class TaxReport_ReportAT, which is used by the periodic function VAT payment in the Tax module to produce a „UVA“ declaration, both printed and the electronic. I reverse engineered it, and it should be noted that

It requires a non-continuous number sequence XML VAT package number to form a message ID.
The printed PDF version is not accepted by the ministry anymore, but it is quite useful to visualize and check the VAT return prior to the booking. The latest template required by the class can be downloaded here.
The printed form expects an exotic address format of the legal entity primary address, one with a separate house number Street number.
The tax number (not to mix with the European VAT (UID)-number) MUST be present in the legal entity, Tax registration number field in the format xxx/yyyy-ZZ, where ZZ is the number of the BMF’s local office. The same can be seen without dashes and slashes on FinanzOnline.
The class uses a set of hardcoded 4 digit codes to map tax codes to cells on the tax return. There are cells (and the respective XML elements) for a total tax base per tax period per VAT rate, or a tax amount per tax period per VAT rate.

Below are the most relevant VAT return cell codes. For more information on the individual VAT return cells, please refer to the comprehensive description (de-at) on the BMF site.
You should add the 16 codes to the table VAT reporting codes with the Report layout = Austrian report layout.

Reporting code	Report text	Brief description
1122	Gesamt Umsatzsteuer: 20% Normalsteuersatz	Total sales VAT: full 20%
1022	Gesamt Bemessungsgrundlage: 20% Normalsteuersatz	Total sales base: full 20%
1011	Bemessungsgrundlage: Ausfuhrlieferungen § 6 Abs. 1 Z 1 iVm § 7	Sales base: Export 3rd country tangible
1021	Bemessungsgrundlage: Steuerschuldübergang § 19, grenzüberschreitende Leistungen	Sales base: Reverse charge incl. export of services IC, 3rd
1020	Bemessungsgrundlage: übrige steuerfreie Umsätze ohne Vorsteuerabzug	Sales base: Other exempt sales
1017	Bemessungsgrundlage: IgL Art. 6 Abs. 1 ohne Fahrz	Sales base: IC delivery
1160	Vorsteuer ohne…	Total purchase VAT except for…
1157	Steuerschuldübergang bei Bezug gemäß § 19 Abs. 1 zweiter Satz, § 19 Abs. 1c	IC purchase payable VAT: Reverse charge on service acquis
1166	Vorsteuer: Steuerschuldübergang gemäß §19, grenzüberschreitende Leistungen	IC purchase receivable VAT: reverse charge on service acquis
1183	Vorsteuer: Einfuhrumsatzsteuer geschuldet (§ 12 Abs. 1 Z 2 lit. b)	Purchase 3rd country import VAT (payable)
1172	IgE Steuerschuld: 20% Normalsteuersatz	IC purchase payable VAT: full 20%
1072	IgE Bemessungsgrundlage: 20% Normalsteuersatz	IC purchase payable base: full 20%
1106	Gesamt Umsatzsteuer: 13% ermäßigter Steuersatz	Total sales VAT: reduced 13% (agro B2C)
1006	Gesamt Bemessungsgrundlage: 13% ermäßigter Steuersatz	Total sales base: reduced 13% (agro B2C)
1129	Gesamt Umsatzsteuer: 10% ermäßigter Steuersatz	Total sales VAT: reduced 10% (foodstuffs, print media)
1029	Gesamt Bemessungsgrundlage: 10% ermäßigter Steuersatz	Total sales base: reduced 10% (foodstuffs, print media)

Finally, the above 16 reporting cells are assigned to my 12 VAT codes in the VAT codes table:

Report setup

exF

exS

euF

euA

euR

euS

doF

doA

doH

doR

Taxable sales

1022

1006

1029

Duty-free sale

1011

1021

1017

1021

1020

VAT payable

1122

1106

1129

Taxable purchases

Duty-free purchase

VAT receivable

1160

Taxable import

1072

1073

Offset taxable import

Import VAT/ purchase VAT

1183

1172

1173

1157

Offset import VAT/ purchase VAT

1166

(EU sales list excluded)

yes

(Country type)

3rd

Dom

The Report setup – credit note of the VAT code records is identical.

The full list of the Austrian VAT reporting codes can be downloaded here. The not relevant codes are marked “N/A”. My criteria for the relevance for a typical manufacturing or a service business were:

Reselling of cars, scrap, gas, electricity, CO2 certificates are ‘exotic’ businesses, as well as seafaring, trucking, taxi services, real estate agencies;
Small businesses below the 100 000 EUR turnover threshold would never use Dynamics AX either;
The Jungholz and Mittelberg exclave valleys with the German VAT are too small to get noticed;
It is not practical to apply a dedicated tax code to goods intended for the self-consumption by the company owner: such goods do not reduce the income/corporate tax base either and should better not appear in the accounting at all, or be simply sold to the owner via a sales order as everything else.

Happy tax paying!