The Business Central Payables Agent Drafts Invoices. It Still Won’t Match a Purchase Order.

Finance professional reviewing an AP invoice matched against a purchase order and receipt on a computer dashboard

A controller at a mid-sized distributor recently described the moment her AP team realized what they’d actually bought. A vendor emailed a PDF invoice to the shared mailbox Business Central was watching, and within a few minutes the Business Central Payables Agent had pulled the vendor, mapped the line items to a G/L account, and dropped a fully drafted purchase invoice into the review queue. It looked like the AP clerk role had been automated away. Then someone asked whether the agent had checked the invoice against the purchase order or the goods receipt behind it, and the honest answer was no. It never does. Purchase order matching sits on Microsoft’s own published list of things the Payables Agent explicitly does not do, right alongside approval flows and anomaly detection.

That gap matters more than it sounds like it should, because Microsoft shipped a separate, unrelated feature in the same Business Central 2026 release wave that does handle order and receipt matching, and the two are easy to mistake for one connected capability. They are not. Understanding where the line actually falls is the difference between a rollout that genuinely reduces AP workload and one that quietly removes a control your finance team assumed was still there.

What the Business Central Payables Agent Actually Automates

The agent’s job starts and ends with turning an inbound PDF into a usable draft. It monitors a dedicated mailbox, pulls unread invoice emails, and runs each attached PDF through Azure Document Intelligence to extract the vendor name, amounts, and line detail. From there it tries to match the sender to an existing vendor record in Business Central; if it can’t do that confidently, it stops and asks a designated supervisor for instructions rather than guessing. When a new vendor genuinely needs to be created, the agent prefills the card from what it read off the invoice, but the record comes in blocked by default until a person reviews and releases it. Only after the vendor question is settled does the agent move to drafting the invoice itself, using historical purchasing patterns and item references to suggest which G/L accounts the line items belong to.

Finance professional reviewing an AP invoice matched against a purchase order and receipt on a computer dashboard

None of that becomes a posted transaction on its own. Every draft lands in a review queue where a human has to confirm, correct, or reject it before it becomes an actual purchase invoice, and Microsoft is direct about why: the agent’s account classifications and vendor matches “can be inaccurate,” and it has no way to evaluate business context the way a person reviewing the invoice would. That’s a reasonable design for what the agent is built to do, which is eliminate the manual keying and re-typing that eats the first half of most AP cycles. It is not built to answer the question of whether what you’re about to pay actually matches what was ordered and what showed up on the dock.

The Three-Way Match Gap Nobody’s Marketing Slide Mentions

Three-way matching, the practice of confirming an invoice against its purchase order and its receipt before payment, is the control most finance organizations rely on to catch overbilling, duplicate charges, and phantom deliveries. The Payables Agent doesn’t perform it. That’s not a bug or an oversight Microsoft is quietly working around; it’s a documented limitation, and as of this writing the agent itself is still labeled a public preview release rather than a finished, generally available feature.

What makes this genuinely confusing for a rollout is that the same 2026 wave 1 release also introduced “Match Purchase Invoices to Multiple Order and Receipt Lines,” a completely separate, non-AI capability built directly into standard purchase order processing. It adds a “Get Order Lines” action that surfaces received-but-uninvoiced or unreceived order lines, a “Matched Order Lines” page for reviewing and adjusting how invoice lines tie back to multiple purchase orders and partial receipts at once, and a “Receipt on Invoice” toggle that can auto-generate the receipt when a linked invoice posts. It reached general availability in April 2026, on its own timeline, with its own set of exclusions that keep it away from prepayment orders, item charges, projects, subcontracting, blanket orders, and intercompany transactions. Nothing in Microsoft’s documentation ties these two features together, and there’s no evidence the Payables Agent hands its drafts off into this matching workflow automatically. They simply shipped in the same release, aimed at the same purchase-to-pay process, and solve two different halves of the problem without talking to each other.

The practical result is that an AP team running the Payables Agent still needs to run invoices through order and receipt matching separately, whether that means the new native matching screens, an existing three-way-match process, or a third-party tool already in place. Treating the agent’s fast, clean drafts as evidence that matching already happened is exactly the kind of assumption that erodes a control environment quietly, one invoice at a time, until an audit or a duplicate payment surfaces the gap.

Consumption Billing Changes How You Budget for This

The licensing model adds a second layer finance leaders need to plan around before anyone flips this on for real volume. Copilot itself is bundled into Business Central’s Essentials and Premium subscription tiers, so the base chat and suggestion features a user sees day to day don’t carry a separate charge. Agents are different. The Payables Agent runs on Copilot Credits, a metered unit purchased through an Azure subscription, and consumption scales with how much work the agent actually does rather than with how many people are logged in. Microsoft’s own guidance is candid that it doesn’t publish a flat per-invoice rate; credit consumption depends on which features get used and what actions the agent performs on a given document, which means the honest answer to “what will this cost us” only comes from watching it run.

Hands comparing a printed purchase order against an invoice on a laptop screen during AP review

That variability lands at an awkward moment for most finance calendars. Invoice volume tends to spike at quarter-end and during seasonal peaks, which is precisely when a consumption-based bill is likely to jump, and precisely when a finance team has the least appetite for a surprise line item. Organizations used to a flat per-seat software cost don’t automatically have a forecasting habit built for variable, usage-driven spend, and marketing language that blurs “Copilot is included” with “the agent is included” doesn’t help anyone build one. There’s also a governance detail worth knowing before you assign ownership: viewing actual billing and consumption detail requires the SUPER or AGENT-DIAGNOSTICS permission set specifically. The narrower AGENT-ADMIN role that would typically administer the agent day to day does not, by itself, grant visibility into what it’s costing, so whoever ends up accountable for the Azure bill needs to be deliberately provisioned, not assumed.

What This Means for a Rollout Decision

None of this argues against adopting the Payables Agent. For an AP team drowning in PDF invoices that arrive by email in a single language, it removes a real chunk of manual entry, and the human-in-the-loop design means it isn’t going to post something wrong without a person signing off first. The documented ceilings are worth checking against your own volume before you commit to it as a strategy rather than a pilot: the agent tops out at 500 processed invoices and 100 monitored emails per day per environment, it’s validated for English only, it only reads PDF attachments up to a handful of pages and a few megabytes each, and it will not touch approval workflows or flag anomalies on its own. A high-volume, multi-language AP operation with heavy PO-based purchasing is going to run into those edges quickly.

The more useful framing for a CIO or CFO evaluating this isn’t “should we turn on AI for accounts payable.” It’s two separate questions that deserve two separate answers: does this reduce the manual work our AP team does today, and does it strengthen or weaken the matching controls we already rely on. The first answer, for the right invoice profile, is genuinely yes. The second, at least for now, is that the agent doesn’t touch that control at all, and the feature that does was built and shipped on its own, waiting to be adopted separately. Firms we’ve worked with on Business Central Copilot rollouts have had the smoothest results when they scoped the agent narrowly, ran it against real invoice volume for a full billing cycle before expanding it, and kept three-way matching exactly where it already lived rather than assuming the new AI layer had absorbed it.

#BusinessCentral #PayablesAgent #APAutomation #CopilotCredits #ThreeWayMatch #ERPGovernance

Business Central Expense Management Reaches GA in October. The License-Free Path Isn’t Actually Free.

Finance director reviewing an expense report approval dashboard in a modern office

If your Concur or Expensify renewal is sitting in front of your CFO this quarter, the timing is inconvenient. Microsoft is about to ship native Business Central expense management, a module inside Dynamics 365 Business Central that had been dismissed by practitioners as a minor, checkbox-only feature when it first appeared on the 2026 release wave 1 plan back in April. It no longer looks minor. Between the original release plan entry and the general availability date now set for October 2026, Microsoft quietly attached an AI-driven Expense Agent to the module that covers most of the ground people assumed only a dedicated T&E platform could handle: receipt scanning, mobile capture, email submission, mileage calculation, and policy compliance checks that flag violations before an expense report ever reaches a manager. For an IT Director or finance leader weighing whether to sign another year of a third-party contract, that changes the question from “does Business Central do expenses now” to “is it ready enough to consolidate onto, and what will it actually cost.”

Finance director reviewing an expense report approval dashboard in a modern office

What changed since Business Central expense management was first announced

When Business Central’s expense reports feature first showed up on the release plan, at least one well-known practitioner in the ecosystem publicly predicted it would fall flat. His reasoning was straightforward: without receipt capture, mobile submission, or corporate card integration, a native module was never going to pull organizations away from Concur or Expensify, tools built around exactly those capabilities. That skepticism was reasonable at the time, because the initial description of the feature read like a manual, form-based expense report tool bolted onto the general ledger.

