Legal Aid Case Management Software: Why Eligibility Screening, Conflict Checks and Case Service Reporting All Break the Same System

Intake is a compliance gate wearing the costume of a form

A woman calls the hotline on a Tuesday about an eviction hearing on Friday. Before an advocate can give her advice, several things have to be established: household size and income against the current federal poverty guidelines, assets, citizenship or eligible immigration status, whether the matter is one the organization is permitted to handle under its funding restrictions, whether the case is fee generating, whether the organization already represents the landlord in another matter, whether it once represented her ex husband in a matter where she was adverse, and which problem code the matter falls under for reporting.

If any of that is wrong the consequences are not administrative. Advice given to an ineligible applicant is a finding. A missed conflict is a professional responsibility problem. A miscoded case is a reporting error that can cost funding. All of it has to happen while a woman with a Friday hearing waits on the phone.

This is why legal aid case management is its own software category and why commercial practice management tools do not fit. Clio, PracticePanther and their peers assume a billable client who was screened by whether their card cleared. LegalServer, Kemps CaseWorks and Legal Files exist because legal aid intake is a regulatory workflow with a case attached, not the reverse.

Eligibility rules move, and they move every January

LSC regulations set financial eligibility for most services at 125 percent of the federal poverty guidelines, with authorized exceptions allowing service above that threshold up to a defined ceiling when specified factors apply, such as medical expenses, child care costs or seizure of income. Those guidelines are reissued annually, which means every January your income tables change and every open screening built on the old numbers is wrong.

What goes wrong in practice is not the arithmetic. It is that eligibility logic gets hard coded, so the January update is a support ticket, and the authorized exception path gets implemented as a free text note because it is conditional and awkward. Then when a monitoring visit asks how a household at 180 percent of guidelines was served, the answer is in a paragraph somebody typed in 2023.

A build treats the guidelines as versioned reference data with effective dates, so a screening performed in December is evaluated against December's table forever. The exception path becomes a structured decision with the factor selected, the authorizing staff member and the reason, which turns an awkward conversation with a monitor into a report. Asset tests, in kind income and household composition rules follow the same pattern: configuration with history, not code with a changelog.

Conflict checking is adversarial, across offices and across years

Commercial conflict checking asks whether you have acted for this person. Legal aid conflict checking asks something harder: whether anyone in any office of your organization has ever acted for anyone now adverse to this applicant, including parties who are not the named opponent. In a family matter that means the other parent, their new partner, sometimes a grandparent. In housing it means the landlord, the management company and possibly the owning entity behind both.

That requires storing adverse parties as first class records, not as text in a case description, and matching across name variants, aliases, former names and addresses. It also requires care about what a searching advocate is allowed to see: the existence of a conflict must be visible, the details of the other client's matter must not be.

Most organizations run a name search and rely on the advocate reading results. A build that matches on normalized names plus date of birth and address, presents a same person likelihood, and records the clearance decision with who made it, is doing real work here. It also has to handle the imputation rules your organization applies when offices are treated as separate units for screening purposes, which is a policy question your general counsel answers before an engineer touches it.

Case service reporting decides how much money you get next year

Case counts reported under the LSC Case Service Report drive funding conversations and are audited against closure documentation. Every closed case carries a problem code, a closure category, and evidence that the eligibility and citizenship documentation exists. A case closed in a category the file does not support is an adjustment, and adjustments compound.

The failure mode is familiar in every legal aid organization: coding is done at closure by whoever closes the case, coding practice varies between advocates, and the compliance director spends weeks each year cleaning before submission. The software rarely helps because coding is offered as a dropdown with no relationship to what the file actually contains.

A build can do better without being annoying. Validate closure against the file: a case coded as extensive service with no substantive activity recorded prompts a question. Flag cases open beyond a threshold with no activity, which are the ones that turn into reporting problems. Run the report continuously rather than annually, so the compliance director sees the shape of the year in March. And keep the problem code taxonomy as reference data with history, because it does change and last year's report must remain reproducible.

Pro bono placement is a different lifecycle entirely

A case referred to a private attorney under the private attorney involvement requirement leaves your building but not your responsibility. It needs a placement record, a volunteer attorney with their own conflict profile and malpractice coverage, an engagement letter, periodic status checks, and closure information that comes back from someone who does not work for you and has no reason to prioritize your reporting deadline.

Most organizations run pro bono in a separate system or a spreadsheet, which severs the case from the reporting and makes the volunteer experience worse than it needs to be. Building the volunteer attorney a genuinely simple portal, with the matter, the documents they need and a two field status update, is a small piece of work that measurably improves both the return of case data and attorney retention.

Confidentiality raises the security bar above ordinary nonprofit software

These files contain protected information about domestic violence, immigration status, health and finances, held under professional privilege. That changes the engineering baseline: field level access control so a paralegal in one program cannot browse another program's clients, complete audit logging of who viewed which record, careful handling of address confidentiality for participants in state address protection programs, and a document store where retention and deletion are enforced by policy rather than by habit.

It also constrains convenience features. Client portals are valuable and every one of them needs an authentication design that does not assume a stable phone number or a private device, because a client fleeing violence may have neither. That is a design constraint most vendors have never had to think about.

What a custom build has to include

• Versioned eligibility reference data with effective dates and structured authorized exceptions
• Adverse parties as first class records, with fuzzy matching, alias handling and recorded clearance decisions
• Conflict visibility that reveals existence without revealing the other matter
• Problem codes and closure categories as versioned reference data, with closure validation against file contents
• Continuous reporting rather than an annual cleanup exercise
• Pro bono placement with a volunteer attorney portal and returned closure data
• Field level access control, full view auditing and enforced document retention
• Hotline workflow separating brief advice from extended representation, with the eligibility gate applied in both

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, a first release covering intake, eligibility, conflict checking and the case record runs $65,000 to $140,000 in 12 to 16 weeks. Document handling, pro bono placement, hotline workflow, outcomes and multi funder reporting bring the platform to $170,000 to $400,000 over 6 to 12 months.

What drives cost up here specifically: the number of distinct funding sources, because an organization with LSC funding plus Violence Against Women Act funding plus state IOLTA plus a medical legal partnership grant is reporting four different things about the same case and the mapping is the work. Court system integration, since e filing and docket access differ by jurisdiction and some are genuinely hostile to automation. Multi state operation, where eligibility and practice restrictions diverge. And data migration from a legacy system that has fifteen years of cases with inconsistent coding, which is a reconciliation project rather than an import. What keeps cost down: one program area first, your current coding practice unchanged, and a manual first reporting cycle.

Build versus buy, honestly

Buy. That is the honest default in this sector and we would rather say it than sell you a project. LegalServer is deeply established in legal aid, understands LSC reporting, and its cost over five years is far below a build. Kemps CaseWorks and Legal Files both have real installed bases. If you are a single state LSC funded program with conventional practice areas and a normal funder mix, a configured product plus a modest integration budget is the right answer and a custom build is a distraction from hiring another advocate.

Build when the shape of your organization genuinely diverges. That means operating across states with different eligibility and restriction regimes. Running major programs outside LSC funding whose reporting models do not fit an LSC shaped product, such as immigration representation at scale, medical legal partnerships embedded in health systems, or disaster response work. Needing deep integration with a hospital or court system that the vendor will not build. Or having a hotline and triage model with volume that a general product handles poorly. In those cases the alternative is not a clean product, it is a product plus five spreadsheets, and the spreadsheets are where the compliance risk lives.

How to choose a developer for legal aid software

Ask them to whiteboard the model. A developer who understands this draws applicant, household with income and composition, eligibility determination with an effective dated rule set, matter, adverse parties, conflict clearance, problem code and closure. They will ask early whether an applicant can become adverse in a later matter, because the answer shapes the conflict design. If they draw clients and cases, they have built a law firm system and you will be paying to teach them what a funding restriction is.

Ask how the January guideline update happens, and whether it is configuration you control or a release they schedule. Ask how the conflict search shows a hit without disclosing the other client's matter. Ask what closure validation they would implement, because that answer reveals whether they have thought about reporting or only about storing.

Ask what they have integrated: e filing, a document assembly tool such as HotDocs or a document automation platform, a phone system for hotline call handling, and a funder portal are four different problems. Get names. Finally, get code and data ownership and a security review in writing before kickoff. You should own the repository and the cloud accounts, and hosting, encryption and access logging should be specified because these files are privileged. At Digital Heroes the organization owns the code from the first commit, and for a legal aid provider that is a professional responsibility question as much as a commercial one.