Dynamics Finance Ops Archives

Power BI Copilot’s Bill Isn’t a License. It’s Fabric Copilot Capacity You Share.

IT and finance leaders reviewing an enterprise Fabric capacity billing dashboard for Power BI Copilot usage

A CFO at a manufacturing group running Dynamics 365 Finance and Supply Chain recently signed off on an F64 Fabric capacity so the FP&A team could start using Power BI Copilot to draft variance commentary and summarize demand forecasts. Three weeks later, an IT director flagged something the approval memo never mentioned: two hundred report viewers across the business no longer needed Power BI Pro licenses at all. That wasn’t a bug or a surprise discount. It was a separate Fabric licensing rule that happens to kick in at the exact same capacity size Copilot is often recommended for, and the two get conflated constantly in vendor pitches and budget spreadsheets alike.

That conflation is the real problem for anyone trying to budget a Power BI Copilot rollout against a Dynamics 365 reporting program. Copilot in Power BI is not a per-seat add-on the way Microsoft 365 Copilot is. It is billed against Fabric capacity consumption, measured in capacity units, and organizations can even designate a specific Fabric Copilot capacity purely to centralize that billing. Whichever capacity ends up holding that designation is shared with every other Fabric workload your organization runs on it. Getting the cost model wrong in either direction, assuming it is included in your existing Pro licenses, or assuming it behaves like a fixed monthly fee, leads to budget requests that are either laughably low or defensively padded past what the workload actually needs.

What Copilot Actually Consumes, and Why the Rate Card Looks Strange

Microsoft’s own Fabric documentation describes Copilot consumption in capacity unit seconds, priced per 1,000 tokens, and the input and output rates are not the same. Input prompt tokens consume 100 CU seconds per 1,000 tokens, cached input tokens (system instructions, schema context, and conversation history that Fabric automatically caches without any configuration) consume only 10 CU seconds per 1,000 tokens, and output tokens, the actual generated text, consume 400 CU seconds per 1,000 tokens. That four-to-one gap between input and output pricing matters in practice: a Copilot-generated narrative summary of a Dynamics 365 SCM inventory report produces far more output tokens than the prompt that requested it, so output pricing dominates the bill.

Take a request with 2,000 input tokens and 500 output tokens, a reasonably typical size for a Copilot-drafted commentary on a Power BI report built over Dataverse or F&O entity data. The math works out to (2,000 × 100 + 500 × 400) ÷ 1,000, which is 400 CU seconds, or roughly 6.67 CU minutes. On its own that number means nothing to a finance leader. What it means in context is the second thing worth understanding: how that consumption gets classified against your capacity.

Background Job Smoothing Changes the Real Exhaustion Risk

Microsoft classifies Copilot operations as background jobs rather than interactive ones, and background jobs get smoothed over a 24-hour window instead of the 5-minute window used for interactive report rendering. Throttling only begins once the capacity has already committed all of its available CU budget for the next 10 minutes. Microsoft’s own documentation walks through this with an F64 example: an F64 SKU carries 64 × 24, or 1,536, CU hours in a single day. A single Copilot request consuming roughly 6.67 CU minutes works out to about 0.11 CU hours, which means an F64 capacity could theoretically absorb well over 13,000 such requests before exhaustion, assuming nothing else on that capacity is consuming CU budget at the same time.

That last clause is where the real governance risk sits, and it’s a genuinely different risk than “Copilot is expensive.” When capacity is exhausted, Microsoft’s documentation is direct about the consequence: all operations shut down, not just Copilot. If your Dynamics 365 reporting workspace, your dataflows, your semantic model refreshes, and your Copilot usage all live on the same Fabric capacity, and a finance analyst runs an unusually large batch of Copilot-assisted narrative generation during month-end close, everyone else’s scheduled refreshes and interactive reports can stall on that same capacity at the same time. This is an argument for isolating Copilot consumption onto its own designated capacity rather than an argument against adopting it at all, and Microsoft built a specific mechanism for exactly that.

Financial analyst working at a dual-monitor desk with Power BI analytics dashboards

The Fabric Copilot Capacity Designation Is Not the Same Thing as F64

Since April 2025, Microsoft has allowed organizations to designate any capacity of F2 or larger, not just F64 and above as originally required at the January 2025 preview launch, as a dedicated “Fabric Copilot capacity.” A Fabric admin enables Copilot for the organization, authorizes a capacity admin to make that designation, and the capacity admin then assigns user groups whose Copilot usage should bill there instead of wherever their content happens to be hosted. Once that’s done, no further action is needed. Users assigned this way can be on Pro, PPU, Trial, Premium capacity, or Fabric capacity license modes, though Embedded is explicitly not supported.

This solves a specific budgeting problem: without it, Copilot costs get spread across whatever capacity holds each user’s content, which makes centralized cost tracking nearly impossible for an IT Director trying to build a clean Copilot line item. With a designated Copilot capacity, every dollar of Copilot consumption lands in one place on the bill, separate from your Dynamics 365 reporting workspace’s own capacity consumption for refreshes and interactive use. Worth noting for architects planning this out: Fabric Copilot on other workloads (Data Factory, Data Engineering, Data Warehouse, Data Science, Real-Time Intelligence, and Activator) is only available on capacities smaller than F64, while Power BI Copilot specifically remains available regardless of capacity size. If your organization runs Copilot across multiple Fabric experiences, not just Power BI, that asymmetry affects which capacity size you actually want for the designation.

Why the F64 Threshold Gets Conflated With Copilot Pricing, and Why That Matters for Your Budget

Separately from anything Copilot-related, Microsoft’s Fabric licensing model has long included a straightforward rule: on any F SKU smaller than F64, every person viewing Power BI content needs a Pro, PPU, or individual trial license. At F64 or larger, a user with only a free Fabric license can view content, provided they hold a viewer role on the workspace. This rule exists independent of Copilot and predates Copilot’s current billing model by a wide margin. It’s an artifact of how Microsoft licenses Power BI content consumption at scale, not a Copilot feature.

The reason this matters for a CFO’s budget conversation is that vendors and consultants routinely present F64 as “the tier where Copilot gets cheap,” when the more accurate framing is that F64 is where per-viewer Pro licensing gets cheap, and Copilot’s own cost is a completely separate, consumption-based line that scales with usage regardless of which SKU size you land on. An organization with two hundred report viewers and modest Copilot usage might genuinely benefit from an F64 capacity purely for the license consolidation, independent of whether Copilot ever gets turned on. An organization with heavy Copilot usage across a small number of power users, finance analysts drafting narrative variance reports all day, might be better served by a smaller designated Copilot capacity and leaving Pro licensing exactly where it is. These are two different decisions being made to look like one decision, and separating them is the actual budgeting exercise.

What This Means for a Dynamics 365 Reporting Rollout

For an IT Director or CFO evaluating Power BI Copilot against Dynamics 365 Finance, Supply Chain, or Customer Engagement reporting, start by quantifying how many people will actually draft Copilot-assisted narratives, distinct from how many simply view the resulting reports, since those two populations drive different cost levers entirely. From there, model consumption using the token rates above against your actual reporting cadence rather than a vendor’s generic estimate, since output-heavy use cases like automated commentary generation consume capacity differently than short, targeted Q&A against a semantic model. Finally, decide separately whether an F64-or-larger capacity makes sense for license consolidation, and treat that as independent from whichever capacity you designate for Copilot billing.

Fabric’s list pricing follows the capacity unit count linearly, so an F64 capacity costs roughly thirty-two times an F2 capacity’s pay-as-you-go rate, and Microsoft’s own reservation pricing page states that a one- or three-year commitment can reduce that rate by roughly 41 percent compared to pay-as-you-go. Given how directly usage scales with cost here, that reservation discount is worth pricing into any multi-quarter Copilot rollout plan rather than treating it as an afterthought once the pilot succeeds.

None of this makes Power BI Copilot a bad investment for a Dynamics 365 reporting program. It makes it a capacity planning exercise with its own governance questions, closer to provisioning compute than provisioning software seats. Organizations that treat it as the latter tend to either under-budget it or, more commonly, over-provision a capacity size for reasons that had nothing to do with Copilot in the first place. It’s the kind of distinction our team at Routeget Technologies walks clients through before a single dollar of Fabric capacity gets provisioned, since separating the licensing decision from the consumption decision up front is what keeps a Copilot rollout from turning into an unplanned line item six months later.

