Business Central Withholding Tax Just Went Standard. The Setup Still Isn’t a Checkbox.

Finance director reviewing an international vendor payment and tax compliance dashboard in a modern office

For years, a Business Central partner fielding a withholding tax requirement from a customer expanding into Brazil, Nigeria, the Philippines, or a dozen other markets had exactly two honest answers: buy a third-party ISV solution built for that specific jurisdiction, or write custom code against the purchasing posting routines and hope the next major version upgrade didn’t break it. Neither answer was cheap, and neither scaled if the same customer later opened operations in a second country with a different withholding regime. That gap is what Microsoft’s new Business Central withholding tax engine is built to close. With the public preview that opened April 1, 2026 and general availability targeted for October 2026, Microsoft has built the calculation logic directly into the standard, non-localized version of the product, available for any country or region where a business needs it.

This matters more than it might sound like on first read. Country-specific withholding tax logic has existed in Business Central for a long time, but only inside the local functionality packs for markets like Italy, India, Australia, and New Zealand, each maintained as its own separate implementation with its own tables and its own quirks. A partner supporting a customer with entities in Italy and Colombia couldn’t reuse the Italian withholding tax setup for the Colombian entity, because the two were never built on shared logic. The new engine changes that by putting a single, configurable withholding tax framework into the base application, meaning any tenant, in any country, can turn it on without waiting for Microsoft (or an ISV) to ship a localization for that specific jurisdiction.

How the Business Central Withholding Tax Engine Works

The mechanics are straightforward at the conceptual level. When you post a purchase invoice or purchase order for a vendor flagged as withholding tax liable, Business Central calculates the applicable withholding tax based on your configuration, withholds that amount from what you’d otherwise pay the vendor, and creates a withholding tax entry for tracking and later settlement. A separate action, Calculate and Post Withholding Tax Settlements, lets you process and remit those withheld amounts to the tax authority for a given period. None of that is conceptually new to anyone who has worked with Italian or Indian withholding tax before. What’s new is that it’s no longer bolted onto a country pack; it lives in General Ledger Setup as a feature you enable directly.

Enabling it is only the first step, and this is where the “just flip a switch” narrative some blog posts have used falls apart under any real implementation pressure. After turning on Enable Withholding Tax in General Ledger Setup, you still need to build out four interconnected setup layers before a single invoice will calculate correctly. First, Withholding Tax Revenue Types, which define the categories of taxable transactions (each with its own code, description, and display sequence) and which later drive statutory reporting and certificate generation. Second, Withholding Tax Business Posting Groups, assigned to the vendors subject to withholding, and Withholding Tax Product Posting Groups, assigned to the items or G/L accounts the tax applies against. Third, a Withholding Tax Posting Setup record that links a specific business posting group to a specific product posting group and defines the actual calculation behavior: the calculation rule (less than, equal to, or another comparison against a threshold), a minimum invoice amount below which no tax is withheld, the withholding percentage itself, and a Realized Withholding Type that determines whether the tax is recognized at invoice posting, at payment posting, or at whichever comes first. Fourth, the G/L account setup for the prepaid and payable withholding tax accounts, plus the balancing account types and numbers Business Central needs to post the offsetting entries correctly.

That Realized Withholding Type field deserves particular attention from anyone implementing this for a jurisdiction they haven’t worked with before, because it isn’t a cosmetic timing preference. Statutory withholding regimes frequently specify exactly when the withholding obligation legally arises, and that moment doesn’t always match Business Central’s default assumptions. A configuration that recognizes withholding tax at invoice posting when the local rule requires recognition at payment will produce entries that reconcile cleanly inside Business Central while being wrong for the actual filing. This is not a gap in the software so much as a reminder that a generalized engine can’t encode every country’s statutory timing rules for you; that judgment call sits with whoever configures the posting setup, and it needs to be validated against actual local tax guidance, not against what feels intuitive from a US or UK accounting background.

Abstract illustration of a digital invoice with a portion of its value being withheld into a separate ledger

The Parts the Documentation Leaves for You to Test

Microsoft’s own documentation for this feature is candid about what it covers and noticeably quiet about several scenarios that any multinational deployment will eventually hit. There’s no published guidance yet on how withholding tax interacts with early payment discounts, where the discount changes the payment amount after the withholding calculation might already have run. There’s nothing specific on multi-currency purchase documents, where the withholding percentage presumably applies to a converted amount, but the conversion timing (invoice date rate versus payment date rate) isn’t spelled out. Prepayment scenarios, where part of the vendor payment happens before the final invoice, aren’t addressed either, and neither is whether a single vendor can carry more than one withholding tax code simultaneously for different transaction types.

