Z4-Meldung an Bundesbank in D365 for Finance

The Z4-Meldung “Zahlungen im Außenwirtschaftsverkehr (abbreviated “AWV”) is a financial report that German companies must submit to the Deutsche Bundesbank as part of their external sector statistics. Companies are usually required to submit this report on a monthly basis, depending on the volume of transactions.

All German companies that engage in cross-border financial activities (e.g., loans, deposits, securities transactions) with a value above a specific threshold (currently €12500 per transaction) are required to submit this report. The worst part of it: not only transactions with non-EU countries must be reported, but inbound and outbound payments to EU countries as well. This is a nightmare in the tightly integrated EU economy.

Luckily, payments related to trade in goods (such as exports or imports) are not reported in the Z4-Meldung. These transactions are typically covered under other reporting mechanisms, such as the Intrastat for trade within the EU. Instead, the Z4-Meldung focuses on financial transactions unrelated to the direct exchange of goods e.g., loans, financial investments, and – most importantly – services. In particular, these transactions may be:

payments for services rendered for a foreign entity or paid to a foreign supplier,
for instance, freight costs
bank interests paid or received
cash discounts given to foreign customers or received from foreign suppliers
rebates received or paid
intercompany recharge to or from a foreign HQ or a subsidiary
VAT payments to a different EU tax authority.

The Z4 report has a simple XML structure following their proprietary “XMW” schema: XMW – Elektronisches Meldewesen im XML-Format. In the regular payment process, in- and outpayments are classified with a transaction type (BELEGART) of “1” or “2”, respectively. In every transaction the foreign country is listed (ISO2), along with the transaction description and the amount in tsd. Euros. The sub-type classifier “KENNZAHL” poses a significant challenge: there are ~1000 codes in total from “A” for airfare through “S” for services till “U” for the use of software. This list from hell is published here in an inconvenient Excel file: “Kennzahlenliste mit Belegarten”.

We are happy to share an Electronic Reporting configuration for the Z4 report in Dynamics 365 for Finance. Only the regular payment transactions (“DIKAPPOSTEN”) are supported, not shares or similar capital investments. To segregate payments by the highly detailed “KENNZAHL“, we suggest using the voucher prefix. For example, you may need to introduce different GL journal names for salary payments and commissions payments, both with distinct voucher number sequences. To avoid mistakes, we recommend separate payment methods, especially for goods and services, with every payment method to be processed in its own AP/AR payment journal.

Setup and use

Download the 3 configurations here: XMW_Model_Mapping_Format_v2
Install them in the following order: XMW Deutsche Bundesbank model -> XMW Mapping -> Z4 (format). Beware: the configurations are provided to you “AS IS” and with all faults and defects without warranty of any kind.
Select the Z4 configuration and open Application specific parameters / Setup. You may Import a rudimentary setup from the ZIP file.
With this setup you match patterns in the voucher of the bank transaction to the “KENNZAHL” codes. In some cases, you may decide to start looking for keywords in the payment description instead. This will require a slight modification of the formula in model/Messages/Message/Transactions/$ClassifierEnum. Alternatively, you may start probing for vendors or introduce a special vendor group with regards to the Z4 reporting; this is going to require a minor adjustment in the mapping and the format.
Set the status of the application specific parameters to Completed when ready.
Select the Z4 format in the Electronic reporting tree and hit Run.
The Firmennummer is the unique end-to-end ID issued by the Bundesbank at the registration. You may also set the Extranet-ID of the user, if known. The mandatory phone, e-mail and other contact information are extracted from the employee card of the current user (the user who is executing the report i.e. you).
With the Period date you select the reporting period (month). An empty period date means the current [session] month. Try to exclude bank transactions with regards to the trade of goods with the filter of Records to include, for example by the voucher number, if possible. You may also consider opening a different bank account for the regular intracommunity business. Again, try to separate payments of service, commissions etc. with distinct journals = voucher number.
Hit OK and execute the report.
You may also run the report in an unattended, batch mode. Configure an Electronic reporting destination such as an internal e-mail address or a SharePoint folder, schedule a monthly batch and keep the period date empty to support the rolling date. You can monitor the batch runs in Organisation administration > Electronic reporting > Electronic reporting archived jobs.

Result

The resulting file may look like this:

				
					<LIEFERUNG-AWZEL xmlns="http://www.bundesbank.de/xmw/2003-01-01" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bundesbank.de/xmw/2003-01-01/BbkXmwAwzel.xsd" version="1.0" erstellzeit="2024-09-27T08:30:33+02:00" stufe="Produktion" bereich="Statistik" dateireferenz="1">
    <ABSENDER>
        <FIRMENNR>00345678</FIRMENNR>
        <NAME>ER-Consult GmbH</NAME>
        <STRASSE>Franz Lehar-Gasse 18</STRASSE>
        <PLZ>7111</PLZ>
        <ORT>Parndorf</ORT>
        <LAND>AT</LAND>
        <KONTAKT>
            <ANREDE>Miss</ANREDE>
            <VORNAME>Julia</VORNAME>
            <ZUNAME>Funderburk</ZUNAME>
            <ABTEILUNG>Sales & Marketing</ABTEILUNG>
            <TELEFON>425-555-5053</TELEFON>
            <EMAIL>julia@contoso.com</EMAIL>
            <EXTRANET-ID>EXNTESTA</EXTRANET-ID>
        </KONTAKT>
    </ABSENDER>
    <KOMMENTAR>Und ich dachte, ich bleibe unter dem Radar...</KOMMENTAR>
    <MELDUNG erstellzeit="2024-09-27T08:30:34+02:00">
        <MELDEPFLICHTIGER>
            <FIRMENNR>00345678</FIRMENNR>
            <NAME>ER-Consult GmbH</NAME>
            <STRASSE>Franz Lehar-Gasse 18</STRASSE>
            <PLZ>7111</PLZ>
            <ORT>Parndorf</ORT>
            <LAND>AT</LAND>
            <KONTAKT>
                <ANREDE>Miss</ANREDE>
                <VORNAME>Julia</VORNAME>
                <ZUNAME>Funderburk</ZUNAME>
                <ABTEILUNG>Sales & Marketing</ABTEILUNG>
                <TELEFON>425-555-5053</TELEFON>
                <EMAIL>julia@contoso.com</EMAIL>
                <EXTRANET-ID>EXNTESTA</EXTRANET-ID>
            </KONTAKT>
        </MELDEPFLICHTIGER>
        <MELDETERMIN>2024-09</MELDETERMIN>
        <VDR_04>
            <DIKAPPOSTEN belegart="2" kennzahl="523" zahlungszweck="Provision 2024">
                <BETRAG land="CN" landname="China" betragsref="APPM000063">-18</BETRAG>
            </DIKAPPOSTEN>
        </VDR_04>
    </MELDUNG>
</LIEFERUNG-AWZEL>

Electronic reporting blog series

ZUGFeRD 2.2-2.3.x import for Dynamics 365 for Finance

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is an e-invoicing format combining a human-readable PDF/A-3 and an embedded XML file using the CII (Cross-Industry Invoice) syntax. The CII syntax may also be used in the xRechnung, which is a pure XML version of the German e-Invoice. From 2025, the ability to receive and process electronic invoices becomes mandatory for B2B transactions in Germany.

Microsoft’s current solution in Dynamics 365 for Finance provides support specifically for the UBL (Universal Business Language) format of the xRechnung: Import vendor electronic invoices – Finance | Dynamics 365 | Microsoft Learn. It enables the import of vendor invoices received in this format, mapping them as pending vendor invoices in D365. The invoice may be uploaded directly into the system or placed in a SharePoint folder for unattended processing.

We are happy to announce the release of the CII (Cross-Industry Invoice) dialect of the xRechnung / ZUGFeRD electronic invoice. This solution is implemented via Electronic Reporting (ER) configurations, which means it does not require any customisations and can be easily installed across all active versions of D365. It sits on top of the standard Invoice model v280, Vendor Invoice Mapping to Destination v280.46, side by side with the configuration Vendor Invoice Import ~~v280.7~~ v280.9 (state: Jan. 2025).

The functionality aligns with the standard Microsoft UBL import, utilizing the key data elements for processing and ensuring PO matching:

Header: Invoice ID, Invoice date, Due date, Vendor ID, Currency code, PO number, a header-level note and header attachments (in XML embedded MIME documents).
Lines: Line number, Item ID, Quantity, Sales unit of measure, Sales price, Discount (percentage discounts are converted to absolute values as the XML schema doesn’t support percentages), Price unit, Name, Description, and Line amount (excluding VAT).