#PowerBICopilot #FabricCapacity #CopilotCostGovernance #DynamicsFinanceOps #EnterpriseAI #FinanceTransformation

Time Zone-Agnostic Resource Planning Fields Reached GA in Project Operations. Extend Booking Still Isn’t Automatic.

Resource manager reviewing a project scheduling timeline with time zone indicators on a large office display

A resource manager in Chicago books a developer in Manila for a two-week sprint starting Monday at 9 a.m. The booking looks correct in the schedule board. Three weeks later, someone extends that booking by a week, and the new segment quietly starts two hours later than anyone intended, because the underlying date fields were interpreted in the resource manager’s time zone, not the resource’s, and the assignment profile that governs the extension only overlapped with the developer’s working day by a narrow window. Nobody notices until the invoice reconciliation shows unbilled hours that don’t match the timesheet. This is not a hypothetical edge case for any organization running distributed delivery teams on Dynamics 365 Project Operations. It is the default behavior the platform has shipped with since resource scheduling first launched, and as of September 2026, Microsoft has finally shipped time zone-agnostic resource planning fields, giving administrators a way to turn off that recalculation for the fields where it causes the most damage.

What time zone-agnostic resource planning fields actually change

The feature, tracked under Message Center announcement MC1465316 and published in the Dynamics 365 Project Operations 2026 release wave 1 plan, reached general availability in September 2026 (Microsoft’s own release plan lists the month without a specific day, while the Message Center post cites September 30). It lets administrators configure resource requirement and resource booking start and end dates so they are stored and displayed without automatic time zone conversion, rather than being silently recalculated based on whichever user’s personalization settings happen to be active when a record is viewed or edited.

Under the platform’s existing behavior, a resource requirement’s dates are date-time fields, and Dataverse date-time fields carry a time zone behavior setting: user-local, time zone-independent, or date-only. Most of the scheduling entities in Project Operations were built as user-local by default, which is exactly what causes the Manila example above. A record entered by someone in Central Time and viewed by someone in a different zone gets recalculated on the fly to match the viewer’s offset. That is a reasonable default for a calendar invite. It is a poor default for a resource requirement that a project manager in one country, a resourcing specialist in another, and an automated allocation engine somewhere in the middle all need to interpret identically.

Why this has been a real operational problem, not a cosmetic one

The root cause sits in how Project Operations already handles time zones for projects and tasks, and it predates this release. A project’s time zone is inherited from the work hour template applied to it. Dates on the project form are shown relative to the logged-in user’s time zone on every tab except Tasks, where dates always render in the project’s own time zone. That inconsistency alone trips up new administrators. Layer resource bookings on top, and the practical failure mode Microsoft’s own documentation describes is the Extend Booking scenario: a bookable resource needs at least one minute of overlapping work time with the assignment profile used to define the extension, or the extension either fails or lands at an unexpected time. In practice, teams have worked around this by insisting device time zones match Dynamics 365 personalization settings exactly, which is a fragile control to enforce across a distributed workforce and does nothing to fix the underlying data model.

The financial exposure is not abstract. Project Operations bookings feed resource utilization reporting, and utilization numbers feed billing for time and materials engagements. A booking that silently shifts by two hours because of a time zone recalculation does not usually change the total hours booked, but it does change which calendar day or which shift a resource shows as committed, and that mismatch is exactly the kind of discrepancy that turns a routine month-end reconciliation into a multi-hour investigation. For organizations running global delivery models where a single project pulls resources from three or four time zones, this has been a recurring, quietly expensive class of data integrity issue rather than a one-off annoyance.

Solution architect at a dual-monitor workstation reviewing a resource booking schedule board across time zones

What actually changes once you enable it

Enabling time zone-agnostic behavior on resource requirement and booking date fields converts them from user-local to time zone-independent at the platform level. Once that switch is made, the stored value for a start or end date stops being reinterpreted based on the viewer’s personalization settings. Everyone who opens that record, regardless of where they are logged in from, sees the same date and time. This is the same mechanism Dataverse has long supported for other entities; Project Operations is catching up by extending it to the specific tables where resource planning data lives.

Two things are worth flagging before you flip this on for a live environment. First, this is an opt-in configuration change, not a default behavior swap, so existing bookings created under user-local semantics do not automatically reinterpret themselves; plan for a validation pass on in-flight bookings after enabling the feature rather than assuming historical data self-corrects. Second, the Extend Booking overlap requirement between resource and assignment profile working hours does not disappear just because the date fields are now time zone-independent. That constraint is a scheduling logic rule, not a date-storage rule, and it will still reject or misalign an extension if a resource’s working calendar genuinely does not overlap with the profile driving the extension. Time zone-agnostic fields fix the data consistency problem. They do not fix a genuinely misconfigured working calendar.

A practical rollout sequence

Start by auditing which projects and resource pools actually span more than one time zone today; if your delivery model is single-region, this feature is low priority regardless of how appealing it sounds. Where it does apply, enable the setting in a sandbox environment first and pull a sample of active bookings that were extended or modified in the last quarter, then compare their displayed start and end times before and after the change for a handful of test users logged in from different time zones. That comparison is the fastest way to confirm the fields are behaving as time zone-independent rather than assuming the toggle worked from the release notes alone.

Next, reconcile resource calendars against project work hour templates for any team that has triggered Extend Booking issues in the past. Since the overlap requirement is unaffected by this change, this is the moment to fix calendar misalignments you may have been tolerating as a known quirk. Finally, update any Power Automate flows or integrations that read resource booking dates directly, since a flow written to expect user-local conversion behavior will now receive a raw, unconverted value, which is the correct behavior going forward but a breaking change for logic that implicitly depended on the old conversion.

The bigger pattern worth watching

This release is a narrow fix, but it points at a broader gap in how Project Operations was originally modeled for single-region delivery and is now being retrofitted for genuinely distributed teams. Organizations that have built manual device-time-zone-matching policies as a workaround should treat this as an opportunity to retire that policy rather than run both approaches in parallel indefinitely. For firms like Routeget that implement and support multi-region Project Operations deployments, this is exactly the kind of platform change worth validating in a client’s sandbox before it reaches their production resourcing team, since the difference between a correctly configured rollout and a rushed one is measured in reconciliation hours saved every single billing cycle.

Sources: Microsoft Learn, “Overview of Dynamics 365 Project Operations 2026 release wave 1” and the associated planned-features page for “Use time zone-agnostic fields in resource planning” (public preview March 31, 2026, general availability September 2026); Message Center announcement MC1465316; Microsoft Learn, “Manage multiple time zones” (Project Operations resource management documentation) for the Extend Booking overlap requirement and project/task time zone inheritance behavior.

#ProjectOperations #ResourceScheduling #TimeZoneManagement #DynamicsFinanceOps #ProjectBillingAccuracy

Dynamics Finance Ops Project Billing Accuracy Project Operations Resource Scheduling Time Zone Management

Business Central’s Bank Reconciliation Copilot Went GA in 2024. The Docs Still Call It Preview.

Finance professional reviewing bank reconciliation Copilot matches on a laptop dashboard

A client’s controller asked a straightforward question during a recent Business Central scoping call: is the bank reconciliation Copilot feature safe to turn on for month-end close, or is it still something we should treat as experimental. The honest answer took longer to give than it should have, because Microsoft’s own documentation contradicts itself on this point. The 2024 release wave 2 plan lists general availability for “Complete bank account reconciliation faster with Copilot” as October 1, 2024. The current feature page and its companion FAQ, both carrying a May 2026 update stamp, still put “(preview)” in the title. For a firm advising clients on what they can rely on inside a signed statement of work, that gap between the release-plan record and the live documentation is not a footnote. It changes what you tell a client about support commitments, change-notice expectations, and whether the feature belongs in a production close process at all.

What Bank Reconciliation Copilot Is Actually Doing

