Community Action Agency Software Problems: The 6 That Trigger Monitoring Findings, and How to Avoid Them

Why does a community action build get scoped as one intake form?

Because the visible pain is the family sitting at the desk while a worker keys the same pay stubs into four systems. So the requirement gets written as a single intake form that feeds everything, and that is genuinely useful and genuinely not the hard part.

The hard part is that the four programs measure different things. Community Services Block Grant eligibility, energy assistance and weatherization each use a different income threshold, over a different measurement window, with a different definition of the household. One counts the grandmother in the back bedroom, one counts the heating account holder, and one counts the dwelling unit. Self employment is handled differently by each. A zero income household needs an attestation for one and a third party verification for another. Confirm the actual figures against your own state plan, because they move, and because the numbers are not the point. The differences are.

A single form that collects everything and then asks a worker to apply the arithmetic in her head against a laminated chart taped to the monitor has moved the problem, not solved it. What the first release needs is a household modelled once, with people, income sources, addresses and documents as objects carrying effective dates, and each program's eligibility written as a separate versioned rule set tied to a program year. Intake then runs every rule set at once and returns what the family qualifies for today, what one more document would add, and exactly which document. That is what turns a forty five minute interview into fifteen minutes, and a form alone will not do it.

What goes wrong when you migrate household files and paper records?

Duplicates first. The same household exists in the block grant system, the energy assistance spreadsheet and the weatherization waiting list under three spellings and two addresses, and your annual reconciliation already surfaces them every June. Merging on last name and date of birth is what created the problem in the first place, and doing it faster in code makes it worse.

Use scored candidate matching with human adjudication, a recorded decision and a reversible merge. Budget it as staffed work over weeks, not as a load script. Every merge changes a served household count that appears in a report somebody already submitted, so involve whoever owns your reporting before the first merge rather than after.

Paper is the second and it is where these projects lose their budget. The instinct is to digitise everything. The honest approach is to scan and index only what your funders' retention windows actually require, attach it to the migrated household record, and leave the rest in storage with a finding aid. Full digitisation of a decade of files is a project with its own budget and it should be treated as one, or declined.

The third is historical determinations. Do not re score old decisions with the new engine. Import them as recorded outcomes with whatever supporting documents exist, clearly labelled as imported, and start capturing the rule version and inputs from go live forward. A monitor asking about a 2024 determination wants the 2024 rules, and a system that silently reinterprets history is worse than one that admits the boundary.

Why do state portal and utility vendor feeds break after launch?

Start with the honest answer about the state system: many states offer no interface at all, so the realistic design is a controlled export plus a person, with reconciliation between what your system says was submitted and what the state shows as received. Agencies that assume an integration exists and discover otherwise in month four lose an application season. Ask the state before scoping, get the answer in writing, and design for the answer you actually have.

Utility vendor files are the ones that break continuously after launch. Every gas utility, electric cooperative and propane dealer defines its own format, changes it without notice, and rejects records for reasons that arrive as a return file nobody is watching. The failure is silent: benefits show as paid in your system while credits were never posted to customer accounts, and you learn about it when a client with a shut off notice calls in February.

Three fixes. Validate account numbers against each vendor's own check digit rules before the file goes out, which removes most rejections at source. Treat a benefit as an obligation that becomes a payment that becomes a confirmed credit, with each state visible, so a payment that was never confirmed sits in a queue rather than looking complete. And reconcile totals with each vendor on a schedule rather than assuming agreement.

The third integration is accounting. Program payments and job costs have to reach the general ledger coded to the right grant, and the common failure is a duplicate posting after a retry or a posting that succeeded while the case system still shows it pending. Use a single posting attempt with an idempotency key, write the ledger document number back onto the record, and run a reconciliation report between the two systems.

What happens when cost allocation and record permissions are not covered?

Cost allocation is where the single audit actually goes. Staff time has to land on the right grants with documentation that supports it, and most agencies run a monthly percentage estimate that has not been revisited in three years. It is defensible right up until somebody tests it against what people actually did.