None of this means the feature is unfinished in a way that should block evaluation. It means that any partner scoping an implementation should treat those four scenarios (discounts, multi-currency, prepayments, multiple codes per vendor) as required test cases before go-live, not edge cases to handle reactively after a customer complaint. Build a small set of test vendors and test posting groups in a sandbox, run each scenario through to a posted settlement, and compare the resulting entries against what the local tax authority actually expects. That’s a half-day of structured testing that will surface problems far more cheaply than discovering them during a live settlement run in month three.

There’s a second practical wrinkle worth planning around: coexistence with the existing localized versions. A customer running Italian local functionality for their Milan entity and the new standard engine for a newly opened Kenyan entity now has two withholding tax implementations active in the same tenant, built on different tables, with different setup pages, and (presumably, though Microsoft hasn’t published a migration path) no automatic bridge between them. For partners supporting genuinely multinational customers, this is worth raising proactively rather than waiting for someone to ask why the Italy withholding tax report doesn’t include Kenyan vendors.

Why the Timing Matters Right Now

Because the feature is still in public preview as of this writing, with general availability set for October 2026, this is the window where testing and feedback actually shape the shipped product rather than reacting to it after the fact. A conflicting timeline circulated by at least one independent Business Central blog puts general availability as early as June 2026, but Microsoft’s own release plan documentation lists October 2026 as the GA date, which is the figure worth planning around until Microsoft says otherwise. Partners with customers who have been paying for third-party withholding tax add-ons or running custom code against the purchasing module have a real opportunity here: a standard, Microsoft-supported alternative is arriving, and the preview period is the right time to validate it against the specific statutory requirements those customers already comply with, rather than assuming general availability means production-ready for every jurisdiction on day one.

At Routeget, this is the kind of feature we tend to see underestimated at the scoping stage, precisely because “Microsoft now supports withholding tax natively” sounds like it closes a requirement rather than opening a configuration project. The posting groups, the realized timing decision, and the untested edge cases are where the actual implementation effort lives, and getting them wrong doesn’t surface until a settlement run doesn’t match what the tax authority expected.

#DynamicsBusinessCentral #WithholdingTax #FinanceAutomation #TaxCompliance #ERPGovernance #GlobalFinance

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.

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

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

France’s E-Invoicing Mandate Is Now Live. Here’s What Dynamics 365 Finance Teams Still Need to Check.

Abstract visualization of connected electronic invoices flowing on a monitor in a European finance office, representing the France e-invoicing mandate for Dynamics 365 Finance.

On September 1, 2026, France’s e-invoicing mandate stopped being a future compliance project and became an active legal requirement. Large and mid-sized companies operating in France are now required to issue structured electronic invoices for domestic B2B transactions, and every company doing business in the country, regardless of size, must now be able to receive them. If your Dynamics 365 Finance environment was still treated as “on the roadmap for later this year,” that roadmap has already run out.

This is the third deadline France has set for this reform. The original target was January 2023. It slipped to July 2024, then again to September 2026, and each delay gave finance and IT teams a reasonable excuse to deprioritize the work. That excuse no longer applies. Microsoft shipped the France e-invoicing mandate feature for Dynamics 365 Finance to general availability on July 24, 2026, after a public preview that opened in late April, and the enforcement clock is now running against a live requirement rather than a projected one.

What France’s E-Invoicing Mandate Actually Changed, and What Didn’t

The French reform bundles two distinct obligations that are easy to conflate. E-invoicing covers the structured exchange of invoices for in-scope domestic B2B transactions: sales orders, free text invoices, project invoices, credit notes, and customer prepayment invoices between French entities. E-reporting covers everything that falls outside that scope, including B2C sales, cross-border transactions, and exports, where a full structured invoice isn’t required but transaction data still has to reach the tax authority. A transaction that is exempt from e-invoicing is not automatically exempt from e-reporting, and this distinction is where a lot of otherwise well-prepared finance teams get tripped up during scoping.

The size-based phasing matters too, but not in the way most people assume. Large enterprises and ETIs (entreprises de taille intermédiaire) are the ones on the hook to start issuing compliant e-invoices as of September 1, 2026. Small and mid-sized businesses and micro-enterprises get until September 1, 2027 before they carry the same issuing obligation. What applies to everyone immediately, regardless of size, is the receiving requirement: any company transacting in France must be capable of accepting a structured electronic invoice today. A smaller French subsidiary that assumes it has another year of breathing room is only half right, and the part it got wrong is the part most likely to cause a stalled transaction with a supplier who has already moved to full compliance.

What Microsoft Actually Built Into Dynamics 365 Finance

The GA feature routes outbound and inbound invoices through the Electronic Reporting framework inside Globalization Studio, using pre-built configurations for the French electronic invoice format and its associated status reporting. Invoices are transmitted in a UBL-based structure aligned to the EN 16931 European standard, and the system enforces the mandatory lifecycle statuses that French regulation requires: an invoice has to move through states such as deposited, refused, and payment received, with status round-trips flowing back into Dynamics 365 rather than living only on the transmission platform. On the inbound side, vendor electronic invoices arrive through the same integration and land in Finance as structured documents rather than PDFs that someone has to key in manually.

The transmission itself runs through EDICOM, which functions as what the French system calls a plateforme agréée, or approved platform, the current designation for the state-registered platforms that handle invoice validation, formatting, and delivery to both trading partners and the tax authority’s central directory. Businesses don’t submit invoices directly to the government portal. The approved platform does that on their behalf, which is the architectural reason Microsoft built its out-of-box configuration around a specific provider rather than a generic connector.

The Part That Deserves More Scrutiny Than It’s Getting

Here is the catch that a lot of go-live plans are glossing over: Microsoft’s out-of-box configuration is built specifically around EDICOM, and the Globalization Studio artifacts, the electronic reporting formats, the response processing logic, name EDICOM directly rather than treating it as one interchangeable option among the more than 120 platforms France has approved. For an organization that wants to standardize on a different provider, whether for existing commercial terms, regional coverage, or an established relationship elsewhere in the business, implementation partners working with early adopters have described the effort to extend the configuration to a second platform as a genuine build project, involving new XML format work and direct API integration with that provider, not a parameter change in a setup form.

There’s also a cost dimension that’s easy to miss because it sits outside the base ERP license. Electronic Invoicing in Dynamics 365 Finance is a metered add-on service that requires separate enrollment even for organizations already licensed for Finance, Supply Chain Management, or Project Operations, and it’s billed on transaction volume rather than bundled into the platform subscription. One Microsoft partner’s published implementation analysis pegged the metering at roughly $300 per 1,000 transactions per tenant per month, with response and status submissions counted as separate billable events from the original invoice, on top of whatever commercial fee the approved platform itself charges. Those figures will vary by contract and shouldn’t be treated as a universal rate card, but the structural point holds regardless of the exact number: this is a usage-based cost line that finance leaders should be sizing against actual invoice volume before assuming the feature is a simple checkbox to enable.

What to Verify This Quarter

A finance professional reviewing an electronic invoicing compliance dashboard on a monitor in a modern office.

Given that enforcement is already active, the practical task for finance and IT leadership isn’t deciding whether to comply. It’s confirming that what’s configured actually matches what the business needs, before a blocked transaction or a failed status round-trip surfaces the gap for you. Start by confirming receiving capability is genuinely live in production, not just configured in a sandbox, since that obligation applies to every size of business as of the September deadline that has already passed. Next, walk through your actual transaction mix against the e-invoicing versus e-reporting boundary described above, because it’s common to find that project invoices or prepayment transactions were left out of the initial scope simply because they’re less frequent than standard sales orders. Confirm which legal entities in your Dynamics 365 environment are actually in scope based on size thresholds, and don’t assume a smaller subsidiary is safe until 2027 without checking whether it crosses the ETI threshold on a consolidated basis. Finally, if EDICOM isn’t already your organization’s platform of choice for other reasons, have an honest conversation now about whether standardizing on the out-of-box provider is the pragmatic choice for this deadline, with a migration to another platform evaluated later as a deliberate project rather than something attempted under deadline pressure.

France won’t be the last major economy to force this kind of structural change into how ERP systems handle invoicing. Similar mandates are already active or advancing in Poland, Germany, and elsewhere in the EU, and organizations that build a repeatable internal process for evaluating and validating these Globalization Studio configurations, rather than treating each country as a one-off fire drill, will spend less time scrambling the next time a deadline like this one arrives. Routeget Technologies has worked through several of these localization rollouts alongside finance teams who needed the configuration validated against their real transaction data rather than just the release notes, and that verification step is usually where the actual risk gets found.

#FranceEInvoicing #D365FinanceCompliance #ElectronicInvoicing #TaxCompliance #ERPGovernance #EUTaxReform