How to Handle State by State Tax Treatment Differentials When Setting Up Payroll Codes in Dynamics GP

In an earlier post, we were warned of the dangers of having payroll codes with tax treatments that do not match the tax treatment of the payroll code setup record. There can be many reasons for this situation to occur and the consequences can be severe in terms of financial penalties and employee morale. Yet we still come across those who purposely setup a payroll code this way. Why would they do that?

Here is a common example:

A company has operations in both Pennsylvania and New Jersey. New Jersey allows you to exclude employee 401(k) contributions from state taxable wages (i.e. before tax deduction). In Pennsylvania, employers are required to include 401(k) contributions as taxable wages for state income tax withholding purposes (i.e. after tax deduction).

When the company first set up their Dynamics GP payroll module, they wanted a single deduction code setup for the 401(k) plan. They reasoned that all of their employees work for, and are paid by the same company, and they are covered by the same 401(k) plan that is administered by the same third party administrator. Therefore, they setup a single deduction code named “401K”.

Best practices require that each payroll code have one tax treatment setup and that all employees assigned to that code have the same tax treatment as the code’s primary setup record. Therefore, the proper way to handle this situation is to set up two codes, for example: “401KPA” and “401KNJ”.

Here’s why multiple codes are the best practice:

The single code solution requires HR/Payroll staff to determine and maintain the tax treatment of the 401K deduction on an employee by employee basis. Consider the 401K Deduction Maintenance cards for the two employees in Figure 1 below. A payroll clerk, or anyone, would look at these two records and question why they are treated differently for state tax purposes. It is not immediately clear that it’s because one is a New Jersey employee (Ackerman) and one is a Pennsylvania employee (Barbariol). Do you expect all of your payroll staff to know all state payroll tax laws? What happens when an employee moves from one state to the other? Does the payroll staff remember to change the tax status on the 401K deduction? Remember, there can be very severe consequences to getting payroll taxes wrong, including stiff financial penalties and negative effects on employee morale.

If the deduction codes were 401KPA and 401NJ, it would be immediately clear that there are legitimate reasons for the tax treatment differential and every employee assigned the code would have exactly the same tax treatment as the codes primary setup record in accordance with best practices.

Many will push back at this recommendation. Here are some of the arguments heard, and the counter argument:

1. Multiple codes complicate reporting to the third party benefit administrator.
   • The solution is simple, Have a SQL view written to aggregate all the 401K codes into one report. You are likely already doing this with your health insurance codes – separate codes for separate coverage’s from the same carrier.
2. Payroll staff still need to know which payroll code to assign, so what’s the difference?
   • True, but that is a lot easier to determine – assign the code based on where they live – NJ gets 401KNJ, PA gets 401KPA. And no one is messing with the tax treatment after the initial setup. Set it and forget it.
3. We operate in all 50 states and I don’t want 50 different 401K deduction codes.
   • That’s understandable. A good compromise would be to have two codes, one for before state tax (401BST) and one for after state tax (401AST). Not quite as easy to assign as indicating the state in the code, but still no one is messing with the tax treatment after the initial setup.

In summary, when setting up Payroll codes in Dynamics GP, apply best practices and make sure that each payroll code has one tax treatment setup and that all employees that are assigned that code have the same tax treatment as the code’s primary setup record. Contact your state revenue agencies for applicable state payroll tax regulations.

To learn more about how you can take advantage of this and other Dynamics GP features, visit RSM’s Microsoft Dynamics GP resource. To make sure you stay up to date with the Microsoft Dynamics Community, subscribe to our Microsoft Dynamics Community Newsletter. For more information on Microsoft Dynamics 365, contact us.

By: Dave Funk

Dave Funk