Dynamics 365 Finance 10.0.49: Automatic Clearing of Bridged Payments During Bank Reconciliation

Capability overview

Dynamics 365 Finance 10.0.49, planned for September 2026, introduces a new Cash and bank management capability for clearing bridged payment transactions through the bank reconciliation framework. Microsoft classifies the feature as administrator-controlled, so it should be treated as an optional process change requiring deliberate activation and validation.

A bridged payment normally uses an interim ledger account between payment posting and confirmation that the amount has moved through the bank. This avoids posting directly to the final bank balance before the transaction is represented on the bank statement.

The simplified accounting flow is typically:

1. A payment is generated and posted.
2. The payment amount is recorded against a bridge or clearing account.
3. The transaction appears on the bank statement.
4. Reconciliation confirms the bank movement.
5. The interim balance is cleared against the bank account.

The new capability brings the clearing step into the bank reconciliation process for supported bridged transactions. The practical objective is to reduce the need for a separate manual operation after the bank statement has already provided evidence that the payment was processed.

What changes in 10.0.49

Before this enhancement, bank reconciliation and bridge-account clearing could represent two related but operationally separate tasks. A bank transaction might be successfully matched or reconciled while the corresponding bridge transaction still required additional processing.

This separation creates an avoidable gap:

• The bank statement confirms that the payment was processed.
• The reconciliation status may be complete.
• The bridge account can nevertheless retain an open or uncleared amount.
• Finance users must identify and clear that amount through another step.

Version 10.0.49 is intended to connect these activities more closely. For transactions within the supported scope, reconciliation can also perform the accounting action required to clear the bridge.

The improvement is not simply fewer clicks. It aligns the operational evidence from the bank with the related ledger update. This should make the bank reconciliation result more complete and reduce the period during which temporary balances remain on bridge accounts.

Microsoft's short release description does not explain several important details, including:

• Which reconciliation matching result initiates clearing.
• Whether the capability applies to both modern and advanced bank reconciliation scenarios.
• Which customer or vendor payment methods are eligible.
• How partial payments, grouped statement lines or payment reversals are handled.
• Whether clearing occurs immediately during matching or only when reconciliation is finalized.
• How cross-company accounting entries are generated for centralized payments.

These points should be documented as assumptions during solution design and confirmed through sandbox testing rather than inferred from the feature name.

Why this is an improvement

Less manual bridge-account clean-up

Manual clearing is repetitive and can be difficult to monitor when payment volumes are high. If reconciliation can clear the related interim entry, users no longer need to revisit transactions that have already been confirmed by the bank statement.

Better alignment between subledger, bank and ledger processing

A reconciled statement line and an uncleared bridge balance tell different operational stories. Completing both actions within one controlled process reduces timing differences between the bank reconciliation records and the general ledger.

Lower risk around period-end activities

Bridge accounts are commonly reviewed during daily controls and month-end closing. Old balances may indicate failed payments, missing statement transactions, incorrect setup or an incomplete clearing process.

Automatic clearing should allow reviewers to focus on genuine exceptions rather than transactions waiting for a routine follow-up step. This does not remove the need to reconcile bridge accounts, but it should reduce the volume of expected timing items.

Improved handling of centralized payment structures

Centralized payments add another dimension because the legal entity paying the bank may differ from the legal entity carrying the original payable. If the feature indeed targets centralized vendor payments, integrating bridge clearing with reconciliation could remove a particularly awkward cross-company clean-up activity.

The exact legal-entity posting behavior is not specified in the release summary. It must therefore be verified with the organization's actual centralized payment setup, including due-to and due-from accounts.

Who is affected

Business roles

The following roles should assess the change:

• Bank accountants and treasury users, because their reconciliation work may produce additional accounting entries or status changes.
• Accounts payable teams, if the scope includes centralized vendor payments.
• Accounts receivable teams, if the feature name accurately indicates customer payment scenarios.
• General ledger accountants, because bridge-account balances and period-end controls will change.
• Finance solution owners and system administrators, because activation is controlled and requires coordinated deployment.
• Internal control and audit teams, where bridge clearing is a documented control or requires separate approval.

Processes

The capability may affect:

• Electronic payment generation and posting.
• Centralized payment processing.
• Bank statement import, including ISO 20022 statement files.
• Automatic and manual transaction matching.
• Bank reconciliation finalization.
• Bridge-account reconciliation.
• Payment reversal and rejection handling.
• Month-end bank and cash controls.

