Z4-Meldung an Bundesbank in D365 for Finance

Z4-Meldung an Bundesbank in D365 for Finance

Die Z4-Meldung „Zahlungen im Außenwirtschaftsverkehr“ (abgekürzt „AWV“) ist ein Finanzbericht, den deutsche Unternehmen der Deutschen Bundesbank im Rahmen ihrer Außenwirtschaftsstatistik vorlegen müssen. Unternehmen sind in der Regel verpflichtet, diesen Bericht monatlich einzureichen, abhängig vom Volumen der Transaktionen.

Alle deutschen Unternehmen, die grenzüberschreitende Finanzaktivitäten (z. B. Kredite, Einlagen, Wertpapiertransaktionen) mit einem Wert über einem bestimmten Schwellenwert (derzeit 12500 € pro Transaktion) durchführen, müssen diesen Bericht einreichen. Das Schlimmste daran: nicht nur Transaktionen mit Nicht-EU-Ländern müssen gemeldet werden, sondern auch eingehende und ausgehende Zahlungen in EU-Länder. Dies ist ein Albtraum in der stark integrierten EU-Wirtschaft.

Glücklicherweise werden Zahlungen im Zusammenhang mit dem Warenhandel (wie Exporte oder Importe) in der Z4-Meldung nicht erfasst. Diese Transaktionen werden typischerweise über andere Meldesysteme wie Intrastat für den Handel innerhalb der EU abgedeckt. Stattdessen konzentriert sich die Z4-Meldung auf Finanztransaktionen, die nicht mit dem direkten Austausch von Waren verbunden sind (z. B. Kredite, Finanzinvestitionen und – am wichtigsten – Dienstleistungen).

Der Z4-Bericht hat eine einfache XML-Struktur, die dem proprietären „XMW“-Schema folgt: XMW – Elektronisches Meldewesen im XML-Format. Im regulären Zahlungsprozess werden Ein- und Auszahlungen jeweils mit einer Transaktionsart (BELEGART) von „1“ bzw. „2“ klassifiziert. Bei jeder Transaktion werden das Land (ISO2), die Buchungsbeschreibung und der Betrag in Tausend Euro angegeben. Die Untertypklassifizierung „KENNZAHL“ stellt eine erhebliche Herausforderung dar: es gibt insgesamt etwa 1000 Codes, von Flugkosten über die Dienstleistungen bis zur Nutzung von Software. Diese Liste aus der Hölle wird hier in einer unpraktischen Excel-Datei veröffentlicht: „Kennzahlenliste mit Belegarten“.

Wir freuen uns, eine Konfiguration fürs Modul „Elektronische Berichtserstellung“ (Electronic Reporting) für die Z4-Meldung in Dynamics 365 for Finance bereitzustellen: XMW_Model_Mapping_Format.zip. Beachten Sie bitte, dass ER-Consult GmbH keine Gewährleistung übernimmt und haftet nicht für Schäden, die durch die Nutzung der Konfigurationen entstehen.

Es werden nur die regulären Zahlungstransaktionen („DIKAPPOSTEN“) unterstützt, nicht jedoch Aktien oder ähnliche Investitionen. Um Zahlungen nach der detaillierten „KENNZAHL“ zu trennen, empfehlen wir die Verwendung des Belegpräfixes. Beispielsweise können Sie unterschiedliche GL-Journalnamen für Gehalts- und Provisionszahlungen einführen, jeweils mit eigenen Belegnummernkreisen. Um Fehler zu vermeiden, empfehlen wir die Verwendung separater Zahlungsmethoden, insbesondere für Waren und Dienstleistungen, wobei jede Zahlungsmethode in ihrem eigenen Kreditoren-/Debitoren-Zahlungsjournal verarbeitet wird.

Mehr dazu in Englisch: Z4-Meldung an Bundesbank in D365 for Finance – ER-Consult (erconsult.eu)

Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

Aktueller Stand der eRechnung in D365 for Finance (Deutschland)

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 umgeschlüsselt (analog dem UBL-Export, siehe auch Austrian Peppol-UBL e-invoice). 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. Nach der Testphase wechselt Ihr Konto automatisch auf das kostenlose Abonnement, das jeden Monat am 1. Tag 50 Gratis-Credits bereitstellt. Sie bleiben in diesem kostenlosen Abonnement, bis Sie entweder zu einem kostenpflichtigen Plan wechseln oder Ihr Konto kündigen; 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 weitergeleitet.

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. 

WIP in der Bilanz

WIP in der Bilanz

WIP in der Bilanz

WIP in der Bilanz

WIP in der Bilanz

WIP in der Bilanz

WIP in der Bilanz

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.