Mastering Tax in Dynamics 365 Finance & Operations

A Guide to Tax Types, Setup, Tax Calculation Service, Reporting, and Period-End Settlement

Tax management is one of the most critical areas of a Dynamics 365 Finance implementation. Whether an organization operates in one country or across multiple jurisdictions, accurate tax determination affects regulatory compliance, financial reporting, cash flow, audit readiness, vendor payments, and customer invoicing.

Dynamics 365 Finance provides a flexible tax framework that supports indirect taxes such as Sales Tax, Value Added Tax (VAT), Goods and Services Tax (GST), unit-based fees, and Withholding Tax. The system calculates and records these taxes during sales and purchase transactions and supports their periodic reporting and settlement.

Modern implementations can also use Tax Calculation, a configurable and scalable tax engine designed to automate tax determination and calculation across legal entities, tax registrations, and jurisdictions.

This guide covers:

The D365 Finance tax architecture
Core tax setup components
Sales Tax Groups and Item Sales Tax Groups
Major tax types and their high-level setup
Reverse Charge VAT
Use Tax for US scenarios
Tax Calculation Service
Tax-supporting applications and services
Tax inquiries and reports
Month-end and quarter-end tax settlement
Reconciliation, testing, and implementation best practices

Understanding the D365 Finance Tax Framework

The D365 Finance tax framework helps organizations determine:

Which taxes apply to a transaction
How the taxable amount is calculated
Which rate should be used
How the tax is posted to the General Ledger
How tax transactions are reported
When tax balances are settled
How amounts are paid to or recovered from the tax authority

For every tax that an organization must account for, a Sales Tax Code is normally defined. The code stores information such as tax rates and calculation rules. It is associated with a Sales Tax Settlement Period and a Ledger Posting Group. The settlement period determines when the tax is reported and paid, while the Ledger Posting Group determines the main accounts used for tax postings.

Core Tax Setup Components

Although individual tax requirements vary by country, most configurations depend on the same foundational components.

1. Main Accounts

Before configuring tax, the organization must define the General Ledger accounts that will be used to record:

Tax payable
Tax receivable
Recoverable input tax
Collected output tax
Use Tax liability
Tax expense
Settlement balances
Tax authority payments

The required accounts depend on the applicable tax model, localization, and accounting policies.

2. Ledger Posting Groups

Ledger Posting Groups connect Sales Tax Codes to the General Ledger.

They control where tax amounts are posted, including relevant payable, receivable, expense, and settlement accounts. Microsoft identifies the Ledger Posting Group as a required element of the standard sales tax setup.

A clear posting design is essential because tax reports and tax subledger transactions must later be reconciled with the General Ledger.

3. Sales Tax Authorities

A Sales Tax Authority represents the organization to which taxes are reported and paid.

Examples include:

National tax authorities
State tax authorities
Regional tax authorities
Local tax authorities

A tax authority can also be associated with a vendor account so that the organization can process the payment of the settled tax liability.

4. Sales Tax Settlement Periods

Settlement Periods determine how frequently tax must be reported and settled.

Common frequencies include:

Monthly
Quarterly
Annual
Localization-specific periods

A Sales Tax Code is linked to a Settlement Period, and the Settlement Period is linked to a Sales Tax Authority. This relationship allows D365 Finance to organize tax transactions according to reporting periods and authorities.

5. Sales Tax Codes

Sales Tax Codes contain the rules required to calculate and report tax.

Depending on the scenario, a code can define or reference:

Tax percentage
Effective dates
Calculation method
Tax direction
Settlement Period
Ledger Posting Group
Reporting Codes
Exemption characteristics
Applicable limits or intervals

Examples might include:

Tax Code	Description	Illustrative Rate
VAT-STD	Standard VAT	20%
VAT-RED	Reduced VAT	5%
VAT-ZERO	Zero-rated VAT	0%
GST-STD	Standard GST	10%
ST-STATE	State Sales Tax	8%
USE-TAX	Use Tax	8%

