Unemployment Insurance Claims Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the whole modernisation get scoped as one project?

Because the pain is felt everywhere at once. The call centre is overwhelmed, the adjudication queue is at nineteen days, employers are complaining, and the benefit system is thirty years old, so the procurement is written to replace all of it. That produces a multi year programme with federal oversight where nothing improves for the first two years, and where the requirements are frozen before the agency has learned what it actually needs.

The specific trap in unemployment insurance is that the benefit calculation and payment engine is both the least broken component and the riskiest to replace, because claims are being paid through it while you work. Conversion and parallel running against a live payment stream is the reason these programmes take years, and it is not incompetence on the vendor's part.

The fix: separate the channels and workspaces from the engine. Claimant intake and weekly certification, the adjudication workspace, the employer portal, identity and fraud triage, and appeals are each separable, each improvable inside a year, and each measurable against numbers the agency already reports federally. Build those first, even alongside a larger modernisation, because they teach the agency what its real requirements are before the big programme freezes them. Do not commission a custom replacement of the payment engine while claims run through it, and be suspicious of anyone who offers a full benefits and tax modernisation inside eighteen months.

What goes wrong with wage records and the legacy system of record?

Monetary determination is arithmetic against quarterly wage records, and most legacy systems do it correctly, including alternate base period cases that need the most recent quarter before it has been reported. The problems are around the edges of that data and they surface in the new component rather than the old one.

Employer accounts do not reconcile across the benefits and tax sides of the house, so the same employer appears twice with different identifiers, and a separation notice goes to one of them. Wage records arrive with names that do not match the claimant's application, particularly after a change of name, so a claim that should clear monetarily goes to a manual queue. And where the only interface to the system of record is a nightly batch, every new component is showing yesterday's state while the claimant is looking at today's.

The fix: establish employer identity resolution as its own piece of work before building the employer portal, because a portal that shows an incomplete account view damages trust faster than no portal. Where the interface is batch, make staleness explicit on the screen rather than hiding it, with the as at time visible, so a claimant is not told something the agency will contradict tomorrow. Reconcile wage record name mismatches into a resolution queue with a defined turnaround rather than letting them sit inside the monetary backlog.

Why do the exchange, identity and payment integrations break after launch?

The national separation information exchange only helps when employers respond, so a component built around it inherits their behaviour. Responses arrive late, arrive incomplete, or arrive from a third party administrator whose access was arranged by sharing credentials, and the deadline clock the system enforces means nothing if the consequence of lapse is not defined in your procedures as well as your code.

Identity proofing breaks in the other direction. The vendor integration works, and it works too well, refusing legitimate claimants who cannot pass remote proofing, disproportionately older workers, people without credit history, and people whose identity was already stolen. Payment integrations fail quietly at the account validation step, so a claim shows as paid in your system and no money has arrived, which generates calls the component was built to prevent.

The fix: design the alternate path before the primary one. Every identity flow needs a route that ends in payment, including an in person option at a workforce office, and the existence of that route is a policy decision to settle before engineering. Give third party administrators proper delegated access rather than tolerating shared credentials, which is a security fix and a data quality fix at once. Treat the payment confirmation as a separate state from the payment instruction, and reconcile the two daily, so nobody is told they were paid when they were not.

What happens when fact finding and the identity risk model are not covered?

Separation fact finding is where the queue actually sits. The claimant statement is a free text box producing three lines, the employer response is late or absent, and the adjudicator telephones both parties, which is why a determination takes weeks. Adding adjudicators does not fix it, because the bottleneck is that half the file is missing at first touch.

Identity is the mirror image. Organised fraud against unemployment programs during 2020 and 2021 was extensive and widely documented, and it permanently changed what a claims front door has to do. Agencies that bolted a proving gate onto the front then created a second problem, which is a population of real claimants who cannot file at all.

The fix: replace the free text box with structured branching fact finding that asks only the questions the statute requires for that separation type, so a voluntary quit case collects the specific facts a determination needs. Show the adjudicator both accounts side by side with conflicts highlighted, and draft from a decision framework that cites the statute. Treat identity as a risk score rather than a gate: clean matches proceed, higher risk claims proceed with payment held pending a defined verification step, and high risk patterns such as many claims from one device or one bank account across unrelated claimants route to investigations before money moves. Stopping a fraudulent payment before it leaves is worth far more than recovering it afterwards.

Should you build custom or configure what you already own?

If you are a small state or a territory with modest claim volume and no active modernisation, buying a hosted benefits system from an established vendor is a defensible answer and we would say so rather than pitch a build. Geographic Solutions, Sagitec and Fast Enterprises all run real state systems, and the cost of a bespoke benefits engine at that volume is not justifiable.

If a modernisation is already under way, the right question is not whether to add a custom project but which components can be improved now without waiting. The channels and workspaces are the answer, and they are compatible with the larger programme rather than competing with it.

Commission custom work when a specific queue is measurably the bottleneck, when claimants abandon your online process at a step you can identify, when a policy change takes your incumbent two quarters to deliver, or when your certification flow does not work properly on a phone. Do not commission it to replace the benefit calculation and payment engine while that engine is paying claims.

How do hidden costs get into the quote?

Federal tax information is the first and largest. If a component touches wage or offset data obtained through federal exchanges, IRS Publication 1075 controls come into the environment, and that is a security programme with its own review cycle covering hosting, staff access, logging and physical controls. Keeping a component out of that scope entirely is frequently cheaper than bringing it in, and the boundary has to be decided during design rather than discovered.

Language access and accessibility are the second, because a programme serving the entire workforce needs a broader set of languages than most government portals and needs accessibility built into the first screen rather than remediated later. The alternate identity path is the third, since it carries operational cost in workforce offices as well as engineering cost. Appeals is the fourth and is genuinely its own product: hearing scheduling with parties, representatives, interpreters and recorded proceedings is not a module. And the interface to the system of record is the fifth, because a nightly batch forces design compromises throughout the component.

The fix: settle the federal tax information boundary, the language list and the appeals scope before asking for a number, and ask for each to be priced separately so you can see what you are buying.

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

Ask how they would design fact finding for a discharge for misconduct. If the answer involves a text area, they have not read a state statute and your adjudicators will still be making phone calls after go live. Ask what happens to a claimant who fails remote identity proofing, and require an answer that ends in payment rather than in a dead end. That they have thought about it at all tells you whether they understand the population being served.

Ask how a new federal benefit program would be added. If the answer is a code release and a deployment, you are buying the same problem your current system has. Program definition, eligibility rules and their effective dates belong in versioned configuration that a policy analyst can read. Ask how the weekly certification distinguishes when work was performed from when it was paid, since that single confusion generates a meaningful share of non fraud overpayments, and each one becomes an establishment, a notice, an appeal and a collection that costs more than the payment.

Then settle ownership before kickoff. The agency should hold the repository, the rules configuration and the environments outright, with the right to move the work to another firm. Unemployment systems outlive administrations and vendors, and an agency that cannot move its own logic elsewhere has committed to a decade of change orders.