Strip away the marketing language and the feature does two distinct jobs inside the Bank Acc. Reconciliation page. First, after Business Central’s standard rule-based automatch runs and leaves a set of unmatched bank statement lines, Copilot inspects the leftovers and looks for matches the deterministic engine missed, weighing transaction dates, amounts, and free-text descriptions together rather than requiring an exact rule hit. The example Microsoft uses in its own documentation is a single lump-sum deposit that actually represents five separate customer payments; automatch sees one bank line and five ledger entries and gives up, while Copilot can propose the one-to-many match. Second, for whatever remains genuinely unmatched, a separate Copilot action suggests a general ledger account to post the difference against, based on how the transaction description compares to your chart of accounts naming. A line that reads “Fuel Stop 24” gets proposed against a Transportation or Vehicle Expense account rather than sitting in a suspense account until someone investigates it manually.

Both actions are additive, not automatic. Nothing posts until a user reviews the proposed matches and explicitly selects “Keep it,” and the G/L suggestions can be saved into the Text-to-Account Mapping table so the same vendor description resolves the same way next month without asking Copilot again. That mapping table is worth building deliberately during rollout rather than letting it accumulate ad hoc, because it is the actual long-term efficiency gain here. The AI matching helps once; the mapping table helps every month after.

The status conflict, and why it matters for how you scope this

The release-plan record and the live docs cannot both be describing the same feature in the same state, so one of two things is true. Either the GA declaration from October 2024 covered only the base matching capability, and the newer G/L suggestion and mapping workflow that shipped afterward is what the current “(preview)” label actually refers to, or Microsoft’s documentation team simply never updated the page title when the feature graduated. Nothing in the current feature page, the FAQ, or the release-plan history explicitly resolves which of those is correct, and that ambiguity is the finding worth passing to a client rather than picking one interpretation and presenting it as settled fact.

Practically, this affects two decisions. The first is whether you commit to this feature working a specific way inside a contract, since preview features in Business Central online can change behavior without the same notice period Microsoft gives to GA capabilities. The second is how you frame it to the client’s audit or SOX-adjacent controls owner, who will reasonably ask whether a “preview” label means the output is less trustworthy. It does not mean that: the matching logic runs the same way regardless of the label, and the mandatory human review step is unchanged either way. But an auditor reading the page directly will see the word “preview” before they see your explanation, so raise it first rather than let them find it.

The entry-count ceiling most rollouts hit without noticing

The feature enforces a hard scan window: it only considers open bank account ledger entries dated between one day before the earliest bank statement line and the latest bank statement line, and it caps how many open entries it will process in that window. On 2025 release wave 1 and earlier, that ceiling sits around 1,000 open entries, depending on how long the description text runs. From 2025 release wave 2 onward, Microsoft raised it to roughly 3,000. Neither number is exposed anywhere in the user interface as a running count, so the first sign a client hits it is usually a reconciliation that used to surface a dozen AI-proposed matches suddenly surfacing none, with no error message explaining why.

For a company reconciling a single operating account monthly, 1,000 to 3,000 open entries is generous headroom. For a client running high-volume accounts payable through a single bank account, or one that has let old unapplied ledger entries pile up instead of writing them off, that ceiling is closer than it looks. Two mitigations are worth building into the rollout rather than discovering during a live close: confirm the client’s release wave version before promising Copilot behavior at a specific volume, and treat unusually old open ledger entries as reconciliation debt to clean up on a schedule, not just a reporting nuisance, since they silently consume slots in that scan window every single month.

Language alignment is a real constraint, not a compliance checkbox

Microsoft’s own guidance states plainly that matching accuracy depends on the G/L account names, ledger entry descriptions, and bank transaction descriptions all being in the same language, and that mixed-language data produces measurably fewer matches and suggestions. For a domestic single-language client this is a non-issue. For a multi-entity client running a shared chart of accounts across a US and a Mexico or Canada entity, where account names might be maintained in English but transaction descriptions arrive from a bank feed in Spanish or French, this is a concrete reason the feature will underperform in exactly the entity where the manual reconciliation burden is heaviest. Check the supported-language list against each legal entity’s actual operating language before setting client expectations, not after the first disappointing reconciliation run.

What the responsible AI documentation actually commits to

The FAQ is more specific here than most feature pages get, and it is worth quoting to a nervous data governance stakeholder rather than paraphrasing. Microsoft does not use company data, prompts, or Copilot responses to train its underlying models. Prompts and responses are retained as diagnostic data for twenty days, within the same geographic and compliance boundary as the rest of the company’s data, and that retained data is accessible only to Microsoft support personnel under existing Customer Lockbox controls. Usage telemetry is anonymized and excludes the actual prompts, responses, and customer data. None of this is unusual for a Business Central Copilot feature at this point in the platform’s maturity, but it answers the two questions a client’s compliance team will ask first, and having the citation ready saves a follow-up call.

Accountant reviewing AI-suggested bank transaction matches on a laptop dashboard

A rollout sequence that avoids the common failure mode

The most common way this feature disappoints a client is not a bad match, it is silence: a reconciliation runs, nothing gets proposed, and the user assumes Copilot is broken rather than assuming they hit the entry ceiling or a language mismatch. Enable the capability through the admin center first, confirm which release wave the client’s environment is on so you know the actual entry ceiling, and run the feature against one account’s real historical statement before go-live rather than a demo company, since Business Central’s built-in demo data is tuned to succeed and will not surface any of the above limits. During that test, deliberately build out the Text-to-Account Mapping entries for the client’s recurring, easily-categorized transactions, since that mapping table is what turns a one-time AI convenience into a permanent reduction in manual coding work. Finally, document the “Post if fully applied” auto-post option as an explicit decision rather than a default: it is convenient for a fully reconciled batch, but a client with a formal month-end sign-off process may want every AI-originated posting to pass through a human approval step regardless of match confidence, and that is a control decision worth having in writing.

Close-up of a bank statement reconciliation screen with matched and unmatched transaction lines highlighted

None of this makes the feature something to avoid. Two years after its stated GA date, the underlying matching logic is mature enough that Routeget now includes it as a standard discovery item on Business Central finance engagements, specifically so the entry-count ceiling and language dependency get surfaced during design rather than during the client’s first live close. The lesson is less about this specific feature and more about a pattern that shows up across the Copilot rollout in Business Central generally: the release-plan announcement and the day-to-day product documentation do not always stay in sync, and the responsible move is to check both before you tell a client what to expect, not just the one that sounds more finished.

#BusinessCentral #BankReconciliationCopilot #ERPIntegrations #FinanceAutomation #DynamicsFinanceOps #ResponsibleAI

Bank Reconciliation Copilot Business Central Dynamics Finance Ops ERP Integrations Finance Automation Responsible AI

Copilot Studio’s Computer-Use Agents Reached GA. The Success Rate Numbers Change the Business Case.

IT director reviewing an automated workflow diagram representing a Copilot Studio computer-use agent on an office monitor

A mid-market distributor recently asked its systems integrator for a quote to build an API bridge between Dynamics 365 Finance and Supply Chain Management and a fifteen-year-old carrier portal that still runs on a browser-only interface with no exposed endpoints. The estimate came back at nine weeks and roughly $160,000, most of it spent reverse-engineering a login flow and a rate-lookup screen that changes its layout every few months. That is the exact situation Copilot Studio’s computer-use agents were built for, and as of May 2026 the capability is generally available rather than sitting in preview. For CIOs and finance leaders staring down a similar quote, the real question is not whether the technology works. It is whether it works well enough, cheaply enough, and safely enough to replace a project that would otherwise sit on the backlog for a year.

What Copilot Studio’s computer-use agents actually shipped at GA

Computer-use agents let a Copilot Studio agent operate a website or a Windows desktop application the way a person would: it takes a screenshot, reasons about what it sees, and performs a click, a keystroke, or a scroll toward a stated goal. Microsoft’s own release announcement frames the GA milestone around three changes from the preview period. Credential handling moved to a more secure model rather than embedding logins in flow definitions. Customers can now choose which underlying model drives the automation, matching cost and capability to the task instead of accepting a single default. And the agents became noticeably more resilient to interface drift, meaning a carrier portal that shuffles a form field or repositions a button is less likely to break the automation outright, which was one of the most common failure modes reported during preview.

The feature also picked up a genuinely useful architectural change: computer-use steps can now be embedded inside a broader workflow, so a single process can call an API where one exists, fall back to UI automation where it does not, and route to a human approver for anything in between. That matters more than it sounds. Most legacy integration problems are not purely API-less. They are mixed: part of the process has a clean endpoint, and the rest lives behind a login screen nobody ever modernized. Treating the whole thing as one workflow, rather than stitching together a separate RPA tool alongside your Power Automate flows, is the actual value proposition here, not the novelty of an AI agent clicking buttons.

Where the economics genuinely hold up

Computer-use agents consume Copilot Credits on a per-step, consumption-based model that behaves differently from the message-based billing most finance teams are used to budgeting for a chatbot or a Copilot assistant. A short, well-scoped task, four or five steps to submit a form and confirm a result, costs relatively little. A long, branching process with dozens of steps run at volume compounds that cost quickly, and it compounds faster than most stakeholders expect the first time they see a monthly bill next to the pilot’s success metrics. Before approving a production rollout, finance and IT should jointly model the cost of the highest-volume scenario at expected transaction counts, not just the demo scenario that sold the project internally.

The honest framing for a CFO is this: computer use is not a general substitute for API integration. It is a tool for the specific and fairly common case where an API genuinely does not exist, the vendor has no near-term plan to build one, and the manual alternative already costs real headcount hours. A carrier rate portal, a government filing site, an old third-party benefits administrator, or an internal legacy application from a prior ERP era are the kinds of targets where the math works. Where an API does exist, even a mediocre one, direct integration through Power Automate or a custom connector will almost always be cheaper per transaction than UI automation, because every additional screenshot and reasoning step adds cost that a direct API call skips entirely. Teams that reach for computer use as a default integration pattern rather than a fallback tend to discover this the expensive way, usually around the second or third month of production volume.

Abstract illustration of an AI agent cursor navigating connected software interface panels

The success-rate numbers that should set expectations

Microsoft’s own documentation is candid about current performance limits, and CIOs evaluating this for anything beyond a narrow pilot should read those numbers before committing a budget line. Web-based tasks succeed at roughly 80 percent, which sounds reasonable until you consider what a one-in-five failure rate means for a process running hundreds of times a day. Desktop application tasks succeed at closer to 35 percent, a gap wide enough that any deployment targeting a legacy Windows client, rather than a browser, should be scoped as an assisted process with human review built in from day one, not a lights-out automation. Dropdowns, date pickers, and custom UI widgets remain a known weak point, along with the tendency for an agent to loop when the screen state does not match what it expected.

None of this makes the technology unusable. It makes it a tool that needs the same production discipline any automation project requires: define what “success” means precisely, measure it against a real baseline rather than a demo, and build an escalation path for the failures you know are coming rather than treating them as edge cases to handle later. Microsoft’s own guidance recommends exactly this, pointing customers toward least-privilege service accounts, restricted execution environments, and human-in-the-loop review for lower-confidence steps as standard practice rather than optional hardening.

Governance decisions to make before the first production run

Three controls matter most for a finance or IT leader signing off on this. First, audit logging: computer-use sessions can send activity to Microsoft Purview under a dedicated operation type, independent of the standard Dataverse logs the agent keeps by default, and that Purview trail is what most compliance teams will want to see before approving a process that touches financial data or customer information. Second, session visibility: every run generates a step-by-step activity map with screenshots, timestamps, and a list of exactly which credentials and which sites or applications were accessed, which gives an auditor something concrete to review rather than a black box. Third, and easy to overlook, the allow-list that restricts which sites an agent can act on does not fully prevent navigation to sites outside that list, only actions on non-allow-listed pages. Organizations with strict data-boundary requirements should layer network-level controls, such as browser policies through Microsoft Intune, on top of the Copilot Studio allow-list rather than treating the allow-list as a complete boundary on its own.

Administrators who decide the risk profile is not yet acceptable for a given environment can disable computer use entirely at the environment level, or disable the hosted browser specifically at the tenant level, through the Power Platform admin center. That toggle is worth knowing about even for organizations planning to adopt the feature, since it gives a clean way to pilot in one environment while keeping it off everywhere else until the governance model is proven.

What this means for the next integration decision

The distributor with the fifteen-year-old carrier portal does not need to choose between a $160,000 custom build and doing nothing. A scoped computer-use pilot against that single portal, with success measured honestly against the current 80 percent web success rate and a human reviewer catching the rest, is a legitimate middle option that did not exist eighteen months ago. The mistake would be extending that same logic to every integration gap on the roadmap without first checking whether each one is genuinely API-less or just under-prioritized. For organizations already running Dynamics 365 Finance and Supply Chain Management or Business Central alongside a Power Platform footprint, the practical next step is an inventory: which manual, screen-based processes actually lack an API path, which have one nobody built yet, and which are high-enough volume that the per-step credit cost changes the calculation entirely. Routeget Technologies has been walking clients through exactly that kind of inventory as computer-use agents move from a curiosity into a line item finance actually has to approve, and the pattern holds across industries: the technology is real, the cost model rewards precision over enthusiasm, and the governance controls exist, but only for the teams who turn them on before the first production run rather than after an incident.

#CopilotStudio #ComputerUseAgents #AgenticAI #RPAGovernance #EnterpriseAutomation #DynamicsFinanceOps

Agentic AI Computer Use Agents Copilot Studio Dynamics Finance Ops Enterprise Automation RPA Governance

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

Accounts Payable Cash Management Dynamics Finance Ops Finance Automation Vendor Payment Priority Working Capital

Power BI Semantic Model Refresh Just Got Granular. Your Dynamics 365 Reports Still Refresh Everything.

A solution architect reviews a data refresh and capacity monitoring dashboard on a large screen at night

A Fabric capacity dashboard turning red at two in the morning is one of the more specific kinds of dread in Dynamics 365 reporting work. Somewhere in the tenant, a scheduled job kicked off a full refresh of a forty-table semantic model built over Dataverse-linked Finance and Operations data, and now every other overnight pipeline is queued behind it. The general ledger fact table alone might carry a decade of posted transactions. None of that history changed since yesterday. It gets reloaded anyway, because until recently, “refresh” in Power BI meant one thing: everything, from scratch, every time.

That default is finally negotiable. Power BI’s August 2026 update made granular semantic model refresh controls generally available in both Desktop and the service, giving report owners a real choice between refreshing schema, refreshing data, or refreshing both, down to the level of an individual table. For anyone maintaining Power BI models over Dynamics 365 F&O, Business Central, or Dataverse data more broadly, this is the kind of change that should prompt an actual architecture review rather than a shrug and a changelog skim.

What changed, specifically

The expanded Refresh control in Power BI Desktop and the service now exposes three distinct operations instead of one. Refresh Schema and Data is the familiar default: Power BI checks the source for structural changes, applies them, and then reloads data. Sync Schema Only updates the model’s structure, picking up new or renamed columns and data type changes, without pulling fresh rows. Refresh Data Only does the opposite: it reloads current values while deliberately ignoring any structural drift at the source, which matters more than it sounds like it should when a source system adds a column you have no interest in modeling yet.

Critically, this granularity now applies at the table level through the UI itself, not just through a REST call. Select a table in the Data pane, and you can choose to refresh its schema, its data, or both, independently of what happens to the rest of the model. Under the hood, this builds on the Enhanced Refresh API’s objects parameter, which has supported table- and partition-level targeting in JSON refresh requests for several years. What is new is that the capability is no longer something you had to script or automate through Power Automate to get; it is a first-class option in the interface most report authors actually use.

The timing lines up with Direct Lake’s move to general availability for OneLake semantic models in March 2026. Direct Lake models query OneLake data at query time instead of importing it into a separate in-memory copy, which changes what “refresh” even needs to accomplish. A schema-only sync is explicitly called out as the more sensible operation for many Direct Lake scenarios, since the underlying data is already current in OneLake and what actually needs updating is the model’s awareness of structural changes upstream.

Why Dynamics 365 semantic model refresh costs add up fast

Generic BI advice treats all semantic models as roughly interchangeable, but Dynamics 365 F&O and Business Central models have a particular shape that makes blanket full refreshes disproportionately expensive. A handful of tables, typically the ones behind AP aging, open sales orders, or current inventory positions, change constantly and need frequent, current data. Most of the rest of the model, historical GL transactions, closed projects, prior fiscal years, is functionally read-only from one day to the next. When Fabric Link or the older entity-store approach lands both categories in the same semantic model and a nightly job refreshes the whole thing on one schedule, the model pays the full cost of reprocessing static history every single time it wants fresh numbers for the tables that actually moved.

