Mutual Aid Resource Request and Reimbursement Software: From the 1am Phone Call to the Settled Invoice

One in the morning, and the request is a phone call

Landfall was six hours ago. The state coordinator is working a list of counties that need swift water rescue capability and a shorter list of places that might have it. Every allocation happens by phone. He asks a neighbouring region for three teams, is told maybe two, calls back forty minutes later to confirm, and by then the region has committed one of those teams elsewhere because a different coordinator called them directly. Nobody is at fault. There is no shared record, so two people are allocating the same resource in parallel.

Somewhere in the next eight hours, teams start moving. Some check in at a staging area. Some drive straight to a county that asked for them privately. Three days later a team demobilises and goes home without telling anyone, and its home jurisdiction begins accruing costs it will invoice for later. Four months after the event, an invoice arrives claiming twelve operational periods for a team the receiving jurisdiction believes was there for eight, at a rate nobody recognises, and the argument that follows is settled by whoever kept better notes on their phone.

A resource request is a contract, and almost nobody writes it down

What is actually happening in that 1am call is contract formation. One party asks for a defined capability for a defined period, another party offers it at a defined cost, someone accepts, and financial obligations attach to that acceptance. Every element that will be disputed later, what was asked for, what was offered, what was accepted, when the clock started, what rate applies, is agreed verbally and recorded nowhere in a form both sides hold.

The systems in use do not close this because they were designed for a different job. They record that a request exists, or they record the incident, or they record what a jurisdiction has in its inventory. None of them is the shared, mutually visible instrument that both jurisdictions can point at nine months later. That instrument is what a custom build produces, and it is the reason the finance directors on both sides will support the project even when the operations people are ambivalent.

Where the EMAC Operations System, WebEOC and Veoci stop

The interstate compact's own operations system is the required path for state to state requests and it is competent at that specific job. What it does not cover is everything inside your state: county to county, region to region, special district to city, and the local agreements that carry the overwhelming majority of movements in any real event. It also does not connect to your own credentialing, fleet or payroll data, so the package you eventually assemble for reimbursement is compiled by hand from its records plus yours.

Juvare WebEOC is entrenched for good reasons and has resource request boards that many states have configured heavily. The constraint is that a board is a communication surface rather than a state machine: it shows the request, it does not enforce that a resource cannot be committed twice, and it does not carry the resource from acceptance through arrival, operational periods, demobilisation and invoice as one object with one clock. Veoci is more flexible and will let you build closer to that shape, at the cost of building it inside their abstraction and hitting the usual friction when you need to reach into credentialing systems and financial ledgers.

Typing is only useful if it means the same thing on both sides

Everyone nods at resource typing until an event happens and a type three engine arrives with a crew of two, no breathing apparatus for wildland work, and a pump rating that does not match the definition the requesting jurisdiction had in mind. The typing framework is national and the language is common, but the actual capability behind it is claimed by the sending jurisdiction and inspected by nobody until it shows up.

A build fixes this by making the typing claim explicit and attributable. The sending jurisdiction registers the resource with its type, its components, its crew composition and the date the claim was last verified. The request specifies the type and any additional requirements. The acceptance binds a specific registered resource to a specific request, so the receiving jurisdiction knows the tail number, the crew size and what was claimed before it arrives. When the claim turns out to be wrong, that is recorded against the resource rather than argued about in a parking lot, and it informs the next event.

Credentialing has to be answerable at the gate

• Personnel qualifications for the position each person is deploying as, with expiry dates, verified before departure rather than at the checkpoint.
• Medical and licensure status where the position requires it, particularly for clinical and rescue roles crossing state lines.
• Vehicle and equipment inspection status, because an apparatus that fails inspection at a staging area is a resource you counted and do not have.
• Background and access requirements for the receiving jurisdiction, which differ and are usually discovered on arrival.
• A check in and check out record at the staging area that produces the arrival and departure timestamps the invoice will later depend on.

