Companies will then be required to submit their payment orders in XML format based on the ISO 20022 standard. Specifically, the existing EBICS order type AZV will be replaced by the new order type AXZ, and the new data format for cross-border credit transfers will be pain.001.001.09 – an XML message in accordance with ISO 20022.
In this article, we explain what is changing, which systems are affected, what this means specifically for SAP systems, and what companies should do now to be prepared in time.
What is changing?
DTAZV (Datenträgeraustauschverfahren für den Auslandszahlungsverkehr) has so far been the standardized file transfer format used to process cross-border and foreign currency payments between corporate clients and banks. This legacy format – a plain text file with a limited field structure – is now being replaced by ISO 20022-based XML payment messages. The migration essentially affects two areas: the file format and the data content.
New format (AXZ instead of DTAZV): In the future, cross-border credit transfers must be submitted using the XML format pain.001.001.09 with the EBICS order type AXZ. The old DTAZV format will be no longer be supported. For SEPA direct debits (including cross-border SEPA SDD), a migration to pain.008.001.08 is required. The German Banking Industry Committee (Deutsche Kreditwirtschaft) has mandated these new formats; banks already support them in parallel and will no longer accept the legacy DTAZV format from November 2026 onwards. During the transition period until November 2026, companies may still use the existing formats but should migrate to the new XML standards as early as possible.
Structured address data as a requirement:
One of the most significant changes concerns the way address information is provided. Previously, the name and address of the payer or beneficiary could be transmitted in free-text fields. Going forward, at least the city and country must be provided in separate structured fields. In November 2025, a ‘hybrid’ address structure was introduced: while two lines of free text will still be permitted, the elements Town Name (city) and Country must be provided as structured data. This hybrid address structure is explicitly defined as a permanent ‘strategic option’ and should not be considered a transitional model.
From November 2026 onwards, unstructured address information will no longer be permitted – payment files in which the city or country is missing will be rejected by banks. Companies must therefore ensure that their master data is updated accordingly so that all relevant address fields are properly maintained by that time.
What other changes should be considered?
The new XML format also introduces several content-related changes:
- Sender party currency: The currency of the sender’s account is explicitly transmitted as a dedicated field, whereas in DTAZV the account currency was not provided as a separate data element.
- New charge codes: OUR/SHA/BEN are represented in ISO 20022 by the codes DEBT (Debtor pays), SHAR (Shared), and CRED (Creditor pays).
- UETR transaction reference: Each payment can be assigned a unique transaction reference. For the first time, this enables end-to-end tracking of international payments – a major benefit for transparency and compliance.
What does the migration mean for SAP systems?
For SAP Business One users, SAP plans - according to OSS Note 3716789 - to provide a software update by August 31, 2026, which will technically remove the existing DTAZV format and replace it with a new format. Until that point, the DTAZV format will remain fully usable.
For SAP ERP, S/4HANA On-Premise, and Private Cloud, OSS updates may need to be implemented depending on the release. In S/4HANA Public Cloud, the formats are already available. If these have already been applied or are not required, the DMEE tree CGI_XML_CT_V9 or the payment format DE_CGI_XML_CT_V9 for pain.001.001.09 can generally already be used.
Further details can be found in the following OSS Notes:
- Note 2784858 – Collective information note: CGI_CT/CGI_CT_V9 and CGI_DD/CGI_DD_V8 based on DMEEX (current mappings for pain.001.001.09 and pain.008.001.08; replaces 2253571 as of S4CORE 102).
- Note 2253571 – Collective information note: DMEE formats CGI_XML_CT/CGI_XML_DD including CGI_XML_CT_V9 (pain.001.001.09) and CGI_XML_DD_V8 (pain.008.001.08); applicable to ERP and older S/4 releases and replaced in S/4HANA On-Premise by the DMEEX formats according to Note 2784858.
1. Configuration of the new payment format
In SAP, payment media are typically generated using the Payment Medium Workbench and the customizing settings for the payment program.
2. Adjust EBICS configuration
For all systems using EBICS-based bank communication, the EBICS order type for cross-border payments must be updated in addition to the format migration.
3. Master data check in SAP
Vendor and customer master data should be reviewed to ensure that city and country are fully maintained in the address fields. In many legacy data records, country codes are missing for domestic recipients, or city and postal code are combined in a single field. Such data quality issues must be resolved. From November 2026 onwards, a single missing city entry may result in the rejection of the entire payment file.
4. Adjust bank connections and perform testing
Contact your house banks at an early stage. Ask them to confirm from when AXZ files will be accepted and how testing can be carried out. Many banks already offer the option to submit test payments in the pain.001.001.09 format. Take advantage of these options: run internal test cycles and send test files to the bank or validate them using the tools provided. This ensures that your system is correctly configured and that the bank can process the files.
We recommend starting the migration now. We would be happy to support you throughout the process.
Conclusion
The discontinuation of the DTAZV format as of November 1, 2026, is mandatory for the German Banking Industry Committee. An extension of the deadline is not planned. Companies that start the migration too late risk payment delays and, in the worst case, immediate impacts on liquidity. In practice, master data cleansing and coordination with house banks are typically the most time-consuming steps - and precisely the ones most often underestimated.
