Broadband Grant Compliance Software: Proving Every Awarded Location Was Actually Served

The draw that sat for four months

A grants manager at an electric cooperative submits a reimbursement request for construction that happened in the spring. Six weeks later it comes back with questions. The state office wants invoices matched to the specific award, and the invoices from the boring contractor cover three jobs at once, only one of which is grant funded. It wants proof the material was domestically produced, and the supplier certification is in an email thread. It wants confirmation that the crews were paid prevailing wage, and the certified payroll is with the general contractor. The build data that would tie all of this to specific route miles lives in the GIS, in a construction management tool, and in a foreman's daily reports. The money is real and it is sitting still.

This is what broadband grant compliance actually is. It is not a reporting problem, it is an evidence assembly problem, and the evidence is generated by five different systems that were never asked to know which award they were working under.

The exposure is asymmetric in a way that catches operators off guard. Construction risk is priced and understood. Compliance risk is not, because the failure arrives years later as a finding, and by then the crews have moved on, the subcontractor is out of business, and the person who knew where the certification email went has left. Federal awards are administered under the Uniform Guidance at 2 CFR 200, and larger recipients also sit inside a single audit. Neither is satisfied by a folder called Grant Docs Final.

Problem 1: the unit of compliance is a location, and your systems do not think in locations

Modern broadband awards are written against serviceable locations. The obligation is not to build 400 route miles, it is to make a specific enumerated set of addresses capable of service by a date. The FCC Broadband Serviceable Location Fabric, maintained by CostQuest, is the reference layer that most of this rides on, and your award attaches to identifiers in it.

Your construction systems think in route miles, splice cases, and job numbers. Your OSS thinks in service addresses that you named yourself. Your GIS thinks in geometry. Nothing in that stack holds an awarded location list and reconciles it against what got built. So proving that location 12,847 out of 14,200 is now serviceable requires a human to look at a map, find the drop, find the terminal, and assert it.

A custom build makes the awarded location the primary object. Every location carries its award, its obligation date, its current status, the network element that will serve it, and the evidence attached to that status. When a splice crew closes a job, the locations that job serves flip status automatically because the build data is joined to the location list rather than sitting beside it. That join is the entire product, and it is why generic grant management tools do not solve this.

Problem 2: every draw is an evidence assembly job done backwards

A reimbursement draw asks a simple question: what did you spend, on what, and prove it. Answering it requires cost coded to the award, invoices matched to those costs, proof the work happened, and proof it happened under the conditions attached to the award. Most providers assemble this after the fact, going back through the accounting system and hunting for supporting documents.

Doing it forward is not harder, it is just a decision nobody made at the start. Purchase orders carry the award code from issue. Invoices attach to the PO and to the construction job. Daily reports and photos attach to the job. When it is time to draw, the package assembles itself and the grants manager reviews rather than researches. In our experience with document heavy compliance builds, this is the change that takes a draw cycle from weeks of work to a day of review, and it is entirely a data modelling decision made early.

The other half is the reconciliation nobody wants to do: costs that belong partly to the award and partly to a private build in the same trench. Allocation has to be documented and consistent, and it has to survive somebody asking about it three years later. A build handles this with an explicit allocation rule per cost object, recorded once, applied everywhere, and visible in the audit view.

Problem 3: the reporting template changes and your spreadsheet does not

Reporting formats move between funding rounds and between programs. A BEAD subgrantee reports differently from a USDA ReConnect borrower, and both differ from a state program with its own rules. Separately you are filing Broadband Data Collection availability data to the FCC on its own cycle, and the availability you report there should agree with the locations you claim as served in your grant reporting. When it does not, somebody notices.

Providers handle this with a spreadsheet per report, rebuilt each period, which guarantees that the same underlying fact gets stated three different ways. A build separates the data from the template: locations, costs, milestones, and evidence live in one model, and each report is a mapping over that model. When the state issues a revised template, you change the mapping, not the data, and every historical report can be regenerated on the new format. That regeneration ability is worth more than it sounds, because a mid program template change otherwise means back filling by hand.

Problem 4: labor, procurement and environmental conditions are compliance too

