RSS Feed (xml)
46C - US Use Tax[/b]
Question: Do Companies default use tax codes in the purchase order from condition record or is is filled manually?
SLR[/b]
Answer:
condition record NAVS
Answer:
Can we change the access NAVS and how difficult is it to base it on material/vendor registration in state combination/Use combination
SLR
Answer:
Yes you can customize NAVS access--add new "key combinations" Not sure that I follow the rest of your question though. At the time the NAVS condition is evaulated and the default tax code is entered into the PO, the vendor and material information is known, so you should be able to use that in the decision.
Answer:
The issue being vendor registration. The vendor should be registered in the state of purchase and not in his original state. Hence it could be that the vendor is registered in PA but not in NY. So if the purchase is made in NY then we have to self access tax. Thus the access sequence should be vendor along with state in which the purchase is made.
SLR
Answer:
In that case I would use a manually assigned tax code during invoice verification when it is determined that tax is owed but has not been invoiced. At PO time you don't know if the vendor will charge the tax, but you will know if the purchase is taxable.
Answer:
Then it becomes giving more authority to the person who does the invoice verification. Which is too dangerous and not manageable when purchasing is a decentralised function.
Now in many cases the vendor does not understand the meaning of registration in the state of purchase. So if he is registered in his original state then he charges the same rate and thinks he is registered in every state and charges tax accordingly. In such a case the tax rate is different than that determined by taxware and that charged by the vendor.
Any thoughts??
SLR
Answer:
Hi SLR,
You are not really giving that much authority to the AP person. The system has already determined that tax is due via the tax code provided by NAVS. The only thing that the AP person is doing is changing that code (which requires that the vendor charge the tax) to a new code that is for a use tax accrual. You only need one use tax accrual tax code (i.e. U1) and it gets the proper amount from Taxware based on the jurisdiction. If you are afraid that the AP person will change to the wrong tax code, you could develop an ABAP report that compares the tax code from the PO to the tax code used in invoice verification and review it periodically. The use tax code creates an entry in a tax liability account and the tax department will have a chance to review the entries before remitting to the state.
I have tried many different approaches to this problem and have even created a mod in the tolerance portion of the LIV code that automatically books the use tax for either the full accrual (vendor charged nothing) or a partial accrual (vendor did not charge enough). It worked well, but the LIV code was too unstable for the mod to have any shelf-life so it was gradually phased out in favor of the more manual approach.
Why would Taxware not be returing the correct rate? Is New York an "origin" or "modified origin state?" In most states, the tax rate depends on the point of goods receipt (i.e. plant, cost center). In some states the use tax is lower from the sales tax, but that is not often the case. Vendors often charge taxes incorrectly, but Taxware should be returning the correct rate almost all the time--100% would be great but it is expensive to get there given all the factors involved. Using the U1 example above, the call to Taxware passes a tax code for use tax and a jurisdiction code for the point of receipt (ship to) and taxware returns the correct amount which is posted to the accrual account. In reality four jurisdiction codes are passed over, but mostly the ST is used. Even if the use tax rate was different from the sales tax rate, Taxware should return the correct answer. One disclaimer here--I have only worked with Vertex and SAP so I am assuming some things about Taxware.
I hope this is helpful.
Regards,
SLR[/b]
Answer:
condition record NAVS
Answer:
Can we change the access NAVS and how difficult is it to base it on material/vendor registration in state combination/Use combination
SLR
Answer:
Yes you can customize NAVS access--add new "key combinations" Not sure that I follow the rest of your question though. At the time the NAVS condition is evaulated and the default tax code is entered into the PO, the vendor and material information is known, so you should be able to use that in the decision.
Answer:
The issue being vendor registration. The vendor should be registered in the state of purchase and not in his original state. Hence it could be that the vendor is registered in PA but not in NY. So if the purchase is made in NY then we have to self access tax. Thus the access sequence should be vendor along with state in which the purchase is made.
SLR
Answer:
In that case I would use a manually assigned tax code during invoice verification when it is determined that tax is owed but has not been invoiced. At PO time you don't know if the vendor will charge the tax, but you will know if the purchase is taxable.
Answer:
Then it becomes giving more authority to the person who does the invoice verification. Which is too dangerous and not manageable when purchasing is a decentralised function.
Now in many cases the vendor does not understand the meaning of registration in the state of purchase. So if he is registered in his original state then he charges the same rate and thinks he is registered in every state and charges tax accordingly. In such a case the tax rate is different than that determined by taxware and that charged by the vendor.
Any thoughts??
SLR
Answer:
Hi SLR,
You are not really giving that much authority to the AP person. The system has already determined that tax is due via the tax code provided by NAVS. The only thing that the AP person is doing is changing that code (which requires that the vendor charge the tax) to a new code that is for a use tax accrual. You only need one use tax accrual tax code (i.e. U1) and it gets the proper amount from Taxware based on the jurisdiction. If you are afraid that the AP person will change to the wrong tax code, you could develop an ABAP report that compares the tax code from the PO to the tax code used in invoice verification and review it periodically. The use tax code creates an entry in a tax liability account and the tax department will have a chance to review the entries before remitting to the state.
I have tried many different approaches to this problem and have even created a mod in the tolerance portion of the LIV code that automatically books the use tax for either the full accrual (vendor charged nothing) or a partial accrual (vendor did not charge enough). It worked well, but the LIV code was too unstable for the mod to have any shelf-life so it was gradually phased out in favor of the more manual approach.
Why would Taxware not be returing the correct rate? Is New York an "origin" or "modified origin state?" In most states, the tax rate depends on the point of goods receipt (i.e. plant, cost center). In some states the use tax is lower from the sales tax, but that is not often the case. Vendors often charge taxes incorrectly, but Taxware should be returning the correct rate almost all the time--100% would be great but it is expensive to get there given all the factors involved. Using the U1 example above, the call to Taxware passes a tax code for use tax and a jurisdiction code for the point of receipt (ship to) and taxware returns the correct amount which is posted to the accrual account. In reality four jurisdiction codes are passed over, but mostly the ST is used. Even if the use tax rate was different from the sales tax rate, Taxware should return the correct answer. One disclaimer here--I have only worked with Vertex and SAP so I am assuming some things about Taxware.
I hope this is helpful.
Regards,
No comments:
Post a Comment