Business Central Archives

Business Central’s New EDI Documents Feature Won’t Let You Cancel Your EDI Provider

Finance operations manager reviewing electronic document exchange status in a logistics office

If your finance team is currently paying an outside EDI provider a recurring fee to keep your Business Central environment talking to Walmart, a major distributor, or a third-party logistics partner, the preview notes for Business Central 2026 release wave 2 probably caught your eye. Buried in the update 29.0 feature list is the new EDI documents feature: the ability to exchange orders and payments, not just invoices, directly through the E-Documents framework using the Peppol BIS 3 standard. For a CFO or IT director who has spent years signing checks to a middleware vendor just to keep retail trading partner mandates satisfied, that sentence reads like an invitation to finally consolidate. It is worth understanding exactly what changed before anyone drafts a cancellation notice.

What the new EDI documents feature actually adds

Business Central’s E-Documents framework is not new. It has existed for several release cycles as the mechanism behind country-specific e-invoicing mandates: Peppol for Australia and New Zealand, OIOUBL in Denmark, XRechnung and ZUGFeRD in Germany, Factura-E in Spain, with France support arriving this year. Until this release, the framework’s job was largely to get sales invoices out the door and purchase invoices in, formatted correctly for whichever national authority or trading network required them.

What update 29.0 adds, currently in public preview as of September 2026 and scheduled for general availability in October, is support for exchanging orders and payments through that same framework, using the Peppol BIS 3 EDI standard specifically. In practical terms, that means a document type beyond the invoice can now move through E-Documents using a message format built for machine-to-machine exchange rather than a PDF attached to an email. That is a genuine expansion of scope, and for the right customer it closes a real gap.

The catch is in the phrase “Peppol BIS 3.” Peppol is a specific network and message specification, developed originally for European public procurement and now widely used for e-invoicing compliance across the EU, the UK, Australia, New Zealand, and a growing list of other jurisdictions. It is not the same thing as the ANSI X12 or EDIFACT standards that govern the EDI relationships most North American manufacturers, wholesalers, and distributors maintain with retail trading partners. A purchase order transaction set 850, an invoice 810, or an advance ship notice 856 sent through a retailer’s EDI network does not speak Peppol, and nothing in this release changes that.

Abstract illustration of electronic documents flowing between two connected trading partner networks

Why the connector layer still matters

There is a second detail worth flagging before anyone assumes this feature makes Business Central’s e-document capability self-sufficient. The E-Documents framework has always relied on named third-party service connectors to actually move documents onto whatever network the recipient uses. Pagero, Avalara, Logiq, SignUp’s ExFlow e-invoicing service, and B2BRouter are the currently supported options, and each requires its own separate contract and, in most cases, its own subscription cost. Microsoft’s documentation is explicit that these are external commercial relationships, not services Microsoft itself manages end to end.

That architecture does not change with the EDI feature. Adding order and payment support to E-Documents means the framework can now carry more document types over the Peppol BIS 3 rail, but a business still needs a connector relationship in place to actually reach a Peppol access point, just as it does today for invoices. For a company operating primarily in Peppol-covered geographies, that is a meaningful simplification: one framework, one set of document types, and potentially fewer point-to-point integrations for order confirmations and payment status messages that previously ran through a separate mechanism entirely.

For a company whose EDI obligations run through a North American retail network instead, the calculus barely moves. The dedicated EDI platforms built around Business Central, names like TrueCommerce, SPS Commerce, and the various Business Central-specific EDI ISV solutions on AppSource, exist precisely because they translate between Business Central’s data model and the X12 and EDIFACT transaction sets that retailers, grocers, and big-box trading partners require, along with the value-added network relationships those partners often mandate. None of that is addressed by extending Peppol BIS 3 coverage to orders and payments. If your EDI provider’s invoice is for connecting to a VAN and translating X12 850s into sales orders, this preview feature does not touch that relationship at all.

What to actually check before wave 2 reaches general availability

The practical work here is not deciding whether to switch, it is figuring out which category your organization falls into, and that requires a document-by-document inventory rather than a guess. Start by pulling the list of every trading partner your company currently exchanges electronic documents with through Business Central, and note the standard each one actually uses. A subsidiary invoicing government or large enterprise customers in the EU, Australia, or New Zealand through a Peppol access point is a strong candidate to benefit directly once this feature reaches general availability, since order and payment documents for those same relationships may be consolidatable into the same connector and the same E-Documents setup already in place for invoicing.

A distribution or manufacturing business fulfilling retail purchase orders through a VAN-based EDI relationship should not expect this update to reduce that spend. It is worth raising the question directly with your existing EDI provider anyway, since some of them are exploring hybrid support that bridges Peppol and traditional EDI standards, and a provider roadmap conversation now costs nothing and might surface options before your next contract renewal.

It is also worth remembering that this is a preview feature, not a shipped one. General availability is not expected until October 2026, and preview functionality in Business Central has a track record of shifting in scope, licensing treatment, or connector support between preview and GA. Testing this in a sandbox environment against a real Peppol-connected trading partner, rather than assuming the release notes describe the final behavior, is the responsible way to validate whether it does what your business actually needs before making any commercial decision tied to it.

One more consideration deserves a place on the evaluation checklist: cost. Connector-based e-document exchange through Avalara, Pagero, or similar providers is typically priced per transaction or per connection, separate from Business Central licensing itself. Adding order and payment document types to that same connector relationship may increase transaction volume through the connector without necessarily reducing your total third-party spend, particularly if your current EDI provider is priced on a flat annual basis rather than per document. Getting an updated quote from your connector provider that reflects the expanded document scope, before assuming the math works in your favor, avoids an unpleasant surprise on the next renewal invoice.

The gap this does close

None of this is a criticism of the feature itself. Extending E-Documents to cover orders and payments, and doing it through a widely adopted international standard rather than a proprietary Microsoft format, is a sensible direction for a platform that increasingly serves multinational subsidiaries alongside single-entity small businesses. Firms with meaningful European, UK, Australian, or New Zealand operations that have already invested in Peppol-based invoicing now have a credible path to extend that same investment to a broader set of transaction types, which is exactly the kind of incremental platform improvement that reduces the number of point integrations a lean IT team has to maintain over time.

