Multi-Tax Expense Integration for Dynamics 365 F&O

Overview

This project extends an existing integration between Microsoft Dynamics 365 Finance & Operations and a third-party expense management platform used to automate the accounts payable invoice intake process.

Within this workflow, vendors submit invoices to the external platform, where an AI-powered document processing engine extracts relevant information such as supplier details, invoice totals, tax information, currencies, and supporting metadata. After business validation and approval, the processed data is synchronized with Dynamics 365 Finance & Operations, where accounting journals are generated automatically, reducing manual data entry and streamlining invoice processing.

The original integration consumed version 1 of the provider’s API and was designed around a single-tax model. As the external platform evolved to support multiple tax rates and additional tax concepts within the same invoice, the existing implementation became insufficient to represent accounting transactions accurately.

The objective of this project was to upgrade the integration to API v2 while introducing full multi-tax support, preserving compatibility with the existing processing flow and enabling Dynamics 365 Finance & Operations to generate accurate accounting entries for increasingly complex financial documents.

 

Business Context

Supplier invoices frequently contain multiple VAT rates and additional tax components that must be represented independently within ERP accounting entries. While the previous integration successfully automated invoice posting, it assumed that every document contained a single tax rate, limiting its applicability to more complex fiscal scenarios.

The enhanced integration was required to interpret richer tax structures provided by the external platform and transform them into accounting transactions that correctly represented every taxable base and additional tax component.

Rather than replacing an existing production integration, the challenge consisted of evolving it while preserving established business processes and minimizing operational risk.

 

Architecture Decisions

The integration relies on the batch processing framework of Dynamics 365 Finance & Operations, where scheduled batch jobs execute automatically once per day to retrieve newly approved expenses from the external platform and generate the corresponding accounting journals inside the ERP.

Since the integration was already operating in production, backward compatibility became one of the primary architectural objectives.

Although API v2 introduced significant structural changes compared to its predecessor, replacing the entire accounting pipeline would have increased implementation risk and duplicated already validated business logic. Instead, an intermediate normalization layer was introduced to transform the new API payload into an internal representation compatible with the existing integration whenever possible.

To support both processing models, the solution adopts the Strategy Pattern, selecting the appropriate execution path at runtime. During journal generation, the integration analyzes the tax structure of each expense and delegates processing accordingly: legacy single-tax documents continue through the existing implementation, while multi-tax documents are processed by a dedicated strategy capable of generating multiple accounting entries and handling additional tax concepts independently.

This approach allows both implementations to coexist while maintaining clear separation of responsibilities, improving maintainability and reducing the impact of future API changes.

As part of this architectural evolution, a new parameterization module was also implemented within Dynamics 365, allowing administrators to configure mappings between external tax concepts and ERP ledger accounts without requiring source code modifications.

 

 

Technical Implementation

The implementation required modifications across both stages of the integration pipeline.

The first stage consists of periodically retrieving approved expenses from the external platform through its REST API. As part of this project, the integration was migrated from API v1 to API v2, adapting endpoint consumption and handling the provider’s new JSON schema.

Rather than propagating these structural changes throughout the existing codebase, incoming payloads are normalized immediately after retrieval, allowing downstream components to continue operating against a stable internal model while minimizing the impact of the migration.

During journal generation, the integration dynamically detects whether an expense contains multiple tax entries and selects the corresponding processing strategy.

For multi-tax documents, the implementation iterates through every taxable base received from the API and generates independent accounting transaction lines, leveraging Dynamics 365’s native tax engine to calculate each tax automatically through configured tax groups and item tax groups.

Support for additional taxes was also incorporated through a configurable mapping mechanism. Instead of embedding fiscal rules directly into the application logic, a new configuration module allows external tax concepts to be associated with their corresponding ledger accounts inside Dynamics 365. During execution, these mappings are applied dynamically, allowing new tax types to be incorporated without requiring software changes.

Finally, additional validation rules were implemented to verify accounting consistency before journal creation, ensuring that invoice totals, taxable bases, and tax amounts remain coherent throughout the integration process.

 

Results

The project successfully modernized an existing production integration while preserving compatibility with the legacy processing model.

The enhanced solution supports invoices containing multiple tax rates and additional tax concepts, upgrades the integration to the provider’s latest API version, and introduces configurable tax mappings that improve maintainability without requiring future development for new tax scenarios.

By separating legacy and modern processing strategies, the integration remains extensible and well-positioned for future enhancements while maintaining compatibility with existing business processes.

 

Lessons Learned

This project reinforces the importance of isolating external API contracts from internal business logic. Introducing a normalization layer significantly reduced the impact of the API migration while simplifying the coexistence of multiple processing models.

It also demonstrates the value of backward compatibility when evolving enterprise integrations. Preserving stable production behavior while extending functionality often delivers greater long-term value than redesigning an existing solution from scratch.

Finally, implementing configurable business rules instead of hardcoded accounting logic provides a scalable approach for ERP integrations, where fiscal regulations and external platforms continue to evolve over time.