Prepare your ERP for an ISO 20022 implementation.

1. Assess what the ERP already supports.

Start with the installed ERP version, licensed modules, configured bank interfaces and current export or import routines. Ask the vendor or implementation partner which relevant capabilities are available in that exact setup. A missing configuration, an older mapping or incomplete source data can look like a missing product feature.

Describe the operational failure in terms the team can verify: a rejected file, repeated manual editing, statements that do not import or entries that cannot be reconciled. Measure the current process with a few representative examples. Record what the operator changes by hand and why.

Output: a short gap assessment separating native configuration, data correction and custom implementation work. Keep that distinction visible when estimating effort. Building an adapter makes sense when it solves a confirmed gap.

2. Choose one complete first workflow.

Define the initial company, account, currency, source export, bank channel and message version. Keep the first acceptance target small enough that the team can understand every input and outcome. Expand only after that workflow has been tested.

Payment preparation, bank submission, authorisation, status handling and statement reconciliation are different responsibilities. Write down which are included. A file-based integration can leave submission and authorisation in the customer's existing banking channel. Direct connectivity requires a separately agreed access model and operating responsibilities.

Output: an agreed workflow diagram and a clear list of included steps, exclusions and dependencies.

3. Document the source-data contract.

For each source field, record its meaning, type, requiredness, owner and transformation. Agree how amounts, dates, currencies, identifiers, account details and remittance information are represented. Define what happens when a required value is missing or an export changes shape.

Use stable references to connect the source record, generated instruction, response and later reconciliation where the available messages support that link. Define duplicate detection and correction behaviour explicitly. Do not rely on a filename as the only source of identity.

Output: a versioned mapping specification plus synthetic or anonymised fixtures. See our illustrative mapping and validation example for the kind of detail to make reviewable.

4. Freeze the bank requirements for the first release.

The ISO 20022 catalogue contains message families and multiple versions. The latest catalogue version is not automatically the version accepted by a particular bank channel. Record the exact guide, profile, schema and supported options agreed for the implementation.

Plan checks for structure, message constraints and bank requirements. The ISO Registration Authority's implementation checklist treats these as separate considerations. Keep the relevant rule sources attached to the project so that a later profile update can be assessed rather than guessed.

For statement imports, agree which references and transaction information the channel actually delivers. The EPC's customer reporting recommendations are useful context for relevant payment schemes, while actual samples establish what your importer needs to handle.

Output: a dated profile baseline, a named bank-testing dependency and a procedure for handling changes.

5. Define acceptance, exceptions and recovery.

Prepare a repeatable test set before declaring the happy path complete. Cover a valid export, missing required data, a duplicated instruction, a rejected record, an unclear submission outcome, an unmatched statement entry and a repeated statement import. Match the test set to the agreed scope.

Local validation, channel receipt, bank acceptance and reconciliation should have distinct evidence. Define the information an operator sees when a step fails. For an uncertain payment outcome, decide who investigates and what evidence is needed before any resubmission.

Run user acceptance with the people who prepare payments and resolve exceptions. Ask them to complete a correction and recovery task, not just observe a successful demonstration. Record the expected result, actual result and any unresolved limitation.

Output: a signed-off test record, reviewable exceptions and a controlled release decision. The pain.001 validation guide and camt.053 reconciliation guide expand the two sides of that test plan.

6. Make the workflow operable after handover.

Assign owners for the source export, bank profile, application configuration, authorisation and finance exceptions. Agree who handles a bank-specification change or an ERP upgrade. Document the supported versions, release process and the way issues should be reported.

Decide where files, logs and review records are retained and who can access them. Keep sensitive payment data out of ordinary support messages. Establish the agreed method for sharing diagnostic samples, and use synthetic or anonymised examples wherever they are sufficient.

Output: an operating guide, support boundaries and a change owner. NICOLLA.AI's ISO 20022 implementation service starts with this kind of bounded scope: a useful connection, documented decisions and evidence the team can work with.