As I reflect on year and the calls we took, it was an overall success.  ACA was still a big topic, but not as prominent as the year before as more knew what to do because of the work that was done last year. But this year over last it seemed like we got questions about state wages and why they do not match federal.  We really do not have this documented well so I thought this was in order.

Here are some common items about Federal vs State wage that may help you, I would consider verifying this each quarter instead of waiting till end of year, it will be easier to catch an issue.

1. Deductions could be TSA's from federal but the state box was unmarked or setup incorrectly from the start.  Here is a GREAT KB on how items can get off and impact around wages.

2. If a pay code at one point in time was not subject to state wage, even if it is marked now, we capture this each time a payroll is processed.

3. If an employee works in multiple states, this could cause a difference from federal to state wage.  Also for the TSA deductions with multiple states, they will be pro-rated across the different states at the time of the payroll.

4. When you process payroll, if a state tax was not entered on the transaction (or imported incorrectly) and you missed the calculate checks error "Pay was subject to state tax but no state tax was specified", ignoring that error will cause issues at year end!!

5. Cards | Payroll | Tax, if there is no state tax listed here for default, it will not be withheld nor be added to wages.

6. Manual checks, if you did a manual check and forgot to update wages (state, FICA, local, etc.) it will cause issues.  Here is a great BLOG Andrea did about Manual checks, awesome reference of all the fields in manual checks.  You can run a script like below to look at manual checks and see if wages were accidently forgotten, happens way to often when adjusting taxes.
FICA/Federal
select fdwgpyrn, ficasswp, ficamwgp,* from UPR30100 where year1='2017' AND auctrlcd like 'UPRMC%' order by chekdate
State
select payrolcd, uprtrxam, TXBLWAGS, * from UPR30300 where PYRLRTYP='4' and year1='2017' AND auctrlcd like 'UPRMC%' order by chekdate

7.   In my extended life time, I have seen a couple cases where if a deduction frequency for some reason is set to zero, state wages do not update.  See my BLOG on scripts to check and see if you have this problem with some employees.  Usually if it is zero you cannot run payroll with the error, but rare things happen!!

8.  If by accident an employee was setup with a state tax of CA and Ca, it will create two records and then cause you issues.  You can easily find this in the UPR30301 or UPR30300 tables, payroll type of 4 = state tax.

select payrolcd, * from UPR30300 where PYRLRTYP='4'

select payrolcd, * from UPR30301 where PYRLRTYP='4'

When I work with customers around this issue here is a tip I like to share.  Honestly it is hard to catch the above as we do not show you all wages at the time of the calculate checks report, so these items get missed.  BUT, there is a trick, we can go to Tools | Setup | Posting | Posting, choose Series of Payroll and Origin of Computer Checks, if you have the HRM Solution Series installed (Payroll Extensions) you will see reports such as Benefit Register - PPR.  PPR stands for print before post.  YES you can get all your posting reports BEFORE you post to catch lots of errors.  The report I want to draw your attention too is the
Distribution Report Detail - PPR and Distribution Report Summary- PPR
Turn those reports on and run them to screen or save them to a file (they may get large, I would not print them)  the report will kick out after your calculate checks.
These reports will show you TAXABLE WAGES...exactly what you want.  This way you can spot check employees and make sure the payroll information is pristine for printing of checks.  Customers like these reports so much we are looking in GP 2018 to have them available to print as a reprint report, just like your other reprint posting journals.  That is a huge for our customers to see the taxable wages at any given prior pay period easily!

Have fun reconciling your wages, monthly-quarterly is always best practice vs year end

Terry Heley
Microsoft