Dynamics 365 Finance 10.0.49: Preview Automatic Bank Reconciliation Matches

Capability overview

Dynamics 365 Finance version 10.0.49, planned for September 2026, adds a preview capability to automatic bank reconciliation. The feature is controlled by an administrator.

The practical change is the introduction of a checkpoint after the matching rules have evaluated the bank and Finance transactions but before their proposed results take effect. A user can inspect the suggested matches and decide whether they are acceptable before continuing.

This separates two activities that are operationally different:

1. Running the matching logic to generate proposals.
2. Applying accepted proposals to the reconciliation.

For finance teams, that separation is important. An automatic rule can be technically valid while still producing a result that requires human judgement. Similar payment amounts, reused references, aggregated bank entries, fees, and timing differences can all create plausible but unsuitable matches.

What changes in the reconciliation process

Before this enhancement, the automatic process offered a less distinct review point between rule execution and the application of matching results. If a rule produced an inappropriate result, the accountant could have to identify and correct it after the reconciliation state had already been updated.

Version 10.0.49 changes the control model. The expected process becomes:

1. Import or create the bank statement information.
2. Run the configured automatic reconciliation rules.
3. Review the proposed matching results.
4. Approve acceptable results.
5. Continue with the processing that applies the reconciliation outcome.

The exact names and sequence of the actions in the user interface must be confirmed after the feature becomes available. In particular, Microsoft’s short description does not establish whether approval is performed for the entire result set, selected lines, or both.

The capability should not be confused with a redesign of the matching engine. There is no stated indication that version 10.0.49 changes how rules evaluate amounts, dates, references, or transaction types. The documented change concerns when users can review the outcome.

Why this is an improvement

Earlier detection of unsuitable matches

The main benefit is that exceptions can be identified before they affect the reconciliation. Correcting a proposal is generally simpler than reversing or undoing an applied result.

This is particularly useful where transactions are not uniquely identifiable. Examples include:

• Multiple customer receipts with the same amount.
• Regular supplier payments with similar references.
• Bank fees deducted from a settlement amount.
• One bank statement line covering several Finance transactions.
• Several bank entries corresponding to one ledger-side transaction.
• References truncated or reformatted by a bank.

A matching rule can return a result in these scenarios, but a bank accountant may still need to evaluate whether the pairing is economically correct.

Better operational control

The preview creates a natural control point in the daily or periodic reconciliation procedure. Organizations can require the responsible user to review the proposals before committing them.

This does not necessarily mean that Dynamics 365 Finance provides a formal maker-checker workflow for the feature. The term “approve” in the release description may refer to accepting proposed results rather than submitting them to another user through Workflow. That distinction must be tested.

Safer rule tuning

Matching rules often evolve as banks, payment references, and business processes change. A preview makes it safer to assess the effect of a modified rule on live-style data.

For example, a team may widen an allowed date difference to accommodate delayed bank value dates. The wider range may improve the match rate, but it may also increase ambiguous results. Reviewing the proposals before applying them gives the team evidence for deciding whether the rule is sufficiently precise.

Pain point removed

The feature addresses the cost of discovering a poor automatic match too late.

When matching results are applied without a clear intermediate review stage, users may need to:

• Search for incorrectly paired transactions.
• Remove or reverse reconciliation results where supported.
• Repeat part of the reconciliation.
• Explain changes during period-end review.
• Investigate why an unmatched item is no longer available for the correct bank line.

A preview does not eliminate incorrect proposals. It moves their detection to a safer point in the process. The matching rules still need appropriate criteria, and the user still needs enough information to judge the proposed result.

Who is affected

Roles

The following roles or responsibilities are most likely to be affected:

• Bank accountants and treasury operations users: They run automatic matching and review daily reconciliation results.
• Cash and bank management process owners: They define the operating procedure and exception handling requirements.
• Finance controllers: They may rely on the review checkpoint as part of period-end controls.
• Dynamics 365 Finance functional consultants: They configure matching rules, document the process, and design test cases.
• System administrators: They control feature activation and deployment timing.
• Internal or external auditors: They may need to understand whether preview acceptance represents an application control or only an operational review.

Security should be reviewed after activation. Do not assume that running matching, reviewing proposals, and approving results are represented by separate privileges until this has been confirmed in the target build.

Processes

The change is relevant to legal entities using automatic bank reconciliation. It has limited impact where reconciliation is entirely manual or performed outside Dynamics 365 Finance.