The mistake would be treating a preview release note as a green light to unwind an existing EDI relationship without first confirming which standard that relationship actually runs on. Routeget’s engagements with Business Central customers on electronic document strategy typically start with exactly that inventory: mapping every trading partner document exchange against the standard it uses, before any conversation about consolidating connectors or renegotiating contracts. That groundwork takes a few days, and it is the difference between a genuine cost reduction and a canceled contract that gets reinstated three months later once a retail partner’s EDI compliance team sends a noncompliance notice.

#BusinessCentral #EDIIntegration #PeppolBIS3 #ElectronicDocuments #TradingPartnerCompliance #DigitalTransformation

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.

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

Business Central ERP Modernization ERP Tax Compliance Finance Transformation Fixed Asset Depreciation Tax Book Reconciliation

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

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

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

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

Why tax jurisdiction matching needed its own review step

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

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

What the Tax Matching Agent actually does

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

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

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

Part of a larger connector overhaul, not an isolated feature

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

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

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

What technical teams should actually do with this

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

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

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

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

The takeaway

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

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

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

Business Central’s New Financial Report Change Log: What BC29 Actually Audits

Finance systems administrator reviewing a financial report audit trail dashboard in Business Central

A finance systems admin gets a message from the controller two days before month-end close: the Income Statement pulled into the board deck last quarter grouped two expense accounts differently than this quarter’s version does, and nobody can say who changed the row definition, or when. In most Business Central environments today, that question has no good answer, because there has never been a financial report change log tracking those definitions. General ledger entries are tracked obsessively. Posted documents are locked down. But the row, column, and report definitions that decide what a financial statement actually shows have sat outside the audit trail entirely, unless someone thought to add them to Change Log Setup years ago, which almost nobody did.

Business Central 2026 release wave 2, shipping as version 29, closes that specific gap. Two general-availability features land together: a financial report change log that runs automatically with no setup required, and a G/L account tracing tool that lets report authors see exactly how an account feeds into a calculation before they publish it. Both are currently in public preview, running from the first week of September through the first week of October 2026, with general availability expected once the wave completes its rollout in October. Neither one touches how reports are distributed. This is about knowing what changed in the definitions themselves, and why a number moved.

Why financial report definitions were an audit blind spot

Business Central’s Change Log has existed for years, and it works well once configured. An administrator opens Change Log Setup, picks the tables worth watching, and chooses between tracking every field or a curated subset, since tracking everything tends to bloat the database and slow things down. Microsoft’s own guidance steers people away from logging ledger entries and posted documents for exactly that reason, and toward system fields like Created By and Created Date instead. The result is a tool that most BC partners configure around customers, vendors, and a handful of setup tables, because that’s where the obvious audit risk lives.

Financial report row definitions, column definitions, and report definitions rarely make that list. They’re metadata, not transactional data, so they don’t feel like an audit priority in the same way a blocked vendor or a changed payment term does. But a single edit to a row definition, adding an account to a subtotal, changing a totaling formula, retiring a category mapping, can silently change what every downstream financial report shows without touching a single ledger entry. That’s precisely the kind of change that’s hard to catch after the fact and easy to miss during a routine change log review, because nobody thought to put it there.

What the financial report change log actually captures

The new financial report change log in BC29 doesn’t require anyone to open Change Log Setup at all. Direct modifications to financial row definitions, column definitions, and report definitions are recorded automatically, the moment they happen, regardless of whether change logging is turned on for anything else in the environment. Entries land on the same Change Log Entries page administrators already use for everything else: who made the change, what table and field, the old value, the new value, and when it happened.

Abstract illustration of financial report rows and columns tracing to general ledger accounts

That last detail matters more than it sounds. Business Central’s Change Log has a well-known quirk where entries don’t actually appear until the acting user’s session refreshes, whether that’s a session timeout, a company switch, or a full sign-out and sign-in. Teams unfamiliar with that behavior sometimes conclude the log isn’t working when a change made minutes ago doesn’t show up yet. That quirk applies here too, so it’s worth flagging to anyone reviewing financial report changes in near real time during a close cycle.

Because this tracking is always on for report definitions specifically, it sidesteps the performance tradeoff that governs everything else in Change Log Setup. Report and row and column definitions are edited rarely compared to transactional tables, so logging every field on them doesn’t carry the same database bloat risk that logging every field on, say, the G/L Entry table would. Microsoft appears to have made that call deliberately rather than leaving it to each partner to configure correctly, or more likely, not configure at all.

Tracing G/L account usage before you publish a change

The second GA feature addresses a different, more immediate problem: figuring out where a specific account shows up across a financial report before you make a change that affects it, rather than after. Financial reports in Business Central are built from row definitions and column definitions that act as two separate vectors, with each report cell calculated by applying a row’s formula against a column’s data definition. Rows commonly reference G/L Account Categories rather than individual accounts, a deliberate design choice that keeps a report resilient when the chart of accounts changes underneath it. That resilience comes at a cost: it’s genuinely hard to eyeball a row definition and know which accounts it actually pulls in, or whether an account has drifted out of its intended category entirely.

The account tracing capability gives report authors a way to identify uncategorized accounts and see how a given account maps into calculations, directly from within the report definition, before publishing. Paired with the change log, this closes a loop that previously required guesswork: an admin can now both trace forward, from an account to the reports it touches, and trace backward, from a report change to who made it and when.

What technical teams should actually do with this

Because the financial report change log is automatic and requires no configuration, there’s no setup checklist for the feature itself. The work is in the surrounding governance. Start by pulling the current Change Log Setup and confirming nobody already added the financial report tables manually in an attempt to solve this problem years ago; a duplicate log entry per change isn’t harmful, but it’s noise nobody needs. Next, decide on a retention policy specifically for these entries. Financial report definitions tend to see concentrated edit activity around fiscal year-end and during audit prep, when finance teams restructure statements for new account categories or reporting requirements, so a policy that clears entries older than a fixed window keeps the Change Log Entries page useful rather than cluttered with years of routine tuning.

It’s also worth briefing whoever owns financial reporting on the distinction between this feature and Field Monitoring, Business Central’s related capability that sends email alerts when sensitive fields change. Field Monitoring and Change Log Setup are mutually exclusive per table specifically to avoid redundant tracking, and the new automatic report-definition logging sits alongside both as a third, always-on mechanism. Nobody needs to configure alerts for report definition changes to get the audit trail, but a team that wants proactive notification rather than after-the-fact review will still need to build that separately, since the change log records history rather than pushing alerts.

One adjacent BC29 feature worth a brief mention, since it ships in the same wave and touches the same reports, is the ability to bundle multiple financial reports into a single scheduled PDF output. That’s a distribution capability, not a governance one, and it solves a different problem than the one this article covers. Teams evaluating both should treat them as separate rollout decisions: get the audit trail and account tracing configured and understood first, since that’s what protects report integrity, and treat distribution scheduling as a convenience layer on top once the underlying definitions are something you trust.

The practical payoff

None of this changes how anyone builds a financial report in Business Central. Row and column definitions still work exactly as they did, account categories still map the same way, and the Financial Reports page still looks the same. What changes is accountability. The next time a board-ready statement looks different from the prior quarter’s version and someone asks why, the answer no longer depends on institutional memory or a lucky guess about who touched what. It’s a filtered view on the Change Log Entries page, showing exactly which row, column, or report definition changed, who changed it, and what the value was before.

For organizations running Business Central as their financial system of record, particularly those with external auditors who ask pointed questions about report governance, that’s a meaningful gap closing quietly rather than a headline feature. Routeget Technologies has been walking clients through exactly this kind of financial reporting governance review as BC29 moves from preview toward general availability, and the pattern holds across nearly every environment we’ve looked at: the change log gap was real, and almost nobody had closed it on their own.

#BusinessCentral #FinancialReportChangeLog #ERPGovernance #GLAccountTracing #FinanceAutomation #ERPAuditTrail

Business Central ERP Audit Trail ERP Governance Finance Automation Financial Report Change Log GL Account Tracing

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

IT director reviewing a systems integration architecture diagram on a monitor in a modern office

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

An IT director doing an annual vendor risk review recently found an integration nobody on her team remembered building. A bank feed connector, installed years earlier by a consultant who has long since moved on, was quietly pulling transaction data into Business Central through a SOAP endpoint pointed at a standard Microsoft page. It had run without incident since before her tenure started. The discovery only mattered because of one line buried in a Microsoft release note: that endpoint, and every other SOAP connection built the same way, stops working the moment Business Central version 29 reaches general availability in the first week of October 2026.

That is the practical shape of the Business Central SOAP retirement. It is not a single dramatic cutoff so much as the final step in a multi-year phase-out that a lot of IT teams filed away as a developer’s problem and never revisited. Microsoft introduced a feature key called “Disable SOAP web services on Microsoft UI pages” in the 2025 release wave 1 update, version 26, and it has been switched on by default ever since, blocking any new attempt to publish a standard Microsoft page as a SOAP endpoint. What made that default setting survivable for older integrations was the fact that an administrator could still go into Feature Management and turn the key back off, keeping the legacy behavior alive. Version 29 removes that feature key entirely. Once it is gone, there is no setting left to flip back on, and any integration still pointed at a Microsoft UI page over SOAP simply stops receiving responses.

The Business Central SOAP Retirement Only Touches Microsoft’s Own Pages

The scope here matters more than the deadline itself, because it is easy to overreact or underreact depending on how the news reaches you. What is actually being removed in version 29 is narrower than “SOAP support in Business Central.” Microsoft’s own justification, stated plainly in its developer documentation, is that a UI page was never designed to function as a stable API contract: a field can move, a control can be renamed, and none of that counts as a breaking change from Microsoft’s perspective, even though it can silently break an integration built directly against that page’s SOAP surface. So the retirement targets exactly that pattern: standard, out-of-the-box Microsoft pages exposed as SOAP web services.

Two other patterns are not affected by this particular change. SOAP endpoints built on codeunits keep working, since a codeunit is intentionally structured as a stable interface rather than a UI surface. SOAP endpoints built on custom, per-tenant extension pages also continue to function, because your organization controls that page’s schema and accepts responsibility for changes to it. If your integration inventory turns out to be built entirely on one of those two patterns, version 29 will not touch it. Many organizations, though, will find that at least one long-running integration, often the oldest one, was built the simple way: pointing directly at a Microsoft page because that was the path of least resistance when someone set it up years ago.

Abstract illustration of a legacy data connector being replaced by a modern API connector

The Stopgap That Isn’t a Real Exemption

Microsoft’s own migration guidance includes an option that looks like an easy out: copy the source of the affected Microsoft page into a per-tenant extension, republish that copy as your own page, and expose the copy as a SOAP endpoint instead. Technically, this works, and it buys time without touching whatever consumes the integration on the other end. It is worth treating as exactly what it is, a stopgap, and not as a long-term architectural decision.

Two things argue against leaning on it permanently. First, you now own and maintain that copied page yourself, including any future logic changes Microsoft makes to the original that you will need to track and replicate by hand, which is precisely the maintenance burden the API-first approach was designed to avoid. Second, this is not the only deprecation moving through the same pipeline. Microsoft has already issued the equivalent warning for exposing Microsoft UI pages as OData endpoints, with removal currently targeted for the 2027 release wave 1 update, version 30. The pattern is consistent: UI-page-based web services of any protocol are being phased out in favor of purpose-built API pages and queries. A team that spends its 2026 budget re-platforming a SOAP integration onto a per-tenant extension, rather than onto a proper API page, is likely to be back doing similar work again in 2027 for the same underlying reason.

What This Means for Your Integration Portfolio

For a CIO or IT director, the practical risk is less about any single connector breaking and more about not knowing how many connectors exist in this pattern in the first place. SOAP-based integrations against Microsoft pages tend to cluster in a few high-value, low-visibility categories: bank statement and payment feeds set up early in an ERP implementation, EDI order intake with a long-standing trading partner, warehouse scanning or shop-floor tools built from an older sample or tutorial, and ISV add-ons purchased years ago from a vendor who may or may not have modernized their own connector since. None of these show up on a typical application inventory unless someone specifically goes looking for the transport protocol underneath them, which is exactly why this kind of deprecation tends to surface as an incident rather than as a planned project.

