Examples of tax engines

Question

We are creating software for selling software for Mac and are committed to updating our tax mechanism. It's pretty simple right now, with taxes consisting of a name, code and rate, which can be applied to each product individually. Although this is good enough for some people, we had many requests for handling more complex situations. Some examples are U.S. city / county sales taxes, Canadian taxes (taxes), French Ecotax, and luxury taxes in New York.

We have identified most of the characteristics that these taxes have and are inclined towards some kind of rule-based implementation. We do not need to support every case there, but we want to be able to extend it if necessary (to avoid another rewriting).

We seek advice from people who have built something similar before, or examples of projects that try to solve the same in an elegant way.

Answer 1

I would recommend a set of database tables and connections.

Example:

• Jurisdiction : list of states, countries, countries, cities, etc.
• Product : obvious
• Save : list of places where you sell,
• StoreJurisdiction (StoreID, JurisdictionID): a list of jurisdictions in the store responsible for collecting taxes for
• ProductTaxCode (ProductID int, TaxCodeID int): type of product for tax purposes: basic, luxury, etc.
• JurisdictionTaxCodeRate (JurisdictionID, TaxCodeID, InterestRate, RateType): for each applicable combination of jurisdiction and tax code, indicate the applicable tax rate and the type of rate (compound, simple, etc ..).

To find the list of applicable taxes, all you need is the INNER JOIN of the store, its jurisdiction, the jurisdiction that applies to these jurisdictions and product tax codes.

You can define ProductTaxCode as a view so that all products receive TaxCode by default, unless a special one is provided. By abstracting TaxCode, you can have the same product metadata (for example, "Food") for different regions in different ways. If a particular jurisdiction has its own definition of “food,” you simply add a code specific to the jurisdiction and apply it to the products as needed.

This may require some customization for online purchases, bulk purchases, and other situations where the sale is somehow tax-free or the customer is responsible for transferring them. It also needs to be set up for situations where the location of the client, and not in the store, determines the tax rate.

Other settings: here, for example, in Texas, we have a “tax-free” weekend when state and local taxes are not collected on some classes of products where the sale price of individual items is less than $ 100. The idea is to provide cheaper school supplies, clothes, etc. For children going to school for the new year. Such customization can be implemented by displaying a table of date ranges for each JurisdictionTaxCodeRate in the future, as far as possible.

Answer 2

My suggestion would be to use database tables for what they are good for (for storing values) and for the rules for which they are good (business logic). Of course, I would not put such things as tax rates or lists of jurisdictions in the rules - they should be in the tables. I would use a rule engine to determine the logic that determines which rate applies to which transactions. So, for example, if I buy a suite of products online from a company based in state X that travels from state Y to three different locations, what tax rates apply to those parts of the transaction? This combination of database rules and tables is very common - rules ensure that you look for the right things, while tables help in reporting, etc. For example, the California DMV did this with car registration fees - all the various fees are kept in place while the rules determine which fee applies to which car is driven in the rule base. If you try to put everything in the rules, you won’t be able to communicate well, and if you try to put everything in the database tables, you will get dozens of tables to manage all exceptions and corner cases. Jt

Answer 3

Here is an example of a home rule city in the metropolitan area of ​​Denver, CO:

http://www.c3gov.com/pages/about/division_salestax.html

You, as a seller, can also send tax payments to different places. For cities that are not the “home rules” of cities (which is a special term that probably only applies to Colorado, but then probably every state has the same special term like this), you send all tax payments to the state which will then be distributed to their respective parties. Colorado has a function where there are “special tax areas” that are allowed to levy sales taxes for certain benefits (for example, RTD is the public transportation area, and “Invesco Field” is the stadium where the Denver Broncos play).

To expand Mr. Tallent’s answer on this topic, you also need to include in your jurisdiction table some way of representing that taxes can go to different places.