The codes and percentages shown above are illustrative. Actual rates and configuration must follow the relevant jurisdiction and effective dates.

6. Sales Tax Reporting Codes

Reporting Codes classify tax amounts for tax declarations and supporting reports.

They can be assigned to the different amount types calculated by a Sales Tax Code. The Sales Tax Payment by Code report can then present totals by Sales Tax Reporting Code for the selected Settlement Period and interval.

A well-designed Reporting Code structure can help distinguish:

Input tax
Output tax
Recoverable tax
Non-recoverable tax
Zero-rated transactions
Exempt transactions
Reverse Charge VAT
Use Tax
Adjustments

Sales Tax Groups and Item Sales Tax Groups

One of the most important concepts in D365 Finance tax configuration is the intersection between the Sales Tax Group and the Item Sales Tax Group.

Sales Tax Groups

Sales Tax Groups represent the tax profile of the party involved in a transaction.

They are commonly assigned to:

Customers
Vendors
Ledger accounts for transactions without a customer or vendor

A Sales Tax Group contains one or more Sales Tax Codes. Microsoft describes Sales Tax Groups as groups of codes that are attached to customers and vendors, or to ledger accounts for transactions that are not posted to a specific customer or vendor.

Examples include:

Domestic customer
Domestic vendor
Export customer
Government customer
EU vendor
Non-resident vendor

Item Sales Tax Groups

Item Sales Tax Groups represent the tax characteristics of the product, service, or procurement category.

They can be assigned to resources such as products and may contain one or more Sales Tax Codes.

Examples include:

Standard goods
Reduced-rate goods
Exempt services
Zero-rated exports
Professional services
Non-recoverable purchases

How Tax Determination Works

For a transaction to calculate tax, both a Sales Tax Group and an Item Sales Tax Group must be available.

D365 Finance compares the codes in the two groups. Only a code that exists in both groups applies to the transaction.

Example

Customer Sales Tax Group

VAT20
VAT5

Item Sales Tax Group

VAT20

Result

VAT20 applies
VAT5 does not apply

This approach separates the tax characteristics of the business party from those of the product or service.

Major Tax Types and Their Setup

1. Sales Tax

Typical Usage

Sales Tax is commonly associated with US state and local taxation. Depending on the jurisdiction, tax may be determined using factors such as the transaction location, delivery location, customer status, product taxability, and applicable state or local rules.

High-Level Setup

Create the required main accounts.
Create a Ledger Posting Group.
Create the Sales Tax Authority.
Define the Settlement Period.
Create state, county, city, or other jurisdictional Sales Tax Codes as required.
Enter the rates and effective dates.
Create Sales Tax Groups.
Create Item Sales Tax Groups.
Assign the groups to customers, vendors, products, categories, or transaction defaults.
Configure Reporting Codes.
Test Sales Orders, Purchase Orders, Free Text Invoices, and Vendor Invoices.
Validate posting, reporting, and settlement results.

Example

Net invoice amount: $1,000
Sales Tax rate: 8%
Tax amount: $80
Gross invoice amount: $1,080

This example is illustrative and does not represent the layered state, county, city, or special-district structure that may apply in an actual US implementation.

2. Value Added Tax

Typical Usage

VAT is an indirect tax commonly applied through the supply chain. Organizations generally record Output VAT on sales and Input VAT on purchases, subject to the applicable recovery rules.

High-Level Setup

Create VAT payable and VAT receivable accounts.
Configure the Ledger Posting Group.
Create the relevant Tax Authority.
Define monthly, quarterly, or other Settlement Periods.
Create standard, reduced, zero-rated, or other relevant VAT Codes.
Maintain tax rates and effective dates.
Create customer and vendor Sales Tax Groups.
Create product and service Item Sales Tax Groups.
Configure VAT Reporting Codes.
Assign the defaults to master data.
Test sales, purchases, returns, credit notes, and corrections.
Validate the VAT statement and settlement process.

