ISO 20022 & SAP S/4HANA: The Complete Practical Guide for FI Consultants

By November 2026 at the latest, the use of many still-widespread payment formats will end. Companies still using MT940, DTAZV, or older pain versions will no longer be able to submit their payments. For SAP FI consultants this means: migration to ISO 20022 is not an optional upgrade – it is a mandatory project.

1. What Is ISO 20022?

The official name is UNIFI – Universal Financial Industry Message Scheme. Developed by the International Organization for Standardization (ISO) under technical committee ISO TC68, it covers not only payments but also securities, foreign exchange, and cards. Messages are transmitted in XML – a technology that every modern ERP system can process cleanly.

Three Central Improvements Over Legacy Formats

• Richer data: Structured fields for purpose, address, and regulatory data – no more 35-character limit
• End-to-end tracking: Each transaction receives a unique UETR traceable across all involved banks
• Higher STP rate: Structured data enables more straight-through processing, fewer manual interventions

2. Message Types: pain & camt

pain Messages (outgoing)

camt Messages (incoming)

3. Structured Addresses – The Underestimated Obligation

One of the most significant content elements is the obligation for structured address transmission. What was previously allowed as free text must now be divided into dedicated XML fields.

⚠️ Mandatory fields from November 2026: TwnNm (city) and Ctry (country) must be present as dedicated data elements. Payments without these fields will be rejected by clearing.

4. Timeline: Deadlines for Germany & SWIFT

🚨 No buffer! Unlike the SEPA introduction, there is no extended parallel phase this time. Payments submitted in legacy format after 22 November 2026 will be rejected.

5. ISO 20022 in SAP S/4HANA

The migration touches four interconnected areas:

1. Outgoing payments – DMEEX, format tree pain.001.001.09, FBZP, F110
2. Account statement processing – camt.053/052, XSLT transformation, GVC → BTC mapping
3. Master data – Business Partner, structured addresses, IBAN quality
4. Status feedback – pain.002.001.10, Bank Communication Management (BCM)

5a – From DMEE to DMEEX

The DMEE (Data Medium Exchange Engine, transaction DMEE) was the previous tool for maintaining payment carrier format trees. In SAP S/4HANA from release OP 1709 it was supplemented by DMEEX.

⚠️ Important: SAP is deprecating transaction DMEE in upcoming S/4HANA releases. SAP provides the predefined format tree CGI_CT_V9 (via SAP Note 2784858) as the template for pain.001.001.09.

5b – Payment Customizing: FBZP & F110

5c – Electronic Account Statement: camt Instead of MT940

The most significant content change: the three-digit GVC code (e.g. 051 for credit transfer) is replaced by the alphabetical ISO Bank Transaction Code (BTC). All posting rules built on GVC codes must be adapted.

5d – Master Data: Business Partner

Ensure TwnNm (city) and Ctry (country) are maintained for all active vendors and customers. Only activate the new format tree after complete data cleansing.

6. Customizing Roadmap: Step by Step

1. System analysis & SAP Notes – Apply Notes 2784858, 2881354, 2253571; check DMEEX availability
2. Create/adapt format tree (DMEEX) – Copy CGI_XML_CT_V9; transfer customer-specific extensions
3. Adapt payment programme (FBZP) – Assign format tree; switch DTAZV to AXZ
4. Convert account statement processing – XSLT transformation for camt.053 V08; switch GVC to BTC in posting rules
5. Cleanse master data – Mass evaluation of all BPs for address completeness
6. Test & Go-live preparation – Generate test payments; process pain.002; read camt.053 V08

7. Typical Pitfalls & How to Avoid Them

• Format tree activated before master data cleansed: Payments rejected because TwnNm or Ctry missing → always cleanse master data first
• Old BAdI no longer fires: Customer BAdI implementations from DMEE don't apply automatically to CGI_XML_CT_V9 → re-register in new BAdI
• DK standard vs. CGI standard in XSLT: SAP's XSLT transformation is CGI-based; German banks deliver DK standard → test with real bank file
• GVC code mapping in posting rules forgotten: camt.053 delivers BTC codes, not GVC → create complete GVC-to-BTC mapping
• Bank tests started too late: Banks have limited test capacities → start as early as possible

Conclusion

ISO 20022 is not a pure compliance project – it is a modernisation of the entire payment infrastructure. Those who approach it in a structured way gain cleaner data, higher automation, and significantly more transparency in payment processing. The critical deadlines are set, the tools in S/4HANA are available. Now is the right time to act.

Summary: Hard cut November 2026 | Target format payments: pain.001.001.09 | Target format statements: camt.053.001.08 | SAP core note: 2784858 | New transaction: DMEEX instead of DMEE | Critical master data: TwnNm + Ctry

Would You Like Support with Your ISO 20022 Project?

I'm happy to support you – whether as a sparring partner, with concrete system implementation, or with targeted training for your team. From analysis to go-live.

Request collaboration now →