A. To implement all tax code accounting functionality make:
All tax codes apply to an individual line item and a single account ie single rate tax codes. Include settings to handle the current tax code behavior.
Add the ability to calculate tax based on the initial line item amount or the amount including proceeding taxes. This could be implemented by making tax codes an ordered list (rearrange similar to COA) and have a check box on each tax code to specify “Tax inclusive of proceeding taxes”.
Support multiple tax codes for each line item
Internally no other form of tax code is used. As a result there should be exactly one Manager tax for each of a jurisdictions legislated taxes.
B. Separate the user interface from the internal representation. To aid in user selection of taxation regime and simply display of tax codes
Support putting single and multi rate taxes in groups.
The ability to display & select a tax code from the line item group at the line item level. Similarly allow selecting & displaying a tax code from the transaction level group at the transaction level. Which is internally done by apply the tax code to each line item. Conversely tax codes are shown at the transaction level if they are in a transaction level group and all line items have the tax code (which will always be the case unless tax code definition has changes since the transaction was created in which case residual tax codes default to the line item level).
The interface can be extended by allowing defining multiple line item level groups and multiple transaction level groups. Allowing user selection of multiple tax codes at the line item or multiple groups of tax code at the transaction level.
Note group B features only effect the user interface. All the underlying accounting functionality being purely defined by group A functionality.
The advantage of this general structure is it would support
Tax reporting based on the underlying legislated tax not the various combinations of taxes
Country localisation grouping or individual user grouping of tax codes based on typical usage patterns
Adds the full tax code functionality and reporting to withholding tax
Add full and efficient support for jurisdictions where multiple levels of government independently levy VAT taxes
A possible example of creation of a multiple rate tax code
A possible way of defining a group for each tax code
A possible example of applying / showing multiple groups of tax codes at the line item level
A possible example of applying / showing multiple groups of tax codes at the transaction / invoice level
This becomes enormously complex when you think about being able to return part of a single line item from a sales invoice invoking the full range of options.
Onestly I’ve never seen such a thing in any accounting software and I think it is too complex.
Since we are talking about tax modules, what I’ve seen in most of the other accounting softwares is:
for VAT, the possibility to have multiple Tax Sections,
ie subgroups of Invoices with indipendent numbering with a specific prefix. This is needed for companies with different kind of activities, for example a real estate company that does both sales of apartments and rent of apartments. This ends up with a distinct tax declaration for each Tax Section.
a specific module only for withholding taxes.
Here are how these works.
For point 1 you have a specific setting area for Tax Sections in which you set:
a specific name (“Sales Section”) for each Tax Section
a prefix ("SL-)
a numbering structure, for example YY-NNNNNN would end up with SL-20-000001, YYYYNNNN SL-20200001, YY/MM-N SL-20/07-1
Reverse Charge for VAT has it’s own Tax Section, so it should me moved from Tax Code to Tax Section, also due to the fact that Reverse Charge can be applied to each existing Tax Code
b. a drop down list at Invoice level (each kind of invoice, ie sales and purchase invoice/credit and debit note) that classificates the invoice and consequently set the specific autonumbering
c. each kind of Tax Report can be filtered for each Tax Section.
For point 2 again you have a specific area for each WithHolding Tax in which you set:
a name for each WHT
the amount to which you apply WHT, ie total with VAT, total without VAT, a subcategory with or without a VAT (this last one can be achieved with the implementation of a custom drop-down field at line level shared through all kinds of Invoices)
the WHT rate
if WHT is to be paid on cash or accrual basis
b. the WHT module should be implemented specularly both for active and passive invoices
c. the development of specific reporting based on all the infos above
A universal numbering system across all jurisdictions Manager software is used in (so Manger can deduce the taxation treatment required).
Spreading the definition of tax functionality over tax code definition and COA code / section.
System generated accounts based on tax code and report section.
I do not doubt such a system could work well when accounting software is heavily based on a single jurisdictions reporting / coding requirements. I’m less convinced a general solution for all jurisdictions would be simpler.
Btw I have edited the opening post to clarify what I was initially suggesting. No doubt Lubos is aware of the issues. Hopefully he can craft a system which adequately addresses his target markets.
you have edited your opening post 13 times, this communicates the suggestions complexity.
Tax authorities themselves don’t function with this degree of complexity, so why should accounting software. In fact, tax authorities keep their various tax regimes, GST/VAT, WHT, PAYG, Income Tax - Business / Personnel, as completely separate departments, and so should the accounting software.
Updated the opening post to include a possible implementation to support taxes based on the after tax amount of earlier taxes.
The real issue is how different the back end is from the current Manager internal implementation, something only Lubos knows.
Btw
I agree the suggestion is very flexible, but that is the intention.
Manager’s target market covers many jurisdictions, many of which have taxation regimens which result in some items having multiple taxes proportional to the items value applied to the same item.
The proposed program representation is the probably the simplest way of representing a jurisdictions taxation legislation. One code per legislated tax. Amounts calculated at the line item level to ensure rounding occurs in one place and program uniformity / simplification.
The proposed user interface also supports display of the simplest / most efficient tax code grouping given each jurisdictions taxation regiment and users typical use patterns.
Examples
Australia: GST, Stamp duty
India: CGST, SGST, UTGST
USA: County, State, Federal
etc
As a side effect it is likely to also provide a method of efficiently accounting for a sole traders personal use (a tax code applied first which transfers a fixed percentage to owner equity)
I agree that Manager should cover every jurisdiction but in the end the typologies of taxes are direct and indirect, withholding and reverse charge. We don’t need to reinvent the wheel but to look at mainstream software like Navision.
This can already be handled by creation of a composite tax code with calculated effective rates. The compounded rate only needs to be calculated once. From the Guide:
Bingo
That is the point, the core change suggested is in fact very similar to what is done already in Manager.
Currently multi-part taxes are defined by
A new way of defining multi part tax code
It does the same thing but
Now if new multi-part tax code is created, with no extra effort it will work with the old reports and group the tax parts together as it is using the same underlying tax codes.
If this works for line item tax codes, why not use the same mechanism for invoice level tax codes like withholding tax, then Manager would support jurisdictions with multiple withholding taxes.
Some jurisdictions tax systems is best represented by taxes other than with holding taxes at the invoice level, so why not support other taxes at the invoice level.
Some jurisdictions have multiple taxes from multiple levels of government resulting in a ridiculously large number of potential combination, so why not support their tax system by allowing more than one group at the line item or invoice level.
Each is a small step. If you do them all you end up with the opening post. A flexible system but at it’s core not a lot different to how Manger already works.
Once again, totally and utterly agree. Why one would want to aggregate direct taxes which are reportable and indirect taxes which are not reportable into a composite tax code is beyond belief, especially when they are individually calculated from a different base value.
Accounting software should simply replicate how Tax Authorities function. Tax Authorities don’t aggregate differentiating taxes so why should the accounting software…
If you really believe that you can combine these two taxes into some form of composite tax code, then quite frankly you are living in fairy land. For a start, Stamp Duty is always an expense (even if it is being capitalised) and never ever requires a tax code.