Typical VAT Categories

Standard rate
Reduced rate
Zero-rated
Exempt
Reverse charge
Partially recoverable
Non-recoverable

Example

Net invoice amount: €10,000
VAT rate: 20%
VAT amount: €2,000
Gross invoice amount: €12,000

Actual VAT rates and recovery rules depend on the country and the nature of the transaction.

3. Goods and Services Tax

Typical Usage

GST is used in several jurisdictions and shares many accounting concepts with VAT. However, the exact structure, terminology, reporting format, and localization requirements vary by country.

High-Level Setup

Create the GST-related main accounts.
Configure the Ledger Posting Group.
Set up the relevant Tax Authority.
Create the GST Settlement Period.
Define GST Codes and applicable rates.
Create Sales Tax Groups.
Create Item Sales Tax Groups.
Configure Reporting Codes.
Assign GST defaults to customers, vendors, products, and services.
Test sales and purchase transactions.
Validate the jurisdiction-specific GST return.
Reconcile GST transactions with the General Ledger.

Example

Net invoice amount: $1,000
GST rate: 10%
GST amount: $100
Gross invoice amount: $1,100

The example is illustrative. Local GST rules and reporting requirements must be validated separately.

4. Withholding Tax

Typical Usage

Withholding Tax is used when the payer retains part of a payment and reports or remits that amount to the relevant authority.

It may apply to transactions involving:

Consultants
Contractors
Professional services
Rents
Royalties
Interest
Cross-border services

The actual scope depends on local legislation.

High-Level Setup

Confirm that the relevant Withholding Tax functionality or localization is available.
Create the required liability and settlement accounts.
Create Withholding Tax Codes.
Enter rates, limits, and effective-date requirements.
Create Withholding Tax Groups.
Assign the groups to applicable vendors or customers.
Configure posting and settlement rules.
Test invoices, payments, partial payments, prepayments, and credit notes.
Validate certificates and statutory reports where applicable.
Reconcile withholding balances with the General Ledger.

Example

Vendor invoice: €10,000
Withholding Tax rate: 10%
Vendor payment: €9,000
Withholding Tax liability: €1,000

This example is simplified. The calculation point may be the invoice or payment depending on localization and legal requirements.

5. Zero-Rated Tax

Typical Usage

A zero-rated transaction is included within the tax system but calculated at a 0% rate.

Possible examples include:

Qualifying exports
Specific food products
Certain international transactions
Other legally defined supplies

Zero-rated and exempt transactions should not automatically be treated as the same reporting category.

High-Level Setup

Create a dedicated 0% Sales Tax Code.
Associate the code with the correct Settlement Period and Posting Group.
assign the relevant Reporting Code.
Add the code to appropriate Sales Tax Groups.
Add the same code to applicable Item Sales Tax Groups.
Assign the groups to qualifying customers, vendors, products, or services.
Test the transaction.
Confirm that the transaction appears in the correct reporting field despite having no tax amount.

6. Tax-Exempt Transactions

Typical Usage

Tax exemptions can apply to a customer, vendor, product, service, or transaction.

Possible examples include:

Certain healthcare services
Certain educational services
Certain financial services
Qualifying public-sector organizations
Customers holding exemption documentation

High-Level Setup

Identify whether the exemption belongs to the party, item, or transaction.
Create the required exemption code or tax setup.
Configure Sales Tax Groups and Item Sales Tax Groups.
Assign applicable Reporting Codes.
Maintain exemption documentation or certificate information where required.
Assign the setup to the relevant master data.
Test invoices and credit notes.
Validate that exempt amounts appear correctly in statutory reporting.

Additional Tax Scenarios

7. Reverse Charge VAT

Typical Usage

Reverse Charge VAT shifts responsibility for accounting and reporting VAT from the seller to the recipient of the goods or services.