That cost shows up in two places that matter to whoever owns the Fabric capacity bill. Wall-clock refresh duration extends as historical fact tables grow, which is a slow-motion problem that eventually collides with the maximum refresh duration ceilings on shared and Premium capacity. And CU consumption on Fabric capacity is metered by the compute the refresh operation actually performs, so reprocessing unchanged partitions burns capacity that has no analytical payoff. Neither problem is solved by adding capacity; both are solved by refreshing less.

Applying granular refresh to a Dynamics 365 semantic model

The practical starting point is an honest table-by-table audit of your existing model, sorted by two questions: does this table’s data actually change day to day, and does its schema drift when Microsoft ships a Finance and Operations or Business Central update. Tables like open transactions, current inventory on-hand, and active project status are obvious candidates for a Refresh Data Only cadence that runs frequently, maybe hourly if the business case justifies it, without touching schema at all. Large historical fact tables, closed fiscal periods, and reference dimensions that rarely change structure are candidates for a much less frequent Refresh Schema and Data pass, perhaps weekly, with the understanding that if Microsoft renames a field or adds a column mid-week, you will not see it in the model until the next scheduled schema sync.

Abstract illustration of a few illuminated data table blocks refreshing among many dimmed, unchanged ones

Where this pairs particularly well with existing Power BI capability is incremental refresh policies on the largest transaction tables. Incremental refresh already partitions a table by date so that only the current period’s partition gets reprocessed on a routine basis; layering table-level refresh selection on top means you can decide, table by table, whether even that partitioned refresh needs to run tonight or can wait until the weekend. For a semantic model spanning several Dynamics 365 legal entities, this combination is usually the difference between a refresh job measured in tens of minutes and one measured in hours.

Implementing this through the Enhanced Refresh REST API rather than clicking through the UI is worth the extra setup for any model refreshed on a schedule, because it lets you express the table list as configuration rather than tribal knowledge sitting in someone’s memory of which tables to click. A request that targets specific tables through the objects array, with applyRefreshPolicy set appropriately for whether you want the incremental refresh window respected, is straightforward to build and far easier to audit six months later than a manual process. Teams running Power Automate flows or Azure Data Factory pipelines to orchestrate refreshes should treat this as the moment to replace a single “refresh the whole dataset” call with a small set of targeted requests, each on its own cadence.

Where this still needs judgment, not just configuration

Schema-only sync deserves particular caution in Dynamics 365 contexts because Microsoft’s release cadence for F&O and Business Central genuinely does add and rename fields with some regularity, and a model that never runs a full schema sync will eventually diverge from its source in ways that surface as confusing blank columns or broken relationships rather than clean errors. A reasonable middle ground is to schedule schema syncs on their own cadence, independent of data refreshes, rather than skipping them indefinitely because a table’s data refresh doesn’t need one.

It is also worth being explicit with report consumers and downstream teams about which tables now run on which schedule, since the old assumption that “refreshed this morning” meant the entire model was current no longer holds once refresh granularity is in play. A short data dictionary note next to each table, or a dedicated tab in the workspace documentation, prevents the kind of confusion where someone builds a decision on a historical table that was deliberately left out of last night’s run.

The architecture conversation this actually forces

The real value of granular refresh isn’t the UI convenience, it’s that it forces a semantic model design conversation that most Dynamics 365 reporting teams have been avoiding: which tables in this model are operational and which are archival, and should they even live in the same refresh schedule, or the same model, at all. Teams that have this conversation now, while the tooling to act on the answer just became native to the product, will end up with leaner Fabric capacity bills and faster refresh windows than teams that keep treating every semantic model as a single monolithic refresh unit. At Routeget, this is usually the point in a Fabric or Power BI engagement where we walk a client’s existing model inventory table by table rather than accepting the assumption that a full nightly refresh is simply the cost of doing business with ERP-scale data.

#PowerBIRefresh #SemanticModels #DirectLake #FabricCapacity #DynamicsFinanceOps #BusinessCentral

Business Central Direct Lake Dynamics Finance Ops Fabric Capacity Power BI Refresh Semantic Models

Project Operations Subscription Billing Is Live, But Not for Every Deployment

A finance director at a mid-size systems integrator called her Microsoft partner last week with a simple question: can we finally bill our managed services retainers automatically instead of re-keying the same fixed-fee lines into a project invoice every month? She had just read a Message Center notice about Project Operations subscription billing and wanted to know how soon her team could stop doing this by hand. The answer she got was more complicated than the announcement suggested, and it is worth walking through, because the gap between what is generally available today and what is entering preview later this month will shape a real budgeting decision for a lot of professional services firms this quarter.

Project Operations Subscription Billing: Two Announcements, Not One

There are actually two separate pieces of functionality connected to this topic, and conflating them is the easiest way to make a bad planning decision. The first, “enable project fee journals to support subscription billing,” has been generally available since Dynamics 365 Finance version 10.0.46, released in October 2025. It lets a project generate a billing schedule through the Subscription Billing module, using Project Fee Journal as the invoice transaction type instead of a standard project invoice. The second, tracked in Microsoft’s Message Center as MC1472430 and titled simply “support subscription billing for Project Operations,” entered public preview on September 30, 2026. It promises recurring billing on flexible cadences, tiered pricing models, subscription hold and termination handling, and refund management, described by Microsoft as reducing manual intervention in recurring invoicing. Only the first one exists in production today. The second is a preview, and previews change shape before they reach general availability.

How the Fee-Journal Mechanism Actually Works

For the capability that is live now, the workflow starts on the project record itself. From Project management and accounting, a user creates a new billing schedule directly from the project, and the system automatically populates the customer account, the project ID, and the funding source. The invoice transaction type gets set to Project Fee Journal rather than Sales Order, which determines how the billing schedule lines behave. Each line carries a fee category, a unit price, and the usual tax fields, but it flows through work-in-progress and accrual postings before it ever becomes a customer-facing invoice.

That sequencing matters more than it sounds. Rather than posting a project invoice the moment work is recorded, the system books WIP and accrual entries through the fee transaction first, then generates the actual invoice on a schedule, whether monthly, quarterly, or however the contract is structured. A firm can choose from three posting behaviors: generate the fee journal only and create invoices manually later, generate the journal and stop at an invoice proposal for review, or post the invoice automatically in one step. That range gives controllers real choice over how much human review sits between recognized revenue and a document that goes out to the client.

The catch, and it is a significant one, is that this fee-journal path is only available for Project Operations deployments that run on the Finance and Operations platform, what Microsoft’s own documentation refers to as Project Operations for manufacturing. A standalone deployment of Project Operations, the version many services firms chose specifically because it does not require standing up the full Finance and Operations stack, cannot use it. If your organization licensed Project Operations to avoid exactly that complexity, the subscription billing capability that shipped last October simply is not on your platform, no matter how current your update cadence is.

Why the Deployment Distinction Is the Actual Decision Point

This is where the finance director’s original question gets harder to answer cleanly. If her firm runs the Finance-integrated deployment, the fee-journal mechanism is already available, and the work is largely configuration: enabling the relevant features in Feature management, setting project stage rules to trigger billing schedule creation automatically, and deciding which of the three posting behaviors matches her team’s risk tolerance for unattended invoicing. If her firm runs standalone Project Operations, the near-term answer is to watch the MC1472430 preview closely rather than assume it will simply extend the same mechanism to her platform.

Microsoft’s release documentation for 2026 wave one describes the fee-journal capability specifically in the context of manufacturing deployments, and nothing in the public preview announcement confirms that the broader recurring billing framework will be deployment-agnostic once it reaches general availability. Firms that commit new client contracts to a subscription billing structure on the assumption that Project Operations will automate it end to end, without first confirming which platform variant they run, are setting up a manual workaround they did not budget for. That is an expensive mistake to discover six months into a new retainer agreement.