What shipped alongside it in preview is a different story. The Expense Agent, which Microsoft documents as a production-ready preview feature, performs the parts of the workflow that used to require a third-party app: it reads a receipt image or PDF, extracts merchant, amount, date, and category, calculates mileage reimbursement against a configured company rate, and groups related expenses into a report automatically. Submission works through a dedicated web app, a mobile app with camera capture and offline support, direct email to an organization’s expense mailbox, or a Copilot chat interface inside Microsoft Teams. None of that requires opening Business Central at all. What Microsoft’s current documentation does not describe, at least not yet, is automatic reconciliation against corporate card statement feeds, a feature dedicated expense platforms have offered for a decade and that larger organizations in particular tend to depend on. That gap is worth watching, not dismissing; it may simply not have been documented yet ahead of GA.

The workflow, and who actually needs a Business Central license

The module organizes expenses through a status flow that will look familiar to anyone who has used a modern expense tool: Open, Pending Approval, Released, Approved, Rejected, Processed for Payment, and Completed. An employee can enter mileage, add participants to a shared expense, itemize a single receipt into multiple categories, or split a hotel bill into refundable and non-refundable lines when part of it (the minibar, say) falls outside policy. A manager reviews and approves or rejects from within that same flow, and an accountant posts approved reports to generate Expense Ledger Entries and drive reimbursement, with posting accounts controlled through Expense Categories and Expense Posting Groups an administrator sets up in advance.

Employee capturing a paper receipt with a smartphone for expense report submission

The detail that deserves the most attention from a finance leader is licensing, because it does not follow the pattern most Business Central features do. An employee who only submits expenses, whether through the web app, email, or the Copilot chat interface, does not need a Business Central license at all. That sounds like a straightforward cost win until you read the next line: that access method draws on Copilot Credits instead. Anyone who needs to open Business Central itself to manage or approve reports needs at minimum a Team Member license, and posting the reports and processing payment requires Essentials or Premium. So the module has effectively three separate cost levers rather than one: a consumption-based charge for expense-only submitters routed through Copilot Credits, a per-user subscription cost for anyone touching the module inside Business Central proper, and the underlying Essentials or Premium tier required to post anything at all. None of that is disclosed as a flat number in Microsoft’s documentation, which does not publish a specific Copilot Credit consumption rate for expense processing the way it has for some AI Builder scenarios.

Why that licensing structure matters more than the feature list

A CFO comparing this against a Concur or Expensify renewal is not just comparing feature checklists. They are comparing a predictable per-seat SaaS cost against a hybrid model where the cost of casual expense submitters scales with Copilot Credit consumption, a metric most finance teams have no historical baseline for. An organization with 40 people who occasionally submit an expense report and five people in finance who approve and post them will have a very different cost profile than one with 400 field employees submitting receipts weekly through the mobile app, even though both fit inside the same license categories. Before treating this as a straight replacement decision, it is worth actually modeling that consumption, not estimating it, because Copilot Credits behave differently from a fixed per-user fee and can move with usage in ways a traditional T&E contract does not.

There is also a timing consideration that is easy to overlook. As of this writing, the module and its Expense Agent are still labeled a production-ready preview, meaning Microsoft considers it stable enough to run in production but reserves the right to change it, and it operates under supplemental preview terms of use rather than Business Central’s standard product terms. October 2026 is the stated general availability date, but Microsoft’s own release plan documentation carries the standard disclaimer that projected functionality and delivery timelines may change. Organizations with a Concur or Expensify contract expiring in the next renewal cycle should treat October as a target to validate against, not a date to build a migration plan around before it actually happens.

What to do before the next contract renewal

The practical path for a finance or IT leader facing this decision now is a short, deliberate evaluation rather than an early commitment in either direction. Set up the module in a sandbox environment, route a real slice of a month’s expense volume through the Expense Agent’s mobile and email submission paths, and track how many receipts require manual correction after the AI extraction step, since the documentation itself notes that users should expect to review and correct results rather than trust them blindly. In parallel, ask your Business Central partner or internal admin to estimate Copilot Credit consumption against your actual expense submission volume, not a generic average, since that number is the one piece of this decision Microsoft has left for each organization to work out on its own. If your current Concur or Expensify agreement has a shorter renewal term available, or a month-to-month bridge option, that flexibility is worth paying for this cycle specifically so the decision isn’t forced before GA lands and the Copilot Credit math has a real quarter of data behind it.

None of this means the module isn’t a legitimate option. For organizations with straightforward expense policies, modest transaction volume, and no dependency on corporate card feed reconciliation, native Expense Management removes a genuine integration cost and keeps expense data inside the same ledger as everything else. Routeget Technologies has walked several Business Central clients through exactly this kind of licensing and consumption modeling ahead of a platform consolidation decision, and the pattern holds: the module’s capability gap has closed faster than the ecosystem expected, but the cost model needs its own diligence before it replaces a contract that already works.

#BusinessCentral #ExpenseManagement #ERPLicensing #CopilotCredits #FinanceTransformation #SMBERP #DynamicsBusinessCentral

An AI Builder Prompt Inside a Copilot Studio Agent Skips Your AI Builder Credits. It Draws From Copilot Credits Instead.

Solution architect reviewing an AI agent cost analytics dashboard on a large office monitor

A solution architect at a mid-market manufacturer spent the spring building a Copilot Studio agent to triage vendor emails: pull the invoice number, classify the request type, draft a reply for a human to approve. The extraction logic ran through an AI Builder custom prompt, the same kind the finance team had already been using inside a Power Automate flow for months. The architect assumed the agent’s usage would draw from the same AI Builder credits the company had already purchased through a capacity add-on for that flow. It didn’t. Three weeks after the agent went live, the Copilot Credits pool that governed an entirely different project ran dry, and nobody could explain why until someone actually read the fine print on how AI Builder prompts get billed once they leave Power Automate and start running inside an agent.

This is not a hypothetical edge case. It is the direct, documented behavior of how Microsoft splits AI Builder consumption across its two billing meters, and it matters to anyone scoping a Copilot Studio project that leans on AI Builder for extraction, classification, or generative text work. The split is simple to state and easy to miss: AI Builder credits, whether seeded through a license or purchased as a capacity add-on, only ever pay for AI Builder usage inside Power Apps and Power Automate. The instant that same prompt is wired into a Copilot Studio agent, whether through a topic, an agent flow, or an AI plugin, the meter that runs is Copilot Credits, full stop, regardless of how much unused AI Builder capacity sits in the tenant.

How an AI Builder Prompt Actually Gets Into an Agent

There are three distinct ways to wire an AI Builder prompt into a Copilot Studio agent, and they carry different reliability and governance tradeoffs worth understanding before picking one for a production scenario. The first is a Prompt Action, built through Copilot Studio’s own five-step wizard: name the action, write the prompt with its input variables, map inputs and outputs, test it, and publish it as a general availability capability that Copilot for Microsoft 365 can invoke directly. The second is a Topic Node, where a “Call an action” step inside a scripted topic calls a custom prompt built inline, giving a developer explicit control over exactly when the prompt fires within a defined conversation flow rather than leaving invocation to the model’s own judgment. The third, still in preview, is an AI Plugin, where the agent decides on its own whether a user’s phrasing matches the prompt’s description closely enough to invoke it, which is convenient for open-ended agents but introduces a layer of semantic matching that a cost-sensitive, high-volume scenario probably should not depend on without testing it thoroughly first.

Each of these paths has a quirk worth planning around. Newly published actions can take a few minutes to actually appear inside the live agent experience, which has tripped up more than one team mid-demo. And because AI Plugin invocation depends on the model correctly matching a user’s intent to a prompt’s written description, a poorly worded action description will simply never fire, silently, with no error to debug against; the fix is almost always writing a sharper, more literal description of what the prompt does and when it should be used, not adjusting the prompt itself.

Close-up of hands on a keyboard with a dual-monitor setup showing an AI agent builder interface and a billing usage graph

How AI Builder Credits and Copilot Credits Actually Split

Microsoft’s own AI Builder credit management documentation states plainly that AI prompts run on AI Builder credits “in the context of Power Apps and Power Automate flows.” Its companion licensing page, updated as recently as June 2026, closes the loop on the other side: every AI Builder capability used inside a Copilot Studio agent, whether that’s a prompt fired from a topic, an action, or an agent flow, consumes Copilot Credits instead. There is exactly one carve-out, and it is a narrow one: prompts triggered from the agent’s own embedded test panel during development do not consume credits at all. Once that same prompt is live and being called by an actual conversation, real users, real credits.

The rate table behind that consumption is tiered in a way that rewards knowing which tier a given prompt actually needs. Basic text and generative tools run at roughly a tenth of a Copilot Credit per thousand tokens, characters, images, or pages processed. Standard-tier tools run fifteen times that rate, and premium-tier generative models run a hundred times the basic rate. Content processing tools, the category that covers document and image-heavy extraction work, run at eight Copilot Credits per image or page regardless of tier. An architect who defaults every prompt in an agent to the most capable underlying model available, out of an understandable instinct to maximize accuracy, can inflate the agent’s running cost by two orders of magnitude compared to a version that used a standard-tier model for routine classification and reserved the premium tier for genuinely ambiguous cases.

