Adjust your Tax Calculation to Use Billing Address in Episerver Commerce

casper.rasmussen/ July 9, 2018/ Uncategorized/ 2 comments

Even thought there are great tax calculation providers with add-ons for Episerver Commerce (like Vertex), which makes tax compliance in e-Commerce a breeze, it happens to be required for developers to leverage the built-in taxation system in Episerver Commerce.

Configuration of tax jurisdictions, through various geographic descriptors, taxation types and corresponding fee’s are always required. Once in a while, we are on top of that in the need of making further changes than that.

Abstraction of Episerver’s Tax System

Episerver’s calculation workflows relies on an interface named ITaxCalculator, located in EPiServer.Commerce.Order, which acts as the abstraction of the entire tax calculation system. It can, like most other public Episerver APIs, be easily interchanged with your own custom implementation – e.g. if you are in the need of adjusting the behavior beyond the configurable jurisdictions.

All you need to do is to implement the required operations as per your business requirements, and then register it via Dependency Injection.


Sample Customization of the Episerver Tax System

Episerver’s built-in tax calculations are of course tailored to meet common compliance requirements, but we are sometimes faced by the need of customizing it. Let me provide an example.

Out-of-the-box, Episerver uses the shipping address of each shipment as the parameter for the tax calculation. That is not always sufficient to achieve tax compliance, and we have a number of times overridden the out-of-the-box behavior to accommodate the requirements for business-to-business transactions in parts of the world – that is relying on the billing address as the parameter for deciding the tax values.

Please note that the retrieval of billing address has been removed from the sample, since that is required to be implemented according to your business logic – especially when we’re calculating taxes for the shipping fee. We’re relying on the concept of MemoryOrders in Episerver Commerce to avoid duplication of the entire tax calculation logic shipped with the Episerver platform. It saves a lot of headaches down the road, since we directly will benefit from any changes made by Episerver during upgrades!



  1. Just a note, DI has been abstracted away now away from writing structure map specific code you should be registering your services using the generic methods e.g. context.Services.AddTransient or context.Services.AddSingleton

    1. That’s right! Didn’t consider that, given the solution I took it from was relying on StructureMap Registries to manage inversion of control.

      Thank you for that note.

      /Casper Aagaard Rasmussen

Leave a Reply to casper.rasmussen Cancel reply

Your email address will not be published. Required fields are marked *

Please type the characters of this captcha image in the input box

Please type the characters of this captcha image in the input box
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>