Everything and Anything you wanted to know about SUTA in Microsoft Dynamics GP!

Over the years, we have gotten many cases on SUTA (State Unemployment Tax Authority) and our SUTA calculation as straight forward as it can be, we seem to make it tricky.  I thought a detailed blog on the ins and outs of how this calculates would be a great way to kick off the new year!

1. Common misconception, my FUTA (Federal Unemployment) report is right on the money, why is my SUTA report wrong?
FUTA and SUTA are completely different reports and code bases in Microsoft Dynamics GP.  In our minds we think they are the same, but they really are not.
SUTA will calculate and sort data differently, SUTA has multiple states where FUTA does not, I could go on and on, you get my drift.

2. I installed the tax update but the rate or maximum did not change for SUTA, why not?
Our tax tables do not store SUTA nor FUTA rates and amounts.  This is something you manage yourself as each company may be different. 
This is under Tools | Setup | Payroll | Unemployment tax.

3. Federal Credit Reduction and how to handle it in Microsoft Dynamics GP.

4. A case we may get at the beginning of the year will be I set up a new deduction and it is reducing my SUTA wages, how do I fix?
Tools | Setup | Payroll | Unemployment tax, mark the box Tax Sheltered Annuities and insert over the deductions you want included as taxable wages.

5. SUTA and FUTA reports are based on Federal Taxable wages, not Gross Wages.  The Workers Compensation report is based on Gross Wages due to different setup than SUTA and FUTA.

6. SUTA and FUTA reports are meant to be run based on a calendar year date range.  If you run these reports across years, example 12/1/2016 to 1/31/2017 your results will not look right and vary especially with the yearly maximums in place.   Even though your pay period may cross the year, the checks were probably dated in one year vs the other so run the report for that range and try not to cross years to have accurate reporting.

7.  SUTA Performance
- When you run the SUTA report, it will take 1 pass through the UPR30300 (Transaction History)  table to grab all the year1 records for the date you are running the report
Puts them in a temp table…then circles through this temp table as it crunches number for the SUTA report.

- This is a dexterity report, it will take a long time to run, especially by the end of the year.  Come January it will speed up again.
Since this is a dexterity based report, it gets a low priority when requesting data, plus in the trace the report will look like it is just "chatting" with the server.

- If it is running slow for you, you can try to run the report at the server and see if you get the same results, this will take out any connection issues the customer may or may not have.

- If you watch a trace/ log of this running, (yes it will slow it down more), you may see it looping on the UPR00501 (deduction based on table)
What has happened is several pay codes are in this table that are not even used for this specific employee, and this causes a huge hit for performance on the SUTA report as it is looping on that table and getting zero results as the employee is not even using that pay code.  Recommend to clean up that table if at all possible.  Example, 1 employee had 4 pay code records assigned to him.  For his 401K deduction, it was based on 307 pay codes that he does not even have…huge hit on the SUTA calculation, this happens as customers roll down pay codes on “classes”  that are not really needed for that employee.

Sample scripts, back up required, verify your data and run in test first/at your own risk.

select a. * from upr00501 a left outer join 
(select payrcord, employid from UPR00400) b on
A.employid = B.employid

where A. bsdoncde not in (select B.PAYRCORD  from UPR00400 B)

___

delete  a from upr00501 a left outer join 

(select payrcord, employid from UPR00400) b on

A.employid = B.employid

where A. bsdoncde not in (select B.PAYRCORD  from UPR00400 B)

 - You could run the below index in SQL against the company DB…but usually this does not change the results.
This will only help if SQL for some reason was using the incorrect index to cumulate the data and usually it is already using this index.
CREATE INDEX [Performance1_UPR30300] ON [dbo].[UPR30300] ([EMPLOYID], [PYRLRTYP], [PAYROLCD], [YEAR1], [CHEKDATE], [DEX_ROW_ID]) ON [PRIMARY]

8. The SUTA report is generated on the fly, the data pulls from the URP30300 transaction history table.
Sample script to view information, you can also print the employee pay history report.  Reports | Payroll | History.  Do not pull SUTA information from the Payroll Summary SmartList.  This is not accurate data, nor where the SUTA report pulls from.

SELECT SUTASTAT, SBJTFUTA, WRKRCOMP, * FROM UPR30300 WHERE PYRLRTYP='1' AND YEAR1='2019'


