ISO 20022 payment automation for ERP: what it is, why it matters, and how to get there.

ISO 20022 is the messaging standard banks worldwide are converging on for payments and account information. It replaces a long tail of older national formats with a single XML-based vocabulary that every party in the chain (your ERP, the sending bank, the clearing scheme, the receiving bank) can speak. There are three message families that matter for corporates.

• pain.001, the customer credit transfer initiation. This is the file your ERP produces to instruct the bank to pay one or more suppliers, employees, or tax authorities.
• pain.002, the customer payment status report. The bank sends this back to tell you, per payment, whether it was accepted, rejected, or pending, and why.
• camt.053 (end-of-day) and camt.052 (intraday), the account statements that flow back so reconciliation can match incoming money to invoices automatically.

Two forces are turning this from a nice-to-have into a deadline. SWIFT's cross-border migration to ISO 20022 completes in November 2025, and the EU's instant payments regulation requires banks across the eurozone to send and receive SEPA Instant in ISO 20022 by October 2025. Older proprietary formats keep working at some banks, but the roadmap is one-directional: every bank is moving onto the standard, and every bank is publishing its own profile of it.

ERPs are very good at the parts they own. Dynamics 365 Finance, Business Central, SAP S/4 and the rest hold the supplier ledger, the approval workflow, the cash forecast, and the posting logic. They can produce a pain.001 file out of the box.

The gap opens the moment that file has to leave the building. Every bank publishes its own implementation guideline on top of ISO 20022. They disagree on which optional fields are mandatory, on character sets (some still reject "&" or "/"), on length caps for remittance information, on whether structured creditor references are required for domestic rails, on file naming conventions, on whether you wrap pain.001 inside an additional bank-side envelope, on the exact moment they send pain.002 back, and on the channel they expect you to use (EBICS, SFTP with a specific PGP setup, a bank-specific web service, or a managed pipe like Bank Connect in Denmark).

Most ERPs sidestep this by producing a generic file and leaving the last mile to you. So finance teams end up with one of three working arrangements: a manual export and portal upload per bank, a brittle in-house adapter that someone wrote two years ago and is now afraid to touch, or an aging legacy bank connector that nobody at the vendor wants to maintain. None of these scale to more than a handful of banks, and none of them recover gracefully when a bank quietly updates its schema.

The end state is simple, and worth describing concretely. Finance approves a payment run inside the ERP, the same way they do today. From that point on, nobody touches a file, logs into a bank portal, or reformats anything.

1. The ERP emits a canonical payment instruction. It does not need to know that one beneficiary is at Deutsche Bank in Germany and another is at OP in Finland.
2. A connectivity layer validates the instruction in three passes: against the ISO 20022 schema, against universal business rules (IBAN checksums, amounts, currencies, value dates), and against the receiving bank's specific profile.
3. It transforms the canonical instruction into the exact pain.001 dialect each bank requires, packages it for the bank's expected channel, signs and encrypts it, and delivers it.
4. The bank's pain.002 status report comes back the same way. Each payment in the original batch gets a status (accepted, rejected with a reason code, pending), and that status flows back into the ERP against the original payment record.
5. camt.053 and, where the bank offers it, camt.052 flow in on the same pipe so AR reconciliation runs the same day instead of the next.

The behavioural change inside finance is bigger than it sounds. Rejected payments are caught before they leave, not the morning after. Payment status is visible per transaction instead of per batch. Reconciliation is a continuous process, not a Monday morning project. The auditor sees an unbroken trail from invoice through approval through the bank's confirmation.

The right question is not "do you support Bank X" in isolation, but "do you support the ISO 20022 profile the banks I actually use, on the channel they require." The practical coverage spans Denmark, Germany, the Netherlands, Sweden, Norway, Finland, and the UK, including the long tail of smaller banks that hide behind shared service providers like BEC, SDC, and Bankdata in Denmark.

The full coverage facts lists ~290 bank profiles across ~21 countries and 21 payment rails. Country-level guides go deeper on the specific schema quirks and channels in each market:

• Danske Bank and Nordea for the Nordics.
• Deutsche Bank for EBICS-based connectivity in Germany.
• DNB for Norway and OP for Finland.
• HSBC for the UK and multi-country corporates.

Building bank connectivity in-house is possible. A capable integration team can stand up a single-bank EBICS adapter in a quarter. The trouble is not the first bank. It is bank number four, the schema update that lands on a Friday, the certificate rotation nobody documented, and the pain.002 reason code that means something different at one bank than at another.

The break-even sits around two to three banks and one schema migration cycle. Beyond that, the maintenance burden compounds and it stops being an integration project and becomes a small team's full-time job. Buying makes sense the moment connectivity stops being a differentiator for your business, which for almost every corporate is on day one.

Six questions cut through most vendor pitches.

1. Does it support your specific bank's profile? Not "ISO 20022", not "SEPA", but the exact pain.001 variant each bank you use will accept today. Ask for the bank list with profile versions, not a country map.
2. How does it integrate with your ERP? Native D365 or Business Central extensions are cheaper to operate than file-drop integrations. For SAP, look for clean API boundaries rather than middleware that lives inside the ERP itself.
3. Who maintains the bank side? When the bank changes its schema, who updates the connector, on what notice, and at what cost to you. The right answer is "the vendor, automatically, included".
4. Is it multi-bank or single-bank? Single-bank connectors lock you to a relationship. Multi-bank lets treasury negotiate without rebuilding plumbing.
5. What does implementation actually look like? Real implementations include a bank-side onboarding step (EBICS keys, web service certificates, test transactions). A vendor who skips this in the demo is hiding the hard part.
6. What is the audit and approval model? Maker-checker, role separation, append-only logs, and evidence your auditor can read without a translator.