This distinction also reframes how a team should think about the AI Builder seeded-credit removal scheduled for November 1, 2026, when Microsoft strips seeded AI Builder credits out of existing license entitlements and stops selling new AI Builder capacity add-ons to net-new customers entirely. For a team whose AI Builder usage lives mostly inside Power Automate flows, that deadline is a real budgeting event requiring a Copilot Credits purchase to replace lost capacity. For a team whose AI Builder usage lives mostly inside Copilot Studio agents, the deadline changes almost nothing, because that usage was never drawing on AI Builder credits to begin with. Knowing which bucket a given deployment actually falls into, before the deadline rather than after, is the entire point of understanding this split.

Building a Cost Model Before Scaling an Agent

The practical move for a technical team is to treat cost measurement as a required step before an AI Builder-backed agent goes anywhere near production traffic, not an afterthought handled through a monthly invoice review. Run the agent through a realistic volume of test conversations in a sandbox environment first, using the same prompts, the same model tiers, and roughly the same document sizes the production scenario will see, then check the Copilot Credits consumption reported in the Power Platform admin center against the AI Builder consumption reported separately for the same period. The two numbers will not match the way a team accustomed to Power Automate-only AI Builder usage might expect, and that mismatch is the whole exercise.

It is also worth deliberately testing each invocation path’s actual reliability under realistic phrasing before committing to it for anything customer-facing. A Topic Node call is deterministic: it fires exactly when the flow logic says it should, which makes its cost entirely predictable and its behavior easy to audit. An AI Plugin action is probabilistic in comparison: it fires when the model believes it should, based on matching user language to a written description, which means its cost and its behavior both carry a margin of uncertainty that shrinks with better description writing and testing but never fully disappears. For a scenario where getting the wrong answer, or no answer, actually costs the business something, that tradeoff deserves to be a documented decision, not a default nobody examined.

None of this is a reason to avoid combining AI Builder with Copilot Studio; the pairing is genuinely useful, and it is how most organizations will end up bringing extraction and classification capability into a conversational agent without building a custom model from scratch. Routeget Technologies has walked several clients through exactly this kind of agent-cost modeling exercise before a production rollout, and the pattern is consistent: the surprise is never that the technology doesn’t work, it’s that the invoice arrives against a different budget line than the one everyone was watching. Building that visibility in during the design phase, rather than discovering it after a month of live traffic, is the difference between a predictable agent rollout and an uncomfortable finance conversation.

#AIBuilder #CopilotStudio #CopilotCredits #AgenticAI #PowerPlatformLicensing #EnterpriseAI

Case Management Agent Shadow Mode Won’t Save You From the Credit Bill

Customer service operations analyst reviewing AI case prediction dashboards

A Dynamics 365 Customer Service admin at a mid-size insurer recently asked a reasonable question in a planning meeting: if Case Management Agent can draft responses and reclassify inbound support email on its own, why not just turn it on for one team and watch what happens? The answer, as it usually is with autonomous case handling, is that “watching what happens” after the agent has already sent a reply or changed a case status is not watching, it’s cleanup. Case Management Agent shadow mode exists specifically to close that gap, and it reached general availability in May 2026. What it does not do is make that validation free, and the fine print around it is messier than the release notes suggest.

Shadow mode lets a case update rule generate everything Case Management Agent would normally act on: the identified customer intent, a drafted response, proposed field updates, and a recommended resolution path, without sending a single email or writing a single change to a live case. Administrators and CSR managers get a dedicated shadow results view where they can open a case, see what the agent would have done, and compare it against what a human agent actually did. That comparison is the entire point: it turns “we think the AI is ready” into a defensible, case-by-case answer before anyone flips the switch on autonomous handling for a whole queue.

Customer service operations analyst reviewing AI case prediction dashboards

What Case Management Agent Shadow Mode Actually Validates

The mechanics matter more than the marketing description. Shadow mode is enabled per case update rule, not per agent, per queue, or per line of business. On the Case creation and update page, under Case update by AI agent (any channel), you select an individual rule and choose Shadow mode from the toolbar; the rule’s status changes accordingly. That granularity is a feature and a trap in the same breath. It means you can pilot the agent’s behavior on a narrow slice of traffic, say, billing inquiries routed through one specific rule, without touching anything else. It also means that if your case management setup has a dozen rules covering different email types, languages, or business units, validating the agent properly means walking through each rule on its own rather than assuming one clean test covers the whole configuration.

Once a rule is running in shadow mode, reviewers pull up results through Review shadow runs, which surfaces old and new values side by side, grouped by case, with each case expandable to show every shadow response tied to it. For a technical team, this is genuinely useful data: you can see not just whether the agent’s classification matched reality, but whether its drafted response tone, its proposed field updates, and its resolution recommendation would have held up. That level of visibility is a meaningfully higher bar than most organizations apply before turning on any AI-driven automation, and it’s worth using deliberately rather than as a two-day formality before go-live.

The Cost Nobody Budgets For

Here is the detail that gets lost between the release plan bullet point and the actual rollout plan: shadow mode consumes Copilot or AI credits in exactly the same way live predictions do. Running a rule in shadow mode for three weeks across a meaningful volume of cases is not a free dry run, it is a second production workload layered on top of whatever else is drawing from the same consumption pool. Teams that budgeted AI credits for the automation itself, and treated validation as a rounding error, are the ones who get an uncomfortable surprise on the Azure bill partway through a pilot.

There’s a licensing prerequisite tied to this that’s easy to miss during a proof of concept. Shadow mode, like the broader autonomous case agent framework it belongs to, requires the Power Platform pay-as-you-go plan with Azure subscription consumption-based billing already configured. If your organization is running Dynamics 365 Customer Service on a standard licensing model without PAYG enabled, shadow mode is not a checkbox you flip in an afternoon. It’s a procurement and finance conversation that needs to happen before the technical team can even start the guided setup for Case Management Agent, which is itself a prerequisite for shadow mode to appear as an option at all.

Technology professional reviewing side-by-side data validation comparison on screen

A GA Feature Microsoft’s Own Documentation Still Calls Preview

This is the part worth flagging directly rather than glossing over. The 2025 release wave 2 plan lists shadow mode’s general availability date as May 2026, and it has been publicly available since then. But the current administrator documentation for enabling it states plainly that shadow mode “is a preview feature and isn’t meant to be used in production environments,” and ties usage to Microsoft’s supplemental terms of use for preview features rather than standard product terms. That is not a minor wording inconsistency. For a regulated organization (an insurer, a bank, a healthcare provider) the difference between a GA feature and a preview feature governs what a compliance or vendor-risk team will actually sign off on, and which support commitments apply if something goes wrong.

There are two ways to read this gap. One is that Microsoft’s release-plan GA date refers to the feature’s availability in the product, while the standing administrator guidance simply hasn’t been updated to match, which would not be the first time a fast-moving Copilot feature outpaced its own documentation. The other is that shadow mode genuinely still carries preview-level support and terms regardless of what the release plan says, and the GA label refers only to it no longer requiring a preview opt-in toggle. Neither interpretation is confirmed by anything Microsoft has published, and a team relying on shadow mode’s output to justify a production automation decision should treat that ambiguity as a real governance question, not a documentation typo to shrug off.

Pairing Shadow Mode With the New Classification Features

Shadow mode is most useful right now paired with the classification capabilities Microsoft shipped alongside it. Email classification into administrator-defined categories reached general availability on April 10, 2026, letting Case Management Agent tag inbound email based on subject and body content before anything downstream (unified routing, Automatic Record Creation rules, Power Automate flows, or reporting) ever touches it. That expanded into a full taxonomy of categories and subcategories on August 21, 2026, giving organizations a hierarchical structure instead of a flat list.

The practical implementation sequence follows from how much of the platform now depends on that category value. Because routing rules, ARC logic, and reporting all key off the classification attribute, a wrong category assignment doesn’t just mislabel one email, it can misroute a case, trigger the wrong automation, or quietly skew the metrics a supervisor is using to staff a queue. Running the classification rule in shadow mode first, and specifically checking whether the predicted category and subcategory match what a human agent would have assigned, is a more honest test of readiness than checking whether the agent’s drafted response reads well. A well-written response built on a wrong classification is still a routing failure waiting to happen.

What to Check Before You Rely on This

Before treating shadow mode results as sufficient sign-off, confirm three things. First, that the security role doing the review actually has CSR Manager or Customer Service Representative access, since the shadow results view isn’t exposed to every role by default. Second, that the guided setup for Case Management Agent has been completed correctly upstream, because shadow mode inherits whatever intent recognition and field-update logic that setup produced; a poorly configured agent will look exactly as unreliable in shadow mode as it would in production, which is the point, but only if the setup itself was done right. Third, that whoever owns the Azure consumption budget knows shadow mode is running and for how long, since a validation period with no defined end date is how credit consumption quietly becomes a permanent line item instead of a bounded pilot cost.

