Bridged Payment Clearing Just Became Mandatory in Dynamics 365 Finance

Finance professional reviewing a bank reconciliation dashboard showing bridged transaction clearing

A technical consultant reviewing the release notes for Dynamics 365 Finance and Operations version 10.0.49 will hit a line that looks routine until it isn’t: automatic clearing of bridged transactions during bank reconciliation, previously something you could turn on when you were ready, is now mandatory. Self-update customers got the build on September 11, and autoupdate production environments follow on October 2. Anywhere bridging accounts, methods of payment, or bank reconciliation parameters were never fully configured, that gap stops being a backlog item and becomes an active problem in the general ledger the moment the update lands.

This is the kind of change that rewards people who read upgrade notes closely and punishes people who don’t. Bridged payment clearing isn’t a new concept in F&O, Microsoft first shipped the automatic version of it a couple of release waves back, but plenty of environments left it disabled because the manual clearing process, while tedious, was at least predictable. Mandatory rollout removes that opt-out, so it’s worth walking through what bridging actually does, what specifically changes in 10.0.49, and what a technical team should check before the autoupdate window closes in early October.

Finance professional reviewing a bank reconciliation dashboard showing bridged transaction clearing

How Bridged Payment Clearing Actually Works

A bridging payment is a payment that posts to the general ledger in two steps instead of one. When a vendor or customer payment is created, the amount lands first in an intermediate bridging account rather than directly in the bank main account. It only moves to the real bank account once the transaction actually clears, which is confirmed during bank reconciliation. The gap between those two events, sometimes hours, sometimes several business days for checks or ACH batches, is exactly the timing problem bridging accounts exist to solve. Without one, your cash position either overstates funds that haven’t cleared yet or requires someone to manually track which payments are still in flight.

Centralized vendor payments add a second layer of complexity on top of that timing gap. When a shared services organization pays vendors out of one legal entity on behalf of several operating entities, the bridging transaction has to reconcile correctly across that entity boundary, not just across time. That’s the specific scenario the 10.0.49 changes target, and it’s also the scenario most likely to have been left half-configured, because centralized payment setups tend to get built by one team and handed off before every downstream parameter gets revisited.

Abstract illustration of payments flowing through a bridging account to a final bank account

What Changes in Version 10.0.49

Three related capabilities move from optional to mandatory in this release: automatic clearing of bridged transactions through advanced bank reconciliation, the extension of that clearing to centralized bridged vendor payments specifically, and use of the latest exchange rate when posting bank transactions. A fourth item, clearing bridged customer payments automatically on the accounts receivable side, reaches general availability this same month, giving Finance teams parity between the vendor and customer sides of bridging for the first time. Microsoft also shipped a preview capability to review automatic bank reconciliation matching results before they post, along with performance improvements to bridge transaction selection that matter once you’re running this at real transaction volume rather than in a sandbox.

The practical effect is that any environment relying on the older manual clearing workflow, where a user posts a general journal by hand after reconciliation, no longer has that as a supported path once the mandatory feature activates. If your bank reconciliation parameters, methods of payment, or bank account records were never updated to support automatic clearing, the reconciliation worksheet’s “mark as reconciled” action will attempt to post clearing journals against configuration that isn’t there, and that’s where things go sideways.

Configuring It Before the Update Lands

The setup itself isn’t complicated, but it touches three separate configuration surfaces, and missing any one of them is enough to cause posting failures. Start in Feature Management and confirm that “Automatic clearing of centralized bridged vendor payments during bank reconciliation” is actually enabled rather than assuming it inherited a default; feature flags introduced in earlier waves don’t always carry forward cleanly into new environments cloned from production.

Next, check the methods of payment used for the affected vendor and customer payment types. The “Bridging account by bank account” parameter determines which account the system treats as the offset for the bridging entry: turned on, it pulls the bridging account configured on the bank account itself, and turned off, it falls back to whatever bridging account is set on the method of payment record. Mixed configurations, where some payment methods rely on the bank account setting and others rely on their own override, are a common source of confusion during testing, so it’s worth documenting which methods use which approach rather than assuming consistency.

Bank account records need attention in two places. On the General tab, confirm the bridging account itself is populated and points to a valid, active main account. On the Reconciliation tab, the “Clear bridged transactions during reconciliation” toggle needs to be on; if it’s off, the system still requires someone to clear bridging payments through a manual general journal, which defeats the purpose of the mandatory automation and will look like the feature “isn’t working” when really it’s configured to not run. Finally, in Cash and Bank Management parameters, the clearing journal name on the Bank reconciliation tab has to point to a journal name that’s actually set up to accept these postings; a blank or misconfigured journal name is a quiet failure point that won’t surface until someone tries to reconcile a real bank statement.

Handling What Doesn’t Clear Automatically

