Disaster Cost Recovery Software: Capturing Labor, Equipment and Procurement Evidence While the Response Is Still Running

The letter that arrives three years late

The event was in the autumn of a year you have mostly stopped thinking about. The money came, the projects closed, the staff who ran the response have retired or moved on. Then a letter arrives asking for supporting documentation on force account labor for two project worksheets, and specifically for the pay policy in force at the time, the timesheets showing which employees worked which hours on which eligible activity, and the equipment logs showing hours by piece of equipment at the rates claimed.

The finance director walks to a storage room. The timesheets exist, in boxes, as scanned images of paper filled in during an event by crew leads who wrote the storm name in a margin because there was no cost code for it yet. The equipment hours are on daily sheets that record a truck number and a shift, not the eligible activity. The person who could explain the coding retired. What is being decided in that room is whether the jurisdiction keeps money it spent and already accounted for, and the answer is being decided by the quality of paperwork nobody had time to think about during a flood.

The rules that decide eligibility are published in advance

This is what makes the problem tractable and the failure so avoidable. The eligibility tests are not a mystery revealed at closeout. The programme guidance sets out what is eligible under emergency work versus permanent work, how force account labor is treated differently between the two, that your pay policy has to have existed before the event rather than being written for it, how equipment is claimed against a published rate schedule, and what federal procurement standards require of any contract you executed under time pressure. Records generally have to be retained for three years after final closeout, which is why the letter arrives so late.

Every one of those tests can be applied at the moment of capture. A timesheet entry can require an eligible activity, a category and a project reference the day it is entered. An equipment entry can carry the equipment type and the rate that applies. A contract can be flagged at execution if it was awarded without competition and needs a documented justification. The reason none of that happens is that the systems holding the data, payroll and fleet and purchasing, have no concept of a disaster event, so the coding is applied afterwards by memory.

Where the Grants Portal, Crisis Track and Veoci stop

The federal Grants Portal is the submission and management environment for the programme, and you will use it regardless. It is not a capture system for your side of the evidence. It expects you to arrive with documented costs; it does not go into your payroll system and construct them.

Crisis Track is genuinely good at the response side capture, particularly damage assessment and debris, and for jurisdictions whose recovery burden is mostly those two categories it does real work. Where it thins out is the finance office view: reconciling to your general ledger, handling multiple funding sources on the same project, insurance offsets, and the permanent work categories where the documentation looks like construction administration rather than field data collection.

Veoci will let you configure forms and workflows around all of this, which suits organisations that already run their emergency management on it. The friction is that the data you most need lives in payroll, fleet and financial systems, and the value comes from reading those systems continuously rather than re entering their contents into another platform during the worst week of the year.

Force account labor is where most money is lost

Two traps. The first is the treatment of straight time versus overtime, which differs between emergency work and permanent work, and which means a jurisdiction that recorded only total hours has to reconstruct the split from payroll years later. The second is that eligibility depends on a written pay policy that existed before the event and that was applied uniformly, so an agency that paid people generously and informally during a response has created a problem no software fixes retroactively.

What a build does is force the split at entry. A crew member's hours land against an event, a category, a project and an activity, with straight time and overtime separated because payroll already knows the difference. Add the employee's classification and fringe rate from payroll rather than typing it, and the labor claim assembles itself continuously. The finance director stops rebuilding it and starts reviewing it.

Equipment hours at the right rate, recorded as they happen

• Equipment identified by asset number and matched to the published rate category, not described in words on a daily sheet.
• Hours split between operating and standby, because they are treated differently and nobody remembers the split later.
• The operator recorded, so equipment hours and labor hours reconcile rather than double claiming the same person.
• The activity and location tied to the same project reference the labor entry uses.
• Fuel and repair costs during the event kept separate, since claiming them alongside a rate that already includes them is a straightforward finding.
• Rented equipment kept in its own lane with the invoice and the procurement record attached.

Procurement evidence is the other half of the clawback

Contracts signed during a response are the most audited documents in the whole file, because the pressure to sign quickly and the federal requirement for competition point in opposite directions. The findings that recur are predictable: no documented basis for a non competitive award, contracts structured as cost plus a percentage of cost, no documentation of the price analysis, and no evidence that required contract provisions were included.

Handle it at execution. When a contract is created against a disaster event, the system asks how it was competed, captures the justification if it was not, records who approved it, attaches the solicitation and the responses, and flags prohibited structures before signature rather than after. Three years later the file is complete because it was completed at the time. This is the least glamorous feature in the build and it protects more dollars than any other.

What this costs and how long it takes

A first release covering event and project structure, force account labor capture with straight time and overtime separation from payroll, equipment hours against rate categories, and the document repository runs $60,000 to $130,000 and ships in 10 to 16 weeks. A full platform adding contract and procurement evidence workflow, insurance offset tracking, general ledger reconciliation, project worksheet assembly and export, multi funding source handling and the closeout and retention package runs $150,000 to $350,000 across 6 to 12 months.

Costs move with the number of source systems and how cooperative they are. Payroll is the important one and its export capability determines a lot. A hospital system or a utility usually has more complex labor rules than a city and correspondingly more work in the labor engine. Organisations with several separate operating entities under one claim, for example a county with a road district and a hospital authority, need entity separation designed in from the start rather than bolted on.

When to hire a consultant instead of building

If you have one event, a handful of project worksheets and no expectation of a repeat, hire an experienced public assistance consultant. They will pull the file together faster than you can commission software, they know what reviewers actually ask for, and their fee is small next to a build. That is the honest recommendation and we give it regularly.

The build case starts when the events repeat. A coastal county, a flood prone city, a utility that fights ice storms, a school district that has been through two events in five years: each of those has recurring exposure, an institutional memory problem, and staff who will otherwise rebuild the same evidence package from scratch every time. It also starts when your claims are large enough that a percentage of disallowed cost exceeds what a system costs, which for most organisations is somewhere above a few million per event.

How to choose a developer for cost recovery software

Ask them to describe how they would treat force account labor straight time. If they do not immediately distinguish emergency work from permanent work, they have not read the guidance and will build you a timesheet application with a disaster label on it.

Ask what they have integrated on the payroll side and name your system. Reading hours, classifications and fringe rates out of payroll reliably, at the granularity you need, is the load bearing integration in this build and everything else depends on it. Ask how they handle a correction made in payroll after the claim has been assembled, because that will happen and the answer should not be a manual re export.

Ask how the document repository proves completeness rather than just storing files: what is missing per project should be a report, not a discovery made at closeout. Then settle ownership before kickoff, including the repository of evidence documents, which must remain in infrastructure you control for at least the retention period. At Digital Heroes the organisation owns the code and the data from the first commit. Start scoping by taking your most recent closed project worksheet and timing how long it takes to reproduce its supporting documentation today. That number, multiplied by how often you get hit, is the case.