Pension Administration Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does modelling the benefit formula as configuration fail so often?

The scoping conversation goes well because the first three formulas are easy. A multiplier, a final average salary window, a service credit total. Somebody proposes a configuration screen with parameters, everyone can picture it, and the estimate is written against that picture.

Then year two arrives and the fund hits the rule that does not fit. The 2013 amendment changed the multiplier prospectively but grandfathered anyone who had twenty years of service at the effective date. The 2004 tier applies to members hired after a date, except for members who transferred from a merged plan and elected to keep prior terms. A member purchased service in 2006 covering a leave in 2001, and whether that purchased period counts toward the grandfathering threshold depends on language nobody has read since it was drafted.

A parameter screen cannot express that. What happens next is always the same: an engineer writes the exception as code hidden inside a configuration value, or the fund keeps a spreadsheet for that population. Both are invisible in the system's own documentation, and the spreadsheet quietly becomes the real system.

The fix is a design decision made before estimating, not after. Benefit rules must be versioned, effective dated logic with explicit applicability conditions, where each rule declares the population it governs and the period it covers. A calculation then assembles the applicable rules and records which ones it used. Ask any prospective developer to model the 2013 grandfathering case on a whiteboard in the first meeting. If the answer is a configuration screen with parameters, you have found your year-two problem in week one.

What goes wrong with converting decades of service and salary history?

Conversion is the project. Everything else is software. Funds underestimate it because the data looks tidy in aggregate and only falls apart per member, which means the sample everyone reviews during discovery is the wrong sample.

The specific problems repeat across every fund. An employer reported twelve months of service in a year the member was on unpaid leave. Two salary records exist for the same period with different amounts and no rule for which wins. A break in service was never coded, so continuous service is overstated. Service purchase agreements sit in paper files with the election form stapled behind them. Microfilm holds the only record of an era. And the employer reporting format changed three times, so the same field means different things depending on the decade.

The failure mode is treating conversion as a load rather than an interpretation. Data gets moved, the interpreted value is stored, the source record is discarded, and nine months later an analyst answering a member appeal cannot see what the legacy system actually said.

The fix is to convert into a model that keeps the source record alongside the interpreted value, permanently, so every conclusion is traceable. Exceptions get a queue with a workflow and a severity, categorised so the ones affecting a benefit in payment are worked before the ones affecting a hypothetical future calculation. Budget conversion as its own workstream with its own tooling and an agreed reconciliation strategy signed off before it starts. Extraction from scanned documents genuinely helps with service purchase agreements and election forms, but every extraction feeds human review, because a misread election changes a person's income for life.

Why do employer reporting and payroll integrations break after launch?

The two integrations that matter most in a pension system are the ones the project team sees least: employer contribution reporting coming in, and annuitant payroll with tax withholding going out.

Employer reporting breaks because it is not one integration, it is one per participating employer, and in a public system that can be dozens. Each submits on its own schedule in its own dialect, and a school district that changes payroll vendors in July will send you a differently shaped file in August without telling anyone. If your validation rejects the whole submission, contributions stop posting and members' service credit stalls. If your validation accepts it silently, you have corrupted the record that every future calculation depends on.

Annuitant payroll breaks in a different way. The tax rules change annually, withholding elections change per member, deduction arrangements for health premiums change mid-year, and the payroll run has an immovable date. A defect discovered on payroll day is not a bug ticket, it is thousands of people not receiving the right amount.

The fix on the inbound side is per-employer file definitions held as data with versioning, row-level rather than file-level rejection, and an employer-facing view showing exactly which rows failed and why, so the district fixes its own submission instead of emailing your team. On the outbound side, insist on a full parallel payroll period where the new system and the old one both produce a run and every difference is explained before anyone relies on the new one. Then keep a rehearsal run scheduled before every live run in the first year.

What happens when retroactivity and statutory notices are not covered?

This is the gap that generates reconciliation differences nobody can explain, and it is almost always discovered after go live because it looks like an edge case during design.

A service purchase completes today and changes a benefit that has been in payment for two years. A domestic relations order arrives and splits a benefit retroactively to a separation date. A disability determination is backdated. A member reports a salary correction from three years ago. Each of these requires the same machinery: recalculate the benefit as of a historical date, compute the arrears or the overpayment, apply the correct tax treatment for the periods involved, generate the notice, and leave an audit trail showing exactly what changed and why.

Systems that treat annuitant payroll as a separate module handle every one of these with a manual adjustment. Manual adjustments do not carry a derivation, so within eighteen months the fund has a set of payment amounts that cannot be reconciled to any calculation, and the only explanation is in an analyst's memory.

Statutory correspondence has the same shape. Benefit estimates, election packages, tax forms and required notices have content and timing obligations, and a system that treats them as templates fired by a person will miss some. The fix is to make retroactive recalculation a first class operation in the design rather than an exception path, and to generate notices as events triggered by state changes with a record of what was sent to whom on which date. Ask about both in the first technical conversation, because the answer tells you whether the developer has done this work before.

Should you build custom or configure what you already own?

For a good number of funds the honest answer is buy, and we say that as a firm that builds software.

If you are a single employer plan with one formula, no tiers, clean data from one system and no unusual statutory overlay, do not build. A packaged system or a third party administrator will serve you at a fraction of the cost and the complexity that justifies a build simply is not present.

FIS Omni, Sagitec Neospin and Vitech V3locity are proven and used by large public systems. They come with domain staff and other clients who have hit the same problems, which is worth real money. Before commissioning anything custom, get an honest assessment of what your current system can still do, because funds routinely underuse platform capability after the person who understood it retired.

The build case appears when configuration approaches the effort of writing the rules directly, which is a function of how many tiers and amendment versions your plan carries rather than how many members it has. It also appears when a previous packaged implementation stalled and you now understand that conversion, not the product, was the obstacle. When you need integration into a state or agency environment a vendor product will not accommodate cleanly. Or when you want the calculation logic inspectable by your own actuaries and counsel rather than held as vendor configuration.

One warning about the comparison itself. Conversion costs roughly the same on either path. Any evaluation that sets a licence fee against a build price without pricing conversion identically on both sides is not a comparison, it is a sales document.

How do hidden costs get into the quote?

The engineering estimate is usually the honest part. The costs that arrive later are these.

• Paper and microfilm. Records that exist only physically need retrieval, imaging, extraction and review. Funds price the scanning and forget the review, which is the expensive half.
• Tier and amendment count. This, not member count, is the real measure of complexity. A fund with 40,000 members and two tiers is a smaller build than one with 12,000 members and nine.
• Employer reporting. Many participating employers submitting in different ways is a multiplier on both build and support, and it is a permanent operational cost rather than a one-off.
• Disability and death benefits. Each carries its own evidence gathering, medical review and approval workflow. They look like small modules and behave like small systems.
• The regression harness and its aftermath. Running the new engine across the whole population is a modest engineering cost and a significant analyst cost, because every difference has to be triaged by someone who understands the plan.
• The legal decision you cannot avoid. Discovered overpayments and underpayments require a board and trustee decision on remediation. That is not a project cost, but it can become a project delay if nobody has raised it before the harness runs.

What separates a build that works from one that fails here?

Four things, in order of how often they decide the outcome.

The first is that a calculation stores its derivation, not just its result. The output should be a number plus the service periods used, the salary records selected, the formula version applied and the caps tested. That derivation is what an analyst reviews, what answers an appeal a decade later, and what makes a defect findable at all. Systems that store only the result are how an error made in 1998 is still being paid.

The second is proving rather than testing. Ordinary test coverage is not the standard here. The standard is that the new engine reproduces what the old one produced or explains every difference across the entire population, with differences triaged into conversion issues, genuine legacy errors and new defects.

The third is sequencing. Calculation and conversion first, payroll and member portals afterwards. Funds that start with a portal because it is the visible part end up with an attractive interface sitting on top of numbers they cannot yet defend, and a wrong estimate published to a member is worse than no estimate at all. Self service should run the identical engine as the back office, gated on data quality, so a member with an unresolved exception is routed to an analyst rather than shown a confident wrong number.

The fourth is ownership. You should own the repository, the cloud accounts and the unrestricted right to hire anyone else, agreed before kickoff. At Digital Heroes the client owns the code from the first commit. A pension system computes obligations lasting the lifetime of a member and often a survivor after them, so the logic has to stay readable and maintainable by whoever holds the fund's responsibilities in thirty years.