Taxation regimens vary with the item or service traded. An invoice can include items of different taxation regimens. This applies to GST/VAT, State tax, County tax, City tax, Transit tax, Reverse charge VAT as well as Withholding tax (which is why Manager currently has the option to externally calculate the withholding tax then add an invoice specific fixed dollar amount).
Having one Manager tax code per taxation regimen (independent of aggregation) supports efficiency of accounting analysis (localisation, reports).
There are several different ways taxation regimens could be applied to accounting records while maintaining compatibility with the range of taxation regimens used world wide.
Where a business commonly trades items or services to which a relatively small number of combinations of taxation regimens apply, an accounting system such as Manager can efficiently apply / record the applicable taxation regimens by a correspondingly small number of commonly used aggregate taxation codes. The critical issue being the number of combination of taxation regimens the business mostly uses, not the theoretical number of combination.
A possible general implementation is to have a tax code type “Multiple rates” which only consists of a list of leaf (non “Multiple rates”) tax codes. They function only as a holder for a set of tax codes, and may be Manager business specific.
In contrast the leaf codes define the data collection, taxation rates, and account movements. These reflect a countries taxation requirements so are likely to be defined in the countries localisation. Different types being used to support Single rate, Flat rate, Reverse charge VAT, and Withholding tax specific requirements. All supporting a default and optionally Manager Business specific account.
Where a business commonly trades in items or services for which a relatively large number of combinations of taxes are commonly used, it is more efficient for the user to specify the taxation regimens independently. A possible general implementation in Manager is to add a “Tax group” to each tax code. The “Tax group” items and their order would be localisation specific.
Then when a tax code is applied, Manager would show the “Tax group” items as headings and allow independent selection of a tax code for each group. Note the current Manager functions is equivalent to having all existing GST/VAT tax codes in a “Tax group” called “Tax”.
For example if tax codes were defined using “Tax groups” GST, State, and WHT then these groups would be shown when a user entered transactions in that business. Each column allowing selection of a tax code within that tax group for each item.
Both aggregating tax code and multiple tax codes per line item
A third option is to recognised the above two options are actually not that different nor are they mutually exclusive. Both use the same leaf tax codes to determine actual taxation calculations and account allocation. They only differ in how the tax code aggregation is selected and shown to the user. Supporting both simultaneously in Manager would mean having both a “Tax group”, and a tax code type “Multiple rates”. It would be useful in jurisdictions with both a complex primary taxation regimen (eg lots of VAT rates / reporting requirements) and several additional simple taxation reporting authorities. For which aggregating the simpler tax options in one group and having the complex taxation in another group would be optimal arrangement. (Having a “Tax group” item level option to show only aggregate codes ie not leaf codes maybe nice).
A forth option applicable in jurisdictions where a taxation requirement does not vary with the item or service traded, is to specify those taxes at the invoice/transaction level (as they can’t change for that customer / supplier). It has the advantage specifying it once per invoice ensures it applies to all the items on the invoice. The same leaf tax codes could be used, perhaps implemented by Manager internally applying them at the item level (so actually also performing the same accounting functions with just a different user interface). During “Tax group” setup this would mean choosing where each “Tax group” item is displayed (transaction or item level). To mimic Managers current behavior current GST/VAT tax codes would be in the “Tax group” “Tax” displayed at the item level and Withholding tax would be in another group displayed at the invoice level.
For example if “Tax Groups” items for “Transit”, “WHT-federal”, and “WHT-GST” were set to display at the transaction level, and tax codes for each were defined then when a user created and invoice tax codes from each group could be selected.
Default tax codes would need to apply to each “Tax group” in a similar manner to how default tax codes currently can be set per account.
In the longer term many tax codes are selected based on address of the business and suppler/customer (same or different country, state, city, union of countries). Automatically selecting default tax codes base on this information for all cases is likely to be impractical however some automation maybe achievable in a future upgrade (such as address not in localisation country or EU).
For a taxation such as the Australian Prescribed Payment Deductions (PPD) / Voluntary Agreement (VA) this is
“a voluntary agreement is an agreement between a business (the Payer) and a contract worker (Payee) to bring work payments into the pay as you go (PAYG) withholding system”.
The payer/employer must submit a “PAYG payment summary – individual non-business” at the end of each year (ie the same as any other employee).
The ATO allows VA payments for contractors to be submitted via single touch payroll (STP).
Payments (for the payee/contractor income tax) are deducted at a rate of 20% or that payee’s “Commissioner’s instalment rate (CIR)”. This contractor specific tax rate is similar to an employee wanting an increased agreed tax rate (useful for those working more than one job and not wanting a tax bill at the end of the year).
In summary these arrangements result in the contractor payments having considerable commonality with employee payment arrangement. Extending Managers employee/payslip and existing associated reporting may well be more fruitful than trying to extend the invoice withholding tax capabilities.
However in the short term continuing to using an invoice specific payment may be simplest until a better method is implemented.
Setting up taxation codes for each country is not trivial as the taxation regimens which have developed in each country are often quite complex. Fortunately in Manager this is done once per country then subsequent users can import the country specific localisation. Having flexibility when setting up tax codes in Manager should ensure the end user experience is optimal in all countries.
Coding complexity depends both on how many jurisdiction need changes to core Manager functions to achieve compliance with their taxation requirements (ie how general is a proposed solution), and existing program architecture / code. Issues for which only Lubos will have a real understanding.
Quite frankly, how to convert a single string into a complex knot.
And just to clarify - Voluntary Agreements WHT already works perfectly within Manager’s existing invoice process so there is absolutely no need for any extending or modification of the “invoice’s withholding tax capabilities”.
Of special note, when a contractor is registered for GST and also enters into a “VA”, then they are forbitten from also charging GST on their Sales Invoices. Due to the ad hoc nature of this arrangement, it would never form part of any tax localisation.
But the greatest problem (besides the complexity) is that its one sided.
So you have the Supplier creating their Sales Invoice using the Manager multiple tax code.
However, the Customer, who doesn’t use Manager, can’t replicate the entry of the multiple tax code.
Currently, all accounting software use the same approach, so they can talk to each other.
