Business Central Accelerated Depreciation Reaches GA. The Real Decision Isn’t in the Setup Screen.

Finance office desk with a laptop, binders, and a plant, representing fixed asset depreciation recordkeeping

A controller at a mid-market manufacturer with a French subsidiary spends part of every quarter close doing something Business Central was never quite built to do natively outside that one country: running two depreciation schedules for the same fixed assets. One follows straight-line depreciation for consolidated financial reporting. The other follows an accelerated, tax-driven method required by local law, applied through a coefficient that increases with the asset’s useful life. The two schedules rarely agree, and reconciling the gap between them, quarter after quarter, in a spreadsheet that lives outside the ERP, is exactly the kind of manual process that turns a routine close into a source of quiet risk.

That gap is what Microsoft is closing with Business Central accelerated depreciation, a new capability that makes accelerated depreciation methods for fixed assets standard, general-purpose functionality rather than a country-specific add-on. The feature entered public preview on June 5, 2026, and Microsoft’s release plan lists general availability for October 2026, putting it in the same wave as several other core financial management updates, including new handling for withholding taxes and vendor-specific numbering for self-billing invoices. For finance leaders at Business Central customers with international operations, particularly anyone with entities subject to accelerated or declining-balance tax depreciation requirements, this is worth planning for now rather than discovering after the fact.

Finance office desk with a laptop, binders, and a plant, representing fixed asset depreciation recordkeeping

How Business Central Accelerated Depreciation Works

Business Central has supported multiple depreciation methods for years, including declining-balance calculations. What’s new is not a depreciation method in isolation, but a mechanism for running two depreciation views of the same asset side by side and automatically tracking the difference between them. Setup happens in two places. A depreciation book is configured to use an accelerated depreciation method, and the fixed asset card itself is where the acceleration coefficient and related settings get entered. From there, Business Central calculates the accelerated depreciation amount, the equivalent straight-line amount for the same period, and the variance between the two, posting all three to the appropriate general ledger accounts without any custom extension in the mix.

This will look familiar to anyone who has worked with Business Central’s existing France localization, where a very similar pattern already exists to satisfy French tax law: companies above certain size thresholds must track the difference between accounting depreciation and a faster tax depreciation schedule, using what the system calls a derogatory posting structure, with the variance flowing to dedicated derogatory accounts. The mechanics described for this new, generalized feature (an acceleration coefficient, an automatically calculated linear equivalent, a tracked variance, and inquiry pages showing annual depreciation, variance, and remaining book value) map closely onto that existing model. Whether or not the underlying code is literally shared, the design clearly draws from a pattern Microsoft already had working and tested in one jurisdiction, and is now making available as base functionality rather than something scoped to a single country’s localization pack.

That distinction matters for anyone evaluating this outside France. A business in the United States, India, or the UK, for instance, doesn’t operate under the same statutory requirement to track a tax-accelerated depreciation variance the way French entities do. But plenty of these organizations still want the option: a US subsidiary with MACRS-based tax depreciation running alongside GAAP book depreciation, or a private company that simply wants to accelerate cost recovery for internal planning purposes while keeping a clean straight-line view for lenders or investors, are both scenarios this feature could serve without anyone needing to install a country pack that assumes French tax law.

Abstract illustration of two diverging depreciation curves converging into a single reconciled sphere

The Business Case, in Concrete Terms

The immediate value is not abstract. Today, a company that wants to run accelerated depreciation alongside standard book depreciation, without the France localization applying, typically does it in a spreadsheet, in a bolt-on tax fixed-asset tool, or by approximating it through manual journal entries. Each of those approaches introduces the same three problems: someone has to remember to update the calculation every period, the numbers live outside the system of record, and reconciling the two views at close consumes hours that could go toward analysis instead of arithmetic. Native support inside Business Central removes the reconciliation step almost entirely, because the accelerated amount, the linear equivalent, and the variance are all calculated and posted automatically as part of the standard depreciation run.

There’s a second, less obvious benefit for organizations weighing platform decisions. Companies migrating off legacy systems such as Dynamics GP or NAV, or evaluating Business Central against alternative ERPs during a broader Dynamics 365 implementation, often assume that anything resembling statutory dual-book depreciation requires a heavier, F&O-tier platform or a bolt-on fixed-asset module. A capability like this narrows that gap, and it’s a reasonable data point for IT directors and finance leaders building the business case for a Business Central consulting engagement rather than a more expensive alternative.

What Finance Leaders Should Decide Before Turning It On

The setup itself, a depreciation book configuration plus a coefficient on the asset card, is not the hard part. The hard part is the policy decision that has to happen first, and it belongs with the CFO and controller, not with whoever configures the system.

