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

Configuring Financial Report Packages for Month-End Distribution in Business Central

Finance controller reviewing a bundled financial report dashboard during month-end close

A controller at a mid-market manufacturer spends the first three days of every close cycle doing something that has nothing to do with accounting: assembling a stack of PDFs. The profit and loss statement goes to the executive team. The balance sheet and a G/L detail extract go to the audit committee. A budget variance report goes to department heads, each filtered to their own cost center. In Business Central, every one of those documents has lived as its own Financial Report, generated and distributed on its own schedule, which means close week turns into a sequence of separate print jobs, separate emails, and separate chances to send the wrong version to the wrong list.

That specific problem, bundling several financial statements into one coherent, schedulable output, is what Financial Report Packages address in Business Central 2026 release wave 2. The feature landed in the update 29.0 public preview in September 2026, and it is worth understanding now, while it is still confined to sandbox environments, so that the rollout plan for general availability in October is already written by the time the feature reaches production.

Finance controller reviewing a bundled financial report dashboard during month-end close

What changed, and what didn’t, in wave 1

It helps to be precise about what already existed before this. Business Central 2026 release wave 1 (BC28) gave Financial Reports scheduling for the first time. Before BC28, a Financial Report could only be printed on demand; there was no way to have it generate and land in an inbox automatically. Wave 1 fixed that at the level of a single report: from the Financial Reports page or the Financial Report Card, the Schedules action let you configure a code, a description, an “Export to PDF” or “Send Email” option, a list of recipients pulled from User Setup email addresses, a Next Run Date/Time, and a Recurrence Run Date Formula. Each scheduled run created a Financial Report Export Job entry in Job Queue Entries, and you could stack multiple schedules against the same report if different audiences needed it at different cadences.

That was genuine progress, but it left the packaging problem untouched. A controller with five statements to distribute still needed five schedules, five separate emails landing in five separate messages, and no guarantee they arrived in a sequence or format anyone downstream found usable. Wave 1 solved recurrence. It didn’t solve composition.

How Financial Report Packages work

Financial Report Packages, new in the 29.0 preview, introduce a container object that sits above individual Financial Reports rather than replacing them. You reach it either through Tell Me by searching “Financial Report Packages” or via a Packages action on the Financial Reports page itself. Creating a package starts with a header record (the Financial Report Package table, internally table ID 8371) where you set a name and description, the same way you would name any reusable configuration object in Business Central.

The substance of the package lives in its lines, stored in the Fin. Report Package Report table (ID 8372). Each line points to an existing Financial Report, and this is where the design gets genuinely useful for anyone who has fought with one-size-fits-all reporting: every line can carry its own custom filters and its own date formula, independent of the other reports in the same package. A P&L line might use a “-CM” to “CM” formula to lock onto the current month, while a companion cash flow line in the same package uses a trailing twelve-month range. You’re not forcing every statement in the bundle onto identical dimensions or identical periods just because they’re shipping together.

Once the lines are configured, two actions do the actual work. Print generates the combined output immediately, useful for testing a package before you trust it to run unattended, or for the occasional ad hoc request from a board member who wants “everything” right now. Schedules is where the recurring value shows up: you can set multiple schedules per package, each with its own Next Run Date/Time and Recurrence Run Date Formula, and each capable of emailing multiple recipients whose addresses come from their User Setup records. Every run is tracked in a log, so when someone asks whether the March package actually went out, there’s a record rather than a guess.

The output itself still surfaces through the Report Inbox, the existing Business Central page that lists reports generated by scheduling rather than by the Print action, and that also supports pushing files to OneDrive or sharing them with a link. Packages don’t bypass that infrastructure; they feed it a combined file instead of a single-report one.

Close-up of a laptop showing a bundled financial report configuration next to printed statements during month-end close

Setting this up without recreating the wave 1 mess

The mistake to avoid is treating a package as a folder you drop existing schedules into. It isn’t. If you already built individual report schedules under the wave 1 model, plan to retire the redundant ones once a package covers the same distribution, or you’ll end up with both the old single-report emails and the new bundled PDF landing in the same inboxes, which is a worse experience than the one you started with.

Design packages around who receives them, not around how the reports happen to be organized in the Financial Reports list. An executive package might combine the P&L and a cash position summary. An audit-committee package might combine the balance sheet with a G/L detail extract and nothing else, since that audience doesn’t want departmental variance noise mixed in. A department-head package might need per-line filters set to each recipient’s cost center dimension, which is exactly what the line-level custom filters are built to handle. Because each line’s filter and date formula are independent, you can serve genuinely different audiences from the same underlying report definitions without maintaining duplicate report objects just to vary the scope.

One prerequisite is easy to miss until it breaks a scheduled run: every recipient needs a valid email address on their User Setup record. If it’s missing, the system doesn’t fail silently; it throws an explicit error stating the User Setup does not exist, which is at least diagnosable, but it’s worth confirming recipient setup as a checklist item before you go live with any package schedule rather than discovering the gap on the first missed delivery.

Why this matters more than it looks like it should

The same 29.0 preview also introduced G/L account usage tracing for financial report authors, letting you identify uncategorized accounts and preview a report’s calculations before publishing changes to its definition. That capability matters more once packages exist than it did when every report shipped alone. A calculation error or an uncategorized account sitting quietly in one standalone report is a problem for one audience. The same error sitting inside a package that bundles three statements into a single PDF for the executive team turns one mistake into a credibility problem across every report in the bundle, delivered in one shot. If you’re adopting packages, adopt the account tracing discipline alongside them, particularly for any report line feeding a package that goes to leadership.

It’s also worth being honest about timing. Everything described here is currently a preview feature, available only in Business Central online sandbox environments as of the September 2026 update, with Microsoft’s own documentation cautioning that preview features aren’t intended for production use and may carry restricted functionality until general availability, expected in October 2026. That’s a reasonable amount of time to build and test packages against a real close cycle in a sandbox before betting a live month-end on them. Treat October as the date you flip the switch in production, not the date you start figuring out how packages should be structured.

For an organization that has been assembling a five-document close package by hand every month, that lead time is the useful part. There’s no reason to wait for general availability to define which reports belong in which package, which filters each line needs, and which schedules match your actual close calendar. Doing that groundwork in the sandbox now means the October rollout is a configuration change, not a redesign, and Routeget Technologies typically structures exactly this kind of preview-to-production pilot as a parallel run: the new package alongside the existing manual process for one full close cycle, so any gap surfaces before it reaches an executive inbox.

#BusinessCentral #FinancialReportPackages #MonthEndClose #ERPReporting #FinanceAutomation