Dynamics Community Forum Thread Details

Generate a customer payment journal using matching rule on Customer Bank Account / IBAN

Has anyone successfully made use of the Modern Bank reconciliation matching rule functionality? Specifically to generate customer payment journals (unallocated/unsettled) using the matching rule functionality (Cash application in advanced bank reconciliation - Finance | Dynamics 365 | Microsoft Learn):

Complete cash application by using matching rules > Generate customer payments > Automatic customer account matching

If this parameter is turned on, the rule tries to match International Bank Account Number (IBAN) and bank account number fields in customer master data with the information on bank statement lines. If matching is successful, the relevant customer account is used to post the customer payment journal.

Our testing has failed when trying to only use Customer Bank Account and UK Sort Codes (routing numbers and routing number type=SC). We are wondering if the matching rule will ONLY work if the use the IBAN to match? In D365 we do not see the IBAN on our bank statements for domestic customer receipts in our GBP account. We do (sort of) see the IBAN information for EURO receipts / bank account, but this is split across the 'Related Bank' and 'Trading Party' columns in the imported bank statement.

Do we need to specifically seek out / build the 'IBAN' field in our iso:20022 bank statement mapping into D365, so we can get this matching rule to work? Or would this be an issue derived from the iso:20022 bank statement format we are receiving from JPM? This information seems to be derived from the field "FinInstnId" in our JPM bank statements.

Categories:

Dynamics 365 Finance

Hi PC-16021458-0,

1) Issue
- Modern Bank Reconciliation matching rule fails to generate customer payment journals based on Customer Bank Account or Sort Code
- Matching rule does not resolve customer automatically during cash application
- IBAN is not present or not consistently mapped in domestic GBP bank statements
- EUR receipts show IBAN only partially or split across multiple fields
- Uncertainty whether IBAN is mandatory for matching rule functionality

2) Reason
- The issue is caused by the design of the "Automatic customer account matching" functionality in Advanced Bank Reconciliation
- The matching logic is primarily based on IBAN and bank account number matching against customer master data
- According to Microsoft documentation, the system attempts to match IBAN or bank account information from the bank statement line with customer bank accounts to identify the customer automatically
- This leads to a failure when IBAN is not available or not correctly mapped into D365
- Local identifiers such as UK Sort Code are not reliably evaluated by the standard matching engine as standalone keys
- In ISO 20022 bank statement files, IBAN may exist in structured nodes but is not automatically usable unless correctly mapped into the D365 bank statement model
- This can happen because imported data (e.g. JPM format) splits IBAN across elements such as Related Bank or Trading Party instead of mapping directly to the IBAN field

3) Resolution
IBAN dependency clarification
- The matching rule is strongly dependent on IBAN for accurate automatic matching
- Without IBAN the standard process is limited and may not work for domestic payments

Step 1 Validate bank statement mapping
- Review Electronic Reporting (ER) configuration for ISO 20022 import
- Ensure IBAN is extracted and mapped into:
- Bank statement line IBAN field
- Customer bank account IBAN field
- Check structured XML nodes such as:
- Debtor/Creditor account
- IBAN node
- FinInstnId (if applicable)

Step 2 Update ER format
- Extend mapping logic to assemble IBAN if split across fields
- Ensure correct field mapping in D365 so matching engine can consume it

Step 3 Validate customer master
- Ensure IBAN is populated and formatted consistently in customer bank accounts
- Remove formatting inconsistencies (spaces, prefixes)

Step 4 Re-test matching
- Re-import bank statement
- Execute:
- Generate customer payments
- Automatic customer account matching

Step 5 Alternative approach (if IBAN unavailable)
- Extend matching logic via customization:
- Use Sort Code + Account Number as composite key
- Or implement custom matching rules using X++
- Or use reference-based matching (invoice number, payment reference)

Step 6 Source system validation
- Confirm with bank (e.g. JPM) whether IBAN is included in domestic statements
- If not, request enriched statement format with IBAN populated
- Validate CAMT.053 or CAMT.054 structure for IBAN availability

Key takeaway
- Standard Advanced Bank Reconciliation matching rules rely heavily on IBAN-based matching
- Without correct IBAN mapping in ER, automatic customer matching will not function reliably
- Either IBAN must be correctly surfaced in the import or custom matching logic must be implemented

For a more detailed answer, please provide more information.

Rg,

Alexander

*Due to the complex and different possibilities of deploying Dynamics 365 I highly recommend not to setup the application without some expert/partner or support. (For more information contact me under anassl@inno-solutions.info or visit www.inno-solutions.de)

*The Information comes directly from the manufacturer or provider and are validated (not guaranteed) up to date of creation of the posting.

References: