Payroll Data Conversions

[Guest Dharmesh]

What current current tools or techniques are used by Relius users to convert plan sponsor data for use by the recordkeeping system?

Although there has been movement to establish data format standards (such as the SPARK format), my understanding is that there are still a multitude of file formats that sponsors have to deal with.

[Guest DottleC2]

I would venture to guess that you're referring to a much more complex and functional system than what is currently available from vendors to specifically address this, such as an xml schema.

At this point there is just the old reliable text Data Entry Routine that allows text import of payroll elements.

Things happen pretty fast though, there may already be some sort of component available that you are looking for. My guess would be that there isn't anything on a shelf, in a box, like what you describe, that is available for payroll conversion to third party pension administration software like Relius. The exception would be text based - the technique has always been to import and verify.

Having said that, inevitably a paragraph of disclaimer will follow. It would take a dictionary sized explanation to describe the separation of payroll and pension in the context of third party pension administration. Everything is in place for it to happen using Relius schema. There are payroll ID elements within the census data, and various checks and balances within the software, etc. so this type of conversion can be set up as a reliable flow of data. There have always been turnkey payroll systems with pension reports, but nothing standardized to the extent that it would be useful to a broad range of third party pension administrators. There are undoubtedly integrated systems and services that address this that are available, just not out of the box type products. In most cases the sponsor doesn't 'deal with' the format of 401(k) data, they just give the raw data to the third party administrator - in most instances.

Bill

[Guest Dharmesh]

Thanks for your response.

As a disclaimer, I represent a vendor that builds software solutions for recordkeepers and administrators.

One of our products (PlanConvert) is an "out-of-the-box" solution for conversion of payroll data files (in Excel, CSV, flat file, etc.) into a usable format by the recordkeeping system. This product has been available for a while (8 years) and is successfully used by a number of recordkeepers running the SunGard OmniPlus system. As an off-the-shelf solution, it is the leading conversion product for the 401k market.

My interest lies in the value and feasability of taking this product and having it work in conjunction with Relius -- thereby decreasing the cost of payroll conversions for the recordkeeper. Basically, the idea is to create an intuitive way to "map" the data from various file formats and help embed pre-validation rules into the process.

We are seeking potential partners that are interested in improving their current payroll file collection and conversion process. We would work with this partner to modify our product to work with Relius. In exchange for their particaption, they would receive a free license to the product.

Dharmesh Shah

Pyramid Digital Solutions

[Guest Ken Simons]

FYI

As many Relius users know, the system inlcudes Data Entry Routines (DERs) that allow them to map almost all ASCII files (varaible length like CSV or fixed record length) to either census demographic data, payroll data, or financial data like transaction history and fund/source balances. These are included with all levels of the system and can be used for one or more plans. there is no limit to the number of these "conversion of data" routines that can be created.

Additionally, users of the Relius Plan Sponsor web product now can create Data Validation rules that will "scrub" the data before it is loaded into the system. It returns errors and warnings to the plan sponsor who can correct the mistakes and submit for additional validation and then have the data loaded into the payroll or demographic tables. The validation is both web side (for format) and content (in the database) and done by an automation agent that is included with the product. The adminstrator is then notified by e-mail that their client has submitted a file for processing and that transacitons are waiting to be posted.

The same "conversion" routine that was used to load the data electronically, can then be used by the Relius user to review the data manually if desired.

Ken

[Guest DottleC2]

Third party pension administration would be the key word here, there is a large difference between administering to 10 different payrolls for 10 different clients over the course of one day. Versus doing 10 payrolls for one company over the course of 20 weeks.

What would be nice (a wish list item) is to have a program that would store the format of the source, and supply the same target file for each import using the same DER.

Bill

[Guest Dharmesh]

Interesting you should say this, because this is exactly the model we use.

Here's the idea:

a. User defines the input format in a conversion "template" (that maps the data)

b. Application can either generate an output file to match that of what the recordkeeping system needs, or a "standard" format that the user defines (in XML, CSV, etc.)

The idea is to have reusable "templates" for each of the various input file formats expected. The application would then apply the conversion template and "normalize" the file to a standard format.

Another challenge (that we have solved) is dealing with files in CSV, fixed format, Lotus, Excel etc. (without having any third party applications on the desktop).

[Guest DottleC2]

Based on what you've explained thus far, it sounds like you might be needing someone to test and 'tune' a Relius DER to your output or target file specs?

Does that sound more in the ball park of what you where asking or referring to? Or were you looking for a more seamless method. The DER routine is fairly 'robust' to use that too- often-coined term. Once a DER is created, there's no need to replicate. 3rd party administrators I would venture to say, 'live' in the DER routine and just about anyone out there in TPA land would or could test.

I'm interested - you can certainly email me.

Bill