The first question is which assets actually warrant an accelerated view, and why. If there’s no statutory requirement driving it, the acceleration coefficient becomes a matter of internal accounting policy, and that policy should be documented and applied consistently rather than set asset by asset based on whoever happens to be entering the fixed asset card that week. The second question, and arguably the more consequential one for finance teams that haven’t dealt with dual-book depreciation before, is what the tax-versus-book variance actually represents on the balance sheet. In jurisdictions where accelerated tax depreciation legitimately exceeds book depreciation, that gap is typically the source of a deferred tax liability, and finance teams new to running parallel schedules should loop in their tax advisor or external auditor before the first variance posts, not after it shows up in a quarterly review with no clear explanation.

Third, this is a case where the preview window is genuinely useful rather than a formality. With public preview available since June and general availability not expected until October, there’s real time to configure this in a sandbox environment, run it against a representative sample of fixed assets, and confirm the inquiry pages produce numbers that match what a manual parallel calculation would show, before it touches production data. Given how much else is shipping in the same core financial management wave, including changes to withholding tax handling that could interact with the same vendor and asset records, a sandbox validation pass is worth the time even for teams that don’t consider themselves early adopters.

Finally, IT and finance should jointly confirm whether this actually reduces total license or tooling cost. If a bolt-on fixed-asset or tax depreciation tool is currently in use specifically to solve this problem, this feature is a legitimate reason to reevaluate that contract, but only after the sandbox testing confirms the native functionality produces defensible, audit-ready numbers on its own.

None of this makes accelerated depreciation a feature every Business Central customer needs to touch. Most domestic, single-entity businesses running straight-line depreciation for both book and tax purposes will have no reason to configure it at all. But for finance teams already juggling a manual reconciliation between two depreciation views, whether because of a French entity, a multinational tax position, or an internal policy choice, this closes a gap that has existed in Business Central’s core financial management module for a long time. Routeget Technologies has walked clients through comparable dual-book depreciation setups during Business Central and legacy ERP migrations, and the pattern holds regardless of which system is involved: the software can automate the calculation, but only the finance function that owns the underlying accounting policy can decide what that calculation should actually produce.

#BusinessCentral #FixedAssetDepreciation #TaxBookReconciliation #FinanceTransformation #ERPTaxCompliance #ERPModernization

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

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

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

What subcontractor vendor invoice matching actually changes

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

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

The match logic: what has to line up

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

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

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

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

Verification status: the workflow project managers actually see

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

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

Implementation considerations before rollout

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

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

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

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

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

Power Platform Agent Authentication Governance Reaches GA: What to Audit First

An IT administrator reviewing an agent identity and access governance dashboard on a large office monitor

A CISO at a mid-market manufacturer asked her Power Platform admin a simple question last month: how many Copilot Studio agents does the organization actually have running, and how many of them require anyone to prove who they are before they can use them? The admin came back three days later with a spreadsheet of 214 agents. Nineteen had “No authentication” configured. Four of those nineteen had access to a knowledge source containing vendor contract terms. Nobody remembered turning authentication off for any of them, because nobody had turned it on to begin with. It had simply never been set. That gap is exactly what Power Platform agent authentication governance, which reached general availability this month, was built to close.

Microsoft has been describing this exact scenario in its own guidance for a while. In a February 2026 security post, Microsoft described unauthenticated agents as a recurring pattern rather than an edge case: authentication gets “deactivated for testing, left in its default state, or misunderstood as optional,” and the result is an agent that anyone with a link can use, sometimes surfacing internal information through its topics, actions, or knowledge sources without anyone intending it to. The fix Microsoft has been building toward arrived this month, and it changes who is responsible for catching this problem before it reaches production.

What Power Platform Agent Authentication Governance Actually Does

The feature reached general availability on September 2, 2026, after a public preview that opened in late May. Listed in Microsoft’s release plan as “Manage agent security with enhanced admin controls,” it gives administrators a way to set authentication and access policy for agents centrally, at the environment or environment group level, inside the Power Platform admin center. Rather than relying on individual makers to choose the right authentication setting each time they build or republish an agent, an admin can now require Microsoft Entra ID authentication across a group of environments, permit a defined list of approved external identity providers for agents that genuinely need one, or block anonymous access outright.

The detail that matters most for a governance program is when these policies get enforced. This is not a design-time warning that a maker can dismiss and move past. Microsoft’s own documentation describes the policy as evaluated both when an agent is deployed and again at runtime, so a policy change made after the fact actually reaches agents that are already published, not just new ones being built going forward. That closes a gap that has existed in Copilot Studio governance for a while: DLP data policies could already restrict unauthenticated usage at the tenant level, but that control was blunt. It did not give admins a way to say, for example, that the environment group serving finance requires Entra ID, while a separate environment group hosting a public-facing customer service agent is allowed to run anonymously because that is the intended design.

