Avoid cumbersome manual updates and complicated custom ABAP updates in your benefits administration functionalities by implementing the described SAP enhancements. Learn to improve flexible spending account administration, simplify benefits enrollment, and make group enrollment functionality more adaptable.
Key Concept
When SAP’s standard processes stop short of meeting your benefits administration requirements, SAP enhancements may help close the gap. SAP enhancements include SAP Notes, Business Add-Ins, and user exits that help you make the most out of your SAP system’s functionality.
SAP Benefits Administration is constantly evolving. As a result, you can now address customizations that you implemented years ago via an SAP-delivered enhancement or SAP Note. I’ll explain the enhancements available for setting the end dates for flexible spending accounts (FSAs), miscellaneous plans, and savings. In addition, I’ll show you an enhancement for locked benefit plan administration and new functionality for the delivered automatic and default enrollment programs.
Use Customer Exit/Business Add-Ins to Improve FSA Administration
A little more than three years ago, SAP released SAP Note 989966 (FSA plans: customer exit for setting validity dates), a customer exit (PBEN0038) that allows you to set validity dates for FSA plans (IT0170). I still run into people who have yet to hear about this customer exit, which solves a problem benefits administrators have long encountered.
When benefits administrators enroll an employee in an FSA program via the Benefits Administration Enrollment Workbench (HRBEN0001) or the employee portal in SAP ERP, the end date of the plan defaults to 12/31/9999. By law, if employees want to continue contributing to an FSA, they must make a new election each year. Therefore, the end date should be 12/31 of the enrollment year. Prior to SAP’s enhancement, regardless of whether you set your open enrollment period via administrative parameters (Figure 1) or through a more controlled or restricted enrollment via an adjustment reason (Figure 2), you were limited to applying the same end date to all plans in which employees enrolled.

Figure 1
Configuration of benefit area administrative parameters when using SAP-delivered base open enrollment functionality

Figure 2
Configuration of benefits adjustment reason for open enrollment
To remain compliant with the federal law, you were required to perform a follow-up process at the end of the enrollment period to change this date to 12/31/xxxx of the enrollment year. You could use either a custom ABAP program or make the change manually working from SAP’s participation report (HRBEN0072). You had to continuously monitor and update life events during the year because federal requirements prohibited FSAs from automatically rolling over from one year to the next. During a life event enrollment change, if the employee elects to change the FSA contribution, the new plan sets the end date back to 12/31/9999.
Although workarounds were available, they were ineffective and inconvenient for end users and employees enrolling through the employee portal in SAP ERP. The standard functionality only accommodated companies that required employees to make a new election for all plans on an annual basis vs. allowing the standard set of plan offerings to roll over if the employee chose not to make any changes. SAP remedied this problem with the release of customer exit PBEN0038, making it easier for companies to remain compliant with the law.
In Figure 3, you see the FSA with plan end dates set to 12/31/9999. By implementing customer exit PBEN0038 with just a few lines of code, compliance is no longer an issue (Figure 4). Functionally speaking, the design is to simply change the end date (ENDDA) to 12/31 of the begin date (BEGDA) year.

Figure 3
The benefits enrollment view prior to implementing the customer exit

Figure 4
With the customer exit implemented, the FSA plans terminate at the end of the year
SAP also offers the following customer exits to help you with similar problems you may have with other employee benefits:
- PBEN0039 — Customer Exit: Set dates for miscellaneous plans
- PBEN0040 — Customer Exit: Set dates for HSA plans
These are now considered Business Add-Ins (BAdIs) and you can access them via transaction SE18. Follow menu path SAP Easy Access Menu path Tools > ABAP Workbench > Utilities > Business Add-Ins.
Locked Plan Status Permits Changes
The inability to make changes to a plan with a locked status has been a longtime challenge for SAP users. Now, with customer exit PBEN0042, you can administer grandfathered plans via the enrollment workbench or through the employee portal in SAP ERP.
In the configuration of plan statuses you essentially have three options: Closed, Locked, and Open (Figure 5). Closed indicates no employees are actively participating in the plan and it is no longer available for new enrollment. Locked occupies the space between Open and Closed and indicates that employees are actively participating in the plan, but it is not available for new enrollments. Open indicates there are employees actively participating in the plan and the plan is open for new enrollments.

Figure 5
Configuration of benefit plan status
Before the customer exit was released, if a plan was set to Locked status, employees still actively enrolled in the plan could not make changes within the plan. For example, say a company decides to offer a new health insurance plan, but still wants to keep the old plan available for a certain period of time. No new enrollments are permitted in the old plan, but employees remaining in the old plan are permitted to make life event changes.
In the past, you would have set the Locked status for the old plan in configuration. However, this prevents existing enrollees from making life event changes. In short, the selection for “no new enrollments” was also preventing changes to existing enrollments. This prevented changes from being made via the Benefits Administration Enrollment Workbench and by an employee via the employee portal in SAP ERP.
As a workaround, an administrator could make life event changes for employees participating in the old plan through transaction PA30 (maintain employee master data), although SAP best practice discourages making benefits enrollment changes this way. Remember that when making benefits enrollment changes via transaction PA30, eligibility rules and change permissions are not active. Therefore, you would run the risk of making a change that would not be permitted or available via the enrollment workbench or the employee portal in SAP ERP.
With the new customer exit IF_EX_PBEN0042, you can decide if a locked plan (grandfathered or in a phase-out period) permits those employees to make changes within the plan (Figure 6). It may be a feature of the phase-out that future changes do not permit continued participation in the locked plan.