The financial exposure is concentrated, not diffuse. A broken bank feed means a manual reconciliation process returns overnight, right when finance least wants to discover it. A broken EDI intake means orders stop flowing from a partner who is unlikely to be sympathetic to an internal software upgrade as an excuse. Compare that to, say, a reporting dashboard built the same way, where a short outage is an inconvenience rather than a revenue event. Triage should follow that same logic: not every SOAP endpoint deserves equal urgency, but the ones tied to cash and order flow deserve attention well before the October deadline, not the week of it.

A Practical Sequence Before October

The starting point is visibility, not migration. Business Central logs incoming web service requests, and that telemetry can be pulled to show exactly which endpoints are being called, how often, and by page or codeunit type, before anyone commits engineering time to fixing something that may not even be at risk. From there, the sequence is straightforward in outline even if the execution takes real effort: separate the SOAP calls hitting Microsoft UI pages from those hitting codeunits or per-tenant extensions, since only the first category is on the clock; rank the affected integrations by business impact rather than by ease of fixing them, so a low-effort reporting connector does not quietly jump the queue ahead of a bank feed; and for anything ranked high, start the conversation with whoever owns the other end of the integration; internal developer, systems integrator, or third-party vendor, well before the release actually lands, since REST API pages or OData V4 endpoints for the same data may already exist and simply were never adopted when the integration was first built.

For integrations tied to a purchased ISV app, it is worth a direct question to the vendor rather than an assumption either way: ask specifically whether their connector talks to Business Central over SOAP against a standard page, and if so, what their own migration timeline looks like. A vendor who has not addressed this yet is effectively asking your organization to inherit their technical debt on their schedule, not yours.

Treat This as a Cleanup Project, Not a Fire Drill

The organizations that come out of this in good shape are the ones that treat the Business Central SOAP retirement as the forcing function for an integration inventory they should have had anyway, rather than as an isolated ticket to close before a deadline. We have seen the alternative version of this play out with prior Business Central deprecations: a scramble in the final weeks, a rushed fix that solves the immediate protocol problem without addressing the underlying design, and the same conversation repeating itself at the next deprecation cycle. Version 29 is a good moment to ask the larger question once, properly, rather than answering the narrow one twice.

#BusinessCentral #SOAPRetirement #ERPIntegration #APIModernization #IntegrationGovernance #DigitalTransformation

API Modernization Business Central Digital Transformation ERP Integration Integration Governance SOAP Retirement

Business Central CAMT.053 Migration: What Actually Needs to Change

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

A finance systems administrator at a mid-size manufacturer got an email last month from the company’s German house bank. Starting in the first week of the new quarter, the daily MT940 statement feed that had fed Business Central’s bank reconciliation for six years would stop. In its place: a CAMT.053 XML file, delivered on a different schedule, with a different structure. The email asked, almost as an afterthought, whether the ERP would “just work” with the new format. It was not a rhetorical question the bank expected an answer to. It was a notice.

That conversation is playing out across Business Central shops right now, and it is worth understanding why the Business Central CAMT.053 migration is arriving in 2026 specifically, what Business Central’s native tooling actually does with a CAMT.053 file, and where that tooling quietly runs out before a consultant finds out the hard way during a month-end close.

Why the Business Central CAMT.053 Migration Is Landing Now

The ISO 20022 migration has two distinct halves, and they are not moving on the same clock. The first half concluded in November 2025, when SWIFT ended coexistence for cross-border payment instructions. MT103, MT202, and the rest of the legacy payment message types stopped flowing in their original form; everything now moves as ISO 20022 MX, primarily pacs.008 and pacs.009. Institutions that kept sending legacy MT payment formats after that date found them auto-converted by SWIFT, with additional charges applied starting January 1, 2026.

The second half, covering statement and reporting formats rather than payment instructions, was deliberately left on a slower and less coordinated timeline. MT940 and MT950 (account statements), MT900 and MT910 (debit and credit notifications), and MT941 and MT942 (intraday reporting) are being replaced by camt.053, camt.054, and camt.052 respectively, but SWIFT is not converting MT9xx traffic to camt format automatically. Each bank negotiates its own cutover, account by account, on whatever internal schedule its own core banking migration allows. That is precisely why one Business Central customer converted a year ago without much drama, another is getting the notice this quarter, and a third will not hear anything until 2027. There is no single migration date to plan around. There are dozens of them, one per banking relationship, arriving on nobody’s schedule but the bank’s.

The Business Central Side of the CAMT.053 Migration

Business Central handles SEPA CAMT import through a Data Exchange Definition, a mapping layer that translates XML element paths in the bank’s file into fields across three tables: the General Journal table, the Bank Acc. Reconciliation header, and the Bank Acc. Reconciliation Line table. The mapping itself is fairly mechanical once you see it laid out. The transaction amount and its sign come from Stmt/Ntry/Amt combined with the credit or debit indicator at Stmt/Ntry/CdtDbtInd, with a configurable negative-sign identifier (typically set so that DBIT entries post as negative). Posting and transaction dates come from Stmt/Ntry/BookgDt, which can arrive as either a plain date or a full timestamp; Business Central accepts both. Payer information for matching comes from Stmt/Ntry/NtryDtls/TxDtls/RltdPties/Dbtr/Nm, and the free-text remittance information that drives most of the automatic matching logic comes from Stmt/Ntry/NtryDtls/TxDtls/RmtInf/Ustrd.

The field that actually determines whether any of this works is easy to miss: Stmt/Ntry/NtryDtls/TxDtls/Refs/EndToEndId. This is the identifier Business Central relies on to treat each line as unique within an open reconciliation. If a bank’s first-generation camt.053 export leaves this element empty, or populates it with a placeholder value repeated across an entire batch, the failure mode is not an import error. The file parses without complaint. What actually happens is worse in a subtler way: lines with a missing identifier get silently dropped, and lines that share a duplicated identifier with something already posted will import but fail automatic matching one by one, with no message pointing back to the cause. A team that has not specifically gone looking for this will spend a reconciliation cycle assuming the new statement format is simply less complete than the old one, when the real problem is a configuration gap that a five-minute look at the raw XML would have caught before go-live.

Abstract visualization of two data streams merging, representing a bank statement format migration

Where the Generic Definition Runs Out

Business Central ships a generic SEPA CAMT data exchange definition, and it is a reasonable starting point, not a finished solution. CAMT.053.001.08 is a schema, not a single fixed file layout, and individual banks populate it with their own dialect: some banks include optional elements Business Central’s default mapping ignores, some omit fields the default mapping expects, and namespace versions drift between institutions even within the same country. In practice, most multinational Business Central deployments end up cloning the generic definition per banking relationship rather than trying to maintain one shared version that quietly breaks every time a new bank is onboarded with slightly different habits.

It also helps to be honest about geographic scope. CAMT adoption is heavily concentrated in the EU and a handful of other markets that have committed to the SEPA-aligned schema. Plenty of banks elsewhere, particularly smaller regional institutions in North America and parts of Asia, are staying on BAI2 or proprietary flat-file formats for the foreseeable future, with no camt.053 timeline at all. A single Business Central tenant with entities in four countries can easily end up running MT940, camt.053, and BAI2 in parallel for years, not as a transitional state but as the normal operating condition. For organizations with a long tail of smaller regional banking relationships, this is where an ISV connector such as AMC Banking 365 Fundamentals earns its licensing cost: it converts against several hundred bank-specific format variants through its own service rather than asking an internal team to build and maintain a bespoke Data Exchange Definition for every regional bank quirk. That trade-off is worth evaluating deliberately, since routing statement data through a third-party conversion service is a data-governance decision as much as a technical one.

A Practical Migration Checklist

The teams that get through a bank-driven format change without a rough reconciliation cycle tend to do a few things in a specific order. They start by inventorying every bank account’s current import format code and confirming the actual cutover date per relationship, since assuming all banking relationships move together is the single most common planning mistake. Before the cutover, they request an actual test camt.053 file from the bank, not a sample pulled from vendor documentation, and run it through the Data Exchange Definition in a sandbox company where a bad mapping does no damage. They open that test file as raw XML and check the EndToEndId population line by line rather than trusting that because a mapping worked for one bank’s camt.053 export, it will behave identically for another bank using the same nominal schema version. Where any deviation shows up, they clone the generic SEPA CAMT definition into a bank-specific version rather than editing the shared default, so a fix for one relationship cannot silently change behavior for every other bank account using the same code. They keep the outgoing MT940 or BAI2 definition active and assigned for as long as the bank is willing to run both feeds in parallel, because a same-day cutover with no fallback window turns any mapping problem into an immediate reconciliation gap. And before retiring the old feed for good, they re-test automatic matching rates against a full month of real transaction volume on the new format, since a quiet drop in match percentage is a far more reliable early warning of a mapping issue than an outright import failure would be.

What Copilot’s Bank Reconciliation Assist Does and Doesn’t Solve Here

Business Central’s Copilot-assisted bank reconciliation feature, currently in preview, is genuinely useful for what it does: it analyzes unmatched transaction descriptions and ledger entries to suggest matches and likely G/L accounts, including scenarios where a single deposit needs to be split across several invoices. It is worth being clear about its boundaries in this specific context, though. It operates entirely downstream of the Data Exchange Definition, on statement lines that have already been successfully parsed into the system. If a mapping problem is dropping or mismatching lines before they ever reach the reconciliation worksheet, no amount of AI-assisted matching afterward will surface or correct that. The feature also performs best when transaction descriptions and G/L account names share a single consistent language, which is worth double-checking specifically during a format changeover, since a bank’s new camt.053 export sometimes reformats descriptive text differently than its old MT940 feed did.

The Deadline Is the Bank’s, Not Yours

None of this is a discretionary upgrade a Business Central team can schedule around a quieter month. It is a mapping and validation project with a deadline set by someone else’s core banking migration, arriving on a per-relationship basis rather than a single company-wide date. The organizations handling it well are the ones treating each bank’s cutover notice as a trigger for testing, not as an announcement to file away until the old feed actually stops. Routeget has walked several clients through exactly this kind of parallel MT940 and camt.053 coexistence during multi-entity rollouts, and the pattern is consistent: the mapping work is small, but only when someone does it before the bank forces the issue rather than after.

#BusinessCentral #CAMT053Migration #BankReconciliation #ISO20022 #DataExchangeDefinitions #ERPIntegrations

Bank Reconciliation Business Central CAMT.053 Migration Data Exchange Definitions ERP Integrations ISO 20022

Business Central’s Outlook Integration Deadline Is October 1, 2026

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

An IT Director at a distribution company we work with found out about this deadline the way most people do: from a support ticket, not a Microsoft email. A sales rep’s Outlook add-in stopped letting her attach a quote from Business Central mid-thread, and the contact she’d synced from BC to Outlook six months ago had quietly vanished from the folder it used to sit in. Nothing had changed on her machine. What had changed was that her company’s Business Central environment was still two release waves behind, and Microsoft had already started tightening the plumbing underneath a feature nobody in IT had flagged as fragile.

That plumbing is Exchange Web Services, the aging protocol Outlook add-ins and contact sync in Business Central have leaned on for over a decade. Microsoft is retiring it, and the resulting Outlook integration deadline that Business Central’s own product team has set is considerably firmer than the platform-wide retirement schedule most IT leaders have heard about. If your organization runs Business Central and anyone in sales, purchasing, or accounting touches customer or vendor contacts through Outlook, this is worth twenty minutes of your attention before the end of the month.

What’s Behind the Outlook Integration Deadline

Exchange Web Services, usually shortened to EWS, is the API that has quietly connected Outlook to a long list of Microsoft and third-party applications since the mid-2000s. Microsoft first announced its deprecation back in 2018, but the timeline accelerated meaningfully after the Midnight Blizzard security incident in January 2024 pushed the company toward faster retirement of legacy authentication and API surfaces across Exchange Online. The result, as published by the Exchange engineering team, is a phased shutdown: EWS begins to be disabled globally starting in October 2026, with full disablement across all tenants by April 2027.

Business Central’s product group didn’t wait for that full window to close. Because the older Exchange-based contact synchronization and Outlook add-in deployment in Business Central depend directly on EWS calls, the team attached a much nearer deadline to its own 2026 release wave 1 features: organizations need to be on Business Central version 28.0 or later, and Microsoft has stated plainly that after October 1, 2026, Outlook add-in functionality and contact sync built on the older Exchange connection may stop working in earlier versions. That is a considerably tighter window than the broader EWS retirement calendar, and it is the one that actually matters if you’re planning around this.

What Breaks in Practice, Not in Theory

For a company still running a pre-28.0 version, the practical failure points are the ones your sales and finance teams touch daily rather than anything IT usually monitors. The Outlook add-in that lets a salesperson pull up a customer’s Business Central record, attach a quote, or check open invoice balances without leaving their inbox depends on that Exchange connection to authenticate and retrieve data. The legacy Exchange Sync. Setup page, which many mid-market Business Central customers configured years ago and then never touched again, uses EWS to keep a “Business Central” folder of synced contacts current in each user’s Outlook. Automatically tracking email correspondence against a customer record, a feature accounting and account management teams tend to rely on more than they realize until it’s gone, runs through the same plumbing.

None of this fails with a dramatic outage. It fails quietly: an add-in that used to load now times out, a contact that used to sync now sits stale, an email that used to log itself against a customer record now just sends. That’s a worse failure mode for a CIO to manage than a hard outage, because it doesn’t generate an incident ticket. It generates a slow trickle of user complaints that get diagnosed as one-off glitches for weeks before anyone connects them to a platform deprecation that IT technically knew about.

Abstract visualization of data synchronization flowing between two connected systems on a laptop screen

What Version 28 Actually Replaces It With

Business Central 2026 release wave 1, generally available since April 1, 2026 and auto-enabled for all users on that version, rebuilds this integration on Microsoft Graph instead of EWS. The most visible change is a new “Synchronize with Outlook” action added directly to the Contacts list, which copies selected contacts from Business Central into Microsoft 365, making them usable in both Outlook and Teams. Unlike the old Exchange Sync. Setup configuration, which required a separate admin setup flow and validated an Exchange connection before anything would sync, this action sits where sales and account teams already work, and it supports syncing in either direction if an organization wants contacts created in Outlook to flow back into Business Central.

The other change worth flagging to your security and IT operations teams directly is that Outlook add-in installation now requires a one-time additional setup step to verify the account, a deliberate friction point Microsoft added for account protection reasons rather than a bug. If your organization uses centralized deployment to push the Business Central add-in to users automatically rather than relying on individual installs, that deployment process still works, but the added verification step means it is worth testing the rollout against a pilot group rather than assuming a push that worked in 2025 will behave identically in 2026.

Who Is Actually at Risk

If your Business Central environment is a standard SaaS deployment on Microsoft’s evergreen update cadence, there’s a reasonable chance you’re already on version 28.0 or close to it, since Microsoft pushes two release waves a year to every SaaS tenant on a schedule customers don’t fully control. The organizations that should be checking their version today rather than assuming they’re covered fall into a narrower but not small group: companies running Business Central on-premises, where upgrades are a deliberate IT project rather than an automatic platform event; companies that migrated from Dynamics GP, NAV, or SL in the last two years and may still be running an early post-migration version they haven’t touched since go-live; and any organization that has deliberately delayed a release wave update because of a customization or third-party integration compatibility concern, which is common enough in manufacturing and distribution environments with heavily extended BC implementations.

Checking your version takes a few minutes: in Business Central, the Help and Support page shows the current version and build number directly, and any IT Director who can’t answer “what release wave are we on” from memory should treat that itself as a minor governance gap worth closing regardless of this specific deadline.

What to Do Before October 1

The organizations that will sail through this deadline without incident are the ones treating it as a two-part check rather than a single upgrade task. The first part is confirming the Business Central version itself, since anything at 28.0 or later already has the Graph-based integration and doesn’t need to do anything further beyond being aware the old Exchange Sync. Setup pages are being phased out and shouldn’t be reconfigured going forward. The second part, and the one that gets missed, is validating that Outlook add-in deployment and any automated email-tracking workflows actually work end to end after an upgrade, not just that the version number changed. An upgrade that technically completes but leaves the add-in’s new security verification step unaddressed for most users produces the same quiet failure pattern as not upgrading at all, just with a shorter fuse. For any organization using EWS-dependent integrations beyond Business Central itself, Microsoft’s own EWS Usage Reports in the Microsoft 365 admin center are worth a look this month, since Business Central is rarely the only application in a tenant still calling that API.

None of this requires a large project. It requires someone in IT confirming a version number, someone in sales or finance confirming the add-in still authenticates cleanly, and roughly three weeks of runway that is shrinking by the day. Routeget Technologies has walked several clients through exactly this check in the past month, and in every case the fix was smaller than the anxiety the deadline initially produced, provided someone looked at it before October 1 rather than after.

#BusinessCentral #OutlookIntegration #ExchangeWebServices #ERPGovernance #Microsoft365Integration #DynamicsMigration

Business Central Dynamics Migration ERP Governance Exchange Web Services Microsoft 365 Integration Outlook Integration

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.

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

Business Central ERP Reporting Finance Automation Financial Report Packages Month End Close

Business Central 1099 Thresholds Didn’t All Move Together in 2026

Finance controller reviewing a tax compliance and vendor payments dashboard on a wall-mounted monitor in a modern office

A controller closing out Q3 payables in Dynamics 365 Business Central recently found herself staring at a vendor card for a landlord who’d been paid $1,400 in rent through September. Under the threshold she believed applied for 2026, that vendor wouldn’t need a 1099-MISC at all. She was wrong about that specific case (rent does cross the new reporting line), but the mistake that actually worried her had happened two months earlier, when she updated every box minimum in the company’s Vendor Box Setup to a single new number because that was the figure everyone in her network was repeating. Attorney gross proceeds and royalty payments to a handful of consultants quietly stopped generating 1099s the moment she made that change, because neither of those categories moved.

That’s the problem with updating Business Central 1099 thresholds for 2026: the increase is real and significant, but it applies to almost none of Form 1099-MISC uniformly. For a finance team running Business Central, the risk isn’t that they’ll miss the change entirely. Microsoft’s own release notes and every ERP consulting blog covered it. The risk is that they’ll apply it correctly to the one box everyone talks about and incorrectly to the six or seven boxes nobody mentions, inside a system that makes it just as easy to set a wrong minimum as a right one.

What actually changed for tax year 2026

For payments made on or after January 1, 2026, the reporting threshold for Form 1099-NEC nonemployee compensation, and for several categories on Form 1099-MISC, rises from $600 to $2,000. That covers rents, prizes and awards, other income, medical and health care payments, crop insurance proceeds, section 409A deferrals, and nonqualified deferred compensation. It does not cover royalties or broker payments in lieu of dividends and interest, which stay at a $10 minimum, and it does not cover gross proceeds paid to attorneys or purchases of fish for resale, which stay at $600. Interest, dividend, and retirement distribution reporting on Forms 1099-INT, 1099-DIV, and 1099-R sit outside this change entirely, still governed by their own long-standing $10 minimums. Starting in 2027, the $2,000 figure is subject to inflation adjustment, which means the number itself won’t stay fixed even for the categories it does apply to.

One rule that didn’t move at all: any business filing ten or more aggregate information returns across all form types in a calendar year is still required to file electronically rather than on paper. That threshold, which has applied since the aggregation rule took effect for returns filed in 2024, catches most Business Central customers well before they’d ever consider paper filing as an option, which makes the electronic filing path the default rather than a special case.

Business Central 1099 thresholds live box by box, and nothing warns you they differ

Business Central’s current 1099 architecture, rebuilt in the 27.2 release toward the end of 2025, replaced the older preprinted-forms workflow with a set of purpose-built pages: IRS Forms Setup for email templates, IRIS credentials, and TIN protection controls; IRS Reporting Periods for managing each year’s cycle, with a copy-forward action to bring last year’s configuration into the new period; Vendor Box Setup for mapping each vendor to the specific 1099 form and box their payments belong in; and a Form Documents page for generating, reviewing, and transmitting the actual forms.

Accounts payable specialist at a dual-monitor workstation reviewing a vendor tax form configuration screen with a numeric threshold table

The box minimum lives at the box level by design, which is exactly right in principle. The trouble shows up in practice, because nothing in that setup screen warns a controller that the value they’re about to paste into every row isn’t the same value for every row. A company that runs an “Update Form Boxes” pass once a year, changes the number that made the news, and moves on will end up with 1099s that look complete and are quietly wrong. Under-reporting a required form doesn’t just create IRS exposure; it creates a vendor relations problem when that vendor’s own accountant asks where their form went, and a documentation problem when an auditor asks why the threshold on file doesn’t match what’s printed in the IRS’s own instructions for that box.

What native filing now covers, and where it still stops

The bigger structural change in Business Central’s 1099 handling isn’t the threshold at all. It’s that the platform can now submit forms directly to the IRS’s Information Returns Intake System, IRIS, through an API integration that reached general availability on November 1, 2025, for Business Central Online. Forms transmit without a manual export and re-import step, and an IRIS Transmission page tracks status so finance doesn’t have to guess whether a batch went through. Copy B, the version vendors receive, prints or emails as a plain-paper substitute rather than requiring the preprinted stock that year-end close teams used to scramble to order.

That’s a meaningful reduction in the case for a third-party 1099 add-on, but it isn’t a full replacement for one, and it’s worth being specific about why. As of the current release, Business Central’s Form Documents page has no option to print or email every vendor’s form in a single action; each one has to be handled individually, though Microsoft has flagged bulk printing and emailing as coming in a near-term update. TIN matching against IRS records isn’t part of the native workflow, so a company that wants pre-filing verification that a vendor’s name and taxpayer ID actually match still needs to run that check somewhere else. State filing is out of scope too: IRIS handles federal transmission, and any state that doesn’t participate in the Combined Federal/State Filing Program still needs its own submission, which is exactly the kind of gap that standalone 1099 compliance apps in the Business Central ecosystem were built to close and continue to be relevant for. Correction and amendment handling after an original form has already transmitted is also thinner in the native tool than in most dedicated filing services, which matters more than it sounds like it should, since threshold-driven errors are precisely the kind of mistake that generates corrections.

What this means for the close calendar, not just the tax calendar

None of this is a reason to delay adopting the native IRIS integration. Eliminating the preprinted-forms supply chain and the manual transmission step is a genuine operational win, and most finance teams should move onto it as their filing method regardless of what else they use alongside it. The point is narrower: the threshold change is a forcing function to actually open Vendor Box Setup and check every box against the IRS’s own 2026 instructions, line by line, rather than trusting whatever number was last typed in.

Finance and compliance team reviewing a year-end tax compliance checklist and reconciliation chart in a meeting room

That review belongs on the calendar before the fourth quarter closes, not in the scramble between January 1 and the filing deadline. It’s worth having someone outside of accounts payable, ideally whoever owns tax compliance or the external CPA relationship, sign off on the box configuration once it’s set, since the people most likely to hear about the threshold change first are the ones least likely to know which of the seven or eight affected categories it actually touches. If the organization already licenses a third-party 1099 or AP compliance app for TIN verification, bulk processing, or state filing, this is also the moment to confirm that app’s own 2026 configuration has been updated to match, rather than assuming it inherited the change automatically from Business Central.

Routeget has walked several clients through exactly this kind of box-by-box reconciliation ahead of a release change, and the pattern holds regardless of company size: the failure mode is never a controller who ignores a well-publicized rule change. It’s a controller who applies it correctly to the one number that made headlines and never checks the six that didn’t.

#BusinessCentral #1099Thresholds #VendorBoxSetup #IRISFiling #YearEndClose #TaxCompliance

1099 Thresholds Business Central IRIS Filing Tax Compliance Vendor Box Setup Year End Close

Business Central Assumes Infinite Capacity. Your Shop Floor Doesn’t.

Manufacturing operations manager reviewing a production scheduling timeline display in a plant office

A plant manager pulls up a production order in Dynamics 365 Business Central on a Tuesday morning and finds the scheduled start date sitting three days in the past. Nothing is wrong with the data. Business Central’s scheduling engine did exactly what it was designed to do: it calculated lead times backward from a promised ship date, ignored what else was already booked on that work center, and produced a plan that assumes the shop floor has unlimited hours to give. The manager now has two choices. Spend the next hour manually rearranging operations by eye, or accept a schedule that was never realistic in the first place. Multiply that by every work center, every week, and the real cost of Business Central capacity planning becomes visible: not a software defect, but a design decision that a lot of growing manufacturers eventually outgrow.

