Migrating to a new payroll system like SAP Payroll can be a nightmare! Between all the system, infrastructure, and functional tasks to complete, it can be quite challenging.
An SAP Payroll project’s complexity is typically directly proportional to the number of employees in the organization, and inversely proportional to the time available to migrate. Payroll is a system that directly affects finance—hence, accountants are involved in payroll implementations bright and early!
There are ten accounts that young accountants are constantly reconciling after go-live of a payroll system like SAP Payroll. These are also the same accounts that experienced controllers have nightmares about! In this blog post, we will examine these accounts, understand their complexities, and help you prepare for these challenges. The 10 accounts are:
- Net Pay
- Withholding Taxes
- Local Taxes
- Employer paid taxes
- Accrued incentives
- Casualty and Liability Insurance
- Company Stock contributions
- Accrued vacation
Net pay takes the number one spot for a reason. This is where money goes out the door from the company; hence, there are very stringent policies and procedures that govern this activity. It is not enough to just test that the payroll system calculates the net pay correctly. After calculation, there are steps to send the calculated amounts to the bank. Typically, this is done through a file that the bank receives. There are deadlines and procedures on the bank end of things that restrict the timing and processes of monetizing the employee accounts. Treasury is interested in receiving a notification about how many funds are needed to be transferred, so that the bank can find money to fund the employee accounts or request other banks to fund them. The pain does not stop there. Treasury is also interested in receiving a bank statement so that they can verify that what was promised is actually transferred from the company checking account.
A complication that typically arises with this account is the payment timing for terminated employees. Some states in the U.S. require employees to be paid their due on the same day of their termination. This breaks several norms in the well-oiled process of paying employees at the end of a biweekly pay cycle, as is the norm in US, or a monthly cycle in Europe. Banks typically require 48 hours to transfer funds. Therefore, paying through a bank transfer is usually not a great option—some banks do provide same day transfer, but at a much higher cost. In this case, companies will likely prefer to pay these employees by check. Since checks have a totally different process, notification and control requirements get complicated.
Add to this the fact that some employees may owe money to the organization, because they may have been paid in advance, or paid a larger amount than they earned due to a clerical error in entering their master data. Keeping track of this money is very challenging. So much so, that some companies decide to forgive and forget these amounts, since monitoring them is more expensive than recovery costs. But forgiving is also not easy—because governments consider that as extra earnings that have been given to the worker, and expects tax to be paid on it from the employer.
Withholding taxes are taxes that are due from an employee but must be withheld from their pay by the employer and deposited to the government.
Tax rates change, and sometimes retroactively. This causes the amounts deposited to be revised. Changes to tax calculations can have a domino effect on net pay controls.
Even assuming that there are no rate changes, it is a complex process to keep track of overall taxes withheld for all employees, and to deposit the entire amount in a single payment to the government treasury. Since this is an outgoing amount from the bank, there are controls around balancing tax withheld vs. tax paid that is a joint exercise between the payroll department and accounts payable. Then there are also specific filing requirements from the income tax department that need to be part of the triangle of reconciliation.
SAP Payroll provides only one technical wage type (/401) for withholding taxes. This creates a further complication with reconciling taxes, because the taxes need to be deposited for multiple authorities at central, state, and local levels.
Of course, there are ways to get this information. The tax authority (TAXAUTH) is a field that faithfully tracks the beneficiary of the tax collection in the SAP Payroll system. But this is not available for reporting in the standard wage type reporter (PC00_M10_CWTR). There is a standard reconciliation report (transaction code PC00_M10_REC) for this job. But with high volumes, this report can be very slow to run.
Using the third party remittance interface relieves some of the complications, as there are separate accounting entries to keep track of what is collected versus what is sent to accounts payable for depositing to the local authorities. But if a company chooses to use a different tax payment system, this reconciliation must be done outside SAP, thus creating complications around file transfers and acknowledgements.
Employer Paid Taxes
Employer paid taxes are complicated because this does not affect net pay of the employee. All the processes mentioned above cannot bring salvation to reconciling this account. The balancing of this entity remains very obscure in the hands of people who live and breathe tax rates applicable for each locality or state tax, and it requires a very thorough understanding of tax legislation for that region. As with all other taxes, the rates change, and what is more interesting is that there are ceilings. Ceilings are very attractive to organizations because they can stop paying after the ceiling is reached. But this itself is very difficult to keep track of, as it is not necessarily at an employee level (such as the occupational tax in Nevada) and is subject to deductions that a company can take based on the health and welfare subsidies that they provide to the employee.
Incentives are part of an employee’s earnings—something that every worker looks forward to as an annual reward for doing a good job.
What makes them complex from an accounting viewpoint is that it is not an amount that can be accurately calculated in advance. The parameters around incentives are not driven by the worker’s annual or hourly rate of compensation. Often an incentive is tied to the company’s overall performance, which is not available until the profit and loss accounts are balanced at the end of the financial year. But the company must be prepared to fund this by setting this money aside in their books. Most companies prefer to show this in advance using some sort of approximation that estimates this payment. This is called accrued income. This accrual must then be balanced with the actual income that is given to the employee when the bonuses are declared. Since the accrual is at a higher level, the reconciliation requires a different technique to ensure that the differences between actuals and estimates are balanced.
Add to this the complication of the taxes owed due to this bonus and the requirement that some of these taxes need to be paid “when earned” according to legislation of that country. “When earned” is often interpreted as “throughout the year” as it reflects the employee’s performance in a continuous period of time. Hence what makes this account most complicated is the timing of bonus payment vs. the timing of accrual, and the timing of when the employer-paid taxes are considered due.
Casualty and Liability Insurance
This is a mixture of company-paid and employee-paid amounts. The accounts for these must be reviewed by the benefits department, as there are multiple agencies that provide these services. One major complication arises when an employee goes on short- or long-term leave where part of it is unpaid. The employee expects the insurance coverage to continue when they are on leave. But the funding stops because the calculation is dependent on the payroll that is computed for the employee. Often the employee makes a separate check payment for continued coverage, which throws another wrench at balancing the receivable vs. the payable.
Garnishments present two important liabilities for the organization: one to the government where a court order must be executed in the manner prescribed, and one to the garnishment beneficiary (the person who receives the money). Keeping track of the balance and how much to deduct is done by the payroll system, but depositing the money to the garnishee is through the finance system. Therefore, there needs to be an error-free link between the payroll and finance systems that provide the amounts that need to be transferred to the garnishment beneficiary.
While some use the third-party remittance submodule of SAP Payroll to transfer the fund requirements to accounts receivable, some companies outsource this service. In both scenarios, the problems tend to occur when the garnishment is in some sort of flux—i.e. either a stop order has come in late or a correction is received from the court for a garnishment that is already active. Both situations present garnishment refunds that cause reconciliation challenges, especially if the refunds are administered outside the payroll system, leaving no trail in SAP Payroll to reconcile.
Company Stock Contributions
When the organization offers an opportunity to own stocks, there are multiple financial scenarios that may occur. Some contributions are deducted every pay period and easy to track. But some organizations offer a percentage of that contribution free of charge to the employee as an added incentive. While both these are added together and transferred to the company that manages such investments for stock orders, the company incentive incurs tax as this is deemed by the government as income. This has an impact on tax accounts and makes reconciliation a bit of a headache.
Finance departments like to keep track of accrued vacation because that money is owed to the employee if the employee decides to leave. Planning for this amount helps finance departments manage the cash flow better. However, this is not easily available from the payroll system as this is not part of the standard calculation of payroll. There is no money being paid to the employee, but rather just a hypothetical liability, should the employee decide to leave tomorrow. This sort of requirement demands customization using the time keeping system to provide accrued amounts to finance or presents the department with manual work.
This is the bulk of the expenditure that gets posted to payroll, as this is the primary component of payment to the employee. However, this expense needs to be tied to the divisions and cost centers that the worker is employed in to accurately deliver the profit and loss accounts for those units. This requires special coding and master data so that these can be reconciled accurately in cost center and profit center accounting.
There are many complications to consider in general ledger posting that arise out of payroll. Successful solutioning for all such scenarios requires careful planning and analysis. One important aspect of this planning is the inclusion of payroll comparison tests that specifically address general ledger accounts. Pay compare tests that compare a test payroll for the entire population with a payroll that was already run in the old system is a common practice to make the new payroll system error free. The system implementors need to consider an extension of this test to post the general ledger transactions from new payroll to the finance system, and compare the transactions with what was posted out of the old system. Doing this task right significantly reduces the risk of accounting nightmares when the new payroll system goes live.