Figure 6
Interface documentation for BAdI PBEN0042
According to SAP Note 1090259 (Customer exit for changing a locked plan), which contains this customer exit, method LOCKED_PLAN_EDITABLE should return a value of X if a locked plan has to be edited.
With this customer exit activated, locked plans now appear for enrollment activities in the enrollment workbench and the employee portal in SAP ERP. You can also change the locked plans. As with the customer exits for setting plan end dates you can access the BAdI by following SAP Easy Access menu path Tools > ABAP Workbench > Utilities > Business Add-Ins.
Group Enrollment Flexibility
Users of the group enrollment functionality for mass enrollments in automatic plans (HRBEN0012) or default plans (HRBEN0013) know the limits of the functionality. If an eligible employee (EE) was already enrolled in a benefit plan, you could not execute these programs. The programs wouldn’t validate whether the EE was already enrolled in a plan if the plan type was configured for automatic or default enrollment. It simply overwrote the election back to the default or automatic plan, option, or coverage level.
The scenario was that immediately upon hire, a new employee was defaulted into a plan, such as base medical with only employee coverage, and basic life insurance. During the first 30 days of employment, employees made permanent elections for the plan or coverage of their choice and added beneficiaries for life insurance. In Figure 7, the EE has added beneficiaries to his basic life insurance plan after a default enrollment. Note the 100% election to the left of the beneficiaries’ names and the check for contingent beneficiary in the column on the far right.

Figure 7
List of selected primary and contingent beneficiary with percent of benefit elected as of 04/01/2010
On a subsequent execution of group enrollment (on 05/20/2010) a new record is created as of the date of execution of the program and any previous changes are not retained (Figure 8). Note that the percentage elections are set back to zero and the election for a contingent beneficiary is no longer present.

Figure 8
Beneficiary elections after running group enrollment
Fortunately, SAP released SAP Note 1153621 (RPUBEN62 – Already enrolled plan re-enrolled). With this note, the selection screen was modified to give you the flexibility to include or exclude employees already enrolled in the default or automatic plans (Figure 9).

Figure 9
Check box option on group enrollment selection screen
With this change, if you check the Exclude Employees That Are Already Enrolled check box, the group enrollment programs only update the default plans for eligible employees who are not currently enrolled. I should note that one thing that seemed a little inconsistent at the time this SAP Note was released was that all eligible employees were captured for processing, but no changes were made to the elections.
Go back to my earlier example in which the new employee made subsequent beneficiary choices on the group enrollment for Basic Life. Even though the check box was selected to exclude employees already enrolled, the group enrollment program would collect the EE and then determine if an enrollment was necessary in one of the automatic or default plans (Figure 10).

Figure 10
Group Enrollment processing screen
Despite this, the beneficiary selections remained unchanged (Figure 11). The EE made elections for beneficiaries for Basic Life. A subsequent group enrollment was executed with the check box to exclude already-enrolled employees. The SAP system recognized the employee as being eligible for the group enrollment process. Because the EE was already enrolled in the default plan, SAP ERP HCM skipped this EE during the enrollment process.

Figure 11
Post group enrollment processing to exclude already enrolled employees — note beneficiary election percentages and contingent beneficiary remain intact
Even with the initial success of this SAP Note’s release, a problem was discovered when there was a future dated plan. For example, during a designated enrollment period with effective dates for 01/01/xxxx of the next year the company requires employees to make changes or add beneficiaries for Basic Life. Beginning in the new plan year, the company plans to transition to SAP ERP HCM as the system of record.
Figure 12 shows an example of a record for an enrollment completed for 01/01 of the following year. Note the effective date of the plan and the 100% beneficiary elections and the contingent beneficiary selection.

Figure 12
Basic Life election with beneficiaries with a start date in the future
In my example, group enrollment is executed to capture and enroll any employee that is eligible but did not enroll during the open enrollment period. This occurs prior to the start of the new calendar year. Figure 13 shows how the employee is collected for processing even with the check box selected on the selection screen.

Figure 13
Currently enrolled employee with the future dated plan collected for processing for default enrollment
In this scenario with a future-dated plan, overwrite occurs. The effective date of the plan is not changed, but the beneficiaries are dropped (Figure 14).

Figure 14
Beneficiary percent elections are set back to zero and the contingent beneficiary election is removed
To address this overwrite error, SAP released SAP Note 1394888 (RPUBEN62: Already enrolled plan re-enrolled). With it, employees already enrolled in a default or automatic plan type are ignored and are no longer displayed on the program processing screen (Figure 15).

Figure 15
SAP system message for group enrollment if EE is already enrolled in default or automatic plans
In other words, SAP has re-ordered the logic of the program so that it does not collect all eligible employees first and then determine enrollment in a default or automatic plan. Instead it now only collects those employees eligible but not enrolled.
I inquired with SAP via the Support Portal accessed from the SAP Service Marketplace as to when this SAP Note would be released in a Support Package. The response indicated it would be included “in a future legal requirement change package” and that these are generally released “around June and December.”
However this particular SAP Note can be applied individually to your system in advance of the Support Package. Contact your Basis support team and provide them with the number to download and apply to your system.
Stephen J McCarthy
Stephen McCarthy is a managing consultant with HCL-Axon with over 13 years of experience specializing in the Benefits Administration module of SAP. Stephen holds a Master of Human Resources degree from the University of South Carolina and is a Certified Human Resources Professional (CHRP).
You may contact the author at stephen.mccarthy@hcl-axon.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.