None of this argues against using shadow mode. It’s a genuinely better validation mechanism than most organizations had access to a year ago, and comparing predicted actions against real agent behavior on live cases is a far more honest test than a sandbox demo with curated examples. The point is that GA here does not mean settled. It means the feature works as described, the cost model is real rather than theoretical, and the documentation hasn’t caught up to tell you clearly which rules apply. Teams that have gone through a Dynamics 365 Customer Service rollout before recognize this pattern: the technical capability usually arrives before the governance conversation around it is finished, and treating the two as separate workstreams from the start avoids finding out the hard way which one was actually the bottleneck. This is the kind of gap Routeget Technologies typically catches during a pre-rollout technical review, before a client’s compliance team finds it first.

#CaseManagementAgent #DynamicsCustomerService #ServiceModules #AIGovernance #CopilotCredits #EnterpriseAI

Dynamics 365 Service Agent Reached GA. Your Budget Approval Was for the Wrong Number.

A business technology leader reviews a customer service AI analytics dashboard on a large office monitor

A customer service VP at a mid-size distributor got budget sign-off in August for next year’s Dynamics 365 Customer Service renewal, including a line item for “AI capabilities” that her team had been piloting since spring. Then her IT director came back with a different number. Turning on Dynamics 365 Service Agent, the interactive AI layer Microsoft folded into Microsoft 365 Copilot this summer, wasn’t a checkbox inside the Customer Service license she’d already budgeted for. It was a second license, a consumption meter, and a rollout plan that touched roles, queues, and app modules she hadn’t scoped at all.

That gap between what leaders assume “enabling Copilot” costs and what it actually requires is becoming a recurring theme across the Dynamics 365 ecosystem, and Service Agent is a particularly clean example of it, because the feature itself is genuinely useful. The problem isn’t the capability. It’s that the licensing and governance model behind it doesn’t map cleanly onto how most organizations already budget for customer service technology.

What Dynamics 365 Service Agent Actually Does Differently

Dynamics 365 Customer Service has had AI-assisted features for a while: case summarization, suggested knowledge articles, sentiment flags. Service Agent, which reached general availability on June 30, 2026, is a different kind of thing. Microsoft describes the shift as moving from a tool that answers and summarizes to one that reasons and acts, and the distinction holds up in practice. Instead of surfacing a suggestion inside the Customer Service workspace, Service Agent operates through more than 90 Model Context Protocol tools that let a service representative, or a supervisor, update a case, reassign it, draft and send a reply, pull the next item from a queue, or generate a coaching note, all from inside Microsoft 365 Copilot itself. That means Teams, Outlook, and the Copilot chat surface, not just the Dynamics 365 application.

The practical effect is that a rep no longer has to open the Customer Service workspace to get value from the AI. A supervisor can ask Copilot in Teams for SLA exposure across a queue and get an answer grounded in live Dataverse case data, then reassign three at-risk cases without leaving the conversation. Microsoft’s own reference customer, Northern Trust, framed the change as moving from reactive search to proactive intelligence, which is a fair description of what changes when action, not just information, becomes available inside a chat interface.

That is a meaningfully different product than the Case Management Agent capability covered in this publication’s prior look at autonomous email resolution. That feature handles inbound email triage and resolution on its own, largely without a human in the loop for routine requests. Service Agent is closer to a force multiplier for people who are still doing the work, giving them a faster path to the same actions they’d otherwise take by clicking through the workspace. Both features draw on the same underlying AI infrastructure and the same consumption-based billing, which is exactly why they need to be budgeted together rather than as separate, unrelated line items.

The License Stack Nobody Scopes on the First Pass

Getting Service Agent in front of a customer service team requires three separate commercial commitments, and skipping any one of them stalls the rollout partway through.

The first is the Dynamics 365 Customer Service license itself, at Enterprise or Premium edition, which is what grants access to the underlying case data, knowledge base, and workflow engine that Service Agent reads from and writes to. Most organizations already have this if they’re running Customer Service at any scale, so it rarely surprises anyone.

The second is a Microsoft 365 Copilot license, and this is where the August budget conversation usually goes sideways. As of the licensing consolidation Microsoft rolled out in October 2025, the M365 Copilot license at thirty dollars per user per month now includes what used to require a separate twenty-dollar Copilot for Sales, Service, and Finance add-on on top of a fifty-dollar bundled SKU. That’s a genuine simplification from where the pricing sat a year earlier, but it doesn’t change the fact that every representative or supervisor who needs the integrated Service Agent experience, meaning access from Teams and Outlook rather than only inside the Dynamics 365 workspace, needs this license in addition to their Customer Service seat. For a fifty-person service organization, that’s an incremental cost that has to be modeled explicitly rather than assumed to already be covered by whatever Customer Service tier they’re on.

The third layer is consumption-based: Copilot Credits, which meter usage of the premium tools inside Service Agent’s toolset, on top of whatever is included in the base licenses. This requires a Power Platform pay-as-you-go plan with an attached Azure subscription, which in most enterprises means a separate procurement conversation with whoever owns the Azure relationship, not the team that owns the Dynamics 365 or Microsoft 365 contract. Organizations that have already gone through this exercise for the Case Management Agent’s autonomous email resolution feature have a head start, since the billing infrastructure is the same. Organizations tackling Service Agent as their first Copilot Credits commitment are effectively standing up a new procurement process from scratch, and that process alone can take longer than the technical rollout.

None of this is disclosed as a single number anywhere in Microsoft’s GA announcement, because it can’t be. Actual cost depends on how many representatives get the integrated experience versus a Customer-Service-only rollout, and how heavily premium tools get used once it’s live. That’s a reasonable design choice given how differently organizations will deploy this, but it means the budgeting exercise has to happen internally, with IT, finance, and the service organization in the same room, before a number goes to a steering committee.

Abstract illustration of stacked translucent layers representing tiered software licensing above a glowing customer service headset icon

Governance Controls That Make a Phased Rollout Realistic

The part of Service Agent’s design that deserves more credit than it gets is the rollout mechanism itself. Microsoft built in role-based access at three levels of granularity: per role, per application module, and per queue, and every one of those controls is reversible. That means an organization doesn’t have to choose between an all-or-nothing switch and doing nothing at all.

In practice, this supports a pilot pattern that’s more disciplined than what most AI rollouts get. A service leader can enable Service Agent for a single queue handling a well-understood, lower-risk category of requests, watch how representatives actually use the action-taking tools versus the summarization ones, and expand module by module rather than committing the entire service organization to an integrated experience on day one. Running the new experience side by side with the existing Customer Service workspace, rather than replacing it outright, gives teams a genuine off-ramp if adoption or accuracy doesn’t meet expectations in a given queue.

That control granularity is also what makes the licensing conversation tractable. Instead of asking “how many M365 Copilot licenses does the whole service organization need,” the real question becomes “which roles and queues justify the incremental license and credit consumption in phase one,” which is a much smaller number to defend to finance and a much easier one to revise later.

What to Settle Before the Next Budget Cycle

Before committing spend to a broader Service Agent rollout, it’s worth resolving three questions concretely rather than deferring them to the implementation team. First, determine how much license overlap already exists: any representatives who already hold M365 Copilot seats through other departments or through the Sales and Finance Copilot consolidation don’t need a second license, and that overlap can materially change the incremental cost. Second, get a real consumption estimate for Copilot Credits from a pilot queue before assuming what full deployment will cost, since usage patterns for action-taking tools tend to run higher than for pure summarization once representatives get comfortable with them. Third, decide who owns the Azure and Power Platform pay-as-you-go relationship before the rollout stalls waiting on a procurement approval that nobody flagged early enough.

Service Agent is a legitimate step forward for how customer service teams work inside Dynamics 365, and the reversible, granular rollout controls are a genuinely well-designed answer to the usual all-or-nothing AI adoption problem. The organizations that get the most value from it are the ones that treat the licensing stack as part of the technical evaluation from the start, not as a surprise that shows up after the pilot already has executive attention. That’s the pattern Routeget Technologies has seen repeatedly across Dynamics 365 AI rollouts: the technology rarely disappoints, but the budget conversation that should have happened in parallel with the pilot usually happens after it, and that sequencing is what turns a good capability into a frustrating procurement delay.

#ServiceAgentGA #CopilotLicensing #DynamicsCustomerService #CustomerServiceAI #CopilotCredits #ITBudgetPlanning

Dynamics 365 Autonomous Email Resolution: What to Audit Before September 30

Customer service manager reviewing an automated email triage dashboard in a modern operations center