The solution supports the ZUGFeRD 2.1, ZUGFeRD 2.2 or ZUGFeRD 2.3.x / Factur-X 1.0x with the profile EN16931 (also known as the “COMFORT” profile), XRECHNUNG profile or the EXTENDED profile. All three meet the tax law requirements and must be accepted by e-invoice recipients.

In contrary, ZUGFeRD 1.0 (easily recognised by the ~~<rsm:CrossIndustryDocument>~~ root node instead of the proper <rsm:CrossIndustryInvoice>) is no longer permitted in Germany when it comes to complying with the current legal requirements for electronic invoices, and therefore not supported. The same applies to the BASIC and BASIC WL profiles of the ZUGFeRD 2.x, announced by the <ram:GuidelineSpecifiedDocumentContextParameter> tag in the header.

Price

The solution is offered at a fixed fee per end customer / D365 tenant:

Version	Price	Deliverables	Notes
Light	€890	The Vendor invoice import CII Electronic Reporting configuration	This option does not require any X++ customisations or 3rd party software and can be installed and used right away.
Light+	€1200	Same as the Light version but with 5 hours of prepaid support and installation

You can acquire the solution on the official Microsoft AppSource marketplace: ZUGFeRD CII import (microsoft.com)

Setup and use

1. Follow the steps outlined in the Microsoft’s guidance Import vendor electronic invoices – Finance | Dynamics 365 | Microsoft Learn:
2. Import the same three configurations from Microsoft (Prerequisites);
3. Import the configuration Vendor invoice import CII.xml provided to you (menu Organisation administration > Electronic reporting > Configurations, button Exchange / Load from XML file);
4. Open Accounts payable > Setup > Accounts payable parameters; on the Electronic documents tab, select the imported Vendor invoice import CII format.
5. To run either one of the formats – UBL or CII – by choice, you may download and import a complimentary X++ extension with an additional parameter CII vendor invoice and an own menu item AP > Periodic tasks > Import vendor invoices CII underneath the standard one: VendImportInvoice_CII.axpp. In the batch execution mode this does not matter, because each of the formats becomes its own Electronic source with a set of SharePoint folders etc.
6. Prepare the master data: make sure the vendors are stored with proper VAT numbers in Dynamics 365 for Finance. They must have the proper country prefix “DE” and may not contain any spaces or special characters.
7. Make sure that the vendor’s external item ID mapping exists. Any Buyer Assigned ID (our item number) potentially sent by the vendor is neglected by the Microsoft’s mapping, and the conversion to the internal Item ID is always handled via the external item IDs. Under these conditions, the import works as expected and the PO lines may be matched.
8. Make sure that the units of measure are properly mapped to the UNECE Recommendation No. 20 list called “Codes for Units of Measure Used in International Trade”. For instance, the UNECE unit H87 should be mapped to PCS or STK, while C62 may become EA in our system; see also a longer list in https://erconsult.eu/de/blog/aktueller-stand-der-erechnung-in-d365-for-finance-deutschland/. You may need to introduce new units of measure, because the External codes table (ExtCodeValueTable in particular) assumes the 1:1 relation between the system units in D365 and the external unit codes.
9. Perform an interactive test upload by using the function Accounts payable > Periodic tasks > Import vendor invoices (or Import vendor invoices CII if you installed and configured the above extension from step 5). Beware: contrary to the UBL format, the CII (“COMFORT”) invoice does not include any line-by-line reference to the purchase order lines. Just the PO number is sent in the header. We assume that the numeration of the invoice lines mostly follows the PO lines numeration. If not, the standard mapping will fall back to the matching by the line purchase price.
10. Configure the batch mode with Electronic reporting sources i.e. SharePoint folders as outlined in the above Microsoft’s guidance: Import vendor electronic invoices – Configure the sources to import files in batch mode.
11. The standard UBL import from Microsoft and our CII import may be “daisy-chained”: set the error folder (Electronic reporting sources -> Settings / Document type for failed files) of the CII import the same as the input folder (Settings / Document type for input sources) for the UBL. If the XML starts with the <rsm:CrossIndustryInvoice> tag and features the <rsm:>, <ram:> namespaces, then it is a ZUGFeRD and it will be processed regularly by the CII import. If the XML starts with the <ubl:Invoice> or <ubl:CreditNote> tag and features <cbc:>, <cac:> namespaces, the CII parsing is going to fail early, and the XML file will be passed to the UBL parser, which takes it from there.