The feature does not appear to change the ISO 20022 file format itself. Its relevance to ISO 20022 projects is downstream: imported statement transactions provide the bank-side information used by the reconciliation process.

Legal entities

Organizations should pay particular attention when:

• One legal entity operates the bank account for other legal entities.
• Payment journals use bridging in some companies but not others.
• Bridge accounts differ by bank, currency or payment method.
• Reconciliation is performed centrally for multiple companies.
• Intercompany accounting is generated by centralized payments.

Activation should not be assumed to have identical consequences in every legal entity. Scope the rollout by payment process and bank account, even if the feature switch itself is environment-wide.

What to do before the update

1. Document the current process

Record how bridged transactions are cleared today. Identify the journals, batch jobs, inquiries and manual steps involved. Establish who owns unresolved bridge balances and how frequently they are reviewed.

This baseline is needed to determine whether the new feature genuinely removes a step or merely moves it into reconciliation.

2. Inventory relevant configuration

Review at least the following areas:

• Bank accounts included in automated reconciliation.
• Payment methods configured to use bridging.
• Bridge and bank ledger accounts.
• Centralized payment relationships between legal entities.
• Intercompany posting profiles.
• Reconciliation matching rules.
• Posting and approval controls for bank reconciliation.

Do not change production configuration solely on the basis of the release note. First reproduce the current setup in an updated sandbox.

3. Clean up existing exceptions

Obtain a list of open bridge-account items before activation. Separate valid timing differences from old or unexplained balances.

A clean baseline makes it easier to determine which entries were produced or cleared by the new behavior. It also prevents historical exceptions from being mistaken for upgrade defects.

4. Define the expected accounting entries

For each test scenario, write down the expected vouchers before execution. Include:

• Payment posting.
• Bridge-account posting.
• Bank-side posting.
• Clearing entry.
• Intercompany entries, where applicable.
• Reversal entries for rejected or cancelled payments.

This is especially important when the paying company and invoice company differ.

Sandbox test plan

Activate the feature in a representative 10.0.49 sandbox and test complete business flows rather than isolated reconciliation screens.

Recommended scenarios include:

1. A single bridged payment matched to one bank statement line.
2. Multiple payments represented by one statement amount.
3. A payment with bank fees or an amount difference.
4. A partial or split match.
5. An unmatched bank statement transaction.
6. A payment reversal before reconciliation.
7. A payment rejection after the payment journal is posted.
8. A foreign-currency payment with an exchange-rate difference.
9. A centralized payment involving two legal entities.
10. Reprocessing or undoing a completed reconciliation, where supported.

For every scenario, verify:

• The bank transaction and reconciliation status.
• The payment transaction status.
• The bridge-account balance and dimensions.
• The bank ledger balance.
• Voucher numbers and posting dates.
• Intercompany balances.
• Whether duplicate clearing is prevented.
• Whether reversal processing restores the correct accounting position.

Actions after the update

Following sandbox approval, enable the capability through the organization's normal feature-management and change-control process. Activation should include named business owners, a deployment date and a rollback or containment plan.

During the first production reconciliation cycles:

• Compare cleared bridge entries with the reconciled statement lines.
• Review vouchers generated by the new process.
• Monitor bridge accounts daily.
• Investigate items that reconcile without clearing.
• Check for unexpected cross-company or financial-dimension postings.
• Retain evidence from the old and new processes for audit comparison.

Update operating procedures to explain which transactions are now cleared during reconciliation and which exceptions still require manual work. If a previous batch job or manual clearing task becomes redundant, retire it only after several successful reconciliation cycles.

Controls should also be revised carefully. Automation changes the execution of a control, but not necessarily its objective. A periodic review of bridge-account ageing remains useful because failed matching, unsupported transaction types and configuration errors can still leave residual balances.

Practitioner assessment

This is a focused improvement with the potential to remove a common gap between bank reconciliation and ledger clean-up. Its value will be highest in environments with substantial bridged-payment volumes or centralized payment structures.

However, the terminology in the release information is not sufficiently precise to determine whether the first implementation applies to customer payments, centralized vendor payments or both. The correct implementation approach is therefore evidence-led: activate it in a sandbox, trace the resulting vouchers and validate every relevant legal-entity pattern before production deployment.

References

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