The award conditions extend well past build and spend. Build America Buy America requirements mean domestic content documentation for materials. Davis-Bacon prevailing wage means certified payroll flowing up from every subcontractor on a schedule. Environmental and historic review under NEPA and Section 106 of the National Historic Preservation Act means clearances tied to specific route segments before ground is broken. Cybersecurity and supply chain risk plans get attested to. Some awards carry low cost service plan and workforce commitments that have to be evidenced periodically.

Each of these has a different owner, a different cadence, and a different document type, and every one of them is a finding waiting to happen. The practical fix is boring: an obligation register where each condition is an object with an owner, a frequency, a required artifact type, and a status, wired to notifications that fire before the deadline rather than at it. Certified payroll that is not in the system by the fifteenth generates a chase to the subcontractor automatically. Clearance status blocks a construction job from being marked ready in the field app. That is compliance as a control rather than compliance as a report.

Problem 5: clawback is a records problem, not a construction problem

Providers tend to assume the risk is failing to build. The realistic risk for a competent operator is having built and being unable to prove it to the standard the reviewer applies, four years after the fact, when the reviewer is looking at a sample of locations and asking for the evidence chain on each.

The design implication is that your compliance system is a records system first. Evidence should be immutable once accepted, with an append only history, so nobody can quietly replace a photo or backdate a certification. Every status change records who made it, when, and on what basis. Retention should outlive the award period by years because the audit window does. And the export has to be complete and self describing, because the reviewer will not log into your system, they will want a package.

What Ready.net, CostQuest and Sitetracker actually do

These are not interchangeable and it is worth being precise. CostQuest is the location data authority: the Fabric that defines what a serviceable location is. You are almost certainly consuming its data regardless of what else you buy, and you are not going to build a replacement. Ready.net is aimed at the mapping, challenge, and program administration side and is genuinely useful for state offices and for providers navigating award processes. Sitetracker is a capable deployment operations platform for telecom and utility build programs, strong on project and asset execution.

The gap is the join. Ready.net knows locations and program processes but not your accounting, your certified payroll, or your splice records. Sitetracker knows your build execution but does not model an awarded location list with per condition obligations and draw evidence. CostQuest supplies the reference layer and nothing else. What a custom build supplies is the layer that sits across all three plus your ERP (Enterprise Resource Planning) and GIS, holds the award as the organising object, and produces the package. Very often the right answer is a build that integrates these rather than replaces them, and any developer who proposes rebuilding the Fabric should be shown the door.

What this costs and how long it takes

A first release with the awarded location register, status derivation from build data, evidence capture, and draw assembly runs $60,000 to $140,000 over 10 to 16 weeks. A full platform adding the obligation register for labor, procurement and environmental conditions, template driven reporting per program, subcontractor portals for certified payroll, and integration with accounting and GIS runs $150,000 to $400,000 phased across 6 to 12 months.

What pushes cost up here specifically: the number of distinct awards and programs, because each brings its own rule set and template; how many subcontractors have to submit documents, since each one needs a low friction path or they will keep emailing; the state of your GIS, because deriving served status from network data requires the network data to be trustworthy; and whether your accounting system will expose cost detail cleanly, which for an older cooperative ERP can be a project in itself. What keeps cost down: model one award end to end before generalising, and accept manual status flips in release one while the automated derivation from build data is proven in parallel.

When not to build, and how to choose a developer

Do not build for a single award under a few million dollars with one reporting template and a handful of subcontractors. A disciplined shared drive structure, a named owner, and a calendar will carry you, and the software would cost more than the exposure. Do not build if your award is still in the application phase and nothing is under construction, because you would be modelling rules that are not final.

When you do build, ask the developer to whiteboard the data model before you sign. They should draw the awarded location as the central object, with award, obligation, cost, evidence, and network element hanging off it. If they draw projects and tasks, they have built a project tracker and are about to learn grant compliance on your money.

Ask specifically how they will handle a cost that is split between a grant funded route and a private build in the same trench, and listen for an explicit allocation rule recorded once and applied consistently. Ask how evidence is protected from later edits, and expect to hear append only history rather than a permissions answer. Ask what they have integrated: an older cooperative accounting package, Esri, and a construction management tool are three different problems.

Ask who owns the code, the data, and the cloud accounts, and get it in the contract before kickoff. At Digital Heroes the client owns everything from the first commit. The right next step is to take one award, pull the last draw package you submitted, and ask a developer to show you exactly which parts of it their model would have assembled without a human hunting for documents.