There is a real financial argument for making this move regardless of which deployment a firm is on, and it has less to do with saving a few hours of invoice preparation than with getting revenue recognition right. Because the fee-journal mechanism books WIP and accrual entries ahead of the customer invoice, it gives finance teams a documented, systematic separation between when value is delivered and when cash is billed. That separation is exactly what supports ASC 606 and IFRS 15 compliance for recognizing revenue independent of billing milestones. A firm still reconciling that gap manually in a spreadsheet, project by project, is carrying audit exposure that this feature is specifically built to remove. That argument for prioritizing the upgrade path is stronger than “we bill retainers and want less manual work,” even though the manual-work complaint is usually what starts the conversation.

Abstract illustration of a recurring billing cycle with glowing invoice nodes

What to Check Before the Next Contract Renewal Cycle

Before signing a new managed services or retainer agreement on the assumption that Project Operations will handle the billing automatically, confirm three things. First, identify which Project Operations deployment your organization actually runs, since the terminology in vendor conversations, and even in some Microsoft documentation, does not always make the distinction obvious to someone outside the implementation team. Second, if you are on the Finance-integrated deployment, treat this as a configuration and change-management project rather than a licensing question. Feature management settings, project stage rules, and the choice of posting behavior all need to be worked through with whoever owns your Dynamics 365 Finance environment before the first live billing schedule goes into production.

Third, if you are on standalone Project Operations, do not build a client-facing commitment around a preview feature. Track the Message Center entry, ask your partner directly whether the general availability scope will include your deployment type, and keep the manual process in place as a fallback until that answer comes back in writing rather than inferred from a roadmap post. Preview features are, by definition, subject to change, and a contract term written around one is a liability if the feature narrows or slips before it ships broadly.

The subscription billing announcement is a genuine step forward for firms trying to move recurring engagements off manual invoicing, and the fee-journal mechanism that already exists proves the underlying accounting model works in production. What it is not, yet, is a platform-wide capability every Project Operations customer can turn on this quarter. Firms that treat the distinction seriously now will spend less time unwinding a contract structure that outran their tooling. We have walked several clients through exactly this kind of platform-versus-roadmap gap during Project Operations rollouts, and the pattern holds: the tooling question is almost always simpler to answer once the deployment type is confirmed first, before a single retainer contract gets rewritten around a capability that may not yet apply to it.

#ProjectOperations #SubscriptionBilling #RevenueRecognition #ProfessionalServicesFinance #DynamicsFinanceOps #ERPGovernance

Dynamics Finance Ops ERP Governance Professional Services Finance Project Operations Revenue Recognition Subscription Billing

Subcontractor Vendor Invoice Matching Is GA in Project Operations. Ten Silent Fields Decide If It Works.

Project accountant reviewing a vendor invoice reconciliation dashboard for subcontractor cost matching

A project controller at a mid-size engineering firm spends the third week of every month reconciling subcontractor invoices against timesheets in a spreadsheet, because the vendor invoice that lands in accounts payable has no native connection to the hours a contract welder actually logged against a task. She cross-checks rates, dates, and task codes by hand, then emails the project manager to confirm before anything gets marked ready for payment. That reconciliation gap is exactly what general availability of subcontractor vendor invoice matching to actuals in Dynamics 365 Project Operations, reached this September as part of 2026 release wave 1, is meant to close. For any organization running resource-based or nonstocked subcontracting through Project Operations, this is worth a close look before the next AP cycle, not because the concept is new (a version of automatic matching has existed since 2022), but because the field-level logic determining whether a match actually happens is stricter, and less forgiving, than most implementation teams assume going in.

What subcontractor vendor invoice matching actually changes

Subcontract-based project delivery in Project Operations has always followed a familiar shape: a project manager creates a subcontract against a vendor, attaches purchase price lists, links time-based or expense-based subcontract lines to either generic team members (to represent a staffing need) or named contract workers (to draw down capacity), and lets subcontractor resources log time, expenses, or product usage against tasks. Once that work is approved, it generates project cost actuals priced from the subcontract’s purchase rate. None of that is new. What the newly GA capability changes is the connective tissue between those cost actuals and the vendor invoice line items that eventually get paid.

Before this feature matured, matching a vendor invoice line to the underlying cost actuals was either manual or dependent on earlier, more limited automatic-association logic. Now, when a project manager records a vendor invoice with a line referencing a subcontract, Project Operations attempts to associate matching cost actuals automatically, and gives the project manager a structured, auditable workflow (built around a Verification status field) to confirm, adjust, or reject those matches before the invoice becomes eligible for payment.

The match logic: what has to line up

This is the part implementers need to internalize before go-live, because it determines whether the automatic matching actually fires or silently leaves everything to manual review. For a cost actual to link to a vendor invoice line, two separate conditions both have to hold.

Abstract illustration of cost actual records linking to vendor invoice line items in a reconciliation chain

The first is a status condition: the cost actual’s Adjustment status field must be blank. If a cost actual has been recalled, if its approval was cancelled, or if a correction journal against it is in progress, it is excluded from matching entirely, and the system will not surface it as a candidate no matter how closely the other fields align. This one trips up teams during parallel testing more than any other rule, because test data frequently includes actuals that went through a correction cycle, and those actuals simply never appear in the unmatched list, with no error message explaining why.

The second is field equivalence, and this is the longer list: project contract, project contract line, transaction class, project, task, resource category, transaction category, product, subcontract line, and bookable resource. Every one of these fields on the vendor invoice line has to match the corresponding field on the cost actual for a link to be proposed. There is one important carve-out worth building into your test plan: if a field is simply not populated on the vendor invoice line, it is excluded from the comparison rather than treated as a mismatch. That sounds like a convenience, and in some cases it is, but it also means a sparsely populated invoice line can match against a broader set of cost actuals than a fully populated one would, which is not always the outcome an AP team expects when they are trying to enforce tight three-way matching discipline.

Verification status: the workflow project managers actually see

Once matching candidates exist, the project manager works through a Verification status field that moves through three states. Not started is the default state for a fresh vendor invoice line, and it is the only state in which the line remains freely editable. The moment the first cost actual is matched to that line, status automatically advances to In progress, and the line locks against further direct edits outside the matching interface itself. From In progress, the project manager reviews the matched actuals in a grid, can pull in additional unmatched actuals or remove ones that were matched incorrectly, and once satisfied, sets the line to Complete, either manually or through the system’s own completion logic once every actual on the line has been addressed. Only when every line on a vendor invoice reaches Complete can the invoice itself be confirmed, and confirming it is what flips the invoice to Ready for payment, reverses the previously recorded project cost actuals, and books the actual cost from the vendor invoice onto the project instead. That last step matters for anyone reconciling project cost reports mid-cycle: costs on a project can genuinely shift in value between the point a subcontractor’s time is approved and the point the corresponding invoice clears verification, and finance teams need to know that is expected behavior, not a data integrity problem.

Unmatching works, but only in one direction of the workflow. A project manager can select one or more linked cost actuals from a vendor invoice line’s Matched cost actuals tab and unmatch them, but only while that line sits in In progress status. Once a line reaches Complete, unmatching is no longer available through the standard interface, which is a deliberate control: it keeps a verified invoice from being quietly altered after AP has already relied on that verification to release payment.

Implementation considerations before rollout

A few practical points are worth working through with the project accounting team before turning this on for a live subcontracting population. Fixed Price billing is not currently supported for resource-based or nonstocked subcontracting scenarios, so any subcontract lines built around milestone-based fixed pricing need a different reconciliation approach; automatic matching in this feature applies to time-and-material subcontract lines where cost actuals are generated from logged, approved work. Teams that run a mix of fixed-price and time-and-material subcontracts on the same project should map out, line by line, which subcontract lines are even eligible for automatic matching before assuming full invoice coverage.

It is also worth auditing how consistently your existing vendor invoice entry process populates the ten matching fields. If your AP team has historically entered vendor invoice lines with only project and transaction class filled in, and left task, resource category, or bookable resource blank as a matter of habit, the matching engine will happily use whatever partial field set is present, and the practical effect is a much looser match than your controls team may assume is happening. Before rollout, walk through a sample of recent invoices with both project accounting and AP to agree on which fields will be entered consistently going forward, because the strictness of this feature is only as good as the discipline behind the data feeding it.

Finally, because this capability reached general availability in the same month as several other Project Operations updates, including changes to correction journal usability and project accrued revenue reconciliation, it is worth testing subcontractor invoice matching in a sandbox environment that reflects your current configuration rather than assuming behavior documented earlier in the release wave still applies unchanged. Microsoft’s release cadence for Project Operations has been dense enough this year that features shipped in preview back in May have, in some cases, had their default behavior refined by the time they reached GA in September.