Under the generic Reverse Charge mechanism documented for VAT and GST schemes, the recipient reports both Output VAT in the role of seller and Input VAT in the role of purchaser on the VAT statement. The precise scope can depend on goods, services, thresholds, and the status of the supplier and buyer. [learn.microsoft.com]

Reverse Charge VAT can be relevant for:

Cross-border services
Intra-community scenarios
Construction or other regulated sectors
Domestic Reverse Charge arrangements
Goods or services specifically identified by local legislation

Example

Supplier invoice: €10,000
VAT charged by supplier: €0
Output VAT self-assessed by customer: €2,000
Input VAT recognized by customer: €2,000
Net VAT effect: €0, if fully recoverable

The transaction remains reportable even when the net accounting effect is zero.

High-Level Setup

Microsoft’s generic setup includes separate Sales Tax Codes for Reverse Charge sales and purchases, Sales Tax Groups and Item Sales Tax Groups, Reverse Charge Item Groups, and Reverse Charge Rules. Positive and negative purchase tax codes can be used to represent the relevant Reverse Charge VAT entries. [learn.microsoft.com]

A practical high-level sequence is:

Enable the relevant Reverse Charge feature where required.
Create separate Reverse Charge Sales Tax Codes.
Create the required positive and negative purchase tax codes.
Allow negative tax percentages where required by the setup.
Add the codes to the appropriate Sales Tax Groups.
Add the codes to the appropriate Item Sales Tax Groups.
Create Reverse Charge Item Groups.
Define Reverse Charge Rules and applicability conditions.
Configure Posting Groups and Reporting Codes.
Test sales, purchase, invoice, and credit-note scenarios.
Validate the VAT statement and settlement results.

Typical Reports

Sales Tax Transactions
VAT Statement
Sales Tax Payment by Code
Localization-specific VAT declarations
Reverse Charge supporting schedules

8. Use Tax for US Scenarios

Typical Usage

Use Tax is a form of Sales Tax that can apply when a taxable item is purchased from an out-of-state vendor or online retailer that does not collect the applicable Sales Tax. The buyer is responsible for paying Use Tax to the state where the item is used, stored, or consumed.

Common scenarios include:

Interstate purchases
Purchases from non-registered vendors
Online purchases
Under-collected vendor Sales Tax
Self-assessed tax obligations

Example

Vendor invoice: $1,000
Tax charged by vendor: $0
Calculated Use Tax rate: 8%
Use Tax liability: $80

The purchasing organization records and settles the liability even though the vendor did not collect the tax.

High-Level Setup

For the current Use Tax Assessment feature documented by Microsoft, US legal entities can enable the Accrue use tax option in Tax Calculation Parameters. This activates supporting fields in Accounts Payable invoicing, including the vendor-charged Sales Tax amount and the Accrue Sales Tax Type behavior.

A high-level implementation sequence is:

Configure the applicable US tax solution and Tax Calculation Parameters.
Enable Accrue use tax.
Configure the required Use Tax accounts and Posting Groups.
Define the relevant Sales Tax or Use Tax Codes.
Configure Sales Tax Groups and Item Sales Tax Groups.
Set the default Accrue Sales Tax Type on applicable vendors.
Capture vendor-charged Sales Tax on Vendor Invoices.
Compare the vendor-charged amount with the calculated liability.
Generate the relevant Use Tax transactions.
Validate posting, reporting, settlement, and reconciliation.

The available behavior includes options such as default processing and Use Tax accrual. Advanced handling can depend on the supported tax solution provider and related tolerance settings.

Typical Reports and Controls

Sales Tax Transactions
Sales Tax Payment by Code
Use Tax liability analysis
Tax settlement reports
Vendor-charged versus assessed tax comparison
General Ledger reconciliation

Proper Use Tax configuration is especially important because tax might remain due even when it is missing from the vendor invoice.

Tax Calculation Service