A support mailbox that receives a few thousand emails a month tends to look the same from the outside no matter what’s actually happening inside it: a queue, a set of SLAs, a team quietly triaging password resets, order-status questions, and return requests alongside the handful of cases that genuinely need a human’s judgment. Most customer service leaders already know which categories in that queue are repetitive enough that a well-trained system could handle them end to end. What changes on September 30, 2026, is that Dynamics 365 Customer Service ships autonomous email resolution, a first-party feature built to do exactly that, and the decision about whether to turn it on now belongs on a CIO’s or VP of customer operations’ desk rather than in a future roadmap conversation.

The feature is called autonomous email resolution, and it is delivered through the Case Management Agent that Microsoft has been building out across the last several release waves. Microsoft’s own message center announcement, MC1465523, confirms the general availability date and describes the capability plainly: it analyzes an incoming email, identifies the customer’s intent, checks whether the knowledge and actions needed to resolve it are actually available, and then either sends a resolution, asks a clarifying question, or hands the email off as a fully-contexted case for a person to finish. That last part matters as much as the automation itself. Nothing here is pitched as replacing a support team; it is pitched as removing the portion of the queue that never needed a person’s attention in the first place.

Abstract illustration of an AI agent autonomously processing and resolving an email through a neural network

What autonomous email resolution actually ships on September 30

Reading the feature closely is worth the ten minutes it takes, because the mechanics determine how much control an organization actually retains. Configuration happens in the Copilot Service admin center, under email settings, where an administrator turns on email resolution and then, critically, sets a deployment status separately for each line of business. That per-line-of-business control is the real governance lever here: a line handling password resets or shipping status can be configured for fully autonomous resolution on day one, while a line handling billing disputes or account cancellations can be left in a draft-only mode where the system prepares a response but a representative still reviews and sends it. Nothing forces an all-or-nothing rollout, and organizations that treat this as a binary on/off switch are already making the decision harder than it needs to be.

The dependency chain behind the feature is longer than a single toggle suggests, and each link is worth confirming before a rollout date gets put on a calendar. Email resolution depends on the Customer Intent Agent being configured first, since that agent is what actually identifies what a customer is asking for. It depends on the Case Management Agent’s own guided setup being complete. For the fully autonomous path, where the system sends outbound email without a person in the loop, Microsoft requires a dedicated application user and a shared mailbox set up specifically for that flow, which is a reasonable security boundary but one that needs its own review: whoever owns identity and access management should know that a service account now has standing permission to send customer-facing email on the organization’s behalf.

One constraint is easy to miss and expensive to discover after the fact. Each email resolution configuration supports a single language. An organization running support across English, French, and Spanish mailboxes isn’t looking at one feature toggle; it’s looking at three separate configurations, each requiring its own line-of-business mapping and its own review cycle. That’s not a reason to avoid the feature, but it is a reason to scope the rollout by language and region from the start rather than discovering the limitation mid-deployment.

The billing question worth asking before the license conversation

Here is where the fine print earns its place in this article. Microsoft’s broader Dynamics 365 Customer Service pricing already establishes how most AI agent capabilities get paid for: Professional and Enterprise tier customers consume Copilot Credits, purchased separately from the base per-user license, while the Premium tier bundles in a base allocation of included capacity. That’s the billing model most IT and finance leaders have already built into their Copilot budgeting conversations over the past year.

Autonomous email resolution’s own documentation adds a second billing surface to that picture rather than simply drawing down the same Copilot Credit pool. Microsoft’s configuration guidance lists, as an explicit prerequisite, the Power Platform pay-as-you-go plan, which requires an Azure subscription attached to the environment specifically so the system can charge for agent runs on a consumption basis. In practice, that means a team that has already provisioned Copilot Credits for Case Management Agent’s classification and quality-evaluation capabilities can still be blocked from turning on autonomous email resolution until someone also attaches a billable Azure subscription to the Power Platform environment and enables the pay-as-you-go plan there. Those are two different procurement conversations, often owned by two different teams: one usually sits with the Dynamics 365 or Copilot licensing owner, and the other sits with whoever manages the organization’s Azure subscriptions and cost centers.

This is not a reason for alarm, and it is worth saying plainly that consumption-based billing tied to actual agent runs can be the more sensible model for a capability like this one, since cost then tracks usage rather than seat count. But it is exactly the kind of dependency that gets missed when a rollout gets planned purely as a licensing tier upgrade. The practical fix is straightforward: before scheduling a pilot, confirm that data movement for Copilot and generative AI features is enabled in the Power Platform admin center for the target environment, and confirm separately that an Azure subscription is attached and the pay-as-you-go plan is active, rather than assuming an existing Enterprise or Premium Customer Service license already covers it.

Governance gaps worth planning around, not waiting on

Microsoft’s own documentation, as of this writing, does not publish a specific confidence threshold or scoring mechanism that determines when the system resolves an email autonomously versus escalating it. That is a legitimate gap for governance teams to plan around rather than a reason to delay indefinitely. The practical response is the same one that has worked for every other agentic capability Microsoft has shipped into this product line over the past year: run the feature in its production-ready preview mode against a narrow, well-understood line of business first, watch what it actually resolves versus escalates over a few weeks of real volume, and only then widen the automation level or add a second line of business. Treat the per-line-of-business deployment status setting as the real control surface, since Microsoft has not given administrators a separate dial to tune model confidence directly.

It’s also worth having someone on the compliance or risk side confirm that autonomously sent customer emails, generated from enterprise knowledge and business instructions rather than drafted by a person, fit within existing customer communication policies and any regulatory obligations specific to the industry. A financial services or healthcare organization will likely want a longer review cycle here than a retailer fielding order-status questions, and that difference should shape the rollout timeline more than the September 30 GA date does.

What decision-makers should do this month

The practical sequence for a customer service or IT leader evaluating this feature ahead of GA looks like this: identify one or two lines of business with high email volume and genuinely repetitive, low-risk request types, since these are the best pilot candidates regardless of how quickly the organization intends to expand the feature afterward. Confirm the billing prerequisites on both sides, Copilot Credits and the Power Platform pay-as-you-go plan with an attached Azure subscription, well before the pilot’s target start date, since provisioning an Azure subscription and getting it approved through procurement can take longer than the feature configuration itself. Assign clear ownership of the application user and shared mailbox that the autonomous flow depends on, treating that account with the same access review rigor as any other service identity with outbound communication permissions. And build in a deliberate review checkpoint, perhaps two to four weeks into the pilot, before extending the automation level beyond draft-only for any additional line of business.

Routeget Technologies has walked several clients through exactly this kind of staged agentic rollout across the Dynamics 365 Customer Service and Field Service product lines over the past year, and the pattern holds consistently: the technology tends to work about as well as Microsoft describes it, and the actual project risk sits almost entirely in governance sequencing and billing setup rather than in the AI itself. Getting those two things right before September 30 is a smaller lift than it looks, and it is considerably smaller than untangling them after a line of business has already gone live on autopilot.

#AutonomousEmailResolution #CaseManagementAgent #DynamicsCustomerService #CopilotCredits #CustomerServiceAI #AIGovernance

The AI Builder Credits Transition Has a Deadline: November 1, 2026

Finance and IT leaders reviewing Power Platform licensing budget charts on a laptop in an office setting

A Power Platform administrator at a mid-market distributor recently walked into her CFO’s office with a number nobody had budgeted for. Her company’s invoice-processing flow, built on AI Builder’s document processing models three years ago, had been running on credits bundled quietly into a Power Automate Premium renewal. That renewal comes up again in October. She had just learned that whatever gets signed this fall will be the last one to include those free credits at all, and that the resulting seeded credits and add-on option would disappear entirely for anyone who renews after November 1, 2026. Nobody in finance had flagged it as a line item, because for three years it had never been one.

That scenario is becoming common across organizations that adopted AI Builder early, when its credits shipped as a quiet inclusion in Power Apps, Power Automate, and Dynamics 365 licenses rather than a metered, purchased capacity. The AI Builder credits transition Microsoft is now enforcing retires that model outright, and the cutoff sits close enough on the calendar that IT Directors and finance leaders currently mid-negotiation on a Power Platform renewal need to understand it before they sign, not after.

What the AI Builder credits transition actually changes

Abstract illustration of digital credit tokens flowing between two separate licensing systems

AI Builder, the low-code AI layer inside Power Apps and Power Automate that handles document processing, form extraction, sentiment analysis, and prediction models, has historically been funded two ways: seeded credits bundled into premium licenses at no extra cost, and AI Builder capacity add-ons purchased separately when an organization’s usage outgrew the bundled amount. Microsoft’s documentation lists specific seeded allotments: Power Apps Premium includes 500 AI Builder credits, Power Apps per-app licenses include 250, Power Automate Premium and its RPA add-ons include 5,000 each, and Dynamics 365 Finance and Operations includes 20,000. A standalone AI Builder capacity add-on carries 1,000,000 credits.

