Automating UI Overpayment Recovery

And Why Paid Family Leave Belongs in the Conversation

The final post in our latest series on UI fraud closes the loop on recovery, and looks at why the same playbook extends to Paid Family Leave.

The Manual Recovery Bottleneck

Detection can run cleanly. Determinations can be fast and well-documented, as we covered in Part 3 of this series. And recovery can still stall, because collecting on a confirmed overpayment is its own operational problem, separate from proving fraud occurred in the first place. Manual recovery workflows, generating notices, tracking payment plans, coordinating offsets, following up on missed payments, consume staff hours that most agencies simply don’t have to spare.

That bottleneck tends to be invisible from the outside. An agency can point to strong detection numbers and solid determination rates and still be sitting on a recovery caseload that grows faster than staff can work it, because every one of those confirmed cases now needs ongoing, manual follow-through to actually turn into collected funds.

The underlying issue is often the payment infrastructure itself. As we’ve noted in our work on modernizing UI tax and overpayment collections, agencies still relying on mailed notices, paper checks, and batch-based processing introduce delays at every step, which compounds the staffing problem rather than easing it.

Automating Recovery End-to-End

Automating the recovery process doesn’t mean removing staff from it. It means removing the repetitive parts of it, notice generation, payment plan tracking, offset coordination, status updates, so staff time goes toward the cases that genuinely need judgment: a disputed balance, a hardship request, a claimant who’s gone unresponsive. Everything else moves on its own.

Agencies running recovery this way consistently report fewer manual hours per case and faster time to collection, simply because nothing is waiting in a queue for someone to have a free afternoon. As we’ve discussed in the context of machine learning applications in adjudication and recovery, automation here works the same way it does earlier in the lifecycle: it targets and prioritizes the highest-value cases automatically, rather than treating every open balance the same way. The overpayment amount calculated during determination flows directly into a recovery process built to act on it immediately, instead of sitting in a handoff between systems or teams.

Measuring What Recovery Automation Actually Saves

The staff-time argument for automation is easy to make in the abstract and harder to prove without a baseline. Agencies considering this shift are generally best served by measuring current manual hours per case, average time from determination to first payment, and the share of balances that go fully uncollected, before implementation, so the improvement is demonstrable rather than assumed. Those same three metrics tend to be the ones that hold up best in budget conversations, since they translate directly into staff capacity freed up for higher-value work.

It’s also worth separating two kinds of savings that often get lumped together: hours saved per case, and dollars recovered that would otherwise have been written off. The first argument justifies the technology investment on efficiency grounds alone. The second argument, recovering money that was headed for a loss column, tends to be the one that resonates furthest up the budget chain, because it’s revenue protection rather than a cost center improvement.

Same Playbook, New Program: Paid Family Leave

Paid Family Leave has increasingly been folded into the UI Summit conversation, and that’s not a coincidence. In most states, PFL programs sit inside the same agencies running UI, and face nearly identical operational problems: verifying eligibility accurately, catching fraud before it becomes an overpayment, and recovering that overpayment without burning through staff capacity better spent elsewhere.

PFL claims involve their own version of the work-and-earnings question, whether someone drawing benefits is actually on leave, and their own version of the employer verification problem, confirming that a claimed employment relationship and wage history are real. A detection and recovery architecture built for UI doesn’t need to be reinvented for PFL, it needs to be pointed at a second program running largely the same risk patterns.

The lifecycle we’ve walked through across this entire series, detection in Part 1 and Part 2, determination in Part 3, and recovery here, isn’t specific to unemployment insurance. It’s a general architecture for handling improper payments in any benefits program, and Paid Family Leave fits it directly. Agencies running both programs don’t need two separate fraud and recovery playbooks built and maintained independently. The same workflow, applied consistently through Catalis UI Solutions, covers both.