9. The SUTA report does not do well when you run it with dates that cross years, you may get some goofy numbers, due to maximums, etc.
I would not recommend it.

10. Missed a SUTA state on a pay run, not a problem, you can easily add this.  Cards | Payroll | Pay code , pull up the employee and pay code, click the history button, you can expand and edit the Workers Comp, FUTA and SUTA state in this window.  If it is not available, check your options in Payroll Setup to edit financial fields.

11. You may receive an error message similar too:  FUTA, SUTA, or Worker's compensation posting is still in progress, when really it is not.  This could happen due to a user crash during running of the process or something was hung up.  To remove the record from the table, run the following script against the company that is having the above error. 
DELETE UPR10400

Log back into the company and you can try to run the report again, if it posted to General Ledger prior, it will post again if you mark the box to post liabilities.

12. How does your SUTA State default?  When you key in a payroll transaction, we will pull the SUTA state from the pay code for that employee, you can then edit the transaction to change the SUTA state prior to pay run.  If you change the SUTA state under Cards | Payroll | Employee or change the SUTA state on a Class and prompt to roll down, do not "assume" it will roll down to all the pay codes as it does not.  That is a "default" only for when you assign pay codes.  Some customers have created a trigger from the UPR00100 to always update the UPR00400 when a SUTA state is changed, you can always reach out to me for a sample of it if you need.

13. Payroll Manual Check Adjustments affecting SUTA report and SUTA Posting Journal difference.
It would be recommended if you need to make adjustments with manual checks, meaning positive and negative reallocation and no affect to gross or net wages, that you do not include the SUTA states on these adjustment transactions.  Depending on when an employee maxes out on SUTA wages or if there even was wages for the adjustment period, we see this cause the SUTA Report to be different amounts from the SUTA Posting Journal.  Refer to step 8 on editing SUTA states if you need to remove it from the transaction.

14. Multiple SUTA States
When you have an employee that may have multiple SUTA states, there is an option under Tools | Setup | Payroll | Unemployment tax - Include Previous State Wage.  If the maximums between the states are similar such as 8,000 and 7,000 you will not see this issue.  The problem comes into play when you have a state with a maximum of 8,000 and then another state with a maximum of 18,000.  You mark Include Previous state wages but of what?  We do not track that ND wages were used for SD maximum as well, it can get really tricky.  What I typically see work and would recommend is do not mark that box for every state. What we should do is only mark that box on your "highest" maximum state.  Then SUTA seems to like that setup and run correctly.
Remember your benefits and deductions may come into play in this area too and if you have multiple states, they will be pro-rated across the different states for that employee.

15. SUTA does not play well with Negatives wages.
What a conundrum is all I have to say about negative wages.  FUTA report will run fine with them, but SUTA not so much.
In past years, we have made some code changes around negatives, but there are still a couple of gaps, that typically you would not see, but wanted to call them out if you run into them.
Here are some tips for fixing your SUTA if you have negative wages.
-You cannot have just negative wages in a month for SUTA, SUTA needs to see some positive figure to calculate against the negative.  So if for some reason, we have just negative wages for an employee in the month, they will be off, we should try to have the void or negative entered in a month with positive wages.  In SQL you could always play with the check date (UPR30300) to finagle it to work if you just have one off, if for example a VOID happened in the wrong month.  Remove SUTA state is another option, from the edit window listed in #8, but I'm guessing most of the time, you need that on there.

-When SUTA runs it sorts a lot by check date, name of pay code.  If we have negatives, we always want them before or at the beginning of the month and also the alphabet.  If you are going to continually enter negative pay for whatever reason, I would consider using a pay code named something alphabetically before your positive pay code.  If you need to rename a pay code you can always look at the Utility under Tools | Utility | Payroll | Pay code modifier.  A good rule of thumb if you have a negative, if Void or Manual check it is best to put that negative in the same month the positive happened.

- When you are working with negatives, as stated in step #10, we see this cause the SUTA Report to be different amounts from the SUTA Posting Journal maybe a penny or two.  You may also see the reports are off by the amount of tax associated with negative wages.

You are now a certified expert in SUTA reports, Congratulations,

Terry Heley, Microsoft