One of the biggest tax innovations in modern D365 Finance is Tax Calculation.

Microsoft describes Tax Calculation as a highly scalable and configurable tax engine that automates and simplifies tax determination and calculation. It supports configurable data models, Tax Codes, applicability matrices, calculation formulas, multiple registration numbers, and shared tax solutions across legal entities.

Why Tax Calculation Service Matters

Traditional tax setups can become difficult to manage when organizations:

Operate in multiple countries
Have multiple tax registrations
Need frequent tax updates
Handle complex cross-border scenarios
Maintain similar rules across several legal entities
Need additional transaction attributes for tax determination

Tax Calculation addresses these challenges through enhanced determination, configurable applicability rules, centralized maintenance, and reusable tax configurations.

Automated Tax Determination

Tax Calculation can determine or refine:

Sales Tax Groups
Item Sales Tax Groups
Tax Codes
Customer and vendor Tax Registration Numbers
List Codes
Jurisdiction-related tax parameters

The runtime process starts with the default Sales Tax Group and Item Sales Tax Group from the transaction. Tax Calculation evaluates the transaction against the configured applicability matrices and can override those defaults. It then determines the final Tax Codes through the intersection between the Tax Group and Item Tax Group and returns the calculation result to Finance.

Centralized Tax Rules

Organizations can share a tax determination and calculation solution across multiple legal entities.

Benefits include:

Reduced maintenance
More consistent calculations
Reusable tax logic
Improved governance
Lower risk of inconsistent configuration
Reduced duplication across companies

The ability to share the solution across legal entities is a documented Tax Calculation capability.

Configurable Tax Calculation Formulas

Instead of relying only on hardcoded logic, Tax Calculation supports configurable elements such as:

Taxable data models
Tax Codes
Tax applicability matrices
Conditions
Calculation formulas
Jurisdiction-level parameters

This enables tax logic to be maintained through the tax configuration model, although extensions and specialist involvement may still be required for advanced scenarios.

Multi-Registration Support

Large organizations can have multiple tax registrations within the same legal entity.

Examples might include:

VAT registrations in several countries
GST registrations
Regional registrations
Registration requirements related to transaction location

Tax Calculation supports multiple Tax Registration Numbers in one legal entity and can determine the appropriate registration for taxable transactions. It also supports customer and vendor Tax Registration Number determination.

Tax Calculation Service Setup Process

Microsoft’s documented high-level setup flow includes creating a Tax Calculation feature in Globalization Studio, selecting the Tax Configuration version, creating Tax Codes, Tax Groups, and Item Tax Groups, optionally creating applicability rules, completing the feature, and selecting it in Tax Calculation Parameters.

A summarized implementation sequence is:

Open Globalization Studio.
Select the Tax Calculation tile.
Create a Tax Calculation feature.
Select the correct Tax Configuration version.
Create the required Tax Codes.
Create Tax Groups.
Create Item Tax Groups.
Optionally configure Tax Group Applicability.
Optionally configure Item Tax Group Applicability.
Maintain rates, rules, and formulas.
Complete the Tax Calculation feature.
Select the required feature version in Tax Calculation Parameters.
Test representative transactions for every applicable legal entity.
Validate tax posting, reporting, registration determination, and settlement.

The selected Tax Configuration version must be compatible with the installed Dynamics 365 Finance or Supply Chain Management version.

Tax-Supporting Applications and Services

1. Tax Calculation

Tax Calculation is the primary modern tax determination and calculation capability covered in this guide.

Its capabilities include:

Centralized configuration
Enhanced Tax Group determination
Enhanced Item Tax Group determination
Tax Code determination
Configurable applicability rules
Configurable formulas
Multiple Tax Registration Numbers
Shared configurations across legal entities
Transfer Order tax determination, posting, and settlement

2. Globalization Studio

Globalization Studio provides the workspace in which organizations access and maintain globalization-related configurations and services.

For Tax Calculation, it is used to:

Access Tax Calculation features
Select configuration versions
Maintain Tax Codes
Maintain Tax Groups and Item Tax Groups
Configure applicability matrices
Maintain tax rates and rules
Complete and manage feature versions

Microsoft’s current Tax Calculation setup documentation places the creation and maintenance of Tax Calculation features in the Globalization Studio workspace.

3. Electronic Reporting

Electronic Reporting supports configurable business-document and regulatory-reporting formats.

In the tax area, it can support outputs such as:

VAT returns
GST reports
Tax declarations
Tax data exports
Localization-specific regulatory formats

The exact available formats and processes depend on the applicable country or region, localization, and imported configuration.

4. Regulatory Configuration Services

Regulatory Configuration Services, commonly referred to as RCS in earlier Tax Calculation implementations and documentation, was used to manage globalization and tax configurations outside the application.

For a current implementation, the architecture and instructions should be checked against the applicable D365 Finance version because current Microsoft Tax Calculation guidance directs users to Globalization Studio in Finance.

RCS remains relevant when:

Reviewing earlier implementations
Understanding historical Tax Calculation architecture
Maintaining legacy project documentation
Migrating older configuration-management processes

This distinction keeps the blog useful for both established environments and current implementations.

5. External Tax Solution Providers and Tax Calculators

Complex US Sales Tax and Use Tax scenarios may involve an external tax solution provider.

Potential responsibilities include:

Returning applicable tax rates
Supporting jurisdiction determination
Calculating tax liability
Supporting Use Tax Assessment
Comparing vendor-charged tax with the calculated liability
Providing advanced handling for undercharges or overcharges

Microsoft’s Use Tax Assessment documentation references tax solution provider calculations and notes that some advanced assessment behavior depends on provider support.

The selection and design of an external calculator should consider:

Countries and jurisdictions supported
Sales and purchase transaction coverage
Use Tax support
Product taxability
Address validation
Exemption handling
Performance and availability
Error handling
Reconciliation
Audit trail
Return-preparation requirements

These considerations should be included in the solution design rather than treated only as a technical integration activity.

Tax Reports and Inquiries

Tax calculation is only one part of the tax lifecycle. Finance and tax teams must also review, reconcile, report, settle, and audit tax transactions.

Menu paths and report names can vary by localization, enabled features, and application version. The following represents the main reporting concepts that should be included in the solution design.

Sales Tax Transactions

The Sales Tax Transactions inquiry provides detailed tax information generated from posted transactions.

It can be used to review:

Tax Codes
Tax base amounts
Tax amounts
Transaction dates
Voucher references
Customers and vendors
Settlement status
Tax direction
Source transactions

Typical users include:

Tax specialists
Accountants
Controllers
Internal auditors
External auditors

Sales Tax Payment by Code

This report helps summarize tax amounts according to the Tax Codes and Reporting Codes associated with a Settlement Period.

Microsoft states that the Sales Tax Payment by Code report presents totals per Sales Tax Reporting Code for the selected Settlement Period and interval.

It is useful for:

Reviewing Output Tax
Reviewing Input Tax
Checking zero-rated bases
Reviewing exempt amounts
Validating Reverse Charge VAT
Supporting tax return preparation
Comparing balances before settlement

Sales Tax Payments and Settlement Results

The Sales Tax payment and settlement outputs help users analyze the net amount payable to or recoverable from the Tax Authority.

They also support the review of:

Settlement periods
Settlement dates
Posted vouchers
Prior settlements
Adjustments
Tax Authority balances

VAT Statement and GST Returns

VAT and GST reporting normally needs to distinguish between:

Output Tax
Input Tax
Recoverable Tax
Non-recoverable Tax
Reverse Charge Tax
Zero-rated transactions
Exempt transactions
Adjustments
Net payable or recoverable amount

Country-specific reports can be delivered through localizations and Electronic Reporting configurations.

Withholding Tax Reports