Starting November 1, 2025, Microsoft closed new-customer sales of AI Builder capacity add-ons and shifted AI Builder features onto a dual-currency consumption model: an environment draws down its AI Builder credits first, and if those run out, the system automatically falls back to Copilot Credits before blocking the operation. Existing add-on customers could still renew and purchase through that window. November 1, 2026 is the harder cutoff. On that date, existing AI Builder capacity add-ons reach end of life: customers with an active add-on keep using the credits tied to it, but can no longer renew it or buy a new one. Separately, any Power Platform or Dynamics 365 license purchased or renewed on or after that date stops receiving seeded AI Builder credits altogether. If your renewal lands in September or October, you’re likely getting the last cycle that includes them at no incremental cost. If it lands in November or later, that inclusion is gone for the new term.

Microsoft has been explicit that it will honor entitlements already under contract. Licenses and add-ons purchased before the cutoff keep their credits for the remainder of that specific contract term, whatever length that is. What changes is the next renewal, not the current one already in force. That distinction matters enormously for budget planning, because it means the financial exposure isn’t immediate for most organizations. It arrives at whatever renewal date happens to fall after November 1, and for some finance teams that’s uncomfortably close.

Why this is a budgeting problem, not a technical one

The mechanically important detail, and the one most likely to catch a finance team off guard, is that there is no automatic conversion between the two credit systems. Microsoft’s own documentation states plainly that AI Builder credits and Copilot Credits are separate currencies with separate consumption rates per action, and unused AI Builder credits don’t roll over or translate into an equivalent number of Copilot Credits when the seeded allotment disappears. An organization that has been running document processing workloads for years on a bundled 20,000-credit Dynamics 365 F&O allotment, or a 5,000-credit Power Automate Premium allotment, needs to separately estimate what the equivalent workload costs once it draws exclusively on purchased Copilot Credits, because the published rate cards for the two currencies aren’t set up to produce the same effective cost per document or per prediction. Assuming last year’s consumption simply carries forward at the same dollar cost is the exact assumption this transition breaks.

This is where the business risk actually lives. AI Builder adoption inside Dynamics 365 F&O and Business Central environments tends to concentrate in exactly the processes finance departments care most about protecting: accounts payable invoice capture, receipt and expense processing, contract data extraction, vendor document classification. These are high-volume, repetitive workloads that were attractive to automate specifically because the seeded credits made the marginal cost of processing another document effectively zero. Once that seeded allotment is gone, the marginal cost stops being zero, and depending on volume, it can become a meaningful new operating expense that nobody modeled into the automation’s original ROI case.

What CIOs, CFOs, and Power Platform administrators should do before their next renewal

The first step is straightforward but frequently skipped: pull actual AI Builder consumption data from the Power Platform Admin Center, under Licensing and Capacity add-ons, before the renewal conversation starts rather than during it. Monthly consumption resets and doesn’t accumulate, so a single month’s snapshot understates volume during seasonal peaks like month-end close or year-end 1099 processing. Look at a full quarter, not a spot check.

The second step is checking renewal timing against the cutoff with more precision than “sometime this year.” A Power Automate Premium license renewing October 15 keeps its seeded credits for that full new term even though the term extends past November 1, since Microsoft’s honoring rule is tied to the contract’s start date, not to a mid-term calendar boundary. A license renewing November 15 does not get that benefit. For organizations with renewal dates close to the line, it’s worth confirming the exact contractual start date with a Microsoft partner or account team rather than assuming based on the calendar month alone.

Third, for teams that expect to keep growing AI Builder-dependent automation rather than shrinking it, purchasing or renewing an AI Builder capacity add-on before November 1, 2026 locks in access to that add-on’s credit pool and its associated rate for as long as the add-on contract runs, even though new add-on purchases stop being available afterward. That’s a genuine one-time window, not a recurring option, and it’s worth evaluating now rather than assuming it will still be available closer to the deadline.

Finally, this is a reasonable moment to model Copilot Credit costs for AI Builder workloads specifically, rather than treating Copilot Credits as an abstract budget line shared across every AI feature in the tenant. Document processing, form extraction, and prediction actions each draw against Copilot Credits at their own published rate once AI Builder credits are exhausted, and an organization running several automated document workflows across F&O, Business Central, and Power Automate should size that consumption separately from whatever Copilot Studio agent or Copilot chat usage is already drawing from the same pool. Treating them as one undifferentiated bucket is how a finance team ends up with a Copilot Credit shortfall it didn’t see coming from an entirely different application.

None of this requires panic, and it doesn’t require ripping out working automation. It requires treating a licensing calendar date the way a solution architect would treat any other deprecation notice: as a planning input with a hard date attached, not a vague future concern. At Routeget Technologies, the licensing transitions we’ve helped clients navigate tend to follow the same pattern: the technical migration is manageable, but the budget surprise is what actually causes friction with finance. Getting ahead of the renewal date, and getting real consumption numbers in front of the people who sign the contract, is what turns this from a surprise into a line item.

#DynamicsAIBuilder #CopilotCredits #PowerPlatformLicensing #ERPBudgetPlanning #EnterpriseAI #FinanceAutomation

Dynamics 365 Sales Home Lead Research Reaches GA. Read the License Fine Print First.

Sales operations manager reviewing an AI-prioritized lead list on a dashboard screen in a modern office

A sales operations director at a mid-market manufacturer spent part of August walking her CRO through the 2026 release wave 1 notes for Dynamics 365 Sales, and one line stood out: Sales Home lead research and next best actions were shipping this wave, landing directly on the screen every rep already opens first thing in the morning. It read like a free upgrade, the kind of quiet interface improvement Microsoft ships every wave without anyone needing to ask for it. Then she checked the prerequisites. The feature does not turn on by itself. It requires the Sales Qualification Agent, or its lead research capability, to be provisioned first, and that agent draws from the same Copilot Credit pool her finance team had already earmarked for a completely different AI rollout in customer service. What looked like a UI refresh was actually a new consumption-based line item, and nobody in the budget conversation had accounted for it.

That gap between how a feature reads in the release notes and how it actually gets paid for is becoming a recurring theme in the Dynamics 365 Sales roadmap, and it is worth understanding in detail before your own team flips the switch.

Sales operations manager reviewing an AI-prioritized lead list on a dashboard screen in a modern office

What Sales Home Lead Research Actually Does

The feature itself, officially titled “Get lead research and next best actions in Sales Home,” reached general availability this month after entering public preview in June. It puts a prioritized, AI-scored list of leads directly on the home screen sellers already use, ranked by urgency, fit, and engagement signals rather than by creation date or a manually assigned score. For each lead, the panel surfaces a short research summary, the reasoning behind why the system considers it worth pursuing now, and a recommended next action, whether that is a follow-up call, a qualification step, or simply unblocking an agent that is waiting on a decision. Sellers can act on the recommendation without leaving Sales Home, and the system tracks whether the action was taken so high-value leads stop quietly stalling in someone’s queue.

On paper, this solves a real and common problem. Most sales teams do not lack leads; they lack a reliable way to decide which ten of the two hundred leads sitting in a queue actually deserve a call this morning. Manual lead scoring models built on static rules tend to go stale within a quarter, and reps develop their own private heuristics that rarely match what marketing or revenue operations intended. A model that explains its reasoning, rather than just spitting out a number, addresses the trust problem that has quietly limited adoption of every previous generation of predictive lead scoring in this platform.

The Licensing Mechanic Buried in the Prerequisites

Here is where the release notes get less generous with detail than a budget owner would like. The Sales Home panel is not a standalone capability; it is a surface built on top of the Sales Qualification Agent, which does the actual research and reasoning work in the background. That agent is available with Dynamics 365 Sales Professional, Enterprise, or Premium licensing, but it consumes Copilot Credits with every research pass, every drafted outreach email, and every autonomous follow-up it sends. Premium licensing includes an allotment of 1,000 credits per user per month; everything past that draws from a purchased credit pool that is shared across every Copilot-metered feature in the tenant, not ring-fenced for Sales Home alone.

Abstract visualization of a metered digital consumption gauge representing Copilot Credit usage

That last detail matters more than it sounds. Organizations running Dynamics 365 Sales alongside Customer Service or Field Service are increasingly stacking multiple agentic features onto the same finite credit budget: a qualification agent working inbound leads, a service agent summarizing cases, perhaps a Copilot Studio agent doing something entirely unrelated to sales. None of these consumption patterns are visible to a sales operations leader evaluating a single feature in isolation, which is exactly the position our manufacturing client found herself in. The fix is not complicated, but it does require a step most teams skip: pull actual Copilot Credit consumption reports from the admin center before approving a new agent, rather than assuming existing licensing already covers it.

A Cautionary Parallel Already Sitting in the Same Interface