Processes that may require updated instructions include:

• Daily bank statement reconciliation.
• Month-end cash and bank close.
• Reconciliation exception management.
• Matching-rule maintenance.
• Evidence collection for financial controls.
• Support procedures for imported bank statements.

The capability is relevant to ISO 20022 statement imports, such as camt-based processes, but it should not be assumed to depend on ISO 20022. The release description does not state that it is limited to a particular statement format. Verify this with every statement format used by the organization.

Legal entities

Assess impact per legal entity rather than only at environment level. Legal entities can have different:

• Bank accounts and statement formats.
• Reconciliation volumes.
• Matching rules.
• Local control requirements.
• User assignments and segregation-of-duties policies.

Even if activation is environment-wide, the operational rollout may need to be phased by legal entity. The actual activation scope and whether additional setup is shared or company-specific must be verified in the sandbox.

What to do before the update

Document the current baseline

Before enabling the capability, record how automatic reconciliation currently behaves. Useful baseline measures include:

• Number of statement lines per bank account.
• Percentage matched automatically.
• Number of matches corrected manually.
• Common causes of false or ambiguous matches.
• Average processing time.
• Existing period-end control evidence.

Retain representative bank statements and corresponding Finance transactions for regression testing. Data should include straightforward matches as well as known exceptions.

Review matching rules

List the active rules and document their intended sequence and criteria. Pay particular attention to rules based on broad conditions such as amount-only matching or wide date tolerances.

The new preview should not be treated as a substitute for precise rules. A review step can catch errors, but an excessive number of ambiguous proposals will slow down reconciliation and reduce user confidence.

Prepare a sandbox test matrix

At minimum, test:

1. A unique one-to-one match.
2. Several possible transactions with the same amount.
3. A transaction outside the permitted date range.
4. One-to-many and many-to-one scenarios used by the business.
5. Bank charges and amount differences.
6. Previously reconciled transactions.
7. Rejected or unapproved proposals.
8. A rerun after changing a matching rule.
9. High-volume statement files.
10. Each supported bank statement format, including applicable ISO 20022 variants.

Also test concurrency if several users reconcile accounts at the same time. The release summary does not explain proposal locking, session persistence, or what happens if underlying transactions change during review.

What to do after the update

Activate under change control

Because activation is administrator-controlled, enable the feature first in a sandbox. Confirm the exact feature name, prerequisites, default state, and whether activation can be reversed.

Do not assume that a production administrator can disable the capability safely after users have processed preview results. Feature reversibility and data impact should be verified before deployment.

Validate the complete lifecycle

Test more than the preview screen. Follow each scenario through to its final accounting and reconciliation state, then confirm:

• The correct bank and Finance transactions are linked.
• Unapproved proposals remain available for later processing where expected.
• Rejected results do not prevent valid future matches.
• Posted vouchers, if any, are correct.
• Reconciliation balances remain consistent.
• Rerunning the rules does not create duplicate or misleading proposals.
• The result is visible in the expected inquiry and audit information.

Whether the preview itself creates durable audit evidence is not stated. If the control requires proof of who reviewed which lines and when, verify that the application records this information. Otherwise, a procedural or external evidence mechanism may still be necessary.

Update procedures and train users

Revise work instructions so that users understand the difference between generating proposals and applying results. Training should explain:

• Which proposals can be accepted without further investigation.
• Which conditions require supporting documentation.
• How rejected proposals are handled.
• When a matching rule should be corrected rather than repeatedly overridden.
• Who owns unresolved reconciliation differences.

Monitor the first production cycles closely. Compare previewed, accepted, rejected, and manually corrected results with the pre-update baseline. This will show whether the new checkpoint improves control without adding disproportionate processing time.

Consultant assessment

This is a focused process-control improvement rather than a new reconciliation algorithm. Its value is highest in organizations that already use automatic matching but hesitate to broaden their rules because incorrect results are expensive to correct.

The feature should allow teams to use automation with a more deliberate review step. However, several implementation details remain open, including line-level approval, security separation, audit history, locking, and behavior after rejection. These details determine whether the capability is only a user convenience or can support a formal financial control.

The appropriate approach is therefore to activate it in a sandbox, test it with realistic bank data, and update reconciliation procedures only after the actual 10.0.49 behavior has been confirmed.

References

• Microsoft Learn: What’s new or changed in Dynamics 365 Finance 10.0.49