Even with configuration correct, individual transactions will occasionally fail to clear automatically, usually because of a data issue on the underlying payment rather than a setup problem. Dynamics 365 Finance includes a periodic batch job for exactly this situation: Cash and Bank Management > Periodic Tasks > Clear Bridged Transactions lets you select a specific reconciliation ID and resubmit the clearing attempt as a batch process rather than trying to force it through the interactive reconciliation worksheet again. Building a habit of checking this job’s history after each reconciliation cycle, at least for the first few months after the mandatory rollout, will catch configuration gaps faster than waiting for a period-end variance to surface them.

The posting date logic is also worth knowing before someone asks why a clearing entry landed where it did: the system uses the earlier of the reconciliation cut-off date or the system date, not always the date the bank statement itself is dated. For teams doing month-end close under a tight calendar, that detail affects which period a clearing entry hits and is easy to get wrong if you’re reasoning from the statement date alone.

Testing Before the Autoupdate Window Closes

Self-update customers already have this behavior live as of September 11. Autoupdate customers have until October 2 before it arrives automatically, which is a narrow but workable window to validate configuration in a sandbox tier rather than discovering gaps in production. The most useful test isn’t a single sample transaction, it’s running a full reconciliation cycle against a realistic batch of centralized vendor payments, ideally spanning more than one legal entity, and confirming the clearing journals post to the correct centralized entity with the correct offset accounts. Teams that skip straight to production validation tend to find out about a missing bridging account setup during the first live bank statement import after go-live, which is a worse time to find out.

Extending the same test to accounts receivable is worth the extra hour, since the customer-side clearing feature is landing in the same window and shares enough of the underlying mechanics that a gap on one side often points to the same gap on the other.

Routeget Technologies has walked several clients through advanced bank reconciliation configuration changes like this one, and the pattern holds across most of them: the technical setup itself takes an afternoon, but tracking down which of dozens of payment methods and bank accounts were configured inconsistently over several years takes longer than the actual fix. Treating this mandatory change as a prompt to audit that configuration now, rather than after a reconciliation cycle breaks, is the difference between a routine update and an unplanned fire drill.

#BridgedPaymentClearing #BankReconciliation #AccountsPayable #DynamicsFinanceOps #CashManagement #ERPGovernance

Business Central CAMT.053 Migration: What Actually Needs to Change

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

A finance systems administrator at a mid-size manufacturer got an email last month from the company’s German house bank. Starting in the first week of the new quarter, the daily MT940 statement feed that had fed Business Central’s bank reconciliation for six years would stop. In its place: a CAMT.053 XML file, delivered on a different schedule, with a different structure. The email asked, almost as an afterthought, whether the ERP would “just work” with the new format. It was not a rhetorical question the bank expected an answer to. It was a notice.

That conversation is playing out across Business Central shops right now, and it is worth understanding why the Business Central CAMT.053 migration is arriving in 2026 specifically, what Business Central’s native tooling actually does with a CAMT.053 file, and where that tooling quietly runs out before a consultant finds out the hard way during a month-end close.

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

Why the Business Central CAMT.053 Migration Is Landing Now

The ISO 20022 migration has two distinct halves, and they are not moving on the same clock. The first half concluded in November 2025, when SWIFT ended coexistence for cross-border payment instructions. MT103, MT202, and the rest of the legacy payment message types stopped flowing in their original form; everything now moves as ISO 20022 MX, primarily pacs.008 and pacs.009. Institutions that kept sending legacy MT payment formats after that date found them auto-converted by SWIFT, with additional charges applied starting January 1, 2026.

The second half, covering statement and reporting formats rather than payment instructions, was deliberately left on a slower and less coordinated timeline. MT940 and MT950 (account statements), MT900 and MT910 (debit and credit notifications), and MT941 and MT942 (intraday reporting) are being replaced by camt.053, camt.054, and camt.052 respectively, but SWIFT is not converting MT9xx traffic to camt format automatically. Each bank negotiates its own cutover, account by account, on whatever internal schedule its own core banking migration allows. That is precisely why one Business Central customer converted a year ago without much drama, another is getting the notice this quarter, and a third will not hear anything until 2027. There is no single migration date to plan around. There are dozens of them, one per banking relationship, arriving on nobody’s schedule but the bank’s.

The Business Central Side of the CAMT.053 Migration

Business Central handles SEPA CAMT import through a Data Exchange Definition, a mapping layer that translates XML element paths in the bank’s file into fields across three tables: the General Journal table, the Bank Acc. Reconciliation header, and the Bank Acc. Reconciliation Line table. The mapping itself is fairly mechanical once you see it laid out. The transaction amount and its sign come from Stmt/Ntry/Amt combined with the credit or debit indicator at Stmt/Ntry/CdtDbtInd, with a configurable negative-sign identifier (typically set so that DBIT entries post as negative). Posting and transaction dates come from Stmt/Ntry/BookgDt, which can arrive as either a plain date or a full timestamp; Business Central accepts both. Payer information for matching comes from Stmt/Ntry/NtryDtls/TxDtls/RltdPties/Dbtr/Nm, and the free-text remittance information that drives most of the automatic matching logic comes from Stmt/Ntry/NtryDtls/TxDtls/RmtInf/Ustrd.

The field that actually determines whether any of this works is easy to miss: Stmt/Ntry/NtryDtls/TxDtls/Refs/EndToEndId. This is the identifier Business Central relies on to treat each line as unique within an open reconciliation. If a bank’s first-generation camt.053 export leaves this element empty, or populates it with a placeholder value repeated across an entire batch, the failure mode is not an import error. The file parses without complaint. What actually happens is worse in a subtler way: lines with a missing identifier get silently dropped, and lines that share a duplicated identifier with something already posted will import but fail automatic matching one by one, with no message pointing back to the cause. A team that has not specifically gone looking for this will spend a reconciliation cycle assuming the new statement format is simply less complete than the old one, when the real problem is a configuration gap that a five-minute look at the raw XML would have caught before go-live.

Abstract visualization of two data streams merging, representing a bank statement format migration

Where the Generic Definition Runs Out

Business Central ships a generic SEPA CAMT data exchange definition, and it is a reasonable starting point, not a finished solution. CAMT.053.001.08 is a schema, not a single fixed file layout, and individual banks populate it with their own dialect: some banks include optional elements Business Central’s default mapping ignores, some omit fields the default mapping expects, and namespace versions drift between institutions even within the same country. In practice, most multinational Business Central deployments end up cloning the generic definition per banking relationship rather than trying to maintain one shared version that quietly breaks every time a new bank is onboarded with slightly different habits.

It also helps to be honest about geographic scope. CAMT adoption is heavily concentrated in the EU and a handful of other markets that have committed to the SEPA-aligned schema. Plenty of banks elsewhere, particularly smaller regional institutions in North America and parts of Asia, are staying on BAI2 or proprietary flat-file formats for the foreseeable future, with no camt.053 timeline at all. A single Business Central tenant with entities in four countries can easily end up running MT940, camt.053, and BAI2 in parallel for years, not as a transitional state but as the normal operating condition. For organizations with a long tail of smaller regional banking relationships, this is where an ISV connector such as AMC Banking 365 Fundamentals earns its licensing cost: it converts against several hundred bank-specific format variants through its own service rather than asking an internal team to build and maintain a bespoke Data Exchange Definition for every regional bank quirk. That trade-off is worth evaluating deliberately, since routing statement data through a third-party conversion service is a data-governance decision as much as a technical one.

A Practical Migration Checklist

The teams that get through a bank-driven format change without a rough reconciliation cycle tend to do a few things in a specific order. They start by inventorying every bank account’s current import format code and confirming the actual cutover date per relationship, since assuming all banking relationships move together is the single most common planning mistake. Before the cutover, they request an actual test camt.053 file from the bank, not a sample pulled from vendor documentation, and run it through the Data Exchange Definition in a sandbox company where a bad mapping does no damage. They open that test file as raw XML and check the EndToEndId population line by line rather than trusting that because a mapping worked for one bank’s camt.053 export, it will behave identically for another bank using the same nominal schema version. Where any deviation shows up, they clone the generic SEPA CAMT definition into a bank-specific version rather than editing the shared default, so a fix for one relationship cannot silently change behavior for every other bank account using the same code. They keep the outgoing MT940 or BAI2 definition active and assigned for as long as the bank is willing to run both feeds in parallel, because a same-day cutover with no fallback window turns any mapping problem into an immediate reconciliation gap. And before retiring the old feed for good, they re-test automatic matching rates against a full month of real transaction volume on the new format, since a quiet drop in match percentage is a far more reliable early warning of a mapping issue than an outright import failure would be.

What Copilot’s Bank Reconciliation Assist Does and Doesn’t Solve Here

Business Central’s Copilot-assisted bank reconciliation feature, currently in preview, is genuinely useful for what it does: it analyzes unmatched transaction descriptions and ledger entries to suggest matches and likely G/L accounts, including scenarios where a single deposit needs to be split across several invoices. It is worth being clear about its boundaries in this specific context, though. It operates entirely downstream of the Data Exchange Definition, on statement lines that have already been successfully parsed into the system. If a mapping problem is dropping or mismatching lines before they ever reach the reconciliation worksheet, no amount of AI-assisted matching afterward will surface or correct that. The feature also performs best when transaction descriptions and G/L account names share a single consistent language, which is worth double-checking specifically during a format changeover, since a bank’s new camt.053 export sometimes reformats descriptive text differently than its old MT940 feed did.

The Deadline Is the Bank’s, Not Yours

None of this is a discretionary upgrade a Business Central team can schedule around a quieter month. It is a mapping and validation project with a deadline set by someone else’s core banking migration, arriving on a per-relationship basis rather than a single company-wide date. The organizations handling it well are the ones treating each bank’s cutover notice as a trigger for testing, not as an announcement to file away until the old feed actually stops. Routeget has walked several clients through exactly this kind of parallel MT940 and camt.053 coexistence during multi-entity rollouts, and the pattern is consistent: the mapping work is small, but only when someone does it before the bank forces the issue rather than after.

#BusinessCentral #CAMT053Migration #BankReconciliation #ISO20022 #DataExchangeDefinitions #ERPIntegrations