Sales Home is not new territory for features that look simpler in a release note than they turn out to be in production, and the platform’s own history with Sequences is instructive. Sequences, the guided step-by-step workflow tool for structuring outbound cadences, shipped years ago with obvious appeal and has been quietly constrained ever since by details that never made it into the initial pitch. It ties automated email steps to a seller’s personal mailbox, so organizations relying on shared or group mailboxes for outbound outreach have had to build custom workarounds. Enterprise-tier licensing caps sequence assignments at 1,500 records a month, a ceiling that arrives faster than most sales operations teams expect once a cadence scales past a pilot team, and lifting it means moving to Premium. Even the interface has friction: when Sequences’ “Next Up” panel and the standard Timeline component both appear on the same record, reps report genuine confusion about which one is actually telling them what to do next.

None of this means Sequences was a bad investment, and it does not mean the new lead research panel will repeat every one of these specific problems. It means that features surfaced in Sales Home tend to carry structural constraints, whether licensing caps, mailbox dependencies, or credit consumption, that only become visible once a team is past the pilot and into real volume. A decision-maker evaluating the new panel should treat that pattern as a reason to pilot deliberately rather than roll out broadly on day one.

What the Early Evidence Actually Shows

Microsoft has published its own benchmark for the underlying Sales Qualification Agent, introduced in December 2025 as the Microsoft Sales Bench, which compared the agent against a general-purpose model across identical synthetic lead datasets judged by both human reviewers and an LLM evaluator. The agent scored roughly six percent higher on research quality, twenty percent better on outreach personalization and timeliness, and sixteen percent higher on multi-turn engagement handling. Those numbers are worth taking seriously as a signal that Microsoft has purpose-built this agent for the sales qualification task specifically, rather than wrapping a generic model around CRM data. They should also be read for what they are: an internally run comparison on synthetic data, not an independent third-party audit, and a reasonable board-level question is whether your own historical lead data, industry, and deal complexity resemble the benchmark’s assumptions closely enough for the numbers to transfer.

A more grounded data point comes from an early adopter, Sandvik Coromant, whose pilot reportedly saved roughly 120 hours and nineteen thousand dollars in labor cost over three weeks, with a forecasted five percent revenue lift once rolled out fully. That is a genuinely useful reference point, and it is also a single case study from one organization’s specific lead volume and sales motion. Treat it as evidence the mechanism can work, not as a guaranteed return for every deployment.

Questions Worth Answering Before Enabling It

Before turning this on for a full sales organization, a few questions deserve real answers rather than assumptions. First, what is your current Copilot Credit consumption across every agent already running in the tenant, and how much headroom does that leave for a new, continuously-running qualification agent working every inbound lead? Second, is your lead data clean enough for a fit-and-engagement model to produce useful rankings, or will the agent simply be scoring noise, since garbage lead records produce garbage prioritization regardless of how good the underlying model is? Third, has your team learned the operational lessons Sequences already taught the organization about mailbox dependencies and licensing tiers, and does the rollout plan account for the fact that Premium licensing changes both the credit allotment and the feature ceiling?

None of these questions should stop a team from adopting a genuinely capable piece of AI-assisted sales tooling. They should shape how the rollout is sequenced: a single team piloting for a full quarter with credit consumption tracked explicitly, rather than a tenant-wide switch flip driven by excitement over a release note. Routeget Technologies has walked several clients through exactly this kind of staged Copilot-agent adoption inside Dynamics 365 Sales, and the pattern holds consistently: the technology performs well when the budgeting and governance work happens first, and creates friction almost every time it happens after the fact.

The lead research panel in Sales Home is a real improvement to a genuine problem, giving sellers a defensible answer to which lead to call next instead of a gut feeling. Just make sure procurement and revenue operations are reading the same release note your sales team is excited about, because the license question and the feature announcement did not ship in the same paragraph.

#SalesHomeAI #Dynamics365Sales #CopilotCredits #SalesQualificationAgent #RevenueOperations #LeadPrioritization

Copilot Studio Harness Billing: The Free Pilot Period Just Ended

Finance director reviewing cost dashboards for Copilot Studio agent billing

A finance team at a mid-size distributor spent the summer letting two developers experiment with autonomous agents in Copilot Studio: one to triage vendor invoices, another to reconcile shipping exceptions against purchase orders. Nobody logged the hours. Nobody tracked the credits, because there were none to track. Then, on September 1, 2026, Copilot Studio harness billing changed for exactly this kind of pilot, and both agents started drawing against the tenant’s Copilot Credit pool without a single line of configuration having moved. The invoice for October will look different than the one for September, and the person who approves it may have no idea why.

This is not a hypothetical. Microsoft’s own admin guidance for this change tells organizations to go looking for agents they may have forgotten existed, which is a reasonable ask only if someone already knows to look. For CIOs, CFOs, and IT directors who greenlit a handful of “let’s just see what this can do” pilots earlier in the year, the practical question is no longer whether Copilot Studio’s most capable harness is worth adopting. It is whether the agents already running under it are quietly becoming a budget line nobody planned for.

What Copilot Studio harness billing actually changed on September 1

Copilot Studio ships three distinct harnesses, and the distinction matters more than most licensing conversations acknowledge. A harness, in Microsoft’s own framing, is the runtime layer that sits between an agent’s design and the underlying model: it decides when to call the model, what to hand it, how to interpret what comes back, and which tools to invoke on the agent’s behalf. The Standard harness is deterministic. It follows predefined topics and prompts and behaves the same way every time, which is exactly what you want for a help desk bot answering a known set of questions. The Copilot Chat harness is narrower still, built to ground Microsoft 365 Copilot Chat in an organization’s own content for internal, employee-facing scenarios.

The GitHub Copilot harness is a different animal entirely. It reasons autonomously toward a goal rather than following a script, breaks a task into steps on its own, retries and reroutes when something fails, and can read, edit, and reason over Word, Excel, PowerPoint, and PDF files as part of completing a task. It also supports skills and persistent memory, and runs in a secure sandbox designed for multi-step business processes: an accounts payable agent that reads an invoice, matches it to a purchase order, and routes an exception is the kind of thing Microsoft built this harness to handle. It reached general availability on August 3, 2026, and from that date forward, the billing model was unambiguous: authoring, testing, and evaluating an agent all consume Copilot Credits, not just its published, end-user traffic. The meter starts the moment someone starts building.

What was less obvious is what happened to agents and workflows that existed before that date, built during an earlier preview window when this kind of usage did not consume credits at all. Microsoft’s answer arrived on September 1: those pre-GA agents and workflows, including anything sitting in a Dev or Trial environment, now consume Copilot Credits too, for both the ongoing authoring work a maker does on them and their runtime execution. Standard harness and Copilot Chat harness agents are unaffected. This is specifically about closing the gap between agents that got a free head start during preview and the GA billing model everyone built after August 3 has already been living under.

Why this is a governance problem before it is a cost problem

The credit economics themselves are not exotic once you understand them. Copilot Credits can be drawn from prepaid capacity, priced at roughly $200 per month for 25,000 credits, or purchased pay-as-you-go through an Azure subscription at $0.01 per credit, a rate that runs about 25 percent higher than the prepaid tier. Microsoft’s admin tooling in the Power Platform admin center lets you set a monthly consumption ceiling per agent, with two guardrails: a notification as usage approaches the limit, and a hard stop that disables the agent once it’s reached. Overages beyond an agent’s allocation can either draw from a shared tenant pool or bill against a linked pay-as-you-go plan, and a monitoring dashboard shows month-to-date billed credits per agent alongside a twelve-month trend.

Laptop screen showing an administrative usage and credit consumption dashboard

None of that is the hard part. The hard part is that the September 1 change makes cost visibility retroactive for a category of agent that, by design, was never supposed to need it. A pilot built in July to test whether autonomous reasoning could handle exception routing was, at the time, a genuinely low-stakes experiment. Nobody assigned it an owner with a mandate to monitor consumption, because there was nothing to consume. That agent may still be running today, quietly reprocessing the same exceptions it was built to test, and as of this month it is drawing against the same credit pool as anything built deliberately for production. Multiply that by however many “quick pilot” agents a mid-size enterprise typically accumulates across finance, HR, and operations teams over six months, and the exposure is not a single line item. It is an unknown number of them, some of which may not even have an active business owner anymore.

What to check before the next invoice arrives

Microsoft’s own recommendation is a reasonable starting point: pull historical, non-billed Copilot Credit consumption data from the Power Platform admin center to understand what these agents were actually doing before billing applied to them, and use that history to identify which GitHub Copilot harness agents and workflows exist across every environment, including the Dev and Trial environments that pilots tend to live in and get forgotten in. That inventory step matters more than it sounds like it should, because Dev and Trial environments are exactly where governance attention typically does not reach; they are treated as sandboxes precisely because nothing in them used to cost money.

Once that inventory exists, the decision for each agent is binary and should be made deliberately rather than by default. An agent that proved its value during the pilot period should be formally adopted: given an owner, a consumption ceiling with both guardrails enabled, and a place in whatever ALM process governs production agents. An agent that was built to answer a question that has already been answered, or that nobody has looked at since July, should be retired outright rather than left running under the assumption that “it’s probably fine.” The cost of leaving a stale pilot alive is no longer zero, and the credit allocation and access controls that make sense for a small number of intentional, production-grade autonomous agents do not scale gracefully to an undefined number of forgotten ones.

There is a broader lesson in how this rolled out. Microsoft made the GA billing model clear from day one for anything built after August 3, and it gave organizations a full month, not a surprise cutover, before extending that model backward to preview-era agents. That is a fair way to manage a transition. But it also means the responsibility for knowing which agents exist and what they’re doing sat with each tenant the entire time, and plenty of tenants were not positioned to carry it. As autonomous, credit-metered agents become a bigger part of how Dynamics 365 and Power Platform environments get extended, the organizations that treat agent inventory and consumption governance as a standing discipline, not a one-time reaction to a billing announcement, are the ones that won’t be surprised by the next change like this one. Routeget Technologies has been walking clients through exactly this kind of Copilot Studio environment audit over the past several weeks, and the pattern holds: the agents nobody remembers building are almost always the ones costing the most to leave running.

#CopilotStudio #AgenticAI #GitHubCopilotHarness #CopilotCredits #ITCostGovernance #EnterpriseAI

The AI Builder Copilot Credits Shift Is Rewriting Invoice Automation

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

A Dynamics 365 Finance and Operations customer running automated AP invoice capture on AI Builder’s invoice processing model will not notice anything different on November 2, 2026. The flow will still trigger, the fields will still extract, and finance will still get its exception queue for anything below the confidence threshold someone set two years ago. What changes on that date is not the model. It is whether the credits paying for every one of those extractions still exist, and for a lot of organizations that built this automation quietly, without anyone tracking which license line item was actually funding it, the honest answer right now is that nobody knows.

Microsoft has been unwinding AI Builder’s original credit system since November 2025, when it stopped selling new AI Builder capacity add-ons, and the second half of what amounts to an AI Builder Copilot Credits transition lands on November 1, 2026: every seeded AI Builder credit bundled into Power Apps Premium, Power Automate Premium, and Dynamics 365 Finance and Operations licenses gets removed on that date. Copilot Credits take over as the funding mechanism going forward, and Microsoft has been explicit on one point: there is no automatic conversion. Whatever balance an organization is sitting on today does not roll into a Copilot Credits balance tomorrow. It has to be purchased separately, allocated deliberately, or the automation simply stops running.

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

What Actually Sunsets, and What Doesn’t

It’s worth being precise about what this deadline touches, because the shorthand “AI Builder is going away” is wrong and it leads teams toward the wrong response. The invoice processing model, the document processing custom-model tooling, and the AI Builder connector actions inside Power Automate are not being retired. What’s ending is one specific funding source for them. Today, AI Builder actions in Power Apps and Power Automate draw first against AI Builder credits, whether that’s the 500 seeded into Power Apps Premium, the 5,000 in Power Automate Premium, or the 20,000 bundled into a Dynamics 365 Finance and Operations license, and only fall back to Copilot Credits once that pool is exhausted. After November 1, 2026, that first pool disappears entirely for anyone who hasn’t separately purchased an AI Builder capacity add-on before the cutoff, and Copilot Credits become the only meter running. Existing add-on holders get a longer runway, since those add-ons stay valid through their current contract terms even past the end-of-life date, but nobody can buy or renew one after November 1.

How the AI Builder Copilot Credits Rate Table Changes the Prebuilt-vs-Custom Decision

The part of this transition technical teams should actually care about isn’t the deadline itself, it’s the pricing structure underneath it, because it quietly resolves a tradeoff a lot of architects have been living with for years. Under the legacy AI Builder credit system, running a page through the prebuilt receipt or invoice model cost 32 credits, while running that same page through a custom-trained document processing model cost 100 credits, roughly three times as much. That gap pushed a lot of implementations toward the prebuilt invoice model even in cases where a custom model, trained on one vendor’s actual invoice layout, would have extracted fields more reliably. Under Copilot Credits, both capabilities are priced identically at 8 credits per page. The three-to-one penalty for training a custom model is gone.

That’s a real architectural decision point, not a footnote. If an AP automation pipeline has been leaning on the prebuilt invoice model and routing a meaningful share of extractions to manual review because one vendor’s layout doesn’t match the model’s expectations well, whether that’s multi-column line items, remittance details in an unusual spot, or a logo block that confuses the header fields, it’s worth revisiting whether a custom collection trained on that vendor’s actual documents would now clear review automatically instead. The cost argument that used to say no has mostly disappeared, and for high-volume vendors specifically, the accuracy gain from a purpose-trained model can be worth the labeling effort even before factoring in the credit parity.

Reconfiguring the Flow Itself

For teams staying on the prebuilt path, the “Extract information from invoices” action inside the AI Builder connector remains the fastest route to a working pipeline. It returns more than forty fields: invoice ID, vendor name, purchase order, subtotal, tax, and total among them, each in both a raw text form and a standardized number or date form. The standardized fields are the ones worth wiring into a Business Central or F&O AP posting call; the raw text versions exist mainly for audit trails and for surfacing to a human reviewer. Every field also carries its own confidence score between 0 and 1, and the model doesn’t enforce a threshold on your behalf, so that logic has to live in the flow itself. Anything below roughly 0.8 confidence, a starting point worth tuning against your own vendor mix rather than treating as gospel, should route to an approvals step instead of posting automatically. One configuration detail trips up new implementations more than any other: the page-range parameter needs to isolate exactly one invoice per extraction call. Feeding it a multi-invoice batch PDF and letting it run across every page returns fragmented, unusable data, so any intake process that scans a stack of invoices into a single file needs a splitting step before the AI Builder action ever runs.

Solution architect reviewing an automation pipeline diagram and scanned document previews on dual monitors

For teams building or reconsidering a custom document processing model given the new pricing, a few practical constraints are worth knowing before starting. Microsoft’s own guidance puts five documents as the technical minimum to train a collection, but fifteen to twenty is what actually produces usable accuracy, and that number climbs further when the source scans are lower quality. Each collection needs a single, consistent layout, which means a vendor sending three different invoice templates needs three separate collections rather than one, and a model can hold up to 200 collections, generous enough to cover a large and varied vendor base once the labeling work is done properly. High-volume AP operations should also plan around the platform’s processing ceiling of 360 documents per environment every 60 seconds; a month-end batch run that dumps thousands of invoices into a flow all at once will hit that limit and needs to be throttled or staggered rather than fired in a single burst.

Budgeting the Migration Before the Deadline

The practical work between now and November 1 starts with knowing what’s actually being consumed today. The AI Builder Consumption Report in the Power Platform admin center breaks usage down by environment, day, and user, and it’s the fastest way to find out whether a given AP automation flow is currently riding on seeded Dynamics 365 credits, a Power Automate Premium allocation, or an add-on nobody quite remembers purchasing. That figure, recalculated against Copilot Credit rates rather than legacy AI Builder credit rates, is the real basis for a Copilot Credits purchase, not a guess pulled from a vendor conversation. It’s also worth checking whether credits have already been allocated to specific environments in the admin center, because once an environment has an allocation, it only draws against that allocation. There’s no automatic fallback to a tenant-wide pool if it runs dry, which means a production AP flow deserves its own guaranteed allocation rather than sharing an unassigned pool with every sandbox and test environment in the tenant.

The failure mode is also worth testing deliberately rather than discovering it in production. When both AI Builder and Copilot Credits are exhausted, the action doesn’t degrade gracefully; it returns an EntitlementNotAvailable or QuotaExceeded error and the flow run fails outright. For an AP pipeline finance depends on to keep invoices moving, that’s a materially different failure than a low-confidence extraction routed to manual review. It’s a stalled queue with no automatic recovery path until someone notices and tops up credits. Building an explicit fallback now, an error-handling branch that logs the failure and alerts AP operations rather than letting the flow simply stop, is a small addition that avoids a genuinely disruptive incident in November.

None of this is a reason to walk away from AI Builder-based invoice automation, and the pricing shift actually opens up a better architecture for organizations that outgrew the prebuilt model years ago but never revisited the decision. It does mean the flows can’t keep running unattended the way they may have since they were first built. Anyone operating AP automation on this stack should treat the next several weeks as a genuine architecture review rather than a routine licensing renewal, and organizations that have worked through document capture pipelines like this with clients, Routeget Technologies among them, tend to find the credit math is rarely the hard part. It’s the vendor-layout audit and the fallback handling that actually takes the time.

#AIBuilder #CopilotCredits #PowerAutomate #InvoiceAutomation #DynamicsFinanceOps #EnterpriseAI