Pension Administration Software: Why a Benefit Calculated Wrong in 1998 Is Still Being Paid Today

Why pension administration is unlike any other back office system

A member calls to ask what she will receive if she retires in March. She started in 1989. The plan formula changed in 1996, again in 2004 when a new tier was created for members hired after that date, and again in 2013 when the multiplier changed prospectively with a grandfathering provision for anyone with 20 years of service at the effective date. She was on unpaid leave for 14 months in 2001, purchased that service in 2006, and worked part time from 2015 to 2018. Her final average salary calculation depends on which three or five year window applies under her tier, and whether a lump sum payment she received in 2019 counts as pensionable.

An analyst will work this out by hand over the next two days using a benefits handbook, a spreadsheet, a screen from a system written in the 1990s, and a phone call to a colleague who remembers what the 2004 amendment actually said. The answer will probably be right. It will not be reproducible, and when the member retires and a slightly different number appears, the trust in the fund takes a hit that is out of all proportion to the dollar difference.

The vendor products in this market are real and serious. FIS Omni, Sagitec Neospin and Vitech V3locity are used by large funds and public systems and they work. The reason these implementations are famous for running long is not vendor incompetence. It is that a pension administration system is essentially a codification of one plan's entire legislative and amendment history, plus a data conversion project spanning decades of records, and neither of those things is a product. The configuration effort to represent one plan's rules inside a packaged system is frequently comparable to writing the rules directly, and the conversion is identical either way.

Problem 1: the benefit formula is not a formula, it is a history

Members are not on one plan. They are on the plan as it applied to them, which depends on hire date, tier, bargaining unit, elections they made at specific moments, service purchases, and grandfathering provisions written into amendments to protect people mid career. A public system may layer statutory changes on top of that, sometimes retroactively, sometimes with litigation attached.

What a custom build does: model benefit rules as versioned, effective dated logic with explicit applicability conditions, not as a giant configuration matrix. Each rule states the population it applies to and the period it governs, and a calculation for a member assembles the applicable rules and records which ones it used. The output of a calculation is not a number, it is a number with a derivation: the service credit periods used, the salary records selected, the formula version applied, the caps and limits tested. That derivation is what an analyst reviews, what a member appeal is answered with, and what makes the calculation defensible ten years later.

This is the single most important design decision in the whole build. Systems that store only the result are how a 1998 error is still being paid, because nobody can see what the calculation assumed.

Problem 2: the data conversion is the actual project

Service credit and salary history stretch back decades through system migrations, employer reporting that changed format several times, microfilm, and paper personnel files. Records disagree. An employer reported 12 months of service in a year the member was on leave. Two salary records exist for the same period with different amounts. A break in service was never coded correctly.

Everyone underestimates this, including experienced teams, because the data looks tidy in aggregate and falls apart per member. The honest approach is to treat conversion as a first class workstream with its own budget, its own tooling and a reconciliation strategy that is agreed before it starts.

What a custom build does: convert into a model that preserves the source record alongside the interpreted value, so an analyst can always see what the legacy system said and what the conversion concluded. Exceptions get a queue and a workflow rather than a spreadsheet, categorised by severity, with the ones that affect a current calculation prioritised over the ones that affect a hypothetical future one. Extraction from scanned documents helps on paper files, particularly service purchase agreements and election forms, but it must feed a human review because a misread election changes a person's income for life.

Problem 3: the member wants an estimate and the analyst is the bottleneck

Every fund wants member self service estimates. Few can offer them credibly, because the estimate has to run the same rules as the official calculation on data that may have unresolved exceptions, and a wrong estimate on a public portal is worse than no estimate.

What a custom build does: make self service run the identical calculation engine as the back office, with a data quality gate. If a member's record has an unresolved exception that would materially affect the result, the portal says so and routes to an analyst rather than producing a confident wrong number. Members can model scenarios: retire in March versus September, elect a joint and survivor option, purchase the service they are eligible for. Every estimate is stored with its derivation, so when the member calls three weeks later the analyst sees exactly what they were shown.

The operational effect is that analysts stop producing routine estimates and start handling the complex cases, which is the work that actually requires their expertise. Funds we have worked with treat that shift as the main return on the project.

Problem 4: the calculation has to be proven, not tested

Ordinary software testing is not sufficient here. You are replacing an engine that currently pays thousands of people, and the standard of proof is that the new engine reproduces what the old one produced, or explains every difference.

What a custom build does: a regression harness that runs the new calculation across the entire population and compares to the current benefit in payment, member by member. Differences are triaged into categories: conversion data issues, genuine legacy errors the new engine has caught, and defects in the new logic. Every fund of any size discovers historic errors in this process. That is uncomfortable and it is also the point, because the alternative is continuing to pay them. Plan for a legal and governance conversation about how to handle discovered overpayments and underpayments before the harness runs, not after, because that decision belongs to the board and trustees rather than to the project team.

Problem 5: everything downstream depends on the same record

Annuitant payroll with tax withholding and deduction handling. Employer contribution reporting and reconciliation. Actuarial data extracts for the valuation. Financial reporting to the standards public plans report under. Correspondence and statutory notices. Each of those is a system in its own right and each depends on the same member and service record.

What a custom build does: hold one member record with a full event history, and treat payroll, reporting and extracts as consumers of it. The specific discipline that matters is retroactivity. A service purchase completed today can change a benefit that has been in payment for two years, which requires a retroactive recalculation, an arrears payment and a corrected tax treatment. Systems that treat payroll as a separate module handle this by manual adjustment, and manual adjustments in annuitant payroll are how funds end up with reconciliation differences nobody can explain.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering the member and service data model, converted history with an exception workflow, the versioned benefit calculation engine and the regression harness proving it against benefits in payment runs $150,000 to $350,000 and ships in 20 to 28 weeks. A full platform adding retirement application processing, survivor benefits and domestic relations orders, annuitant payroll with withholding and retroactive adjustment, member and employer self service, correspondence, and actuarial and financial reporting extracts runs $500,000 to $1,500,000 phased over 12 to 24 months.

What pushes the number up: the number of distinct tiers and formula versions, which is the real measure of complexity in this domain rather than member count. Data condition, especially paper and microfilm. Defined contribution or hybrid components alongside the defined benefit plan. Disability and death benefit processing, which carry their own evidence and medical review workflows. And employer reporting, if you have many participating employers submitting in different ways, which is common in public systems.

What keeps it down: sequencing calculation and conversion first, and leaving payroll until the calculation is proven. Funds that start with a member portal because it is visible get a portal on top of numbers they cannot yet defend.

Build versus buy, and the honest comparison

Buy if you are a single employer plan with one formula, no tiers, clean data from one system, and no unusual statutory overlay. A packaged system or a third party administrator will serve you at a fraction of the cost and you should not be reading a build article.

The comparison is genuinely close for large funds, and we say that as a firm that builds software. FIS Omni, Sagitec Neospin and Vitech V3locity are proven, and a packaged implementation gives you a vendor with domain staff and other clients who have hit the same problems. What tips funds toward building is usually one of these. First, your plan has enough tiers and amendment history that configuration approaches the effort of writing the rules directly. Second, you have been through a packaged implementation that stalled and you now understand that the conversion, not the product, was the obstacle. Third, you need integration into an existing state or agency environment that a vendor product will not accommodate cleanly. Fourth, you want the calculation logic to be inspectable by your own actuaries and counsel rather than held as vendor configuration. Fifth, the total cost of ownership over fifteen years, including the licence and the specialist configuration staff you will need to retain anyway, exceeds the build.

Whichever route you take, the data conversion cost is roughly the same. Any evaluation that compares a licence fee to a build price without pricing conversion identically on both sides is misleading you.

How to choose a developer for pension administration software

Ask them how they would represent a benefit formula that changed in 2013 with grandfathering for members who had 20 years of service at that date. The right answer is versioned effective dated rules with applicability conditions and a calculation that records which rules it used. If they describe a configuration screen with parameters, they are going to hit a rule they cannot express in year two, and the workaround will be code hidden inside a parameter.

Ask what their regression strategy is against benefits currently in payment. If they do not propose running the new engine across the entire population and triaging every difference, they do not understand the standard of proof this domain requires.

Ask how they handle a retroactive change to a benefit already in payment. Arrears, corrected tax treatment and a clean audit trail are the test, and any answer involving manual adjustment in payroll tells you where your reconciliation problems will come from.

Ask who owns the code and settle it before kickoff. You should own the repository, the cloud accounts and the unrestricted right to hire anyone else. At Digital Heroes the client owns the code from the first commit. A pension system calculates obligations that run for the lifetime of a member and often a survivor after them, which means the logic must be readable and maintainable by whoever holds the fund's responsibilities in thirty years.