The last item is worth more than it looks. Arrival and departure timestamps, captured by the receiving jurisdiction at a physical point, are the single most useful piece of evidence in any later dispute, and they cost almost nothing to capture if somebody is standing there with a device anyway.

The clock is the whole financial argument

Mobilisation begins when the sending jurisdiction is authorised to move, not when the request was made. Travel time is treated differently from operational time in most agreements. Operational periods are defined by the incident, not by calendar days. Demobilisation and return travel are usually claimable. Rest periods may or may not be. Every one of these boundaries is a place where two jurisdictions can honestly disagree by thousands of dollars per resource per day.

So the system has to carry a single, shared, timestamped state history per deployed resource: requested, offered, accepted, authorised to move, departed, arrived, assigned, reassigned, released, departed for home, returned. Both jurisdictions see the same history. Amendments are amendments, visible with who made them and when, not silent edits. Do that and the four month old invoice argument becomes a five minute reconciliation, because the facts are not in contention.

Rates and the reimbursement package

Rate schedules come from your compact, your local agreements and the applicable federal rate references, and they differ by resource class, by jurisdiction and sometimes by event declaration status. Encode them as versioned data with effective dates, because the schedule that applied during a spring flood is not necessarily the one in force when the invoice is finally assembled in the autumn.

Then generate the package rather than compiling it. Personnel hours by position and rate, equipment hours by type against the applicable rate schedule, travel and per diem, consumables, and the supporting evidence for each line: the accepted request, the check in and check out records, the activity logs, the demobilisation record. The receiving jurisdiction gets the same package and can see the same evidence, which is what turns a dispute into a review.

What this costs and how long it takes

A first release covering the request and offer workflow with a shared state machine, resource registration with typing claims, acceptance binding and the check in and check out record runs $70,000 to $150,000 and ships in 12 to 18 weeks. The full platform adding credentialing verification, the versioned rate engine, the reimbursement package generator with evidence assembly, dispute handling, and integrations into payroll, fleet and financial systems runs $180,000 to $400,000 across 7 to 12 months.

Two things drive cost here that do not appear in most public safety projects. The first is multi party visibility: this is not one agency's system, it is an instrument several independent jurisdictions rely on, which raises the bar on access control, on amendment history and on what one party can and cannot see about another. The second is onboarding, because a compact administrator with eighty participating jurisdictions has eighty conversations about resource registration ahead of them, and budgeting for that programme work is as important as budgeting for the software.

When you should not build

Do not build if you are a single receiving jurisdiction. Your problem is keeping clean records of what arrived and when, which you can do with disciplined check in procedures and the tools you already have. Do not build if your mutual aid activity is a handful of movements a year between two agencies that trust each other and settle informally.

Build when you administer a compact or a regional agreement, when a single event generates enough deployed resources that allocation by phone breaks down, when reimbursement disputes routinely run past a quarter, or when you cannot answer, mid event, the basic question of which resources are committed and which are still available.

How to choose a developer

Ask them to draw the state machine for a deployed resource on a whiteboard, from request through return. If the states they draw are open and closed, they are building a ticketing system and your financial arguments will be unchanged. The right answer distinguishes offered from accepted, authorised from departed, and arrived from assigned, because those distinctions are exactly where the money sits.

Ask how two jurisdictions see the same record without either being able to quietly alter the other's view, and listen for amendment history rather than edit permissions. Ask how they version rate schedules by effective date. Ask what they have integrated on the payroll and fleet side, since the labor and equipment evidence has to come from systems of record rather than from typed entries.

Then settle ownership before kickoff, and be specific about the multi party case: the administering authority should own the code and the platform, and each participating jurisdiction should have a documented right to export its own data. At Digital Heroes the client owns the code from the first commit. Start scoping by taking your last event, picking five deployed resources, and reconstructing their full timeline from what you hold today. Where that reconstruction fails is your specification.