Cardinality of the external item number

In Dynamics 365 Supply Chain Management, the relationship between an external item number and an internal item ID is strictly 1:1. Each external ID points to exactly one internal product. This can cause issues when using Microsoft’s Vendor invoice mapping to destination, especially if Procurement categories were converted into service items during the vendor invoice import implementation. For example, spare parts that were once all booked under the procurement category “Maintenance and repair” now require separate released products, and every type of stationery once grouped under “Office supplies” must be split into multiple products. With mapping based on vendor external item numbers, this means creating a separate released product record for every sheet of paper or pen type.

To reduce this complexity, we recommend a small extension to the CustVendExternalItem table. Vendor invoice mapping to destination relies on the method CustVendExternalItem.getItemIdForInvoiceAccount_BR() , which could theoretically return the same internal item ID for different external IDs. However, the table’s unique index blocks multiple external numbers from being linked to the same product and vendor. Fortunately, Microsoft provided an extension point fieldIdsToHash() that allows you to add new fields into the uniqueness constraint, compressed into a hash. The code below extends this index with the Description field, so multiple vendor external item numbers can point to the same internal product.

				
					/// <summary>
/// Allow for internal ItemId 1 : N ExternalItemId
/// </summary>
[ExtensionOf(tableStr(CustVendExternalItem))]
final public class CustVendExternalItem_CII_Extension
{
    /// <summary>
    /// Add the Description to the list of fields that define the uniqueness of a record
    /// </summary>
    /// <returns>The set of field Ids.</returns>
    protected Set fieldIdsToHash()
    {
        Set hashFields = next fieldIdsToHash();

        if (this.ModuleType != ModuleInventPurchSalesVendCustGroup::Vend && 
            this.ModuleType != ModuleInventPurchSalesVendCustGroup::VendGroup)
        {
            return hashFields;
        }
        if (! this.Description)
        {
            return hashFields;
        }

        PurchParameters purchParameters = PurchParameters::find();
        if (purchParameters.ERModelMappingVendInvoice != 0 ||
            purchParameters.ERModelMappingVendInvoiceCII != 0)
        {
            hashFields.add(fieldNum(CustVendExternalItem, Description));
        }
        return hashFields;
    }

}

Use this code carefully: if you already rely on the Description field for other purposes, conflicts may arise. Records with an empty description will still behave as in the standard system and act as a fallback when matching external vendor numbers.

Useful links

End user license agreement: ZUGfERD_Import_EULA
You may download sample invoices here: ZUGFeRD 2.3 | Forum elektronische Rechnung Deutschland (ferd-net.de). To extract an XML attachment suitable for the import, you may use Adobe Reader or Adobe Acrobat.
Splitting ZUGFeRD hybrid invoices may be achieved with the Encodian’s PDF – Extract Attachments flow action for Power Automate. Once extracted, put the XML into the SharePoint input folder from step 10 above.
A rich interactive ZUGFeRD schema navigator is hosted here: EN 16931 – FacturX 1.03 – ZUGFeRD 2.0.1 – COMFORT (gefeg.com) , for the German ‘dialect’ refer to XRechnung_CII; v1.2.1; 28.06.2019

E-invoice and configurable business documents blog series

Austrian Peppol-UBL e-invoice

Austrian Peppol-UBL e-invoice

…in its version 304.13.25 does not work out of the box in Dynamics 365 for Finance, unfortunately. First and foremost, the public entity’s order number (the Customer requisition at the sales header order or in the project contract funding source details) is a must! As you specify the Customer requisition, a reference to the PO line number reference becomes mandatory, too. Yet this invoice line-level field is either malformed or missing. Moreover, Austria always requires an email address of the supplier (us) which is disabled or not working in all 4 standard ER formats. This can be the default e-mail address of the company in the legal entity settings.

As a good start, I recommend the excellent blog series E-Invoice in D365FO for Norway – Part 1 (Intro) – DynFOTech

The core configuration includes specifying the Endpoint ID of the supplier (ours) under Bank account / Routing number in the legal entity parameters, and providing the conversion of the units of measure into the UN standard, see the blog above. For every unit of measure there must be an own Code ‘axis’ to compensate for the well known design flaw in the external code values cardinality in Dynamics 365 for SCM:

Then, to finally make it work, you have to extend all 4 standard electronic formats from Microsoft and make at least the following changes:

Format changes

Issue/Deficiency	Path	Peppol Sales invoice	Peppol Project Invoice	Peppol Sales Credit Note	Peppol Project Credit Note
Mandatory Seller/ElectronicMail	cac:AccountingSupplierParty/cac:Party/cbc:ElectronicMail must be enabled all the way down, and mapped like this:	IF(Invoice.InvoiceBase.CompanyContact.ElectronicMail<>"", Invoice.InvoiceBase.CompanyContact.ElectronicMail, Invoice.InvoiceBase.CompanyInfo.Email)	IF(ProjectInvoice.InvoiceBase.Contact.ElectronicMail<>"", ProjectInvoice.InvoiceBase.Contact.ElectronicMail, ProjectInvoice.InvoiceBase.CompanyInfo.Email)	IF(Invoice.InvoiceBase.CompanyContact.ElectronicMail<>"", Invoice.InvoiceBase.CompanyContact.ElectronicMail, Invoice.InvoiceBase .CompanyInfo.Email)	IF(ProjectInvoice.InvoiceBase.Contact.ElectronicMail<>"", ProjectInvoice.InvoiceBase.Contact.ElectronicMail, ProjectInvoice.InvoiceBase.CompanyInfo.EMail)
Wrong OrderLineRef.ID, namely taken from ProjTransId = alphanumeric instead of numeric	Every of the five cac:InvoiceLine/cac:OrderLineReference/cbc:LineID must be unique and therefore enumerated. In the the Project Credit note the tags are missing completely and need to be added from scratch (5x)		('$ATLineNumberCollection'.Collect(1) + '$ATLineNumberCollection'.Sum(false))-1		('$ATLineNumberCollection'.Collect(1) + '$ATLineNumberCollection'.Sum(false))-1
Missing PaymentMeans, i.e. our (beneficiary) bank account	cac:PaymentMeans/cac:PayeeFinancialAccount/cbc:ID, schemeID and .../cac:FinancialInstitutionBranch/cbc:ID must be enabled all the way down and mapped		ProjectInvoice.InvoiceBase.CompanyInfo.BankAccount.IBAN ProjectInvoice.InvoiceBase.CompanyInfo.BankAccount.SWIFT
Missing OrderReference (their PO number)	cac:OrderReference/cbc:ID must be enabled			Invoice.PurchaseOrder
Missing or wrongly formatted line quantity; the sign is properly displayed in Denmark only 🙂	cac:CreditNoteLine/cbc:CreditedQuantity must be enabled			IF(OR(Invoice.InvoiceBase.CompanyInfo.PostalAddress.Country="DK", Invoice.InvoiceBase.CompanyInfo.PostalAddress.Country="AT"), -(@.LineBase.Quantity), @.LineBase.Quantity)	-(@.LineBase.Quantity)
The ActualDeliveryDate ("Leistungsdatum") refers to the date or the corrected invoice. The data is not really known and not properly mapped, here is a stub:	cac:Delivery/cbc:ActualDeliveryDate is completely missing and needs to be added first			Invoice.InvoiceBase. ShipmentDate	ProjectInvoice. InvoiceBase.VATRegisterDate
The root node bears no name, hence the format cannot be assigned a destination	Call the root node "XMLHeader", for example			X	X

With regards to the collection $ATLineNumberCollection for the enumeration of invoice lines, refer to respective blog below.

Useful links

Format erklären – e-Rechnung.gv.at (erechnung.gv.at)

Test-Upload – e-Rechnung.gv.at (erechnung.gv.at)

Monthly Archives: September 2024

Z4-Meldung an Bundesbank in D365 for Finance

Z4-Meldung an Bundesbank in D365 for Finance

Setup and use

Result

Electronic reporting blog series

ZUGFeRD 2.2-2.3.x import for Dynamics 365 for Finance

ZUGFeRD 2.2-2.3.x import for Dynamics 365 for Finance

Price

Setup and use

Cardinality of the external item number

Useful links

E-invoice and configurable business documents blog series

Austrian Peppol-UBL e-invoice

Austrian Peppol-UBL e-invoice

Format changes

Useful links

E-invoice and configurable business documents blog series