Wildland Fire Contractor Software: Why a Good Season Still Leaves Your Invoices Unpaid in February

Why the paperwork is the product

A wildland fire contractor sells availability and hours. The work itself is done by people who are good at it and who mostly do not want to think about documentation. But the actual product you deliver to the government is not the line you cut, it is a stack of signed forms that proves the line was cut, by whom, on which incident, under which resource order, at which rate, for how many hours, with the correct inspection status on the equipment.

If the stack is complete, you get paid. If it is missing a signature, has a rate that does not match the agreement, shows an operator who was not on the inspection, or reaches the incident finance section after demobilization, it goes into a loop that runs weeks and sometimes months. Contractors tell us the same thing every season: the fire was the easy part, and the money from August lands in December.

The systems that exist here are government systems. IROC handles resource ordering from the agency side. eISuite handles incident business at the incident. Both are competent at what they were built for, which is the government's view of the transaction. Neither is built for you. As a contractor you interact with them through paper handed across a table at a camp, through a resource order number written on a form, and through whatever the incident business advisor tells you. There is no vendor-side portal that carries your rates, your resources and your invoice through the process, so contractors run the whole thing on carbon forms and a spreadsheet that lives on the owner's laptop.

Problem 1: the shift ticket is written in the rain

An emergency equipment shift ticket records the resource, the date, the hours worked or the mileage, the incident, and a government signature. It is written at the end of a shift by a crew boss or engine boss who has been awake for sixteen hours, on a carbon form, often in weather, and signed by whichever government representative is available. Then it travels: one copy to the incident, one copy into a truck cab, one copy that should reach your office.

The failure modes are predictable and they are all documentation, not performance. The copy in the truck cab gets wet. The signature is from someone whose printed name is illegible and whose position is not clear, so finance cannot verify authority. The hours were recorded against the wrong resource order because the engine got reassigned mid-assignment and nobody updated the number. Two tickets exist for the same shift because a relief operator also wrote one. Your office assembles the invoice from what arrives, and what arrives is not everything.

What a custom build does: the shift ticket is captured on a phone in camp with no signal, including a photographed signature and the printed name and position of the signer, then syncs when the device reaches connectivity, which for most crews is the drive out or a spot in camp. Resource order number and incident come from the assignment record rather than being written from memory. Duplicate detection runs on resource plus date, so two tickets for the same shift surface immediately instead of in reconciliation. The paper still gets written where the incident requires it, and your system stops depending on the paper surviving.

Problem 2: your agreement rates are not what the invoice used

Rates come from your agreement. For equipment under a competitive procurement agreement there is a rate for the resource type, and there are conditions: with operator or without, daily rate versus hourly, special rates for particular circumstances, mileage, and adjustments that apply in some situations and not others. Different agreements, different agencies and different years carry different numbers. A contractor with engines under one agreement, a tender under another and a falling module under a third is maintaining three rate structures in their head.

What happens in practice is that the office bills from the last invoice, because the last invoice was accepted. That works until an agreement is renewed at a new rate, or until the incident applies a rate you did not expect and the difference is only discovered at payment. Then you are arguing a variance months after the fact with nobody present who remembers the assignment.

What a custom build does: agreements become structured records with resource types, rate lines, effective dates and conditions. The invoice is calculated from the agreement in force on the date of the shift, not from last time. When the government pays a different amount, the system records the variance per line rather than at the invoice level, which is what turns a dispute from an argument into a table you can send. That table is the single highest-leverage output of the whole build, because a variance you can point to gets resolved and a variance you can only describe does not.

Problem 3: crew time has to satisfy payroll and the invoice at once

The emergency firefighter time report is the government's record of hours for a crew. Your payroll is a separate obligation under wage and hour law, and it is unforgiving: overtime, travel time, rest requirements, per diem and, for crews on some assignments, prevailing wage determinations. The two records describe the same hours and are produced by different processes, which means they diverge, and when they diverge you are exposed on both sides.

The common workaround is that the crew boss fills out the government form in camp and a bookkeeper re-enters the hours into payroll from a photograph of it three weeks later. That re-entry is where errors enter, and it is also why payroll for a July assignment sometimes lands in September.

What a custom build does: hours are captured once per person per day against an assignment, and both the government time report and the payroll export are generated from that single record. Rest and shift length rules can be checked at entry, so a crew boss is warned about a length-of-assignment issue while there is still time to do something about it rather than after an audit. If your payroll runs through a provider with an API, the export is automatic. If it does not, a clean file beats a photograph every time.

Problem 4: availability and inspection status decide whether you get ordered

