Count awards and actions without double-counting

Published by Federal Bid Partners LLC · October 26, 2026 · Data structure

One contract can produce many reported actions. USAspending's analyst guide distinguishes award summaries from the related transactions rolled into them. Its official API documentation also exposes transaction-level details, including amount, action date, modification number, and description. Decide whether you are counting unique awards or actions before interpreting a row count. Read the award-summary explanation; review the official transaction endpoint documentation.

Write the unit of analysis at the top

Use a sentence such as “One row represents one reported contract action in this file” or “One row represents one award summary.” Confirm the sentence against the actual download documentation. A spreadsheet with 1,000 rows is not meaningful until you know what those rows represent. Keep the original file unchanged while you work in a separate analysis copy.

In a fictional file, Harbor Insights finds 12 rows associated with three award keys. One award has eight actions, another has three, and the third has one. The file contains 12 actions and three unique awards. Reporting 12 contract wins would overstate the result. Reporting only three actions would also be wrong. The correct count depends on the question.

Preserve the full documented identifiers

Retain the source's documented unique award key and action identifiers rather than inventing a key from a shortened display number. Keep parent-award references and agency identifiers when the source includes them. A visually familiar contract number may not capture every element required to distinguish records. Use official field definitions when joining files.

• Count raw rows before filtering.
• Count unique award keys separately.
• Inspect duplicate-looking rows before deleting them.
• Document which fields identify an action in the source.
• Check whether a join multiplies rows unexpectedly.
• Save a small worked sample that demonstrates the logic.

Test a join before scaling it

Suppose Harbor joins an award-summary table to a transaction table. The first contains one row for award A; the second contains eight actions for A. The joined result correctly has eight rows for that award. But any award-level total copied onto every joined row is now repeated. Summing that total would multiply it by eight.

Choose the measure at the same level as the calculation. For an action-based total, use the documented action measure. For a count of awards, count distinct documented award keys. For an award-level attribute, select a clear rule for the relevant record or summary. Write the rule into the analysis note instead of relying on an undocumented spreadsheet trick.

Keep parent vehicles out of accidental totals

Create a separate category for vehicles and their orders. Do not casually add a vehicle's potential value to the values of orders issued under it. Preserve the relationship for research, but aggregate only the defined population and measure. A hierarchy is a relationship, not an instruction to add every amount displayed at every level.

Finish with a reconciliation: raw rows, exclusions, remaining actions, distinct awards, and the amount field used. If another researcher cannot reproduce these numbers from your saved file and rules, the analysis needs more documentation. A small trustworthy count is more useful than a large unexplained one.