Reading Federal Software Spending Before the Street Does

July 19, 2026Gerra Research5 min read

The United States federal government is one of the largest enterprise software buyers in the world, and unlike almost every other software customer, it publishes its purchase records. Contract actions are reported through the Federal Procurement Data System (FPDS-NG) and surface publicly on USAspending.gov, which also exposes a documented public API. In principle, an equity researcher can watch a vendor win, expand, and renew government business while the vendor is still quarters away from reporting it.

In practice, the raw feed resists exactly the questions a researcher wants to ask. This note walks through the four problems that sit between the public records and a usable revenue signal, using Gerra's Federal Software Ledger as the worked example. The Ledger maps federal software procurement to 120+ public tickers through 500+ contractor mappings, with contract-level history from FY2018 to the present.

What the raw feed actually contains

A procurement record is an award action: an award ID, a contract vehicle, an awarding and funding agency, an obligated amount, a potential total value, a period of performance, and a free-text description. An award action is a legal event, not a revenue event. Every problem below follows from that mismatch.

Contract reporting itself now lives on SAM.gov, the official GSA system for federal contract opportunities and award records; USAspending is the transparency layer where the same data becomes publicly queryable.

Problem 1: the vendor field rarely names the vendor

Most commercial software reaches the government through resellers who hold the contract vehicle. On those records the prime contractor is Carahsoft, DLT Solutions, Thundercat Technology, or FCN, and the software vendor appears only in the description text. In the Ledger's published sample records, a CrowdStrike renewal at the Social Security Administration is a delivery order primed by DLT Solutions, identifiable only through the description "GSA DELIVERY ORDER FOR LICENSE SUBSCRIPTION RENEWAL TO CROWDSTRIKE SOFTWARE". The mapping entry for CrowdStrike alone lists seven distinct resellers.

Subsidiaries create the mirror problem. Microsoft's federal revenue arrives under Microsoft Corporation, Microsoft Federal, GitHub, LinkedIn, and Nuance entities. Oracle's includes Cerner and Oracle Health. Many vendors also transact through dedicated government entities such as Palantir USG, Datadog Federal, or Okta Federal, which do not always string-match the parent.

Resolving this takes three layers at once: legal contractor names including subsidiaries, known reseller lists per vendor, and keyword patterns over award descriptions. That is what the Ledger's 500+ contractor mappings encode, along with a prime_is_reseller flag on every record so reseller-attributed revenue is never silently mixed with direct awards.

Problem 2: ceilings, obligations, and outlays are three different numbers

Headline contract announcements usually quote a ceiling: the maximum potential value of a vehicle or multi-year award. The number that resembles booked demand is the obligation, the amount committed on a specific award action. Cash actually disbursed is an outlay, which lags both. Conflating the three produces revenue estimates that are wrong in both directions.

The gap is not small. One record in the published sample, a Department of Defense task order for Palantir's Maven Smart System, obligates $292.7M against a $480M potential total value. Treating the ceiling as demand overstates it; discarding it throws away a real signal about program scope. Both fields have to survive into the processed dataset separately, which is why the Ledger keeps obligated_amount and potential_total_value on every record and treats the task or delivery order, not the umbrella IDIQ vehicle, as the unit of analysis.

A related trap: a single obligation can fund years of service. That Maven order runs from mid-2024 to mid-2027. Mapping obligations to quarterly revenue requires the period of performance, not just the award date.

Problem 3: federal time is not calendar time and not disclosure time

The federal fiscal year starts October 1. An award dated November 30, 2024 belongs to federal FY2025 Q1, and the vendor will report it on its own fiscal calendar, which rarely matches the government's. Every aggregation needs to carry both clocks, so the Ledger retains raw dates alongside federal fiscal year and quarter fields.

More important for anyone backtesting: records do not surface on the award date. Across the published sample records, the gap between award_date and publication_date runs ten to eighteen days. A signal indexed on award dates uses information that did not exist yet; indexed on publication dates, it is honest. This is the same point-in-time discipline Gerra applies in its retail sentiment research, and it is the difference between a backtest and a story.

Problem 4: the forward signal is in expirations, not awards

Awards tell you what happened. The recompete calendar tells you what is about to happen. Every record carries a period-of-performance end date, and expirations cluster into windows where the incumbent either renews, often at a higher value, or is displaced.

The sample pipeline view for ServiceNow shows the mechanics: a Department of Veterans Affairs SaaS contract at $312.6M expiring in September 2026, whose predecessor award was $116.2M, a 169% increase at renewal. Tracking expirations inside 90-day and 180-day windows, and separating option exercises from new awards and modifications, distinguishes installed-base expansion from new-logo wins, and both from administrative noise.

From raw feed to research table

Raw feed realityWhat the processed record needs
Reseller listed as prime contractorResolved ticker plus a reseller flag
Vendor named only in free textProduct and category classification
Ceiling and obligation conflated in headlinesBoth values, kept separate
Award date is not publication dateA point-in-time publication field
Federal fiscal calendarFederal FY and quarter plus raw dates
Expirations scattered across recordsA recompete and option-exercise pipeline
The [Federal Software Ledger](/dataset/federal-software-contracts) ships this shape as contract-level records, quarterly ticker aggregations, and a pipeline tracker across cybersecurity, cloud, DevOps, analytics, and IT services vendors, on daily ingestion with weekly delivery in JSON, CSV, and Parquet. Representative records drawn from real USAspending awards are published in the data room in both delivery shapes: [JSON](/data-room/federal-contract/sample.json) and CSV.

Verify before you license

Whether you build this pipeline or buy it, the checks are the same. Reconcile a handful of records back to USAspending by award ID. Confirm reseller attribution on a vendor you know well. Confirm that a publication-date field exists at all, because without it no backtest survives scrutiny. What a serious inspection process looks like, for this or any dataset, is the subject of How to Read a Data Vendor's Data Room.