Because staff are already working inside the system on program tagged activities, the underlying numbers can be derived from real case activity rather than reconstructed from memory. Keep the certification step, because auditors want a signature, but stop signing an estimate nobody can support. This is also the feature that finally lets a finance director answer what a served household costs by program, which is a board question that currently gets an anecdote.

Record permissions are the second uncovered gap and the one with the sharpest consequences for people. A weatherization job file, a domestic violence shelter note and a Head Start record cannot carry the same access rules, and a developer who proposes one flat staff role has not thought about the agency they are building for. Permissions need to be by program and by record category, with access logged, so that a worker helping a family with an energy bill does not see a shelter note and so that you can demonstrate who opened what if a question is ever raised. Retention differs by funding stream too, so deletion should be a documented state rather than an absence.

The third routinely missing piece is crisis timing. Energy crisis assistance carries expectations about how quickly a household in crisis receives resolution, with a shorter clock where the situation is life threatening. That is not a case note, it is a countdown that has to escalate to a supervisor before it breaches, on a Friday afternoon in January when the office is full.

Should you build custom or configure what you already own?

If you are a single county agency running the block grant plus one or two ancillary programs on a budget under roughly four million, buy and be happy about it. CAP60 was built for community action agencies, it knows the annual report, and paying for it beats building a worse version. CharityTracker is the right tool when your real need is coordinated referral across a network of local providers rather than benefit calculation inside your own walls. There is no prize for building software you did not need.

Configure before you build in one specific case. Many agencies use a fraction of what CAP60 already does because the person who was trained on it left. Retraining is cheap and removes a real portion of the apparent requirement.

Build when three or more of these are true. You administer four or more funding streams with different eligibility tests. You deliver weatherization with in house crews or a contractor panel, which is a construction job costing operation rather than a case. You operate across multiple counties with different local requirements. Your last monitoring visit produced a documentation or duplicate service finding. Or your fiscal office reconciles program numbers by hand every quarter. Above that line, coordination between programs is the operation, and no product built for a generic nonprofit models it.

How do hidden costs get into the quote?

Funding stream count is the first multiplier. Each stream is a rule set, a report format and a set of retention rules, and a quote that does not list them by name is priced for two.

Head Start is the second and it should usually be excluded rather than absorbed. It carries an entirely separate data and reporting world, and folding it into a general case management scope is how a project doubles quietly.

Weatherization job costing is the third, because it is a different domain from case management: measure lists, savings to investment justification, an average cost per unit cap watched in real time, contractor purchase orders, deferrals, inspection sign off and photographic evidence.

Paper backlog migration is the fourth and it is almost never in the budget. State portal reality is the fifth, since an export and a human is a different design from an interface. And the sixth is your own staff time writing down eligibility rules and local variations that currently exist as one intake supervisor's judgement, which is on the critical path and appears in nobody's engineering line.

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

Version the rules and record the version on every determination, from day one. When a monitor asks how a two year old figure was calculated, you show the rule as it stood and the inputs used. A developer whose answer to a mid year rule change is that they will update the code has not understood what you are buying, because after that update no past decision can be verified by anyone, including you.

Capture documents at intake, not at audit time. This is the difference between a monitoring packet generated in a minute and a fortnight of assembling files, and it is also where document extraction genuinely pays: reading pay stubs, award letters and shut off notices for employer, gross amount, pay period, account number, arrears and service address, with the worker confirming. Keep eligibility itself as explicit auditable rules, because a monitor will ask you to reproduce a decision and a model cannot.

Make the activity log append only. Nothing edited quietly after the fact, corrections recorded as new entries that supersede. This is what makes the file trustworthy and it cannot be retrofitted.

Launch outside the energy assistance season. Going live in the first week of November is a decision agencies make once. Aim for spring, run a full season on the new system with the old one still available for reference, and migrate the waiting list before the queue forms rather than during it.

Finally, settle ownership in writing before kickoff: the repository, the hosting accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. An agency whose intake system sits in a vendor's account has handed over operational control of its energy assistance season, which is a poor trade at any price.