That distinction is worth sitting with, because the instinct after reading a story like the manufacturer’s spreadsheet is to conclude that anonymous access is always the mistake. It isn’t. A number of legitimate agents, particularly ones embedded in Power Pages sites or public marketing properties, are supposed to be reachable without a sign-in. The problem in most organizations is not that anonymous agents exist. It is that nobody made a deliberate decision about which ones should, and the setting drifted in by default rather than by design.

Abstract illustration of glowing padlock and key icons connected in a network, representing agent identity and access governance

Why This Became Urgent Now

The timing lines up with a broader shift that most IT leaders are already tracking anecdotally even if they haven’t quantified it. Citizen-developer agent creation in Copilot Studio has grown faster than most organizations’ governance processes have kept pace with, and a maker publishing an agent from a template or a quick prototype rarely stops to think about identity architecture. Microsoft’s guidance on securing Copilot Studio deployments at scale describes a zoned model, where agents built by citizen developers are expected to carry the least privilege and the most constrained data access, and where authentication choices become progressively more deliberate as an agent moves toward professional development and broader distribution. Enforcement has lagged the model. Before this release, an admin who wanted to guarantee that zone boundaries actually held had to lean on DLP connector policies and manual audits, neither of which was built specifically to answer the authentication question.

There’s also a compliance dimension that will matter more to some organizations than others. Regulated industries, healthcare, financial services, and any company subject to a SOC 2 or ISO 27001 audit cycle have been fielding questions from auditors about AI agent access controls for a while now, often without a clean answer. A centrally enforced authentication policy, applied at the environment group level and demonstrably active at runtime rather than merely recommended at build time, gives those organizations something concrete to show. It is the difference between telling an auditor that agents are supposed to require authentication and showing them a Power Platform admin center screen where that policy is actually configured and enforced.

What to Audit Before You Roll This Out

The rollout sequence matters more than the feature itself, and getting it backwards creates its own incident. The first step is the one the manufacturer’s CISO already took: get a current inventory of every agent in the tenant and its existing authentication setting, broken down by environment. Most organizations doing this for the first time are surprised by the count, and a meaningful share of that surprise usually comes from test or proof-of-concept agents that were never decommissioned rather than from production systems.

Once the inventory exists, the harder work is deciding environment group boundaries before applying policy, not after. An environment group that mixes internal line-of-business agents with a customer-facing Power Pages chatbot forces an uncomfortable compromise: either weaken the policy to accommodate the anonymous agent or break a legitimate public integration. Splitting those into separate environment groups first, then applying a strict Entra ID requirement to the internal group and an explicit, reviewed exception for the external one, is the pattern that avoids both outcomes.

It is also worth coordinating this rollout with whoever owns DLP policy in the organization, since the two controls now overlap in purpose even though they operate at different layers. A tenant-wide DLP restriction on unauthenticated connector usage and an environment-group-level authentication requirement can either reinforce each other or produce confusing, hard-to-diagnose failures if they are configured without reference to one another. Treating this as a single governance conversation, rather than two separate admin tickets handled by different people, avoids that outcome.

Finally, this is a good moment to revisit whichever Center of Excellence process the organization uses to track agent inventory and ownership, since an authentication policy is only as good as the organization’s ability to know when a new agent shows up outside of it. The policy catches misconfiguration. It does not catch an agent nobody knew existed until the inventory audit runs again.

The Practical Takeaway

None of this requires a large project to act on immediately. A first pass, an inventory of current agents and their authentication settings, a decision about which environment groups genuinely need anonymous access and which don’t, and a staged policy rollout starting with the highest-risk internal environment group, is realistic within a normal sprint or two for most Power Platform admin teams. What changes with this GA release is that the tool for enforcing the decision now exists natively, rather than requiring a workaround built from DLP policies never designed for this specific job.

Routeget Technologies has been walking clients through Copilot Studio governance reviews since well before this feature existed, largely because the underlying problem, agents accumulating faster than anyone tracks their authentication posture, predates any specific Microsoft release. The general availability of centralized agent authentication governance does not solve that problem by itself. It gives the teams already paying attention to it a real lever to pull, and it gives the teams who haven’t started yet a clear, specific reason to.

#CopilotStudio #PowerPlatformGovernance #AgentAuthentication #AIGovernance #EnterpriseAI #DataLossPrevention