A few of our clients came to us with the same request. They needed Avatax to apply an extra layer of logic on top of its standard tax calculation. Specifically, they wanted the ability to pass a flag that tells Avatax in D365 F&O to reduce the calculated tax by a certain percentage, using the standard Avatax calculation as the starting point.
On paper this sounds like a small ask. In practice, it raises a much bigger question for anyone working with D365 F&O and third party solutions: how do you customize an ISV product without putting your future upgrades at risk?
Why This Problem Is Bigger Than One Client
The tension between customization and upgrade safety is not unique to Avatax. McKinsey research on technical debt found that CIOs estimate unmanaged technical debt eats up 20 to 40 percent of the value of their entire technology estate, and that 10 to 20 percent of budget meant for new products gets redirected just to keep up with it. Sixty percent of CIOs said that debt had grown noticeably over the past three years alone.
Every direct edit to an ISV product like Avatax is a small deposit into that same debt pile. It solves today problem while creating tomorrow upgrade headache. This is precisely the gap Reach closes through project assessments and audits, and through ERP rescue and recovery work for clients whose D365 environment has already built up this kind of risk.
The Constraint That Shapes Everything
When we brought this requirement to Avatax, they shared their source code and were upfront about the tradeoff. If we modified their code directly, our changes would work, but they would also be wiped out the next time Avatax released a new version. Avatax was clear that they are not responsible for maintaining or protecting any customization layered directly on top of their code.
This is a common situation for solution architects. Vendors give you access to extend their product, but every direct change you make becomes a liability the moment they ship an update. Many teams end up stuck with two bad options. Either they avoid the customization altogether, or they accept ongoing manual rework every time the ISV pushes a new version.
We wanted a third option.
Finding the Right Seam in the Code
Our technical team spent time understanding how the Avatax engine actually works behind the scenes, not just what its public interface exposes. That deeper look paid off. We found a natural extension point in the code where we could apply the chain of responsibility pattern.
In simple terms, chain of responsibility lets you insert a new step into a process without changing the steps that already exist. Instead of editing Avatax calculation logic, we added our own link in the chain that runs alongside it. Our logic reads the additional value the client needs, in this case a reduction percentage, and passes it through to the Avatax portal so their advanced rules engine can apply it on top of the standard calculation.
The result is a clean handoff. Avatax still owns and runs its core tax calculation exactly as before. Our extension simply adds the extra input the client needs, at the right point in the process, without changing a single line of Avatax own code.
Why This Approach Matters
This solution gives our clients three things at once.
It solves the business need. The client now has a working flag that reduces tax calculation by a set percentage, using the standard Avatax result as the baseline.
It protects future upgrades. Because we never touched Avatax source code, the next version update installs cleanly. There is nothing to reconcile, nothing to re apply, and no risk of our customization silently breaking after a release.
It keeps the system maintainable. Anyone on our team, or the client team, can look at the extension point and understand exactly what it does and why it is there, separate from the core Avatax logic.
The Bigger Lesson for D365 F&O Teams
This project is a good example of a pattern we see again and again. Standard functionality rarely fits every client needs perfectly, and vendors are often unable or unwilling to guarantee support for direct code changes. The real skill is not in writing a workaround. It is in understanding a system well enough to find the point where a clean extension is possible, then using a proven design pattern to keep that extension isolated from the vendor own code.
At Reach, this is the kind of problem our team is built to solve. We do not just implement standard configurations. We go deep enough into the platforms we work with, including ISV solutions like Avatax, to find upgrade safe ways to meet requirements that fall outside the standard playbook. If your team is facing a similar constraint with Avatax, another ISV, or D365 F&O more broadly, we would be glad to talk through how we approached this one.
Let’s Solve the Constraint Together
If your team is facing a similar wall with Avatax, another ISV, or D365 F&O more broadly, you do not have to choose between skipping the feature and risking every future upgrade. Reach has already built the pattern for finding a clean, upgrade safe way through.
Contact Reach today to talk through your specific constraint, and let’s find the seam that makes your next upgrade a non event instead of a fire drill.
Frequently Asked Questions
Any direct edit to the vendor own code is usually overwritten the next time the vendor ships an update. This forces teams to choose between skipping the customization or accepting ongoing manual rework after every release.
It is a design pattern that lets you insert a new step into an existing process without changing the steps already there. In this case, it let Reach add custom tax logic that runs alongside Avatax, rather than inside it.
Yes. The principle, find the extension point a vendor already exposes and build alongside it rather than inside it, applies to any ISV integration running on D365 F&O or Business Central.
Start with a project assessment or audit to map where the risk sits. From there, Reach can scope an ERP rescue and recovery project to bring the environment back to an upgrade safe state.
Principal at Reach
Radovan Miodragovic is a Dynamics 365 Technical Solution Architect and Team Lead in Reach with over 17 years of experience in delivering complex technical solutions. A solution-oriented leader, he specializes in the architectural design, development, and implementation of Microsoft Dynamics 365 for Finance and Operations, alongside expertise in Azure, Power Platform, and DevOps. Radovan holds a Master of Science in Electronics Engineering and carries an extensive list of industry credentials, including the Dynamics 365: Finance and Operations Apps Solution Architect Expert certification.
