Tax Code rate changes

When the price of an invoice sales item is updated, prior invoices do not change. But when a tax rate in a custom tax code is updated, prior invoices using that tax code are modified. This happens even when an invoice has already been fully paid. Previously paid invoices will show a balance due. That seems to contradict the principle of immutability of records.

A workaround can be created by defining a new custom tax code every time one of the components is altered, giving distinct names, such as “Sales Tax after 1/1/2015.” There are potential accounting advantages of doing things this way.

But I wonder if this feature is deliberate or simply something that has been overlooked?

It is as designed. If tax rate changes, you need to create new tax code and perhaps archive the old one if it will no longer be used (I will need to implement archive feature for it though)

I know what you mean about immutability and you are right. Manager shouldn’t allow you to change the tax rate if the tax code has already been used.

I’m not sure an archive is required. Labeling a new tax code with the valid date can work. Several things to think about, however, are:

  1. Effective dates of tax components may vary. Different taxing authorities may impose new rates on dates that differ from other authorities.

  2. Applicability of tax components may also vary. Normally taxable sales delivered in other jurisdictions or to certain types of organizations may not be taxable by some authorities while remaining taxable by others.

  3. In many cases, the majority of sales will carry the same tax assessment, making it convenient to be able to select a single, “customary” tax code without having to indicate all constituent components separately. But individual components should also be selectable and deselectable, automatically taking into account effective dates of rate changes. That suggests a small database of tax parameters.

As an example, my jurisdiction has a sales tax rate with four components, all set by different authorities, none of which necessarily have the same dates for their frequent rate changes. One component, levied by the state, is applicable to anything delivered in the state, but not to anything delivered outside the state. Another, levied by the city, does not apply when something is delivered outside the city. And so forth. None of the components applies to purchases by religious organizations or non-profits. Some types of products are exempt from one component, but not from others. This can quickly get pretty complex.

I am resurrecting this topic to see where your thinking is, @lubos.

In future there will be less emphasis on custom tax codes. Ideally nobody should be using custom tax codes in future.

If “Manager Extensions” project takes off, Manager could simply contain all tax codes from all over the world including their effective dates etc.

I just think it’s wasteful if every business needs to maintain list of tax codes manually. So having them all in-built will benefit users.

That is a noble goal. But I predict great difficulty keeping up with the many changes. See my last post in January 2015. What is your concept for how these extensions would be updated? Irrespective of that question, there would still be the issue of changing applicability of taxes to various products, services, customers, and locations.

Tut…Lubos,

I wonder if I can set a variable category code for tax. Let me be clear on this.

In Malaysia we are based on GST Tax, under it own have several category ex. SR, TX, EST and etc… so along with the item invoice we need to specify the code category. I tried to look into deep solution for this. But if it fixes that way, I find my own solution for it.

See this Guide, which describes exactly your situation:

It’s not simple. But if you always charge all components of a tax code, see this Guide: