Tax Withholding Percentage

ideas
21

@uzair94 your solution has already been advised but to clarify:
When creating the Sales Invoice you have to include your GST 17% and WHT as usual.
You do not need to show the 20% of the 17% GST on the Sales Invoice.

So the invoice total is $11,173.50 (11700 - 4.5% WHT 526.50) and the GST Tax Payable account receives a credit of $1700.

When you receipt the payment for $10,833.50 you allocate $11,173.50 to the Accounts Receivable account and on a second line you allocate a negative $340 to the GST - WHT account.

When you receive the GST - WHT certificate from the paying authority you transfer from the GST - WHT account to the GST Tax Payable account via Journal, or you could edit the receipt.

Your request to have the GST - WHT as a selectable sales invoice adjustment item would only work if Manager shifted the whole WHT process over to being WHT codes, similar to Tax codes, where ticking the WHT would generate a dropdown dialog with an add option.

I agree that a compound tax code would be totally ineffective and also, you wouldn’t require multiple duplicating chart of accounts.

22

Does customer give you two separate certificates for each withholding tax type?

Yeah, that’s one solution. Ability to select multiple withholding tax types on single invoice. Then track balances separately.

23

yes sir they certainly give us certificate for both type of WHT but frequency is different for one they give us monthly and we have to file it to claim it and one of them is given yearly.

24

If you are adding the ability to have more than one withholding tax in a single invoice. I assume that would mean applying a “Withholding tax code” here instead of specifying the percentage.

Withholding%20tax%2001%20current
Withholding%20tax%2001%20current454×831 43.9 KB

Using the same approach as existing tax codes, that would enable specifying multiple tax rates and associated accounts
Withholding%20tax%2002%20Multi%20tax%20code

If this is the case please consider instead implementing “Multiple rate” tax code as a set of single rate tax codes.

By which I mean, when creating a “Multiple rate” tax code, the user should add the constituent single rate tax code. The tax percentage and associated account being a property of the single rate tax code.

The reason is, this approach scales efficiently. Using his approach would also help existing tax codes if implemented there. More specifically it would help

  • Limit the number of unique tax codes when different combinations of tax codes are used.

  • Simply coding of custom reports / localisation as a leaf tax code only exists once, not as a component of multiple tax codes.

  • Helps support regions where many tax codes in many combinations are used (such as USA).

PS:
Thinking about this more, if a sales invoice specific dollar value of with holding tax is required to be supported. Then that forces implementation of multiple tax code facility to be at the sales invoice not tax code level. Single rate withholding tax codes would still be appropriate (for name, associated account and percentage where used) but sales invoice specific dollar value would have to trigger display of a text box on the sales invoice screen to enter the amount. Unfortunately the resultant interface would not be as clean as just selecting a single (with potentially multiple account effects) withholding tax code at the sales invoice level.

It also means the description of an alternate “Multiple rate” tax code above is really only applicable for existing tax codes.

1 Like
25

@lubos my suggestion would be to split the Tax Codes under Settings so that users can define their WHT separately. similar to the custom fields where you have separate line item custom fields.

image
image1041×239 6.12 KB

where the user can define WHT applies to the Sub-total or Tax Amount or Total.
image

in the invoice ability to select more than one WHT.

image
after selecting tax code, the above should also optionally expand to enter amount manually instead of the rate.

3 Likes
26

@Patch, the reason why I made it so only one tax code can be selected on transaction lines is to reduce bookkeeping errors. There is Tax Audit report which can break-down all transactions for the period by tax code. If you could select multiple tax codes on transaction line, it would make it more difficult to spot bookkeeping errors.

@sharpdrivetek I’m impressed how you put in the work to demonstrate the possible implementation with screenshots. The way I’m thinking about approaching this issue is perhaps abandoning Deduct withholding tax checkbox altogether and making tax codes more powerful so they can handle withholding taxes as well. This would make withholding tax functionality available on all transactions (not just invoices) and would make it easier on data-entry. Sure, tax codes would be more complicated to set up correctly but that doesn’t bother me as they will be available for download on website.

27

I don’t like the user adding multiple tax codes on the bottom of the invoice either. It is too ad hoc so would have a high risk of data entry errors.

I amended my post to do that only to support the users specifying an invoice specific absolute dollar amount (not percentage).
Withholding%20tax%2004%20amount
If you combine this with invoices with multiple withholding tax types (going to multiple accounts). Then I couldn’t see any other way of doing it.

Eliminating the requirement for a user entered invoice specific absolute dollar amount would be a cleaner solution if that’s possible.

That’s an excellent idea, and would result in a cleaner user interface.
For those users who need to explicitly specify a withholding tax dollar amount, a line item with a 100% withholding tax code could then be used.

Actually the main point I was trying to make earlier was; for multiple part tax code use a holder code which contains multiple leaf tax codes ie stop defining the details within the multi code holder data structure. The advantages of this approach are as per my earlier post. Although the biggest advantages are:

  • users could then create new multiple part tax codes which would continue to work with the localisation tax leaf codes and reports.

  • All combination of tax code do not need to be entered (tax codes expanding proportional to number of taxes types not number of tax types squared.

Graphically this would result in a display similar to the following where clicking in the “Tax Code” box would show a list of existing “leaf” tax codes (by leaf I mean not multiple rate).
Withholding%20tax%2003%20Multi%20tax%20code

With single rate or withholding tax showing something like
Withholding%20tax%2005%20single%20part%20tax%20code

28

thanks for explaining this is exact solution iam asking this will solve many problems

29

please implement WHT finctionality as explained by @sharpdrivetek

30

@lubos i wonder how WHT will be integrated with the regular tax codes. the way i see it, the users will have to enable an awful lot of tax codes because the WHT is applicable to only transactions with a customer/supplier falling under specific categories according to local tax law.
so a business will have to enable a regular tax code and also the corresponding WHT code.
if we take our country for example, we have 19 regular tax rates for regular customer/supplier. now if we have customer/supplier who fall under WHT, then we will have to enable another 19 tax rates which would be the multiple tax rates of regular and WHT. that makes a total of 38 tax rates to be enabled.
retaining the Deduct withholding tax checkbox will need just 19 + 2 (in most cases maximum WHT rates will not be more than two) tax rates to be enabled.

31

I whole heartedly agree with @sharpdrivetek’s illustrated approach, it is clean and neat.
It doesn’t pollute the current tax codes which have a completely different purpose.
Tax Codes are a levy on a sale transaction, whereas WHT’s are a financial adjustment to the payment.

They are reported separately which can include different authorities and/or periods.

1 Like
32

@Brucanna very true

33

yes i totally agree with you sir this was the same method iam asking from last two years

34
Tax Features
Federal GST/VAT Percentage of line item sale/purchase price. Payable to federal government. Some allow offset sales with purchases. Rates vary with (addresses) foreign vs local sale/purchases
State sales tax Percentage of line item sale / purchase price. Payable to state government, specific account maybe useful. User may need to report to several states. Rates varies with addresses.
County sales tax Percentage of line item sale / purchase price. Payable to county government, specific account maybe useful. User may need to report to several counties. Rates varies with addresses.
Ciy sales tax Percentage of line item sale / purchase price. Payable to city government, specific account maybe useful. User may need to report to several cities. Rates varies with addresses.
Transit tax Percentage of line item sale / purchase price. Payable to transit authority, specific account maybe useful.
Reverse Charge VAT Percentage of line item purchase price. Reported to tax authority typically federal. Typically applicable to foreign suppliers.
Withholding tax Percentage of line item sale/purchase price. Payable to government at one or more of fedral, state, county or city level. Alter when & by who above taxes are paid. Specific accounts useful if more than one may apply.

So the issue is how to efficiently apply these taxes to individual line items given:

  • Multiple can apply to individual line items and in different combinations.

  • All should be specified at the item level (a fixed dollar option is currently included for withholding tax to accommodate items in an invoice having different withholding tax requirements and forcing external manual calculation).

  • The solution efficiently addresses the range of requirements across the taxation schemes used in all the countries Manager is sold in.

  • Defining uncombined taxes is most efficient as that ensures it is only done once and is compatible with Managers localisations.

The choice is where the combination is most efficiently done.

  • Aggregating tax regimens in an aggregating tax code has the advantage common combinations can be quickly and reliably applied. It has the disadvantages that if multiple aggregations are needed by a business they would all need to be created (probably by individual businesses).

  • Explicitly specifying individual regimens via adding multiple tax codes to individual line items has the advantage aggregating tax codes don’t need to be created. It has the disadvantage for common entries the user must ensure every line item has all applicable tax components applied (which maybe a source of accounting error).

No 19 + 2 leaf tax codes
With 1 aggregate tax code applied to each line item.

How many aggregate tax codes a business needs to create would depend on which combinations they found useful in practice.

In practice only a few combination / aggregating tax codes will be used most of the time, so this task is unlikely to be as arduous as feared.

However if this is the driving requirement, you are essentially saying; all multi-component tax codes should be scrapped as the approach is unworkable in Manager.

35

Tax codes are an addition, whereas WHT is a deduction, therefore to contra them off so as to create a NETT tax code and then apply that hybrid code to a line item would not only be impractical but a total nightmare. Especially when the calculation of the Tax code and the WHT is based on completely different criteria.

Alternatively, you could add a string of individual tax codes to a line item but that also becomes equally unworkable as every line item would need to repeat each string, rather than using invoice wide WHT codes.

If we re-visit @uzair94 where he sells the same 10,000 of goods to two different customers.
Customer 1 gets charged 17% GST and deducts 4.5% WHT-1 of the invoice total.
Customer 2 gets charged 17% GST and deducts 4.5% WHT-1 of the invoice total plus deducts WHT-2 which is only 20% of the 17% GST.

This would require two aggregate tax codes and as @sharpdrivetek stated, if you have 19 GST tax codes, then you would require 38 aggregate codes, 19 (GST + WHT-1) applicable to Customer type 1 and 19 (GST + WHT-1 +WHT-2) applicable to Customer type 2. Taxes aren’t just levied on the type of supply (GST) but also on the type of customer (WHT), so the aggregate tax codes would have to reflect all possible combinations of supply and customer.

Furthermore when you consider @uzair94 stated circumstances: (1) WHT-1 and WHT-2 belong to two different authorities and (2) the frequency is also different, one is monthly and one is yearly, then having aggregated tax codes at the front end doesn’t enable (without a lot of complicated programming) the user’s reporting requirements at the backend.

In addition, you also have the added complication where the jurisdiction has WHT rates which are individual taxpayer based. That is, Supplier 1 may have 5% WHT deducted while Supplier 2 may have 10% WHT deducted. In fact you could have 15 Suppliers all with different WHT rates. Now try combining these variable WHT rates with any GST/VAT code.

Australia is one jurisdiction which has this WHT model, it was previously call Prescribed Payment Deductions (PPD) but is now known as Voluntary Agreement (VA) which is either a flat 20% or a rate prescribed by the Tax Commissioner for that individual taxpayer. Payments under a voluntary agreement | Australian Taxation Office

Furthermore these VA rates would never form part of Localisations, therefore, removing WHT from its current location would disenfranchise those users which require a basic WHT application. Also, especially applicable if a jurisdiction only has WHT, no GST/VAT tax.

So in adopting the KIS principle, @sharpdrivetek’s illustrated approach allows the Tax codes and WHT (which are apples and oranges) to function independently without impeding user flexibility…

36

sir yes @sharpdrivetek illustrated best possible way as as you explains yes sometime some items are included in Pakistan 3rd Schedule on which customer cannot withhold 20% of GST as per Law and just withhold 4.5% tax on total. so, giving users such liberty would be best to select what to withhold and what not to.

37

@lubos any update about this?

38

Be patient, @uzair94. This has been in the ideas category only 3 days. It would represent a very major restructuring of the program.

39

@lubos it really needed and by implementing this it will make manager complete solution for Pakistani market as this thing is not being offered by any competitor.

40

@lubos any update about this idea?