RSA 911 Compliance in 2026: What Changed and How to Prepare 

If your agency has ever gotten a corrective action plan tied to RSA-911, chances are it wasn’t caused by one big mistake. It was a handful of specific, recurring data points that got missed, quarter after quarter, until RSA flagged them. 

The good news: the same handful of errors show up across agencies, year after year. Knowing where they hide is most of the battle. 

Where corrective action plans usually start 

Two patterns come up more than any others. 

Post-exit employment data, second and fourth quarter after exit (DE 383 and DE 389). Agencies are required to report on a participant’s employment status well after their case has closed; at the second quarter and the fourth quarter following exit. Because this data comes in long after the case itself feels “done”, it’s the single most common gap RSA flags in quarterly reviews. If your process for closed cases doesn’t include a scheduled follow-up at those two checkpoints, this is where to start. 

Changes to eligibility fields without notifying RSA (DE 5, 6, and 7). These fields cover core eligibility information. When an agency updates them internally, RSA needs to be informed as part of that change. It isn’t automatic. Skipping that step is one of the most frequent triggers for a compliance flag and it’s often not caught until well after the fact. 

A few other specific fields worth double-checking regularly: 

• DE 22: Student with a Disability status 

• DE 50 and DE 354–360: Employment at plan and employment at exit 

• DE 401: Date a credential or measurable skill gain (MSG) was completed or disenrolled 

None of these are complicated fields on their own. What makes them risky is timing. They’re easy to fill in correctly at one point in a case and then quietly go stale as circumstances change. 

What tends to catch agencies off guard 

Beyond the well-known problem fields, a few things trip up agencies less because of what they are and more because of when or how they surface. 

Quarterly report timing. RSA’s quarterly reports are where missing post-exit employment data (DE 383/389) most often gets caught. Not at the time of case closure, but months later, when the second or fourth-quarter window has already passed and there’s no easy way to go back and collect it. 

Service setup, not just data entry. Not every compliance risk comes from a data field. Services that aren’t configured correctly can let staff cut, authorize or pay for something they shouldn’t have access to in the first place. A process gap rather than a reporting gap, but one that creates the same downstream compliance headache. 

One tool, two levels of validation 

DARE, Libera’s RSA-911 compliance solution, checks your data against these patterns (and many more) before submission, not after. 

It comes in two versions. DARE Federal validates against RSA’s published edit specifications, the official rules as RSA has documented them. DARE Complete goes a step further, working to align as closely as possible with what RSA actually checks in practice, which isn’t always identical to the published specs. Most agencies start with one and expand from there as their reporting needs grow. 

Either way, the goal is the same: catch a DE 383 gap or an unreported eligibility change before it becomes a corrective action plan, not after. 

(Related reading: our guide on ensuring RSA-911 compliance covers the broader compliance picture if you’re looking for foundational best practices alongside specific error patterns.) 

About DARE 

DARE is Libera’s data analysis and report edit-checker, built specifically for VR agencies preparing RSA-911 submissions. It flags errors across caseload, office, record, supervisor, element and regional levels; before they reach RSA, not after a corrective action plan is already in motion. Agencies using DARE report saving up to 40% of the time they previously spent on manual compliance checks. 

If your team is still catching these errors after submission instead of before it, it’s worth a look at DARE.