This is not a knock on Business Central as an ERP platform. For finance, inventory, and general operations, it does what a mid-market system should do. But its native production scheduling was built around a simpler assumption than most discrete or process manufacturers actually operate under, and understanding exactly where that assumption breaks is the first step toward deciding whether to live with it, work around it, or bring in something purpose-built to close the gap.

How Business Central Capacity Planning Works Today

Business Central schedules production orders using routing times, work center and machine center calendars, and either a forward or backward scheduling direction depending on whether the driving date is the order start or the promised delivery date. By default, this runs as infinite capacity scheduling: the engine calculates when an operation should happen based on lead times and sequencing, without checking whether the work center is already booked during that window. It is fast, and for a single order in isolation it produces a clean answer. The trouble starts when dozens of orders compete for the same handful of machines.

Business Central does offer a step toward realism through capacity constrained resources. A planner can register a work center or machine center as capacity constrained, which shifts scheduling to account for existing load rather than assuming the resource is always free. Manufacturers can also open the load matrix on a work center card and view capacity against load by day, week, or month, in either a net-change or cumulative view, which is genuinely useful for spotting a bottleneck before it becomes a missed ship date. What this setup does not do is resolve the conflict automatically. It surfaces the overload and leaves the planner to fix it, one operation at a time, inside a grid rather than a visual timeline.

That distinction, between a system that flags a problem and one that helps you solve it, is where the native tool set runs out of runway for a lot of manufacturing operations.

Where the Gap Actually Shows Up

The practical failure modes tend to look the same across different manufacturers, regardless of industry. Sequencing decisions, such as which of three competing orders gets the CNC machine first on Thursday afternoon, are left entirely to the planner’s judgment rather than being informed by setup time, tooling changeovers, or downstream dependencies the system already has data on. Machine breakdowns, absenteeism, and rush orders are realities that the schedule has no mechanism to absorb once it has been generated, so a single disruption cascades into an afternoon of manual replanning rather than a quick recalculation. And because the standard interface presents schedule data as rows in a list rather than bars on a timeline, a planner cannot see at a glance that moving one operation two hours later would clear an overload three operations downstream. Every one of these is solvable inside Business Central’s data model. None of them is solvable inside its native screens without a meaningful amount of planner effort and institutional memory about which orders always cause trouble.

For a small job shop running a handful of work centers, this is manageable with discipline and a good planner. For an operation running double-digit work centers with mixed routings, alternate machines, and customers who expect accurate ship dates, the manual overhead compounds fast, and it tends to land on the same one or two people who become a single point of failure for the entire schedule.

What a Visual Scheduling Layer Adds

This is the gap that a category of AppSource-listed manufacturing extensions has grown up to fill, and it is worth understanding as two distinct tiers rather than one undifferentiated feature.

The first tier is visual scheduling: a Gantt-style planning board that sits on top of Business Central’s existing production order and routing data, showing operations as draggable bars against work centers and machine centers rather than as list rows. NETRONIC’s Visual Production Scheduler, now part of Boyum IT following its 2024 acquisition, is the best-known example of this approach. Moving a bar reschedules the operation and writes the change back to the underlying production order immediately, with capacity histograms showing utilization by day or week so a planner can see an overload forming before committing to a change. This does not automate the scheduling decision. It makes the decision visible and fast to execute, which for many operations is the actual bottleneck rather than the underlying math.

Production planner reviewing a visual scheduling board with machine and work center bookings at a workstation

The second tier adds an automated finite capacity engine on top of that visualization. Insight Works’ MxAPS and NETRONIC’s Visual Advanced Production Scheduler both fall into this category, generating a schedule that accounts for machine and labor availability, tooling constraints, and material readiness without manual sequencing, and allowing planners to run multiple what-if scenarios before publishing one to the live schedule. This tier is a genuinely different proposition than visual scheduling alone. It is closer to the finite capacity planning Microsoft already offers natively in Supply Chain Management for enterprise customers, delivered instead as a third-party layer for the Business Central side of the product family, which does not include an equivalent built-in optimizer.

Neither tier is free, and neither is a drop-in decision. MxAPS, for example, requires the Business Central Premium edition, which itself carries a per-user cost difference from Essentials that should be part of the licensing conversation before a manufacturing operations leader gets attached to a specific tool. The right question is not which named product to buy. It is which tier of capability the operation actually needs, because a company struggling mainly with schedule visibility and manual drag-and-drop effort may get most of the value from the first tier at a fraction of the cost and implementation complexity of the second.

Deciding Whether This Is Worth Solving

Before budgeting for either tier, it is worth running a short internal audit. How many hours per week does a planner spend manually rearranging the schedule after it is first generated, and what is that time worth against a subscription cost measured in the low thousands per year. How often does a customer-facing ship date change because of a scheduling conflict that only became visible after the fact, rather than being caught in advance. And how much of the current process depends on one person’s memory of which machines, operators, or tooling combinations tend to cause problems, since that is institutional risk regardless of what software is in place.

If the answer to those questions points to real, recurring cost, a visual scheduling layer is one of the more straightforward manufacturing investments to justify, because the software sits directly on top of data Business Central already has rather than requiring a new implementation project. If the disruption is occasional and a disciplined planner is already managing it well with the load matrix and capacity constrained resources, it may be entirely reasonable to hold off and revisit the question as order volume or work center count grows.

Routeget Technologies has walked manufacturing clients through exactly this evaluation, weighing native capability against the two tiers of scheduling extensions before a licensing dollar is spent, and the pattern holds across most engagements: the decision is rarely about which vendor has the flashiest demo. It is about matching the tier of automation to the actual planning problem on the shop floor, and being honest about how much of that problem discipline alone can solve versus how much genuinely requires a different tool.

#BusinessCentral #ManufacturingScheduling #ProductionPlanning #ERPCapacityPlanning #DiscreteManufacturing #DigitalTransformation

Business Central Digital Transformation Discrete Manufacturing ERP Capacity Planning Manufacturing Scheduling Production Planning