Organizations that get the field discipline right stand to remove a genuinely manual, error-prone step from project-based AP, and the audit trail built into the Verification status workflow gives finance a defensible record of exactly which actuals supported each payment decision. Routeget’s implementation teams have walked several clients through exactly this kind of subcontract reconciliation redesign, and the pattern holds consistently: the technology is ready well before the underlying data entry habits are, and that gap is where rollout timelines usually slip.

#SubcontractorInvoiceMatching #ProjectOperations #DynamicsFinanceOps #ProjectAccounting #VendorInvoiceReconciliation #ERPGovernance

Dynamics Finance Ops ERP Governance Project Accounting Project Operations Subcontractor Invoice Matching Vendor Invoice Reconciliation

Business Central’s New Shopify Tax Matching Agent: What Confidence Levels Actually Tell You

Finance operations analyst reviewing a multi-state tax jurisdiction dashboard on a monitor

An integration consultant working a Shopify-to-Business-Central rollout will recognize this scenario immediately: an order comes through with sales tax already calculated at checkout, the sales order posts into Business Central, and three weeks later finance finds a jurisdiction mismatch during month-end reconciliation. Nobody did anything wrong. Shopify’s tax engine and Business Central’s tax engine simply disagreed about which jurisdiction, and which rate, applied to that ship-to address, and the native connector had no mechanism to catch that disagreement before posting. With Business Central 2026 release wave 2 (update 29.0), that changes. A new capability called the Tax Matching Agent enters public preview this month, with general availability set for October 2026 alongside the rest of update 29.0, giving technical teams a review checkpoint that has been missing from this integration since Microsoft first shipped it.

This piece looks at what the Tax Matching Agent actually reviews, what its confidence levels and rate differences mean in practice, and how it fits inside a broader set of Shopify connector changes landing in the same release that push the connector well past its original scope as a simple order-sync tool.

Why tax jurisdiction matching needed its own review step

Shopify calculates sales tax at checkout using its own nexus configuration and its own read of the customer’s shipping address. Business Central, when it creates the corresponding sales document, applies its own tax area and jurisdiction logic against that same address, through a separate calculation path, whether that path runs through Business Central’s built-in tax engine or a connected third-party service. The two were never designed to reconcile automatically. Most orders land on the same answer, since most addresses map cleanly to one unambiguous jurisdiction. The trouble shows up at the edges: marketplace facilitator states with their own filing rules, origin-versus-destination sourcing differences, home-rule jurisdictions layering municipal tax on top of state tax, and ship-to addresses that sit near a jurisdiction boundary. With no reconciliation step, those edge cases post silently and surface only when someone downstream, usually in accounting, notices the numbers don’t tie out.

That silent failure mode is really the problem the Tax Matching Agent solves. It isn’t that either system’s tax logic is wrong in some general sense. It’s that nobody was checking whether the two agreed, order by order, until now.

What the Tax Matching Agent actually does

Microsoft’s own description of the feature, as documented in the update 29.0 release notes, is precise about its scope: it lets a reviewer check suggested tax jurisdictions, confidence levels, and rate differences on a new Tax Match Review page before the sales document processes with sales tax. That phrasing matters. This is a pre-posting gate, not a background reconciliation job that fires after the fact and generates an exception report nobody reads until quarter close.

The design follows a pattern Business Central has already established with its other Copilot-based agents. The Payables Agent autonomously processes incoming vendor invoices and matches them to purchase orders, but it proposes posting accounts and flags routing exceptions for a human to resolve rather than posting blind. The Sales Order Agent handles incoming customer email requests and drafts a quote, but a person still reviews and sends it before anything commits. The Tax Matching Agent fits the same model: it does the comparison automatically, but the decision to accept a jurisdiction match, or override it, stays with the person reviewing the Tax Match Review page.

Confidence level and rate difference are the two pieces of information that page is built around, and they answer different questions. Confidence level reflects how closely the agent’s own jurisdiction assignment logic agrees with what Shopify calculated for that order, given the same ship-to and item data. Rate difference is the concrete dollar or percentage delta between the two calculations. A low confidence score with a near-zero rate difference is a very different situation from a high confidence score sitting next to a meaningful rate gap, and teams rolling this out should build their review workflow around that distinction rather than treating confidence level as a single pass or fail signal.

Part of a larger connector overhaul, not an isolated feature

The Tax Matching Agent didn’t ship alone. Update 29.0 adds four other Shopify connector capabilities in the same release, and understanding them together explains why the tax review step arrived when it did. Business Central now supports managing Shopify B2B companies, catalogs, and pricing directly, including mapping company tax identifiers and controlling price synchronization for whatever B2B capabilities a merchant’s Shopify plan includes. It adds handling for edited and exchanged Shopify orders, so changes and refunds on the Shopify side stay aligned with the sales documents already created in Business Central instead of drifting out of sync. It gives administrators explicit control over sales document creation, through Shopify Shop Card settings for order numbering and return processing, plus a contact review step before a sales document is created. And it adds tariff number and country-or-region-of-origin synchronization, through an HS Code and Country of Origin toggle on that same Shop Card, feeding into product synchronization tasks.

Abstract illustration of data flowing from an online storefront to an enterprise system through a validation checkpoint

Read alone, those four changes look like incremental connector maintenance. Read together with the Tax Matching Agent, they describe a connector being pushed past simple direct-to-consumer order capture and into territory that used to need a specialized middleware layer or a heavier custom build: B2B wholesale pricing, cross-border trade documentation, and multi-jurisdiction tax exposure. Each of those areas raises the stakes on getting tax right, which is presumably why the review agent landed in the same wave rather than as a standalone update later.

What technical teams should actually do with this

The preview window is worth using deliberately rather than skipping straight to general availability. Before update 29.0 reaches GA in October, teams running or planning a Shopify connector implementation should pull a sample of historical orders from exactly the jurisdictions known to be difficult: any home-rule state with meaningful order volume, ship-to addresses near a county or municipal boundary, and any state where marketplace facilitator rules changed how Shopify itself handles the calculation. Running those through the Tax Match Review page in preview, even manually, will say more about how the agent’s confidence scoring behaves than the release notes alone can.

It’s also worth being explicit about what this feature does not replace. If the organization already relies on a third-party tax determination engine, the Tax Matching Agent does not remove the need for that engine’s own jurisdiction and rate logic to be correctly configured. It adds a checkpoint between Shopify’s calculation and Business Central’s posting step; it does not become the tax engine itself. Treating it as a substitute for properly maintained tax setup, rather than a safeguard on top of it, is the surest way a team ends up disappointed after rollout.

The review process itself needs a threshold, not a habit of clicking through. A team that reviews every flagged order with equal scrutiny will either burn out and start rubber-stamping everything, defeating the point of the agent, or grind order processing to a crawl. A more workable approach sets a materiality threshold on rate difference, so small variances route to whoever normally processes sales orders, while anything above the threshold, or a persistently low confidence score from a specific jurisdiction, escalates to a tax specialist who can check whether the underlying nexus or tax area configuration needs correcting, rather than approving the same exception every time it appears.

One coordination point matters more than it might seem at first. Shopify’s tax and nexus settings are frequently owned by the e-commerce or marketing team, not finance or the ERP administrator, and a meaningful share of the mismatches this agent surfaces will likely trace back to Shopify-side configuration drift rather than anything wrong on the Business Central side. A feedback loop that gets a pattern of flags on the Tax Match Review page back to whoever manages the Shopify store’s tax settings, not just to the person clicking approve, is what turns this from a reporting tool into an actual fix.

The takeaway

The Tax Matching Agent doesn’t make the underlying tension between two independently calculated tax engines disappear, and Microsoft’s own preview disclaimer is a fair reminder that the exact behavior at GA could still shift before October. What it does is take a failure mode that used to stay invisible until reconciliation, or until an auditor asked an uncomfortable question, and put it in front of a person before the document posts. That visibility is usually worth more than automation would have been. The pattern holds across other e-commerce-to-ERP engagements we’ve worked: the tax gap was rarely a defect in either system so much as an unmanaged handoff between two logics that never talked to each other. The handoff finally has a checkpoint, and a technical team that uses the preview window to learn how it behaves in its own jurisdictions will be in a far better position than one that waits for GA and finds out the hard way.

