‘When paid’ solution for Variable payments – South Africa payroll

Introduction:

‘When paid’ solution for Variable payments – South Africa: In South Africa payroll, payments are made retrospectively but reported and taxed in the period they are accrued (when earned principle). However, there are payments like Overtime which are not realized or calculated before the payroll run for the period. Hence, these amounts are paid in the next period, but reported and taxed in the previous period. Incase, there is a change in tax year these amounts are reported in one tax year and paid in another tax year. This leads to incorrect calculation of interest and penalties from South African Revenue Service (SARS).

 

Illustration:

The employer paid the salary of February 2014 without the overtime amount of R1000 that was due because the amount was not calculated while the regular payroll run of February 2014. Thus R1000 is calculated retrospectively FOR February 2014 and paid to the employee IN March 2014. As you know, the tax year 2014 would close on 28th February 2014 and new tax year 2015 starts on 01.March.2014. Hence, currently with ‘when earned’ principle R1000 would get reported in the old tax year and paid in new tax year.

However, after the solution is activated the tax calculation will be based on tax rates of March (new tax year) and also reported in the March 2014 hence in the new tax year i.e when its paid.

 

The time of taxing and reporting of the payments has changed i.e. now they have to be reported in the period they are paid (in March 2014) and not in period they are accrued (in February 2014).

 

This legal change is applicable for the variable payments which are included: Overtime, Leave encashment, Bonus, Travel Reimbursements and Commission.

 

Solution:

SARS codes that are impacted by the legal change are:

 

The solution was delivered in multiple phases:

 

Phase 1:

This phase included generation of technical wage types that will be used in the next phase of “When paid” solution.  These changes did not impact the processing of the payroll. However, the wage types delivered via this note are critical for calculations after implementing the next phase of the solution.

The wage types which are delivered through this phase are classified as following:

1. Super / Original wage type: This wage type holds the original amount of the technical wagetype that is processed or outflows from that period.
2. Base wage type: This wagetype was created to capture the split of the technical wagetype. The value of the base wagetype is same as the technical wagetype.
3. Outflow wage type: This wagetype have the difference amount that has to be carried forward to the current period.
4. Inflow wage type: This wage type is generated in the IN period (current period) and hold the difference amounts that are carried into the current period from previous periods retros happening in this period.

Note: Outflow and Inflow wage types are generated only after implementing the next phase of the solution. The data displayed below is for explanation purpose only.

To understand the above definition, let’s consider an example where the employee had commission of R1000 in period 01 and in the period 02 the commission amount was changed from R1000 to R2000 retrospectively.

Phase 2:

This phase has the process of generating the retro wage types (Outflow and Inflow wage types). The difference amount is carried forward to the current period for reporting and taxation purpose.

 

The solution provided would work once the switch is activated. Refer to SAP Note 1821617 for the steps  to activate the solution.

 

Payroll Function WORET:

This payroll function reads the previous payroll result and stores it into an internal table which works like a temporary old results table.

Note:  This function is processed in the standard sub schema WMAP.

 

Payroll Function WINFL:

This function has different processing based on the first two parameters passed to the function:

1st Parameter (ACTIO) – There are 3 values that can be passed as first parameter to the function-

1. a. OUT – Outflow wage types are generated when this parameter is used and this value of the parameter is used in the FOR period. Outflow is generated by finding the difference of the Super wage type in the current (IT) and old result tables. Once the difference is calculated the technical wage type is restored to its original value based on the base wage type in original period.
2. b. IN – Inflow wage types are generated when this parameter is passed and this value of the parameter is used in the IN period. The wage type amount is cumulative of the outflow wage types generated in the previous FOR periods.
3. c. BASE – The inflow wage types are added to the technical wage types, before the further processing takes place.

Note: The wage types that are generated based on cumulation class are generated by checking the corresponding cumulation class checked for the inflow wage type. This function is not used for components where the inflow wagetypes are cumulated into the technical wagetype using cumulation class.

1. d. CLR: The intermediate internal table (SDT) which is used for calculating the difference amount (Outflow / Inflow wage type) is cleared using the parameter.

