Dynamics 365 Finance 10.0.48: IN Operator for One-to-One Bank Reconciliation Matching

Capability overview

Dynamics 365 Finance 10.0.48, planned for June 2026, introduces an additional comparison operator for bank reconciliation matching rules. After the capability is enabled through Feature management, the IN operator can be used in statement and document matching logic for one-to-one matching.

In practical terms, an IN condition normally tests whether a value belongs to a defined set. Instead of expressing several acceptable values through separate conditions or separate rules, the matching setup can potentially group them into one criterion.

For example, a reconciliation design might need to treat several transaction codes as equivalent for matching purposes:

• Bank transfer
• Domestic payment
• Electronic payment
• Internal transfer

Conceptually, the condition changes from multiple equality tests such as:

Transaction code = A
OR Transaction code = B
OR Transaction code = C

to a set-based condition:

Transaction code IN (A, B, C)

This example illustrates the expected purpose of an IN operator. It does not prescribe the actual user-interface syntax in version 10.0.48.

What changes for reconciliation design

Before this enhancement, a rule requiring several acceptable values could become difficult to express cleanly. Depending on the existing rule framework and the fields involved, consultants might have needed to use multiple rule lines, construct alternative criteria, or maintain separate matching rules with largely identical settings.

That approach creates several practical problems:

• The same matching intent is distributed across multiple configuration records.
• Adding or removing an accepted value requires changes in more than one place.
• Similar rules can overlap and produce unexpected candidates.
• Rule order becomes more significant and harder to review.
• Testing must cover several nearly identical configuration paths.

The IN operator provides a more direct way to describe the business requirement: the relevant statement or document value must be one of several approved values.

The main improvement is therefore not a new reconciliation process. It is a more expressive matching condition within the existing process. A well-designed set-based condition should make rules shorter, easier to explain, and less prone to configuration duplication.

Scope: one statement line and one document

The capability is limited to one-to-one matching. This means the relevant scenario is a single bank statement line being evaluated against a single Finance document or transaction candidate.

It should not be assumed to support scenarios such as:

• One statement line matched to several documents
• Several statement lines matched to one document
• Many-to-many reconciliation
• Aggregated settlement or batch matching
• Tolerance or amount-allocation logic outside the existing one-to-one framework

The operator expands how a condition is evaluated; it does not remove the one-to-one cardinality restriction.

Example use cases

The feature may be useful where an imported bank statement contains a controlled range of values that should be treated alike.

Possible examples include:

Multiple external transaction codes

A bank may use several proprietary transaction codes for payments that follow the same matching logic. A single rule could list the accepted codes instead of repeating the rule for every code.

Several payment references or classifications

Where the matching framework exposes an appropriate reference or classification field, a company might accept several known values as part of the same rule.

Bank-specific variations

Two banks may represent an equivalent business transaction with different codes. If the same matching rule applies to both accounts, a set of accepted values could reduce duplicated setup.

These examples are design possibilities, not confirmation that every mentioned field supports IN in 10.0.48. Available fields and value-entry controls must be checked in the application.

For ISO 20022 imports, the feature can be relevant when values derived from CAMT messages are available to reconciliation rules. However, it does not change the CAMT import format, XML mapping, transformation, or bank statement parsing. It only affects matching after statement data is available in Finance.

Who is affected

Business roles

The main affected roles are:

• Cash and bank management consultants
• Treasury and banking key users
• Accountants responsible for bank reconciliation
• Solution architects defining automated matching
• Test managers maintaining banking regression scenarios
• Support teams investigating unmatched statement lines

End users performing manual reconciliation may see an indirect benefit through a higher or more predictable automatic matching rate. Their daily process should not otherwise change solely because this feature is enabled.

Processes

Review the feature where the organization uses:

• Advanced or rule-based bank reconciliation
• Automated statement-to-document matching
• Bank-specific transaction classifications
• Repeated matching rules that differ only by an accepted field value
• Imported electronic bank statements, including ISO 20022 CAMT files

Legal entities and bank accounts

Feature activation is managed at environment level through Feature management. Matching configurations and bank reconciliation processes may nevertheless differ by legal entity, bank account, or bank group.

Therefore, do not evaluate the impact using only one company if several legal entities maintain separate rules. Include representative entities with different banks, currencies, statement formats, and reconciliation volumes.

Preparation before updating

1. Inventory the existing rules

Export or document the current statement and document matching setup. Identify rules that:

• Repeat the same logic for different values
• Depend on several alternative codes
• Have overlapping selection criteria
• Are sensitive to execution order
• Generate excessive unmatched or ambiguous results

Keep screenshots or configuration exports so that results can be compared after the update.

2. Establish a baseline

Select completed statements that represent normal and exceptional processing. Record:

• Number of statement lines
• Automatically matched lines
• Unmatched lines
• Incorrect or manually reversed matches
• Rules responsible for the matches
• Processing duration, if performance is relevant

A baseline is necessary to determine whether a consolidated IN condition preserves the existing outcome.

3. Prepare edge-case data

Include values that are:

• Present in the configured set
• Not present in the set
• Blank or null, where possible
• Different only by case or spacing
• Similar but not identical
• Associated with duplicate candidate documents

The release description does not define comparison rules for case sensitivity, whitespace, blank values, or localization. Treat all of these as assumptions to verify.

Activation and sandbox testing

The capability requires activation through Feature management.

Search for the feature by its Microsoft name, Enable In operator for one-to-one matching, review any displayed dependencies, and enable it first in a non-production environment.

Recommended validation steps are:

1. Confirm that the operator appears only in the expected matching setup.
2. Determine which statement and document fields allow it.
3. Check how multiple values are entered and stored.
4. Reproduce the outcome of an existing multi-value rule without changing other criteria.
5. Test both positive and negative values.
6. Confirm that exactly one statement line is matched to one document.
7. Test ambiguous cases where multiple documents satisfy the same rule.
8. Review rule priority and execution order.
9. Compare match counts with the pre-update baseline.
10. Run regression tests for rules that do not use IN.

Actions after the update

After deployment, activate the feature according to the organization’s release controls. Then introduce IN conditions gradually rather than rewriting all rules at once.

A controlled approach is to:

1. Start with one bank account and a rule that has clear expected results.
2. Retain the original rule definition for rollback.
3. Process a representative statement in a test or controlled operational cycle.
4. Compare automatic and manual matching outcomes.
5. Review unmatched and incorrectly matched lines with the banking team.
6. Extend the pattern only after the results are stable.

Update configuration documentation to record the accepted values, their business meaning, the responsible owner, and the reason they belong in the same set. A compact rule is easier to read, but a long unexplained value list can still become a maintenance problem.

Practitioner assessment

This is a targeted configuration enhancement rather than a major functional change. Its value is highest in reconciliation designs that currently duplicate rules to represent alternative bank values.

The expected benefits are simpler rule maintenance, clearer matching intent, and fewer overlapping configurations. The principal implementation risk is assuming details that are not covered by the release description—particularly supported fields, comparison semantics, and behaviour when more than one candidate qualifies.

For that reason, the feature should be treated as a rule-design improvement that requires focused sandbox validation, not as a reason to bypass normal bank reconciliation regression testing.

References

• What’s new or changed in Dynamics 365 Finance 10.0.48