web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / The Dynamics Troubleshooter / Planning the VAT Matrix for...

Planning the VAT Matrix for Dynamics 365 Finance

Views (1)
Paolo Cecchelli Profile Picture Paolo Cecchelli 573
When starting a new implementation of Dynamics 365 Finance, one of the first critical tasks is planning how taxes will be calculated and identifying the necessary system setup. This process can range from very simple to highly complex, depending on localizations and the specific nature of the business.
With the advent of the Tax Calculation engine and its advanced capabilities (Microsoft Docs Overview), understanding and planning your tax setup has become an even more vital step in the design phase.
In this post, I want to propose an offline framework—a way to intercept and categorize sales tax requirements—to help you make better design decisions before even touching the system.

Paving the Way
During the initial meetings with a customer’s accounting team, I usually present an Excel template for them to fill out. The template is straightforward and divided into two main sections: Sales and Purchase.
Within these sections, we create divisions based on the "actors" involved in the process that are relevant for VAT purposes (Column B). These might include domestic customers/vendors, public administrations, foreign entities, or distinctions between goods and services. Essentially, we list every variable that triggers a different sales tax calculation.
In Column C, we add a description of the actual business processes. I always recommend keeping this simple and "accountant-friendly." Descriptions should look like: "Domestic sales of goods," "Domestic sales of services," "Free goods domestic," or "Purchase from foreign vendors."

As you might have guessed, Column B becomes the foundation for creating the Sales Tax Groups that will be attached to Customer and Vendor master records.
Once this draft is ready, I ask the customer to fill in Column D onwards. This is where they map the Sales Tax Codes they are currently using (or the new ones they wish to implement), including details like descriptions, percentages, and non-deductibility rules.

Note: At this stage, I haven't mentioned a single technical feature of Dynamics 365. The goal here is to let the customer elaborate on their scenarios and think deeply about their tax reporting needs first.


Building the Matrix
After completing the first step, we have two clear outputs:
  1. A comprehensive list of Sales Tax Codes for every business scenario.
  2. A deeper understanding of the company's operational processes.
Leveraging this, we have everything we need to build the Sales Tax Matrix—the connection between Sales Tax Groups and Item Sales Tax Groups that results in the correct Sales Tax Code. I typically organize these into two distinct matrices: one for Sales and one for Purchases.

The part of the Sales tax matrix related to Sales
​​​​​​​

The part of the Sales tax matrix related to Purchase

If the term "Sales Tax Matrix" sounds intimidating to users, a visual representation in Excel is exactly what they need to digest the concept. In the example below, I’ve placed Sales Tax Groups in the columns and Item Sales Tax Groups in the rows.
The first two Item Sales Tax Groups are usually the defaults for "Product" and "Service" types, which will populate automatically on line creation. The others are specific groups used to override the defaults when necessary.
  

Common Mistakes to Avoid When Building the Matrix
  1. Neglecting Edge Cases: Don't focus only on standard sales and purchases. Consider scenarios like free goods, intra-company transfers, and sales to exempt entities. Skipping these can lead to manual adjustments later.
  2. Overcomplicating the Structure: While it's important to cover all bases, aim for simplicity. Too many groups and codes can make the system difficult to maintain. Consolidate where possible while ensuring all reporting needs are met.
  3. Ignoring Reporting Requirements: Your matrix should not only calculate the correct tax amount but also generate the necessary reporting data. Make sure your design supports local tax authority requirements and internal reporting needs.

Conclusions
Of course, the number of combinations and the overall complexity will vary based on localization, industry, and other factors. However, using this "on paper" schema helps you build a solid foundation before you ever start configuring the system.
The Sales tax matrix built in this way is not only useful for setting up the system, but is useful also as a quick reference for the business. In case new codes are created and implemented, I always recommend to update the Sales tax matrix, to always have a clear situation of the setup and to avoid a double determination of Sales tax codes.

That’s all folks, see you next time!

Comments