2nd Parameter (BASE) – In this parameter we pass the component that is processed. This parameter works along with the first parameter and the corresponding wage types like outflow and inflow wage types are generated.  The super and base wage types that are used to calculate the difference and restore the original value are determined from the table T5WRTW (View V_T5WRTW)

Phase 3: ( in Pilot testing)

In this phase, changes are delivered for mainly two scenarios:

1. PAYE change scenario

2. Termination scenario

Prerequisite:

Annual tax calculation across PAYE reference number – SAP Note 1914079

For a PAYE change scenario with in the year, the tax calculation is currently calculated considering the taxable income in the current PAYE split as YTD. Then at the end of the year or during termination the tax is re-calculated for year and appropriate amount increase or refund of tax takes place. However, with the phase out of SITE the calculation of the tax every month has to take place considering the YTD taxable income till date even if it belonged to another PAYE number.

 

Tax split based UIF calculation – SAP Note 1915273 (In pilot testing)

UIF calculation currently in the system is based on the wpbp and sv split. However, with the variable payments scenarios where there are payments carried forward across multiple PAYEs (tax splits) its necessary to differentiate UIF basis which is are created from the retro payments based on tax splits. Hence, additionally tax splits are added to the UIF basis and contributions are calculated for each of the tax splits.

Note: Frequently issues is raised that UIF is not calculated in my system after implementing this change. In such a scenario, check if /102 has cntr2 before WUPM UIF function is called. If not please check the following:

a. Check if the manual steps mentioned in the note are performed

b. if implemented, there could be a custom rule which would be eliminating the split. Need to resolve the same.

‘When paid’ solution for Variable payments

1. PAYE change scenario:

 

Overview
If there is a retrospective payment of any of the variable pay from another PAYE the amount and statutory contributions are to reported in the respective PAYE.

For example: If the employee was moved from PAYE A to PAYE B in the month of June. In July payroll if there is a retrospective payment of Bonus of 1000 R for month of March, then the amount is carried forward to the July and tax in July. However it would be reported in tax split for PAYE A.

 

With-in tax year:

Incase the employee changes PAYE within the tax year then there are annual tax splits created in the CST table. This signifies that there would be multiple IRP5 generated for the employee, one for each split. If an employees moves from PAYE A to PAYE B in month of June 2013 and CST cluster would have tax splits for the year 2013 as follows:

If there is a retrospective payment of Bonus of R10000 in month of July for the month of March when the employee belonged to the PAYE A. The amount is carried forward to the month of July and monthly split in July is created in ST table with a new value which is assigned to annual tax split of PAYE A. The payment carried forward in the current month is attached to the monthly tax split in RT table.

ST table for month of July

RT table for month of July

Across tax year:

If the employee is transfer from PAYE A to B across the tax year and there is a retrospective variable payment then the amount is carried forward to the current month a new annual split is created in CST table.

For example: An employee is transferred across tax year from PAYE A to B on 01.03.2014 (i.e.period 01 2015). There is a retrospective payment of R10000 for month of febraury (period 12 2014) then the amount is carried forward to current month along with PAYE details. Incase, there is no annual split in CST for the PAYE tax year 2015 it creates a new tax split in 2015 for PAYE A.

CST for tax year 2014 – in February 2014 ( 12 2014)

CST for tax year 2015 – in March 2014 ( 01 2015)

The new yearly split is assigned to the monthly split similar to the processing explained under section Within year.

Note:

1. CST and ST tables is just an extract of the actual table for explanation. There are more fields in the table

2. For example, tax rate of 10% is considered while calculating tax.

2. Termination

A retrospective payments for an employee who is terminated and the payment is carried forward to the period employee is inactive reported the amount under 00 split. After the change, this amount is taxed in the current month however its reported under the tax split to which the payment belongs where the employee was active.

Tax calculation for a terminated employee cannot take place as the employee does not have any other income and since the employee is not part of the organization in future as well hence the payment cannot be projected for the future periods. Therefore, the tax calculation needs to take place as the final payment using the payroll function SITE. Hence, the tax on retrospective payments for terminated employee takes place in the using SITE run.

Import Notes:

FAQ Note: 1822757