Close
Enter your
text here
SpinifexIT Happy new year it is

Happy New Year! Or Is It…

Happy New Year! Or Is It… 1024 512 SpinifexIT

    It’s a familiar refrain in payroll departments across North America — year-end processing is just no fun! So why does it have to be so difficult?  In this article, we will explore the common headaches, and how to nip them in the bud – targeting those organizations that run SAP payroll systems.

    To start the conversation, I will first provide some pointers regarding wage type configuration.  If you create new wage types during the year and then do not realize until year-end that you did not configure the taxation correctly, well that can be a big problem.  Or perhaps it’s not a new wage type that’s the issue, but existing ones because a tax authority has changed regulations and you needed to change your configuration accordingly…but failed to do so.  

    The second item concerns issues with your Tax Calculations – those scenarios where taxes are not computing correctly, and you end up with out-of-balance cases or taxes stopping at the wrong ceilings.  These are all things that you want to catch during the year, right away, not at year-end.

    The third topic we will discuss is Employee Master Data – for example, ensuring new employees have supplied valid social security or social insurance numbers, or that employees who moved during the year have gone through the appropriate steps to have their addresses updated.

    And finally, those year-end manual adjustments; items like noncash benefits that need added to employee YTD taxable amounts, either using infotype 221 or maybe just by making entries directly into SAP’s US Tax Reporter module.

    So now let’s take a deeper dive into each of those areas.  

    Wage Type Configuration

    Whoever in your organization that is responsible for creating wage types – which might be you – is no doubt very familiar with table T512W.  Cumulations, evaluation classes, and processing classes are all a part of that configuration – and I have listed below for you the processing classes that have an impact on how wage types are taxed (in the US) plus a couple of cumulation classes to be aware of. So, at a minimum, I would suggest your wage type configuration script include these items.

        • PC 64 Alternate Formula indicator
        • PC 65 415 limit category
        • PC 67 Work Tax Proration
        • PC 68 Payment type for tax calculation
        • PC 69 Taxable/nontaxable contribution
        • PC 70 Work Tax Proration (salaried)
        • PC 71 Wage Type Tax Classification (This one is critical)
        • Cumulation /102 (401k wages)
        • Cumulation /114 BSI Base Wages

    For Canadian payrolls, the specifics are a little different; below are the tax-related wage type configuration items I suggest staying on top of:

        • PC 52 Cumulation into gross WTs for Workers Compensation
        • PC 65 Definition of Earnings subject to Health Tax
        • PC 69 Definition of Workers Compensation assessable earnings
        • PC 72 Derivation of GST and other sales tax for income tax
        • PC 84 Definition of PPIP Insurable Earnings
        • Taxable Wage Cumulation WTs:  /102, /103, 104, 105, /112, /113, /118, /119, /120, /121, /122, /130, /131, /132, /140, /141, /142, /152, /153, /154, /158, /160, /161, /162, /163, /164,

    I would also propose that whatever mechanism you use to request a configuration transport be moved through the landscape, that it require the attachment of a test matrix.  Even well-qualified super users doing the config should be required to test their changes before implementing into production.

    Along with that, I recommend some sort of signature approval be required.  This may mean something different to you as compared to other organizations, depending on how your SAP support teams are structured, but there should be some individual required to review and provide signoff.

    Finally – perform regression testing for any changes made – do not fall into the trap of just testing for the expected changes.  And when I say regression testing, here is what I mean:  Run your payroll process prior to the change, followed by a report with the pertinent results, then apply the changes; followed by repeating the process so you can compare before and after results.  And make sure your regression test population – if not a full employee population – contains a good cross-section of different employee types, work schedules, and tax authorities.

    For my final recommendation regarding wage type configuration – we all understand that sometimes you need to adjust configuration due to outside forces – like a tax authority creating a new regulation regarding certain types of employee payments.  To keep on top of any changes like that which could affect your configuration, here are a few suggestions:

    1. Maintain a membership in organizations such as the American Payroll Association or the similar Canada Payroll Association.  That will give you access to website announcements regarding tax reg changes, plus the opportunity to attend both local and national chapter conferences.
    2. Another way to keep up is to subscribe to any mailing lists deployed by various tax authorities, which will allow you to have information pushed out to you instead of needing to remember to go check for updated info all on your own.
    3. And last — periodically reviewing your configuration in the system is always a good idea.  Reviewing your SAP US Tax Model configuration (tables T5ute/y/m) in addition to the wage type configuration I mentioned above, just every so often, is a good idea to make sure nothing has slipped by you.

    Tax Calculations

    In this area, there are a few periodic audits I would suggest doing, throughout the year, starting with a review of your Social Security, Medicare, FUTA & SUTA tax results (for the US) and the Canadian counterparts of CPP/QPP/EI/QPIP/PPIP.  For instance, compare the Employee Withholding and Employer match amounts to see if they are in sync; plus perform tests to determine if the actual tax amounts recorded equal the taxable wages multiplied by their respective rates.

    In addition to these checks, don’t forget to verify the accurate calculation of the additional US Medicare surtax for those people earning over $200K per year, and confirm that all taxes with ceilings (e.g. CPP/QPP/EI, US Social Security, US FUTA/SUTA) are stopping at the appropriate maximums for the year.

    And finally – there are two tables that are maintained in SAP regarding US State Unemployment rates and ceilings – those being tables BTXRATE and T5UTX, plus the same data is entered directly into the BSI software application.  You will want to make sure and verify that the values in all those places are in sync with each other.  From a Canadian perspective, constants used in the tax calculations are stored in tables T511K and T5KTC (as updated every year by SAP via HRSPs) – be sure to confirm your system has been updated timely every year.

    Some more best practices to head off tax calculation issues are  – if you use SAP’s Tax Reporter module for generating US forms such as W2’s, 941’s, and Unemployment reports you should be generating test runs for these forms, on a monthly or quarterly basis, and when you do, always check the log that is produced for any errors or warning messages. I also suggest you periodically perform “three way” reconciliations between Tax Reporter, general ledger postings, and payroll cluster results.  

    In a similar manner, you can run the Canadian T4 program, RPCYERK0, multiple times during the year in ‘test’ mode, confirming results and watching for error messages and employee rejections.  

    Employee Master Data

    Moving to Employee Master Data, let’s cover some of the best practices you should be following as you perform some audits.

    First off, audit those employees claiming tax exemption – perhaps even contacting those employees to verify the data is correct

    Next, I would suggest auditing resident, work, and unemployment tax authorities – info types 207, 208 and 209 for the US, and info types 461, 462, 463, 464 for Canada – in a few different ways:

    1. Compared to the employee’s address (SAP info type 6)
    2. Compared to other system data that might indicate location, like perhaps personnel area or cost center
    3. Compare the values across the info types to each other – obviously there are legitimate reasons as to why for some organizations they do not have to agree – but know what would make sense for your employee population and look for that.

    And finally – audit the SSN/SIN’s found on info type 2, to make sure all employees have valid numbers.

    Taking it a step further – extend your audit process to include contacting your employees to have them validate the data you have on them, such as SSN/SIN, addresses, tax exempt statuses. And of course, include in your notifications the instructions for getting any incorrect data corrected – and if employees can correct it themselves via an ESS portal, all the better!

    Manual Adjustments

    The last topic mentioned in our opening discussion was Manual Adjustments.  I have a few best practices to share, starting with…. JUST DON’T DO THEM 😊

    But since that’s probably not feasible…..do incorporate as many adjustments you can into your regular payrolls to minimize the number of off-cycles that are necessary, and reconcile the info type 221’s that get created versus the ones picked up and actually processed in payroll – make sure there aren’t any yearend adjustments entered but not pushed all the way through.

    As much as possible, I strongly recommend you work with your stake holders to limit the need for these adjustments – good luck with that, right?  But if you can convince the business units to adopt practices that are payroll process friendly, it will relieve some of the headache for you.

    Here’s one example of a business practice you can influence – consider using fiscal year cutoffs rather than calendar years when possible, to alleviate having all the work come down at year end.  For example, I used to work at a company where the employees all had the use of a company vehicle. Those employees had to log any personal use of the car and provide that data to us annually so that an imputed value could be computed and added to their payroll results.  Company policy set the year for those accumulations to be Dec 1 through Nov 30 – giving the payroll department time to record the adjustments during December, instead of a last-minute rush in January.

    And finally, if you use US Tax Reporter, you know there is an option to directly enter in adjustments, via manual table entries, forcing adjustments onto the forms – like W2’s – without ever flowing through either master data or payroll calculation.  It’s a great tool and has its uses – but I would suggest doing so sparingly and keep your documentation to justify the entries made and provide an audit trail.

    So where does SpinifexIT come in?

    Now that we have walked through some of the biggest yearend challenges and offered up some suggestions for meeting those challenges, I of course want to introduce you to a Spinifex product that was built to handle these issues very efficiently.  That product is called Easy Balance and we have both a US and a Canadian version.  

    Easy Balance is basically a suite of reports specifically geared towards payroll tax audits and validations.

    For example, Easy Balance includes reports that audit for undesired negative results, like for instance in tax amounts, which will result in an error when running your W2’s or T4’s.  Easy Balance reports deliver results at a high level as well as including the ability to drill down into specific numbers, to easily locate what exactly is creating an issue. Other functionality delivered by EB allows you to validate the configuration of your wage types, in terms of how their taxability has been set up, addressing those wage type concerns mentioned earlier in this discussion.

    Easy Balance Functions can be categorized under these four major topics –

    1. Validation of tax-related configuration
    2. Pre-delivered exception reports – for example, whose fica wage, multiplied by .062, does NOT equal the tax withheld?  Or, for Canada, employees whose province for health tax purposes does not agree with their province of employment.
    3. Reconciliation between US Tax Reporter, Payroll results, and even the General Ledger postings
    4. Correspondence, like the Address/SSN verification just mentioned, as well as documents explaining US W2 results to the employees

    Regardless of your reporting tool of choice, the suggestions we have mentioned today – as implemented at check points all throughout the year – will hopefully ease some of the year-end stress experienced by your payroll department.  And if you would like to utilize a reporting tool built especially for these needs, my final recommendation is that you check out Easy Balance!

    Your SpinifexIT representative will be happy to demonstrate the features of the product as part of a no-cost demonstration, so that you can see for yourself what we can do to help you have a “Happy New Year”.

    Share this post
      You might also like