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

The Power Automate RPA Licensing Math That Breaks Most Finance Automation Rollouts

Finance operations team monitoring automated workflow dashboards in a modern control room

A finance operations director we worked with last quarter had a good problem: her three-bot pilot for invoice matching had worked exactly as promised. Exceptions dropped, the AP team stopped re-keying vendor data, and the CFO wanted it rolled out across the whole shared services center by the next close cycle. Then IT came back with a licensing quote roughly eight times higher than what the pilot had cost per month, and the rollout stalled in budget review for six weeks while everyone tried to figure out what had changed.

Nothing had changed technically. What changed was the license type, and Power Automate RPA licensing is exactly where a surprising number of finance automation programs lose momentum right after they prove themselves.

Power Automate RPA Licensing: Attended Pricing Is the Pilot Price, Not the Production Price

Most Power Automate pilots run attended, meaning a real person is logged into the workstation and the desktop flow executes while they’re at their desk, often triggered manually or from a scheduled prompt during business hours. Attended automation is licensed through Power Automate Premium at $15 per user per month, and that single per-user cost is genuinely all it takes to build and run desktop flows on a registered machine, with access to premium connectors, process mining, and a healthy daily action allowance built in.

That price is why so many pilots clear budget approval without much friction. Fifteen dollars a month per analyst is a rounding error against the labor hours it replaces, and it’s the number finance teams anchor on when they start sizing a broader rollout.

The problem is that production finance operations rarely stay attended. Month-end close doesn’t wait for someone to be logged into a specific machine, and neither does an overnight AP batch or a weekend bank reconciliation run. The moment a bot needs to run unattended, meaning on a schedule or a trigger with nobody present to log in and supervise it, Microsoft requires a Power Automate Process license (the plan formerly marketed as “per flow”), priced at $150 per bot per month if you supply and register your own machine, or a Hosted Process license at $215 per bot per month if you want Microsoft to provision and manage the virtual machine instead. Attended and unattended aren’t tiers of the same product; they’re licensed as genuinely separate capabilities, and a pilot built on the cheap one tells you almost nothing about what the expensive one will cost.

Finance operations analyst reviewing an automation workflow diagram on a monitor

Concurrency Is the Multiplier Nobody Models in a Pilot

The second gap is even easier to miss, because it doesn’t show up until someone asks how many things need to happen at once. A single Process or Hosted Process license grants one unattended bot capable of one desktop flow run at a time, with a daily ceiling of 250,000 actions. That’s usually plenty of headroom for a single automation running serially through a queue.

Finance operations at scale rarely stays serial, though. During a close cycle, a shared services team might need five invoice-processing automations running in parallel to clear a backlog before a reporting deadline, not one automation running five times faster. Each concurrent execution requires its own license; Microsoft allows stacking up to ten Process licenses against a single flow definition for higher-volume scenarios, but the cost scales linearly with concurrency, not with automation count. A team that budgeted for “the AP bot” as a single line item, based on pilot behavior where one instance handled everything sequentially, will find that peak-period parallelism during close is exactly the scenario that multiplies the bill.

This is worth raising explicitly with finance leadership before the rollout budget goes to the board, because it’s the single most common reason an approved RPA business case comes back for revision. The question to ask isn’t “how many bots do we need,” it’s “how many need to run at the same moment at our busiest point in the month,” and the answer to that question is what actually drives the license count.

Hosted Machines Change Who Owns the Infrastructure Risk

There’s a third decision buried in that $150 versus $215 per bot spread that has nothing to do with automation logic and everything to do with who’s on the hook for infrastructure. A standard Process license assumes your organization registers and maintains the machine the bot runs on: a real or virtual Windows endpoint that someone patches, secures, and keeps available. For an IT team already running a mature VM management practice, that’s a marginal addition to existing work.

For a finance-led automation initiative without dedicated infrastructure support, though, that machine becomes an unbudgeted ownership problem. Microsoft’s Hosted Process model addresses this directly: Hosted Machine Groups run on Azure infrastructure provisioned from a custom VM image through Azure Compute Gallery, with dynamic load balancing across the group and automatic reprovisioning during maintenance windows, and credential management shifts from static usernames and passwords to secrets held in Azure Key Vault rather than a spreadsheet somebody has to remember to update. None of that requires a dedicated RPA infrastructure team to operate day to day.

The sixty-five-dollar-per-bot premium for Hosted Process is, in effect, the price of not needing that team. Whether that trade makes sense depends entirely on whether the automation program is going to stay a handful of finance workflows or grow into a broader shared-services capability that justifies its own operational ownership. Organizations that guess wrong in either direction end up either paying for managed infrastructure they had the staff to run themselves, or trying to bolt VM governance onto a finance team that was never set up to own it.

Budgeting the Rollout, Not the Pilot

None of this means Power Automate is a poor fit for finance automation; the platform’s architecture guidance for scaling RPA operations is specifically built around exactly these production patterns, with capacity planning, committed and maximum bot counts, and utilization thresholds designed for high-volume periods like quarter-end processing and seasonal order backlogs. The issue isn’t the platform. It’s that the pilot’s economics and the production rollout’s economics are different products with different pricing logic, and treating them as the same line item is what turns a successful proof of concept into a stalled budget conversation.

Before a finance automation pilot goes to the board for rollout funding, it’s worth walking through three questions with whoever owns the license budget. First, will production runs actually be unattended, and if so, has the Process or Hosted Process cost been modeled instead of the Premium per-user rate the pilot used. Second, what does peak concurrency look like during the busiest close or reconciliation window, since that number, not the total automation count, determines the license count. Third, does the organization want to own the machine infrastructure or pay Microsoft to manage it, and is that decision being made deliberately rather than defaulting to whichever option the pilot happened to use.

Getting those three answers before the budget request goes out doesn’t just prevent an awkward six-week delay. It’s the difference between an RPA program that scales predictably alongside the finance function’s actual workload and one that keeps getting re-approved a bot at a time because nobody modeled what production would really cost. We’ve walked several finance operations teams through exactly this exercise before their rollout budgets went to committee, and the pattern is consistent: the teams that model concurrency and hosting decisions up front rarely get sent back for revision, and the ones that don’t, almost always do.


#PowerAutomate #RPALicensing #FinanceTransformation #ERPGovernance #DigitalTransformation #EnterpriseAI