Close
Enter your
text here

reconciliation

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”.

Spinifexit blog reconciling single touch payroll
Reconciling Single Touch Payroll
 Reconciling Single Touch Payroll 1024 512 SpinifexIT

Reconciliation Considerations

Over the last 15 years, one of my key roles included working with customers in relationship to the Payment Summary process, and in particular, the reconciliation and additional reporting of their Payment Summary data. Just about every SAP customer has had a process to validate the Payment Summary figures. Most of them do this at year end but a large portion of our customers also reconcile on a per pay period basis.

With STP, you may ask the question of whether there is still a need for Reconciliation, and how you should do this.

The short answer is Yes, there is still the need for Reconciliation to be done.

As the STP solution is still based on Wagetype Configuration and Employee Data (Very similar to Payment Summaries) and given that there is now the need for Transmission to the ATO on a weekly basis, there is still the need for Reconciliation.

To understand this need, the following declaration is part of the new STP process, and as you can see, there is the need to declare that the data is correct prior to transmitting this through to the ATO. 

Most customers I have worked with over the years would be reluctant to just sign off the transmission file without any sort of validation. 

A simple example of what could go wrong is that if a wagetype is not flagged for STP, then it will not be reported to the ATO. Without some form of Reconciliation this can go unnoticed.

The following will give you some areas of reconciliation that we believe will be required:

I Go Live

Initially, during Go Live, there is the need to validate the STP Process. This is not only to check that the support packs have been loaded correctly, it also finds out if your configuration is completely setup and if this process works with your own employee data. 

Some of the areas that you would want to have validation checks are as follows:

  • Verify the STP Mid Year Go Live conversion of the existing Payroll Results over to the new Clusters
  • Validate that the Payroll Run is calculating and updating the STP Cluster tables correctly
  • Check that the STP Reporting process that takes the payroll cluster information (From the new ACRT, SETP and SABN tables) and creates the data for transmission to the ATO

The best approach I can suggest is to ensure that your Payment Summary Reconciliation is up to date so you can compare the original Payment Summary values to the STP values (in the STP tables). NOTE: This is not a 1 to 1 mapping, but should give you an indication that the STP configuration and calculations are correct.

II Normal Pay Runs

Once you have gone live, you would want to have a process to check your STP figures back to what the employee has been paid. Keep in mind that even if everything balances at Go Live, during the normal year, there can be new configuration put into your system, new wagetypes used during payroll, and new scenarios too. (eg. You may have a retrospective pay over the last 2 years that might not report correctly)

Much like Payment Summaries, when customers need to print the final year statements, there is the need to verify the figures in the STP file. It is so easy to miss a wagetype, have a wagetype that is configured to be included in the wrong STP catagory or not flagged for inclusion in STP reporting.

In order to reconcile, most customers have a process where they want to validate the Payments made to the Employee at leave match to what is reported during the STP processing.

Some examples of the reconciliation process include:

Verifying the STP Figures

  • Identifying wagetypes that are paid to the employee (running wagetype reporter is a common process to get these)
  • Mapping these to the STP payments calculated – You might download the STP report data to an excel file
  • Including STP Override values

This is quite a manual process however, as there is the need to keep registers of what wagetypes have been paid to the employee, and build up an extensive Excel Spreadsheet or create other processes.

Either way you reconcile, it is important to have a method to verify your STP figures and of course, the simpler you can make it, the less overhead to you on a per pay period process.

The following items are some things I would recommend when looking to create a reconciliation process.

  1. Think about the aim here and ensure you are following a smart repeatable process
  2. Keep in mind that you need to do this for every pay period so try to make it an easy process
  3. Consider all of your payroll areas and their various frequencies
  4. Remember, employees might transfer payroll areas so make sure your process will cater for this
  5. If you have multiple ABN’s then ensure your process considers this
  6. Ensure that you include terminated employees
  7. Decide on whether you will include the ability to override figures and include this in your process

This is an area that SpinifexIT has worked in for many years, and as part of the new STP solution, we have altered our Easy Payment Summary Reconciliation Solution to also cater for STP.

Meet Easy STP

Some of the areas our Easy STP solution supports include:

  • Configuration Validation – Check the STP Wagetype Configuration and Report ABN Configuration
  • Pre Checking of Master Data – Checks against the employee to ensure data is correct prior to creating STP file
  • Reconciliation Reports – Reconciliation reports for go live (Checking of the STP conversion) and also ongoing Pay by Pay Reconciliation Reports
  • Reporting on STP – Further reports are delivered to report the STP and help reconcile across the entire company
  • Analysis of STP values – Reporting at Employee level with drill down into how the STP values are calculated and from where (Includes overrides)

Existing Easy Payment Summaries customers will receive our Easy STP solution as part of the normal upgrade of our solutions.

Summary

SAP’s STP solution will be released on the 11th October 2018. Now is the time for you to start to plan for your solution’s upgrade and implementation Whilst as a SAP customer, you do have a deferral until May of 2019, we would not recommend waiting too long as there will be quite a lot of work to do.

As part of this preparation, we recommend that you discuss with SAP the option to use their SAP Cloud Platform Integration and also ensure that you involve your technical teams in regards to the SAP HR Support pack upgrade.

For many customers, this also is a large project as upgrading the HR Support packs can take in much new functionality on top of the STP solution, so testing can be quite extensive to ensure that there is no impact on your production payroll.

I will continue to create blogs such as this during the next 6 months. Please visit our STP page on the SpinifexIT website to keep updated with any relevant information.