Check Whether Your Carrier Export Is Complete

To check whether you received a complete carrier export, reconcile the documented request with the actual files, parsed records and distinct identifiers delivered. A download button, a successful transfer or a matching row count alone cannot establish completeness. Preserve the original files, account for overlapping parts and compare membership with an expected list when one is available.

This guide helps research and sales operations teams answer one question before importing a trucking-company list: did this delivery contain the intended selection? The output is a delivery manifest with a specific acceptance state. It does not certify data accuracy, carrier suitability, current operations or buying need.

Define the delivery boundary before counting

A delivery boundary describes what the provider or internal exporter actually committed to supply. Start with the visible export description, agreed scope or existing job record. Record the selection and its version, the intended columns, the unit represented by each row, and whether the output covers a preview, a selected subset or the whole eligible result.

Keep four numbers separate:

• Search matches: records reported by a search at its observation time.
• Requested records: the scope chosen for this particular export.
• Delivered records: data records successfully parsed from the received files.
• Distinct entities: the resolved carrier identifiers represented in those records.

Those counts can legitimately differ. A search may show more matches than the selected export. One carrier may occupy several rows if the output is organized by contact, cargo or dated observation. A file part may overlap another part. Do not turn those differences into an accusation of missing data until the intended boundary is understood.

When the expected scope is not documented, use “delivery received; completeness unresolved.” Do not choose an expected count retrospectively just because it matches the file. The export evaluation guide covers the separate question of whether the delivered data is useful for your research.

Freeze the request and the evidence of receipt

Give the batch a local reference such as delivery-review-01. Keep the original files unchanged and examine working copies. Preserve the original filename, received time, byte size and source reference for each part. If your existing tools supply a file hash, record the algorithm and hash to distinguish byte-identical copies from changed files. A hash identifies file content; it does not certify the supplier or prove that the file contains every expected record.

Record the filter values as they were used, including inclusions, exclusions and date scope. A later screenshot of a search with different filters cannot explain the earlier export. Likewise, a current result count may have changed since the file was prepared. Match counts to the same selection and source snapshot where the provider makes that information available.

FMCSA's Open Data Program distinguishes datasets and their documentation. If an export is based on one of those datasets, identify the specific dataset and field definitions rather than treating all FMCSA-derived files as interchangeable. Your download time is evidence of receipt, not the date every carrier updated its record.

Do not repeat a paid purchase or restart a costly export just to investigate a count mismatch. First inspect the existing delivery record and files. This procedure is a manual review method, not a claim that USDOTData supplies a manifest, export-history screen or particular pagination feature.

Count parsed records, not visible lines

A spreadsheet's last occupied row is not automatically its data-record count. Headers, blank rows, import errors and repeated headers can affect what you see. A text file's physical line count is also unreliable when a quoted field contains a line break.

RFC 4180 documents a common CSV format, including optional headers and quoted fields containing commas or line breaks. It is an informational document, and actual exporters vary. Use an existing CSV-aware import method configured for the file's documented delimiter, quotation and encoding conventions. Do not split every line at every comma and assume the result is correct.

For each part, record parsed data records, the header interpretation, rejected records and any import warnings. Check that the expected columns survived import and that identifiers were preserved as identifiers. An import that completes while discarding malformed rows needs an exception count; “opened successfully” is not enough.

The carrier-data field dictionary helps establish row grain and field meaning. A carrier-level export and an inspection-level file can both contain a USDOT column but answer different questions. Do not deduplicate legitimate observations merely to force the count toward an expected entity total.

Classify repeated keys before combining parts

For a carrier-level delivery, compare the documented identity key across parts. Preserve the source values and the rule used to normalize accidental formatting differences. If a row lacks a resolvable key, keep it in an unresolved group rather than merging it by a similar company name.

Separate these cases:

1. Same key, same retained values: potentially an overlapping delivery row. Count its entity once in the combined view and retain the part references.
2. Same key, different values: a conflict or a legitimate different observation. Inspect dates, grain and the delivery specification before selecting a value.
3. Different keys, similar names: separate entities unless the source establishes otherwise.
4. Missing or malformed key: unresolved identity. Its presence counts as a received record, but not as a newly resolved distinct entity.

FMCSA's Company Snapshot supports a bounded check of carrier identity and recorded information. Checking one record there does not establish the membership or completeness of an entire commercial export.

Worked example: two 70-record parts, 120 entities

Fictional example. These are invented identifiers in a local exercise, not real USDOT numbers or an actual USDOTData export. The documented request is 120 distinct carrier entities, each with one row. The expected membership list contains C001 through C120, inclusive, and all files refer to the same fixed selection.

The two received parts contain:

• Part A: C001 through C070, giving 70 parsed data records.
• Part B: C051 through C120, giving 70 parsed data records.
• Overlap: C051 through C070, giving 20 repeated entity keys.

The combined delivery has 140 data records but 120 distinct keys: 70 + 70 - 20 = 120. The 20 overlaps have identical retained values in this example. Every expected key appears, and no unexpected key appears. After recording the overlap, the reviewer can accept membership completeness against this specified request.

That conclusion depends on more than the number 120. Change Part B so its final key is C121 instead of C120. The combined count remains 120 distinct keys, but one expected entity is missing and one unexpected entity is present. A count-only check would pass the wrong delivery.

The correct exception record is now:

Expected distinct keys: 120
Delivered distinct keys: 120
Expected keys received: 119
Missing expected key: C120
Unexpected delivered key: C121
Repeated delivery rows: 20
Membership result: unresolved mismatch

If no expected membership list had been supplied, the defensible result would be narrower: 120 distinct keys received and numerically consistent with the stated quantity, with membership completeness unverified. A sample cannot prove that every expected entity is present.

Resolve gaps without erasing the first delivery

Attach a correction or replacement to the original batch reference. State whether it supplements missing records, replaces one file part or replaces the entire delivery. Preserve enough evidence to explain why the combined membership changed.

In the example, a one-row supplement for C120 does not by itself settle the unexpected C121. The reviewer must also decide, under the original request, whether C121 is excluded from the accepted working set. Keep the received file unchanged; document the disposition in the working reconciliation.

If a replacement part contains newer source observations, do not call it a correction of the same snapshot without checking that premise. It may require a new batch version. The carrier-list snapshot comparison guide explains the later task of comparing genuinely different selections or dates.

Use a compact acceptance vocabulary:

• Complete against a documented membership list: all expected keys and required parts reconcile, with exceptions resolved under the stated scope.
• Count consistent; membership not independently verified: quantity agrees, but the expected identities are unavailable.
• Partial delivery: a documented part or expected member is missing.
• Delivery boundary unresolved: the request, row grain, source version or part relationship is unclear.
• Import unresolved: the received file cannot yet be parsed reliably enough to count.

These are recommended local workflow states, not provider guarantees or official FMCSA classifications. A partial delivery may still support a clearly labeled limited task if its owner accepts that scope. It cannot silently become “the complete market.”

Copyable delivery manifest

Keep one batch block and a short entry for every file part in your existing authorized system:

BATCH
Batch reference / reviewer / review date:
Intended research decision:
Request evidence and selection version:
Preview, subset or full selection:
Source dataset / snapshot date if supplied:
Documented row grain and identity key:
Expected parts / records / distinct keys:
Expected membership evidence, if supplied:

EACH PART
Original filename / receipt time / byte size:
Optional hash and algorithm:
Header, delimiter, quoting and encoding:
Parsed records / rejected records / warnings:
Distinct keys / unresolved identities:
Part relationship: supplement or replacement:

RECONCILIATION
Overlapping keys / conflicting observations:
Missing expected / unexpected delivered keys:
Acceptance state and its exact evidence:
Allowed next use / unresolved limitation:
Resolution owner / next trigger:

Before approving the import, another reviewer should be able to locate the request, reproduce the counts, distinguish receipt from membership and explain every unresolved difference. Keep sensitive business notes in the existing authorized system; the public example needs no real contact data.

Frequently asked questions

Does a successful download mean the export is complete?

It establishes that a file was received through that action. Completeness also depends on the request boundary, expected parts, reliable parsing and membership checks. A successfully downloaded preview is still a preview.

What if the search count and exported count differ?

Check whether they describe the same selection, time and unit. The export may intentionally contain a subset, while the displayed number may describe all search matches. Preserve both observations and resolve the stated scope before calling the difference a defect.

Can duplicate rows hide missing carriers?

Yes. Total rows can equal a requested quantity while repeated entities displace expected members. Compare distinct keys and, where available, the expected membership list. Keep conflicts separate from identical overlaps.

Can I prove completeness with a sample?

A sample can reveal parsing, identity or content problems. It cannot establish that every expected member was delivered. Use a full membership reconciliation when that evidence is available, or state the narrower count-based conclusion.

What should I do when a replacement file arrives?

Confirm which earlier part it replaces and whether its scope and source snapshot match. Retain both receipt records, then rebuild the accepted working set with the replacement rule. Do not append it automatically and count everything twice.

Does an accepted delivery mean the list contains qualified buyers?

No. Delivery acceptance describes what arrived. Accurate fields, relevant service fit and confirmed buying need require separate evidence. After reconciling receipt, evaluate the file for its intended research purpose and then measure outcomes using a fixed research cohort.

Next step

Choose one existing export and write its delivery boundary before opening the files. Reconcile the parts and identifiers, record the narrowest supported acceptance state, and pass unresolved questions to the person who owns the request. Start quality and fit evaluation only with that boundary visible.

By John Hauler, USDOTData's editorial persona. Sources reviewed October 12, 2026. USDOTData is an independent information service, not FMCSA. The manifest, acceptance states and fictional example are editorial recommendations, not an official certification or a promised product feature.