Before a single hour is billed, you have to be orderable. That means the resource is in an available status, the equipment has passed its inspection, and the people assigned to it hold current qualifications for the position they will fill. Miss any of those and your resource is passed over, or worse, arrives at an incident and is refused, which costs you the mobilization and your standing with that dispatch center.

Contractors typically track this in a wall calendar and the owner's memory. Qualification currency, medical and physical fitness testing, and equipment inspection dates all have expiry, and they expire in the off season when nobody is looking. The first week of a busy season is when everyone discovers what lapsed.

What a custom build does: qualifications, medical currency and inspection dates are records with expiry, and the system runs the calendar backwards from your season start so that renewals are scheduled in March rather than discovered in June. Resource availability is a state you maintain deliberately, with a log of when you set it and why, which also gives you a defensible answer when a dispatch center asks why you turned down an order. The compounding benefit is that this data is the same data your invoices depend on: the person on the time report is the person whose qualification the system already knows.

Problem 5: cash is trapped between demob and payment

The gap between a resource demobilizing and money arriving is where contractors go under. You have paid crews weekly all season. You have fuel, maintenance, insurance and a payment on equipment. The receivable sits at an agency, incomplete, waiting on a signature nobody chased, and you cannot tell your bank when it will land because you genuinely do not know.

What a custom build does: every assignment carries a state from mobilization through demob, invoice submitted, and payment received, with an owner and an age. The aging report is by incident and by agency, so you know that one incident's finance section is sitting on four invoices and another paid in three weeks. That visibility is not glamorous and it is what lets you have a real conversation with a lender in October rather than a hopeful one. It also tells you, at the end of the season, which agreements and which incidents were actually profitable once you account for how long the money took, which is a question most contractors cannot currently answer.

What this costs and how long it takes

A first release covering assignment records, offline shift ticket and crew time capture, agreement rate application and invoice generation with a variance table runs $45,000 to $110,000 and ships in 10 to 14 weeks. Building it during the off season is strongly preferable, and if you come to us in July we will tell you to wait. A full platform adding qualification and inspection currency, resource availability management, payroll export, equipment maintenance and cost tracking, and season profitability reporting runs $130,000 to $300,000 phased across 5 to 10 months.

What drives cost up here: the number of distinct agreements and agencies you work under, because each rate structure is its own set of rules and test cases. Multiple resource categories, since an engine, a hand crew and a falling module have genuinely different billing shapes. Payroll complexity, particularly if you are subject to prevailing wage determinations on some assignments. And offline reliability, which is not optional in this business and which we would rather you pay for properly than discover the limits of at a camp in Idaho.

What keeps cost down: doing one resource category first. Get engines right through a full season, then add crews. The learning transfers and the risk does not compound.

Build versus buy, and when to just stay on paper

Stay on paper if you run one or two engines and a bookkeeper who knows the forms. At that size the binder works, the owner personally sees every ticket, and software would be a cost with no corresponding leak to plug. Stay on paper for one more season if you are in the middle of one, because a half-adopted system during a busy August is worse than a well-run carbon form.

Build once you field more than roughly eight resources, once you work under more than two agreements, or once you can no longer answer from memory which invoices are outstanding and why. Build if you have ever had an invoice rejected for a missing signature and not discovered it for a month. Build if your crews and your equipment are dispatched by different people and the two schedules have collided.

Our view on the government systems: do not wait for IROC or eISuite to solve this. They will not, because it is not their job. They exist to run the agency's ordering and the incident's finance, and your side of the paperwork is out of scope by design. A contractor-side system that produces clean, complete, correctly rated submissions into that process is the only version of this that works, and it is entirely achievable.

How to choose a developer for wildland fire contractor software

Ask them what happens when a device has no signal for nine days. If the answer is that data is cached, ask the follow-up: what happens when two crew bosses on the same engine both create a shift ticket for the same date while disconnected. A developer who has built for genuinely disconnected field work will describe the conflict resolution and ask you which one should win. That question sorts the field quickly.

Ask how they will model agreement rates. The correct model has effective dates and conditions, because rates change between seasons and your historic invoices have to remain reproducible. A single rate field on a resource type means you will lose your own history the first time an agreement renews.

Ask whether they will build for the crew boss or for the office. This system lives or dies on whether a tired engine boss will use it at the end of a shift, which means very few taps, very large touch targets, and no required field that a person in the field cannot actually know. If the demo looks like an accounting screen, it will not survive a fire.

Ask who owns the code, the repository and the hosting, in writing, before kickoff. At Digital Heroes it is yours from the first commit. Then pick your off season and start in October, not in June.