As an employer, you must regularly submit accurate and timely data to your pension scheme. Put simply it sounds a straightforward task for those responsible for Local Government pension returns often it is not the case.
Pension reporting is a matter of serial significance that requires a coordinated and serious application. Inaccurate data and inconsistent approaches can have consequences for your organisation and employees. Yet many organisations cannot say with certainty they are reporting pensions accurately in a timely manner.
Only 45% of employers are providing good data, according to The Pension Regulators Public Service Governance and Administration Survey (May 2017).
Your SAP system can be fine-tuned to meet the ever-demanding requirements of Local Government Pension reporting from legislation and other bodies ultimately providing you with a system that can cut through problems and navigate past issues of data complexity and accuracy.
We will demonstrate how SAP can be formatted to meet any reporting specification, how to ensure we address appropriate collation and calculation of the problem fields and finally how we can interact with third party systems typically used. Furthermore, we show we can build in additional information often deemed too demanding to provide.
I hear you, pension reporting “its complex, it regulatory, its time consuming, demanding of constrained and dwindling resources across a number of departments and it must be accurate”. Indeed.
Bad Data costs
Assumption based on 20.3% contribution for 20000 employees with an average salary at 20,000.
It must be stated the whole gambit of governance and administration duties are vast.
- Reform. Simply being able to embrace the pace of pension reform and the changing definitions of data submissions is a major challenge. The cost of regulatory change is widely accepted as one of the biggest threats to organisations.
For example, Career average regulation imposes new employer duties to provide information for each scheme
Total Pay in the main and 50-50 scheme
Total employee contributions
Total employer contributions
Total additional contribution
- Data Collation: How to manage the collation and transfer of data efficiently. Relying upon paper submission can lead to significant overhead in terms of administration effort. Even most data submitted electronically is often captured initially manually or through a number of sources.
- Data Accuracy: Existing processes tend to rely on the payroll and pension teams team identifying change and submitting the appropriate data to the fund.
- Operational risk: Has all the required data been submitted and was it accurate? Resources are required to provide all the required data across the year.
- Governance: As a result of the Public Service Pension Acts 2013, the importance of quality data I sunder further scrutiny by means of increased governance arrangement. The Pension Regulator can also operate with power to impose fines .The Regulator will be focused on maximising employer compliance with employer duties.
SAP can assist in the collation of data and assist in returning basic data, towards this goal we can assist organisations to provide:
- Annual benefits statements produced on time and accurately
- Employees receive correct information to make decision on their pension choices
- Reduced risk of fines
- Reduced effort in the production of reports
- Reduce effort expended reposing to queries
It has always been possible to attain a basic pension contribution report comprising of employee and employer contributions, the standard SAP pension’s reports available are accurate. But they do not contain the required fields to provide Local Government required data.
SAP has delivered the LGPS reporting wheel.
SAP have delivered monthly and yearly contributions reports based on generic requirements as published by the LGPS. It is not specific to any individual Pension Administration System, so the reports will not exactly meet the needs of any customer. In a nutshell, out the box it won’t meet your requirements, it sounds onerous to modify but we have the capability to deliver a robust reliable solution.
Making the SAP LGPS reporting wheel round
Customer specific file format / Data Interface
The SAP standard interface file format will not meet your requirements. In which case, you can use your own. SAP have delivered appropriate conditions within the reports to facilitate such enablement. It is not the case of being buried under SAP expectations and being burdened with modifying the standard SAP reports but taking advantage of the numerous stops within the SAP reports designed for this purpose. In essence SAP knows to pick up a customer specific defined structure if required.
First you must define your pension reporting field structure which mirrors the definition of your pension administrator
You must use the BADI delivered to take the data from the standard structure to fill your own structure. It is important you thoroughly review the SAP delivery in the first instance to assess the fields to determine which fields can be mapped directly to your structure from the SAP data collection, remember we are not reinventing the wheel as you should leverage as much as possible in order to make reporting possible.
The standard SAP reports contain a lot of difficult information to attain or write succinct code to elicit such as Total Pay in the main and 50-50 schemes throughout the period or year. In essence leverage what you can from the standard report, don’t throw away the baby with the bath water. It is recommend when reviewing you run your report against that of the standard. Within the BADI you can further define code to collect any required fields not available in the standard solutions. It is often cited its difficult in SAP to combine payroll results (PY) with that of Personnel Information data (PA) and this is often the reason for numerous Ad hoc reports within systems but the code here enables such reporting in a fluent manner. It is worth noting LGPS since 2014 (2015) Scotland is typically defined as a when paid solution so the difficulty of assessing in and for reporting periods for pensions results is reduced, if you operate a when earned solution additional effort is required in the collation of results.
In summary, many of the fields will be available from SAP standard but they may not be in the format as required so we need to remap but additional fields can be augmented to enhance your report to meet your pension requirements. A large benefit is your report is contained within standard reporting parameters so you are not constantly searching / updating when faced with new requirements or SAP patching updates.
The generic requirements published on the LGPS website requires employers to provide FINAL PAY Salary. Final Pay being based on the LGPS 2008 definition of pay for the current year. Your final year’s pay when you leave the LGPS will still be used to work out your benefits built up before 1 April 2014.
This is the most complex field on the interface and SAP states “the only reliable way to accurately provide this information is to mimic the solution that is being used for Teachers’ Pension Monthly Data Collection”. That is to derive the amount during payroll (store it in RT) against a wage type delivered for this purpose LGFP “LGPS Final Pay”, so that it can easily picked up by the LGPS End of Year Contributions Report (RPULGPG3). The LGPS End of Year Contributions Report (RPULGPG3) looks at Actual “A” results, so if LGFP has not been populated for a specific employee (or has been created incorrectly) the value can be overwritten by running retro payroll and then re-running the report.
Pre 2014 (2015 Scotland) Full Time Equivalent Pay was defined within each appropriate LGPS pension scheme configured in SAP this had the appropriate configuration to allow factoring up to full time salary but this is no longer valid and assessed during the SAP payroll (function GBLGP). Obviously we cannot simply reinstate pre 2014 functionality but we can emulate it.
SAP has extended the configuration table T5GPBSP_SCH to allow for a Final Pay Scheme Id calculation
For all intent and purposes this definition requires a pension scheme to be defined that has the same settings as your LGPS pension had pre-2014. This new scheme is then defined against any existing LGPS schemes.
The function module GBLGP if relevant will now be capable of producing a Final Pay value as per 2014 changes and this will be stored against the specified wage type, in the example above Wage Type LGFP. This field can now be reported upon. The diagram directly above shows the new groupings that have been reinstated in the pseudo scheme that has been defined. Do note this is a pseudo scheme only.
It is worthy to consider that since 2014 your system will have had new wage types delivered or configured so it it’s not an absolute given that the scheme will calculate the FPS figure for the appropriate factoring groupings so a small review of new or changed wage types should be undertaken to ensure the full time requirement pay is calculating appropriately. Additionally if you previously took advantage of SAP provides BADI’s to modify any calculation it may need turned on again when calculating against the pseudo pension scheme.
The Final Pay derived is triggered if the current payroll period being processed includes one of the “trigger” dates for Final Pay,
a) 31st March (for employees that are active members of LGPS)
b) Ceasing Date (for employees that should to cease active membership) customers should delimit IT0071 accordingly when an employee ceases employment (and therefore scheme membership)
c) Normal Pension Age has been met
Unfortunately, at this point the Final Pay value is not a wholly accurate reflection of the final pay salary calculation required. The value calculated and presented is simply a snapshot of the Full time equivalent pay value at the payroll period. It is very possible this will not satisfy your pension manger or pension’s administration body in respect of annual allowance and annual statements or rather they would desire more.
A brief reminder, the definition of final pay for benefits built up before April 2014 remains the same as it was before the scheme changed. Your final pay is normally the pay in respect of your final year of scheme membership on which you paid contributions, or one of the previous 2 years if this is higher. This remains so from April 2014.
In essence while it may be satisfactory to provide the data as is, i,e once per year (or relevancy) the likelihood is we wish to report the figure based upon the Final pay average over a period of time, typically we have been asked for the average pay for the past year or 365 days. So long as we have the data in SAP we can oblige. At this point we do introduce a small sprinkling of magic dust to allow the standard report we have defined to report this figure, note we always go back to and report from the standard report.
In the first instance we need to be able to calculate the Final Pay Salary value that SAP can derive each month to achieve this we utalise SAP by means of a strategically placed user exit to trigger the calculation each payroll. Having the final pay value each month enables us to use this value within averages going forward. This will not help us for previous payroll results prior to the solution implementation. At this point I should state that payroll results are sacrosanct and nobody should alter in any shape or form previous results. As such I have developed an external function module which reads payroll results for any specific prior period for an individual (single or multi employment) and emulates the GBLGP functionality and calculation used to derive the final pay value. The resulting value is then appropriately stored either in an external table or within Infotype 15 or 2010 for each period. Once we have the final pay salary value for any period we can build that into the calculation of the final pay in the standard report and calculate against any scenario. As time goes by the result are likely to be based solely upon the values calculated during each payroll run but in the interim period it can be a match of the derived value calculated outside payroll and stored in Infotypes and payroll results. The collation and calculation within the standard report can readily be adopted to suit any LGPS authority requirement.
Calculating the required Final Pay Salary in full as defined by your pension authority saves considerable effort for organisations. As mentioned often this value cannot be achieved by an organisation for one month accurately but to enhance it to meet defined pension authority requirements is a large step forward in reporting capability.
Submission of Data
As mentioned at the start we can define the format for any requirement for any authority. It is unlikely that you will submit directly to any pension body but will use a third party to assist in the management and administration of data. In the screen shots above it is likely you have seen I-connect structures. I-connect interfaces directly with the recognised Altair LGPS systems pension administration platform used by the majority of organizations operating a LGPS. (Aquila/Heywood’s)
i-Connect improves the flow of data from your HR and payroll systems to the pension fund, minimising manual intervention in the process. i-Connect amongst other items
- Automatically identifies changes to the workforce.
- Provides a straight through process for submitting data
The SAP solution can be readily adopted to meet the I-connect structure requires for subsequent processing and ultimate submission to Altair.
The effect of combining your reporting structure to meet the I-connect definition enables a smooth reporting operating platform for LGPS reporting.
The ever increasing emphasis on governance within public sector pension schemes is putting pressure on organisations to deliver accurate and timely date yet conversely at the same time, local government schemes are operating in an ever more complex regulatory environment, with increasing demands and time constraints placed up resources which are often dwindling. The SAP solution provided and detailed through the document can help produce such accurate and timely reporting data to meet your needs. It can be mapped against any required format that assist in your goals. The reports can be run in demand against the mist complex of criteria and the reports generated can integrate with your Local government reporting readily.