Download Old Dominion Invoices: Portal and PDF API

To download Old Dominion invoices, start with View Invoices on ODFL.com and the account entitled to the billing records. For recurring collection, Old Dominion also publishes a native Document API that explicitly supports Invoice PDFs. Do not assume browser automation is the only way to obtain them.

This guide uses official ODFL pages and the Document API v1.0 guide dated June 4, 2026, checked on November 9, 2026. It is a documentation-based guide; no customer-account download, API request, or BrowserAct ODFL collector was tested.

Enter View Invoices from the official resources page

Old Dominion's Invoices and Claims page provides View Invoices separately from payment and claims actions. It describes viewing current or past invoices, or looking up an individual invoice by PRO number.

Use this starting sequence:

1. Open Resources, then Invoices/Claims on ODFL.com.
2. Select View Invoices and sign in through the supplier's account flow.
3. Locate the required current, historical, or PRO-specific record.
4. Inspect the invoice output available in the account and save the needed document.

The public entry point was verified; the authenticated download controls and multi-invoice packaging were not. This article therefore does not promise a particular ZIP, batch limit, or signed-in button layout.

For a multi-carrier workflow, use the vendor-portal collection guide to define the expected records before collecting them. Preserve the PRO reference along with the invoice identity and the intended billing-account scope.

Distinguish invoice access from shipment-document access

ODFL's official shipping FAQ places BOL and POD documents in tracking-PRO details, logged-in shipment details, or Shipping Documents. Those are useful supporting records, not substitutes for the invoice.

The native API's permission table adds an important distinction. Invoice access requires a username associated with the shipment's bill-to party. Some other documents, including BOL and delivery receipt, can be available to a linked shipper or consignee as well.

If a user can see a delivery receipt but cannot retrieve an invoice, that difference may reflect the account relationship rather than a file-generation failure. Resolve access for the exact document type before repeatedly requesting the same PRO.

Consider the native Document API for invoice PDFs

The Shipping API Integrations page links the current REST Document service. Its development guide specifies a PRO number, document type, and format for a document request. Invoice is a listed type and PDF is the documented output format.

The response example contains encoded document data, so an integration must save the actual document bytes rather than place a JSON response in the invoice archive. The guide also describes one-hour authentication tokens and a recommended maximum of 12 requests per PRO per hour. Build retries around availability and permissions instead of repeatedly requesting an unavailable document.

This is a real native alternative, not a hypothetical API inferred from ODFL's shipment tracking. A developer should verify the company's authorization and downstream file requirements before choosing a browser-based replacement.

The current integration page says SOAP endpoints are scheduled to retire on March 1, 2027. A new collection project should evaluate the documented REST route rather than copy an old SOAP integration simply because it already appears in a search result.

Preserve preliminary and changed invoice versions

ODFL's Document API guide explicitly describes an invoice as a snapshot that can change. It also explains preliminary invoices and says new usernames have preliminary access by default, with access changes handled through customer support.

This changes the archive's completion rule. The first PDF returned for a PRO should not automatically become the permanently final invoice. Record when it was obtained and the information available about its status. Where a later supplier document differs, preserve the relationship between versions rather than silently overwriting the first file.

Hash comparison can show that bytes changed, but it cannot decide which invoice version the finance process requires. Conversely, a repeated identical PDF does not prove the supplier has finalized the charge. Those decisions belong to the business checks around the file, not just the download transport.

When the API says the invoice has not yet been generated, keep that outcome distinct from “not authorized” or “document not found.” They require different follow-up. A retry after availability changes may be appropriate; repeatedly using the same credentials cannot fix an account-entitlement problem.

Use email or portal exceptions where they fit

ODFL's invoices page offers email-invoice signup. Its shipping FAQ also points to document APIs and sFTP support. Check whether the company already receives a usable native feed before adding a new collector.

Portal work can still be useful when a finance employee needs a targeted historical record or a missing supporting document. Keep that exception list specific: PRO, requested document, account context, expected version, and observed outcome. A folder containing BOLs and delivery photos should not mark outstanding invoice requests complete.

BrowserAct can be evaluated for authorized portal work and consistent handoff across several suppliers. An ODFL-specific Bot would still require proof of the real file output, account permissions, and version-aware repeat behavior. No tested Bot or ready-made template is provided here.

The invoice downloader comparison helps compare original-document collection approaches. To download Old Dominion invoices repeatedly, choose the native route that meets the requirement first, then test BrowserAct for any remaining portal gap.