Depending on the applicable localization, Withholding Tax reporting can include:

Withheld amount by vendor
Withholding Tax Code
Invoice or payment reference
Taxable base
Settlement balance
Certificates
Statutory declarations

The tax team should validate whether reporting is required at invoice time, payment time, or both.

Use Tax Reporting

Use Tax controls should include a comparison between:

Tax charged by the vendor
Tax calculated by the applicable tax solution
Additional Use Tax accrued
Final Use Tax liability
Tax settlement amounts

The Use Tax Assessment functionality includes fields for capturing vendor-charged Sales Tax and controlling the assessment behavior on vendor invoices.

Electronic Reporting Outputs

Electronic Reporting can be used to produce or support country-specific tax outputs such as:

VAT returns
GST returns
Regulatory tax exports
Audit files
Supporting tax schedules
Other localization-specific electronic formats

Electronic Reporting configurations should be version-controlled, tested, and aligned with the relevant application and localization versions.

Intrastat and Related Compliance Reports

Intrastat is not a tax type. It concerns statistical reporting for applicable movements of goods rather than the calculation of VAT itself.

For that reason, it fits better under related regulatory and trade compliance reporting than under the list of tax types. As requested, it is not treated as an additional major tax type in this guide.

Tax Settlement and Period-End Processing

Calculating tax is only one part of the process. Organizations must periodically summarize, report, settle, and pay or recover tax balances.

D365 Finance links Sales Tax Codes to Settlement Periods and Settlement Periods to Sales Tax Authorities. This structure supports periodic tax reporting and payment.

Typical Settlement Frequencies

Depending on local requirements, settlement may be performed:

Monthly
Quarterly
Annually
At another legally defined interval

Examples include:

Monthly VAT settlement
Quarterly VAT settlement
Monthly GST settlement
Quarterly GST settlement
US Sales Tax settlement
Use Tax settlement
Withholding Tax settlement

The filing and settlement frequency must be confirmed for every Tax Authority and registration.

High-Level Period-End Process

At month-end or quarter-end, the tax team commonly performs the following activities:

Confirm that all relevant source transactions are posted.
Review Sales Tax Transactions.
Check missing or unexpected Tax Codes.
Validate tax bases and tax amounts.
Review exemption and zero-rate transactions.
Review Reverse Charge VAT.
Review Use Tax assessments.
Review Withholding Tax transactions.
Reconcile tax subledger balances with the General Ledger.
Review the Sales Tax Payment by Code report.
Produce draft statutory reports.
Investigate and post authorized corrections.
Run the Sales Tax settlement process.
Review the generated settlement voucher.
Produce the final tax return or electronic file.
Submit the declaration.
Process payment to or recovery from the Tax Authority.
Retain the supporting reports and reconciliation evidence.

The exact sequence should be adapted to the country, localization, internal control model, and filing process.

What the Settlement Process Achieves

The settlement process helps:

Identify tax transactions within the relevant Settlement Period
Calculate the amount payable or recoverable
Create accounting entries for settlement
Move tax balances to the designated settlement accounts
Provide a history of settled tax periods
Support Tax Authority payment processing
Establish an auditable link between transactions, reports, and the settlement voucher

Tax Reconciliation and Controls

A reliable tax process requires regular reconciliation between the tax subledger, source transactions, General Ledger, declarations, and Tax Authority balances.

Tax to General Ledger Reconciliation

Compare:

Sales Tax Transactions
Tax Code balances
Input and Output Tax accounts
Settlement accounts
Tax Authority vendor balances
General Ledger trial balance
Posted settlement vouchers

Differences can indicate:

Incorrect Posting Groups
Manual General Ledger postings
Missing tax setup
Incorrect tax direction
Timing differences
Unsettled adjustments
Reporting Code problems

Master Data Review

Tax results depend heavily on master data.

Regularly review:

Customer Sales Tax Groups
Vendor Sales Tax Groups
Product Item Sales Tax Groups
Procurement Category defaults
Delivery and invoice addresses
Tax Registration Numbers
Exemption details
Effective dates
Tax feature versions

Testing the Tax Solution

Tax testing should represent real business scenarios, not only simple invoices.

Domestic Transactions

Test:

Domestic sales
Domestic purchases
Standard rates
Reduced rates
Fully recoverable purchases
Partially recoverable purchases
Exempt customers
Exempt products
Returns and credit notes

Cross-Border Transactions

Test:

Imports
Exports
Cross-border services
Intra-community transactions
Reverse Charge VAT
Foreign registrations
Multiple delivery and invoice addresses

US Scenarios

Test:

Vendor-charged Sales Tax
Vendor undercharging
Vendor not charging tax
Use Tax accrual
Exempt customers
Exempt products
Multiple jurisdictions
External calculator failures and corrections

Operational Scenarios

Test:

Purchase Orders
Sales Orders
Vendor Invoices
Free Text Invoices
General Journals
Project transactions
Transfer Orders where supported
Prepayments
Credit notes
Partial invoicing
Intercompany transactions
Foreign currencies

Tax Calculation supports determination, calculation, posting, and settlement for Transfer Orders as part of its documented capabilities.

Best Practices

Keep Tax Configuration Simple

Avoid creating unnecessary Tax Codes or duplicate structures.

Instead:

Reuse Tax Groups where appropriate
Standardize naming conventions
Separate rates from business scenarios logically
Centralize maintenance
Use effective dates correctly
Document ownership

Design Reporting Early

Tax reporting should not be treated as a final project activity.

Before configuration is finalized, define:

Required declarations
Reporting frequencies
Reporting Codes
Reconciliation reports
Electronic formats
Supporting schedules
Audit evidence
Correction procedures
Responsible teams

Use Tax Calculation for Global Deployments

Organizations operating across multiple jurisdictions should evaluate Tax Calculation early in the architecture phase.

Its documented benefits include:

Enhanced tax determination
Configurable formulas
Multiple registrations
Reusable configurations
Shared tax solutions across legal entities

Test Cross-Border Transactions

Always validate:

Domestic sales
Domestic purchases
Imports
Exports
Reverse Charge scenarios
Foreign Tax Registrations
Intercompany transactions
Multiple addresses
Currency conversion
Credit notes and corrections

Document Tax Logic

A tax matrix should document:

Tax type
Country or jurisdiction
Legal entity
Customer or vendor category
Product or service category
Tax Group
Item Tax Group
Tax Code
Rate
Registration
Reporting Code
Posting accounts
Settlement Period
Exemption condition
Effective dates
Expected report field
Test case
Business owner

Clear documentation reduces dependency on individual specialists and supports future changes, audits, testing, and upgrades.

Establish a Formal Closing Checklist

The month-end or quarter-end checklist should cover:

Completeness of transaction posting
Exception review
Reverse Charge validation
Use Tax validation
Withholding Tax validation
Tax to General Ledger reconciliation
Draft return review
Settlement execution
Settlement voucher validation
Final submission
Tax Authority payment
Evidence retention

Final Thoughts

Tax in Dynamics 365 Finance is much more than applying a percentage to an invoice. The platform provides a comprehensive framework for managing Sales Tax, VAT, GST, Withholding Tax, zero-rated transactions, exemptions, Reverse Charge VAT, and Use Tax.

The standard framework depends on well-designed Tax Codes, Sales Tax Groups, Item Sales Tax Groups, Reporting Codes, Posting Groups, Settlement Periods, and Tax Authorities. Tax Calculation extends this architecture with enhanced determination, configurable applicability matrices, formulas, shared configurations, and support for multiple Tax Registration Numbers.

A successful implementation should manage the entire tax lifecycle:

Configure → Determine → Calculate → Post → Report → Reconcile → Settle → Pay → Audit