Tax Schedule Tip

I’ve got to admit, this tip has been on my list for a LONG time, and relates to a pet peeve of mine with the configuration of tax schedules. Here is this week’s #TipTuesday for you!

Did you know that you don’t need to have separate tax schedules for a “purchasing” tax and a “sales” tax if they are fundamentally the same? Perhaps this doesn’t happen in the USA but in Canada, most jurisdictions have HST (Harmonized Sales Tax) that are the same whether you are buying or selling.

What does that mean?

I’ll use Ontario as an example. The tax rate on the majority of items (not all but a significant amount of things) is 13% no matter if you are selling or buying.

What’s the issue?

What I have seen over the years all too often are consultants setting up separate tax schedules for the “purchase” tax and the “sales” tax. For example, they would set up “P-HST” as a tax detail (correct) and as a tax schedule (redundant). Then they would also set up “S-HST” as both as well. 2 tax details are correct, for the basic tax, one for purchasing and one for sales.

For the tax schedule though, it’s unnecessary! A single tax schedule called “HST”, for instance, would suffice because Dynamics GP *knows* which tax to charge depending on which module you’re using. It’s not like GP will calculate 26% tax!

Example

Here’s my tax schedule setup, in Fabrikam, with 2 new tax details set up for Ontario HST at 13%, on the left, and inserted on the right into a single tax schedule called “HST-ON” for “HST in Ontario”.

I’ve inserted both tax details into this schedule because it works! Here is proof, with a Payables Transaction Entry example using this new tax schedule. Lo and behold, only 1 tax detail calculated because Dynamics GP knows this is a Purchasing transaction, it ignores the Sales tax detail.

Why does it matter?

I can’t even begin to count the number of support calls I’ve dealt with over the years where there are multiple tax schedules set up and the user mistakenly set up the “Payables” tax schedule on a customer or the “Sales” tax schedule on a vendor. Yes, it’s a user error that is completely avoidable but many users see “HST” in the name and select the first one they see.

In my humble opinion, in jurisdictions like Ontario where you *can* do this, why complicate things by having tax schedules for every tax detail?

4 thoughts on “Tax Schedule Tip

  1. Reply
    Mo - January 9, 2019

    HI, thanks for this valuable tip … however I tried setting this up as explained however I’m getting GP to calculate both the Sales and Purchasing tax details on a payable transaction !! Is there some setup I’m missing ?

    1. Reply
      Jen Kuntz - January 14, 2019

      Hi Mo,

      Apologies for the delay in responding. The only time I’ve seen this happen is when a tax detail is set up incorrectly – i.e. both are set to be a Purchasing type of tax detail.

      My suggestion is to open up the tax schedule and then look at each of the tax details on that schedule. If you are using an example like mine above where there are 2 details, 1 sales and 1 purchasing, make sure that 1 detail is set up as Purchasing type and 1 detail is set up as Sales type. If that’s correct, the system should not be calculating both taxes on a Purchasing/Payables transaction.

      Jen

      1. Mohamed - January 15, 2019

        Thanks Jen ,

        I figured it out ! My TAX schedules are setup up correctly, but I had the option for reverse charge activated and that’s what caused the issue of double charging. Apparently this method won’t work if you need the reverse charge option .

        Thanks n regards ,
        MZ

      2. Jen Kuntz - February 9, 2019

        Interesting! Thanks for the update, it’s always good to solve a mystery!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to top