That timing matters because Brazil’s reform is not a single switch that can be handled by adding one tax code. The statutory framework established IBS, CBS, and the Selective Tax, known as IS. Official transition guidance identifies 2026 as a CBS/IBS test year, while the 2027–2028 phase includes the end of PIS/Cofins, zeroing of IPI rates for most products subject to a Manaus Free Trade Zone exception, and the introduction of IS. For Finance customers, this makes tax configuration, accounting treatment, document handling, payment processes, and local integrations part of the same operational problem.
Microsoft’s release plan lists public preview for September 2026 and planned general availability for October 2026. That is the supported schedule—not November 2026. More importantly, a planned general-availability month is not evidence that the functionality has already shipped, and Microsoft warns that projected scope and delivery dates can change.
What Microsoft has actually put on the plan
Microsoft’s published description is specific enough to show the broad areas under development, although it does not provide implementation-level detail for every item. For the January 2027 requirements, the planned feature list includes:
- Support for the IS tax type.
- Additional fiscal-note and event scenarios.
- Support for split payments.
- Configurable posting logic for reformed tax.
- Further CNPJ updates.
Taken together, these items point to a change that spans more than tax calculation. A new tax type affects the way transactions must be classified and processed. Fiscal-note and event scenarios indicate that document and transaction-event handling will also need attention. Configurable posting logic reaches into accounting, where an organization has to decide how taxes and related movements are represented in its financial records. Split payments add a payment-process dimension.
The release plan does not, however, describe the exact user interface, configuration choices, data model, supported integrations, reporting outputs, or limits of each capability. Customers should avoid filling those gaps with assumptions before preview documentation and product behavior can be evaluated.
One wording point is especially important. It would be inaccurate to describe the announced feature as providing generic “tax assessment capabilities” for reformed taxes. Microsoft’s stated functionality specifically includes split-payment support and configurable reformed-tax posting logic. Those are meaningful capabilities, but they are not the same thing as a verified claim that Finance will deliver a separate, comprehensive tax-assessment function.
Why the 2027 phase raises the stakes
Brazil’s reform timetable gives this planned release a concrete regulatory context. Complementary Law No. 214, dated January 16, 2025, established IBS, CBS, and IS. The government’s transition material distinguishes between the 2026 CBS/IBS test period and the subsequent 2027–2028 changes.
For a business running Dynamics 365 Finance, the practical implication is that 2026 should not be viewed merely as a waiting period until a 2027 deadline. It is a window to understand how existing product, vendor, customer, procurement, sales, accounting, and document processes will intersect with the new regime.
The end of PIS/Cofins during 2027–2028, the IPI-rate change for most products, and IS implementation can create overlapping configuration questions. A business may need to revisit which transactions are assigned to which tax logic, how those taxes are posted, and whether existing local processes still produce the expected fiscal documents and events. The dossier does not establish the precise configuration that any individual company should adopt. Those decisions depend on a company’s facts, its transactions, and professional tax advice.
That distinction is not bureaucratic caution. ERP tax work frequently fails when an organization treats a statutory change as an isolated technology upgrade. The implementation can look successful in a test environment while still producing unsuitable postings, missing document scenarios, or inconsistent behavior in connected systems once live transactions begin.
Split payments are operationally significant
Of the listed functions, split-payment support may be the most operationally consequential because it connects tax-reform readiness to payment handling rather than only invoice calculation or ledger setup. Microsoft has confirmed that support is planned, but the published description does not explain the workflow in enough detail to establish how payments will be divided, what exceptions are handled, or how external payment and banking integrations are affected.
That uncertainty should direct the questions that IT and finance teams ask during preview testing. Organizations should establish whether their own payment flows use scenarios covered by the delivered functionality, how payment statuses and reconciliation behave, and whether interfaces that receive or send payment data require updates. These are preparatory testing questions, not statements about the final product’s design.
The same principle applies to fiscal-note and event scenarios. The plan confirms that Microsoft expects additional scenarios to be necessary for the 2027 phase. It does not establish that every document pattern or every company-specific process will be handled out of the box. Companies with unusually complex transaction patterns should pay particular attention to scenario coverage rather than assuming that a feature title answers the question.
Posting logic turns tax reform into an accounting project
Configurable posting logic for reformed tax suggests that Microsoft recognizes a core implementation reality: taxes must not only be calculated or recorded in transaction records; they also need an accounting treatment that fits the organization’s controls and reporting processes.
This is where finance leaders, tax specialists, ERP administrators, and integration owners need to work together. Finance teams may need to determine how the new tax-related entries should appear in their accounts and reconciliation processes. Technical teams need to understand whether existing configurations, customizations, exports, downstream reporting, or interfaces assume the pre-reform tax structure. Tax specialists need to determine the policy that those configurations are supposed to embody.
It is reasonable to infer that this cross-functional effort will be required for many affected deployments, but the inference must not be mistaken for a Microsoft product promise. The published plan says the posting logic will be configurable; it does not say that Microsoft will select the right configuration for every business or automatically convert every existing design.
CNPJ updates should be treated similarly. Microsoft has listed further updates, which makes CNPJ-related data and process validation a sensible testing area. The release-plan entry does not explain precisely which validations, records, or scenarios will change. Customers should wait for the detailed release materials before deciding that no data remediation or integration review is needed.
Planned availability is not a deployment date
Microsoft currently lists September 2026 for public preview and October 2026 for general availability. Both dates are useful for planning, but neither should be treated as a fixed legal-compliance deadline or an internal production go-live commitment.
Public preview is an opportunity to assess the approach, identify configuration implications, and test representative business processes. It should not automatically be considered suitable for a production compliance rollout. General availability indicates the planned broad release stage, but it still does not answer whether an organization is operationally prepared to turn on or configure the feature immediately.
A prudent project plan separates at least three dates:
- The government’s effective-date requirements.
- Microsoft’s currently planned product-delivery date.
- The organization’s own validated production-readiness date.
Those dates may be close together, but they are not interchangeable. A firm that waits for the product to become generally available before beginning analysis could leave itself too little time for configuration, validation, training, process approval, and remediation of integrations or custom work.
Microsoft does not promise blanket Brazilian compliance
The most important caveat is explicit in Microsoft’s Brazilian localization guidance: Dynamics does not address all Brazilian laws, regulations, or commercial requirements. Microsoft advises customers and tax professionals to assess whether custom solutions are necessary.
That statement is a needed counterweight to enthusiastic interpretations of the roadmap. A feature named for meeting 2027 tax-reform requirements indicates product investment in a major regulatory transition. It does not guarantee universal compliance for every company operating in Brazil.
There are several reasons this boundary matters. Different organizations can have different transaction patterns, document requirements, payment arrangements, accounting policies, and connected applications. They may also run extensions or custom integrations whose assumptions were built around older tax processes. Even when standard functionality covers a baseline scenario, company-specific logic can still require review.
The appropriate question is therefore not, “Will this update make us compliant?” A more useful question is: “Which of our required 2027 scenarios does the standard release cover, and what remains a configuration, process, integration, or custom-solution responsibility?”
A practical preparation checklist for Finance teams
For IT professionals supporting Finance on Windows-based business estates, this is not a Windows endpoint update. It is ERP localization work with consequences for finance operations and business controls. The practical response should begin before the planned October general-availability window.
First, inventory the company’s Brazilian tax-dependent processes. Include sales, procurement, billing, payments, refunds or adjustments where relevant, fiscal documents, event handling, and financial posting flows. The aim is to identify real transaction scenarios that can later become test cases.
Second, map each scenario to the announced areas: IS, fiscal notes and events, split payments, reformed-tax posting, and CNPJ updates. Where no direct mapping is apparent, record the gap rather than assuming it will be covered by a broadly named release feature.
Third, review interfaces and extensions. Any custom code, middleware, reporting export, payment connection, or downstream accounting process that depends on tax fields or posting outcomes deserves a targeted impact assessment. A localization update can be technically successful inside Finance while still disrupting an external process built on prior assumptions.
Fourth, plan preview evaluation around representative transactions, not only simple demonstrations. Test cases should be selected with finance and tax stakeholders, and their expected accounting and operational outcomes should be agreed before testing begins. This will make it easier to distinguish a product limitation, a configuration issue, and an internally unresolved policy decision.
Finally, retain a formal decision path for items outside Microsoft’s standard scope. Microsoft’s own guidance makes clear that customization may be needed. Identifying that possibility early is safer than discovering it after a regulatory date has arrived.
The bottom line
Microsoft’s planned Dynamics 365 Finance work is a material signal that the company is aligning Brazilian localization with the 2027 reform phase. Support for IS, new fiscal-note and event scenarios, split payments, configurable reformed-tax posting logic, and CNPJ updates directly addresses areas that can affect day-to-day finance operations.
But the October 2026 date remains a plan subject to change, not evidence of a shipped feature or a company-ready deployment. The product scope should also not be inflated into a universal compliance guarantee. The most defensible approach is to use the plan as a trigger for structured preparation: assess business scenarios, test the released capabilities when available, validate accounting and document outcomes, review integrations, and involve tax professionals in decisions that software alone cannot make.