You mean when you make cash purchase from supplier but it creates WHT liability?
Yes
Exactly how to implement that will take some though / work because if I understand correcly you want
-
WHT deducted on payment which is prior to invoice.
-
payment to accounts payable (tax codes normally not allowed)
-
Shown on invoice but not deducted on the invoice
-
Perhaps you will need a negative line item on the final invoice to deduct prior payment with the tax codes applied at that time
Can we have withholding taxes to have codes too? In PH, we report withholding taxes per Alphanumeric Tax Codes, each with different tax rate.
Only WHT deducted on payment. We will register, then, the invoice without the WHT and we will edit the payment in order to be linked to the invoice. This should work. Them I will start working on a report transformation (if it will be enabled for WHT) or a custom report to see if those info are enough to have everything we need on the same report.
In my opinion Manager would benefit from
-
Making multi component tax codes a set of ordinary tax codes
-
Allowing multi component tax codes at the invoice as well as line item level
-
adding a “Calculation stage” to tax codes to enable specification of before vs after other taxes. Stage 1 based on the price before any taxes (Stage 0 price). Stage 2 based on after Stage 1 taxes etc.
Doing so would enable Report transformations and later electronic reporting in jurisdictions where multiple tax authorities levy taxes (as they would be based on the single component tax codes). This would allow users to construct multi component tax codes to optimise their individual use case independent of detailed tax codes and reporting tools.
However this maybe too big a change for Manager.
It maybe sensible to have a big picture overview, focussing on
- What exactly needs to be reported to the tax authority and when.
- Range of invoice types do users in Italy will typically use
- How this could be supported in the short term
- Is the short term solution achievable for less skilled users? If not how could the workflow be simplified in the long term.
In summary, do you think the changes suggested will work in the long term for less educated users given Italy’s reporting requirements?
Edit
Added tax code stage
I make a small premise:
- WHT in Italy is cash based even if the paying subject has taxation on accrual base. The reason behind this decision is that we are paying taxes on behalf of the supplier which, if subject to WHT, has cash based accounting.
- If the supplier, after the issuance of the proforma and before my payment, is no longer subject to WHT, this change will also have an effect on the document that has already issued to me (which is a proforma, so only a memo without any fiscal ah
- Let’s go on WHT accrual. Every time I pay the supplier, even a down payment, even without a proforma, which is not a real tax invoice, it is just a memo, I will have a liability (even of the paid quota) of the WHT due. So, basically, WHT accrual in based on Payments not on Proforma/Purchase Invoice.
WHT tax reporting is done at the end of the month, it is just a list of the payment group of supplier subject to WHT, and the tax has to be paid before the 16th of the following month through a specific module (F24, which is a tax payment module which is used for many kind of tax payments, even IVA, the Italian VAT).
I think that this was the subject of a long discussion a couple of years ago when Manager changed its way to assign Tax Codes.
After talking with my auditor/chartered accountant we all came to conclusion that it is correct to assume that WHT is applied and accrue on Payments and then it is reported on the Invoice.
Most users want Manager to support their particular use case well. I have suggested the solution as it addresses all jurisdictions requirements, not just any individual case.
It would enable
-
one localisation per tax authority. Consisting of single component tax codes and report transformation.
-
In countries like the USA with many tax authorities, a user would typically only install those relevant to their business.
-
In a jurisdiction like India with a couple of tax authorities, the country localisation is likely to include all tax codes and tax authorities report transformations.
-
The item level tax codes could be kept separate from the invoice level tax codes (currently with holding tax), however I suspect as soon as it was added, user would want to specify other tax codes at the invoice level such as import duties etc.
1 Like
That’s so much more than what I need in the immediate, ie the possibility to add WHT accrual on payments (in the same way we can do for purchase invoice).
Actually what you need is more than I have suggested because is contradicts conventions which apply in all other situations
- Taxes are disabled on line items to accounts payable / receivable as other wise users get confused and apply VAT twice.
- Book keeping can be done on accrual or cash basis, you just need to choose what your business uses
You are asking to break both of these program designs.
I’m not saying it is impossible, just that such changes would have to be done with care so as not to severely compromise all other users.
I’m asking to enable WHT module on payments, not to apply that on account’s payable. BTW you can already assign a tax code under payments Manager. So it is exactly something that is already happening.
This in not what I’m asking. Accounting basis is different from tax accrual. My accounting is accrual basis and WHT is cash basis. So it should be accounted as a debt on payment which happen before invoicing. And there is a logical explanation on that. Actually, at least in Italy, WHT is a payment of a tax you have to do on behalf of your supplier. And, in Italy, a supplier subject to WHT should keep it’s book keeping on cash basis while a big company which pays WHT is accrual basis. That’s why WHT should accounted under cash principle.
So I am not asking to break any rule. And the question of @lubos make me thing that is already feasible: