Accounts Payable Settlement Priority Is Now On by Default in Dynamics 365 Finance. It Solves a Narrower Problem Than It Sounds.

Finance manager reviewing a vendor payment and cash flow dashboard on office monitors

A controller at a mid-market distributor recently asked her Dynamics 365 partner a reasonable question: now that accounts payable settlement priority is on by default in the 10.0.49 update, does that mean the system will hold back lower-priority vendors during a tight cash week and pay the critical ones first? The honest answer disappointed her. It doesn’t do that, and understanding exactly why is the difference between using this feature correctly and assuming it covers a problem it was never built to solve.

Dynamics 365 Finance 10.0.49 reached general availability for self-update customers in September 2026, with auto-update environments following in October. Buried in the Cash and Bank Management section of the release notes is a single line: “Accounts payable enable settle with priority” is now on by default. For years this capability existed behind a feature flag that most organizations never touched, largely because nobody explained clearly what problem it actually solves. Now that Microsoft has switched it on for everyone, finance teams are encountering it for the first time in production, often without having reviewed what it changes.

What Accounts Payable Settlement Priority Actually Does

Abstract illustration of digital invoices sorted into a prioritized settlement queue

Settlement priority operates at a narrower point in the payables process than most people assume. It has nothing to do with deciding which vendors get selected for a payment run in the first place. That job still belongs to the payment proposal, whether generated manually or through the automated vendor payment proposal process, and both of those continue to select invoices based on due date and cash discount date windows exactly as they did before this update.

What settlement priority governs is what happens after a payment already exists and needs to be applied against a vendor’s open invoices. When a single payment doesn’t fully cover everything outstanding for that vendor, perhaps because of a short remittance, a disputed line held back from the total, or simple rounding, the system has to decide which invoices get settled first and which remain partially or fully open. Before this update, that decision followed either manual selection or a straightforward date-based default. With settlement priority enabled, it instead follows a priority number you assign to the vendor, configured on the Settlement priority tab of the Accounts Payable Parameters page, with the option to extend the same logic into automatic settlement once both the “Prioritize settlement” and “Automatic settlement” parameters are turned on together.

That is a genuinely useful piece of consistency. Large accounts payable teams processing thousands of vendor transactions a month have historically dealt with inconsistent settlement outcomes when a payment fell short of the full balance, sometimes resolved by whichever clerk happened to be settling the transaction that day. Replacing that variability with a defined, auditable order is a real improvement, and it is the kind of quiet process-integrity fix that rarely gets attention until an auditor asks why two similar short-payment scenarios were resolved two different ways six months apart.

The Gap Between What CFOs Expect and What Ships

Where the confusion starts is in how naturally this feature’s name suggests something bigger. “Settle with priority” sounds like it should mean strategic vendor prioritization during cash-constrained periods, and that is precisely the capability many finance leaders have wanted from their ERP for years. If working capital tightens ahead of a large tax remittance or a seasonal inventory build, the instinct is to want the system to automatically defer discretionary vendors and protect payments to single-source suppliers or anyone with contractual penalty clauses for late payment.

That is not what happens here, and it’s worth being direct about the practical consequence. If your organization relies on the automated vendor payment proposal process to generate weekly or monthly payment runs, turning on settlement priority changes nothing about which invoices get proposed for payment. The proposal still pulls invoices based on due date adjustments and minimum payment date criteria defined in the process automation setup, with no awareness of cash position, vendor criticality, or the priority numbers you may have just configured. A vendor ranked as low priority in your new settlement configuration will still be selected for payment on schedule if its invoice falls inside the proposal’s date window, because priority only comes into play once a payment already exists and needs to be matched against that vendor’s open balance.

For genuine cash-position-driven prioritization, the lever still sits where it always has: in how proposals are filtered before generation, in manual holds placed on specific vendor accounts, or in a dedicated treasury or AP automation layer sitting alongside Dynamics 365 that can factor in real-time cash forecasts. Settlement priority is a settlement-application control, not a payables strategy tool, and treating it as the latter risks a finance team believing they have protection they don’t actually have during the next liquidity crunch.

What to Check Before This Silently Changes Behavior

Because this shipped as an on-by-default change rather than an opt-in feature, the practical risk isn’t that it’s dangerous. It’s that it’s invisible until someone notices settlement behavior has shifted. A few things are worth confirming in any environment that has moved to 10.0.49 or will auto-update in October.

First, check whether priority numbers have ever been assigned to vendors in your instance. If settlement priority is now active but no one has configured priority values, the system will apply whatever default ordering exists, and finance staff should know what that default actually is rather than assume it matches prior manual practice. Second, review whether “Automatic settlement” is also enabled alongside “Prioritize settlement,” since that combination extends priority-based logic into unattended settlement runs rather than only manual ones, which raises the stakes on getting the configuration right before it processes a batch overnight. Third, walk through a short-payment scenario in a test environment with a vendor that has multiple open invoices, to see firsthand which invoice gets settled and which remains open, rather than relying on documentation alone to predict the outcome.

Where This Fits in a Broader Payables Strategy

None of this diminishes the value of the underlying capability. Consistent, auditable settlement behavior matters more as transaction volumes grow and as more of the payables cycle runs through automation with less manual review at each step. Organizations running multi-entity or shared-service AP operations, where the same clerk may be settling transactions across dozens of legal entities with different vendor relationships, stand to benefit the most from replacing ad hoc judgment calls with a defined priority scheme.

The mistake to avoid is treating this release note as evidence that Dynamics 365 now handles strategic vendor prioritization end to end. It handles one well-defined piece of a much larger payables process, and the other pieces, cash forecasting, proposal filtering, vendor criticality scoring, still need to be designed deliberately, whether through native configuration, process automation rules, or a third-party AP platform. Firms that have implemented and tuned payables processes across enough Dynamics 365 environments tend to see this pattern repeat with almost every feature flip: the capability itself is sound, but the assumption about its scope is usually larger than what shipped. Reading the fine print before the next auto-update cycle is a cheap way to avoid finding out the gap the hard way, during the week cash is actually tight.

#DynamicsFinanceOps #AccountsPayable #VendorPaymentPriority #CashManagement #WorkingCapital #FinanceAutomation

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