#BusinessCentral #ShopifyIntegration #SalesTaxCompliance #ERPGovernance #DynamicsFinanceOps #EcommerceERP

Business Central Dynamics Finance Ops Ecommerce ERP ERP Governance Sales Tax Compliance Shopify Integration

Configuring Dynamics 365’s Account Reconciliation Agent for Inventory Reconciliation

A finance controller reviewing an inventory reconciliation dashboard on a monitor in a modern office

A month-end close checklist at most Dynamics 365 Finance and Supply Chain shops still has one item that nobody has managed to automate: tracing the gap between what the inventory subledger says and what the general ledger shows. Bank reconciliation got an AI agent built for it years ago. Accounts payable and accounts receivable followed. Inventory sat in a spreadsheet, worked by whoever drew the short straw that quarter, because the subledger has more moving parts, more valuation methods, and more timing quirks than a bank statement ever will. That changes with Dynamics 365’s Account Reconciliation Agent reaching general availability this month, expanded in the 2026 release wave 1 to cover inventory as a reconciliation area for the first time.

The catch, and the reason this article exists, is that flipping a feature flag on an inventory-aware reconciliation agent is not the same thing as getting accurate reconciliation out of it on day one. Inventory data is messier than bank or AP data by nature: multiple valuation layers, physical-versus-financial timing gaps, and cycle count adjustments that post on their own schedule. An agent that is good at pattern-matching transactions will happily flag hundreds of false exceptions if the underlying setup hasn’t been prepared for it. This piece walks through what actually changed in the 2026 wave 1 update and where inventory reconciliation specifically breaks if you skip the preparation work.

Abstract illustration of data connections between warehouse inventory and a financial general ledger

What’s New, and What’s Still on the Roadmap

The Account Reconciliation Agent itself is not new. It moved from public preview in April 2025 to a production-ready state covering four reconciliation areas: bank reconciliation, accounts payable, accounts receivable, and tax reconciliation. What the 2026 release wave 1 update adds is inventory as a fifth area, surfaced directly inside the existing Account Reconciliation workspace with the same suggested-action model finance teams already use for bank and AP exceptions. Fixed assets, project accounting, and intercompany reconciliation are on Microsoft’s stated roadmap for the agent, but as of this writing they remain planned expansions rather than shipped capability, so any implementation plan that assumes they’re available today needs correcting before it goes further.

Alongside the new reconciliation area, the update brings three changes worth planning around. Matching accuracy improved across one-to-one, one-to-many, and many-to-many transaction patterns, with fuzzy logic and tolerance rules that reduce the number of near-misses requiring a human decision. A bulk actions interface lets a controller approve or reject a batch of matched exceptions at once, which matters more for inventory than bank reconciliation simply because inventory subledgers generate far more line-level transactions per period. And the agent now feeds into a unified AI ERP agent feed, using Model Context Protocol integration, so it functions less like a standalone tool and more like one node in a broader reconciliation orchestration layer.

Prerequisites Before You Touch Feature Management

The setup sequence looks simple on paper. Enable the Account reconciliation agent feature (along with Immersive homepage and Agent management) in Feature Management, install the required Copilot for Finance and Operations apps at a current version, create a dedicated agent identity with Finance and Operations basic user, Account reconciliation agent, and Environment maker roles, then activate the reconciliation template under Modules > Agents. Environments should be on a reasonably current Dynamics 365 Finance build, since the underlying agent framework has moved fast enough that anything more than a few releases behind will hit missing dependencies during activation.

What the documentation doesn’t spell out clearly enough for inventory specifically is that the agent inherits whatever inconsistencies already exist in your item and dimension setup. If two warehouses post to the general ledger through different posting profiles but share an item number, or if a site’s financial dimensions don’t align cleanly with the legal entity boundary the agent expects, you will see that surface as reconciliation noise rather than a setup error, and it’s much harder to debug from inside an exception queue than it is to catch beforehand in a configuration review.

Why Inventory Breaks the Account Reconciliation Agent’s Usual Logic

Bank reconciliation compares two relatively clean feeds: what the bank says cleared and what the ledger says was posted. Inventory reconciliation compares a physical, cycle-count-driven world against a financial, standard-cost-or-moving-average world, and those two worlds are allowed to disagree temporarily by design. A cycle count adjustment might hit the subledger the day it’s counted but not post to the general ledger until a batch job runs overnight. A partial warehouse transfer can leave inventory in transit for days, showing up as a discrepancy that isn’t actually wrong, just incomplete. None of this is a flaw in the agent. It’s a mismatch between how the agent is tuned to think about timing and how inventory transactions actually move through a supply chain.

The practical fix is configuring exception limits and tolerance thresholds specifically for inventory before turning the agent loose across every warehouse. Start with the participating modules list and put inventory last in priority order relative to the reconciliation areas you already trust, so early exceptions surface where you have the most institutional knowledge to evaluate them. Set daily or monthly exception limits conservatively at first. If the agent hits that ceiling and stops processing, treat it as a signal to review configuration rather than simply raising the limit, because a ceiling that gets hit immediately after activation usually means the underlying data alignment work wasn’t finished, not that the agent needs more headroom.

Getting Matching Rules and Bulk Actions Right

The fuzzy logic and tolerance rule improvements in this release matter most for inventory because standard cost variances and rounding differences across unit-of-measure conversions generate small-dollar mismatches by the hundreds in a typical mid-sized F&O environment. Configure tolerance thresholds by materiality rather than using one blanket percentage across every item category. A $2 variance on a high-volume, low-cost SKU is noise; the same dollar variance on a low-volume, high-value asset-tracked item might be worth a human look. Once tolerance rules are tuned, the bulk actions interface lets a controller clear a screen of small matched variances quickly, reserving individual attention for exceptions that actually cross a materiality line.

Route anything that doesn’t resolve cleanly through the same governance model you’d apply to any other automated journal entry process. Restrict which roles can approve journal entry creation or reversal suggestions coming out of the agent, separate from the roles that can simply view or dismiss exceptions, and confirm the agent activity log is actually being reviewed rather than treated as a compliance checkbox nobody opens. The audit trail Microsoft built into this feature is genuinely useful, but only if someone is reading it.

A Rollout Sequence That Doesn’t Blow Up Month-End

Test the configuration against a copy of production data before activating against a live environment, and pilot with a single legal entity or even a single warehouse rather than switching every site on simultaneously. Run the agent in parallel with your existing manual reconciliation process for at least one full close cycle so you have a direct comparison of what it caught, what it missed, and what it flagged incorrectly. Only after that comparison looks clean should inventory reconciliation actually replace the manual process. Teams that skip this step tend to discover their false-exception rate during the highest-pressure week of the quarter, the worst possible time to debug a dimension mapping issue.

Schedule a recurring cadence, daily during the first month and weekly afterward, to review whatever exceptions the agent surfaces rather than letting them accumulate until close. This is less about the agent’s capability and more about organizational discipline: an automated reconciliation tool that only gets checked once a month at close doesn’t actually save the time it promises, because the exceptions still pile up and still need triage, just later and under more time pressure.

Where This Leaves Finance and Technical Teams

The inventory expansion of the Account Reconciliation Agent is a genuine step forward for organizations that have been reconciling inventory subledgers by hand or through custom SSRS reports for years, and the matching, bulk action, and orchestration improvements in this release apply across every reconciliation area the agent supports, not just the new one. But general availability of a capability and readiness to depend on it in a live close process are different milestones. The teams that get real time savings out of this update treat the first thirty to sixty days after activation as a controlled pilot with tight tolerance rules and close human review, not as a switch flipped once and forgotten. We’ve walked several Dynamics 365 F&O clients through exactly this kind of phased agent rollout at Routeget Technologies, and the pattern holds every time: the configuration and data alignment work up front determines whether an AI reconciliation agent actually shortens close, or just moves the manual effort into a different queue.

#AccountReconciliationAgent #DynamicsFinanceOps #InventoryReconciliation #D365FO #FinanceAutomation #ERPGovernance

Account Reconciliation Agent D365 FO Dynamics Finance Ops ERP Governance Finance Automation Inventory Reconciliation