Does EDI 840 Still Work for Freight RFQs?

Does EDI 840 Still Work for Freight RFQs?

Technically, yes. In practice, almost nobody uses it that way anymore. EDI 840 can carry a request for pricing on goods or services, and nothing in the X12 spec stops you from stuffing lane and equipment data into it. But freight carriers didn't build their systems around it, and most shippers solicit carrier rates through TMS tender modules or carrier portals instead, leaving the EDI 840 request for quotation pair to industrial and government procurement of physical goods.

What does an EDI 840 transaction actually contain?

An EDI 840 opens with a BQT segment that sets the context for the whole request, stating the purpose, the quote request number, and the date. From there, the transaction moves into the detail section built around the PO1 loop, where the mandatory PO1 Baseline Item Data loop specifies each line item being quoted. Optional segments round out the picture. CTP and DTM segments allow buyers to communicate pricing expectations, delivery date requirements, and other commercial terms relevant to the RFQ. A full breakdown from SPS Commerce adds REF and PER segments for reference numbers and contact details. Here's the thing to notice: every one of those segments assumes you're quoting discrete items with quantities and unit prices, not origin-destination pairs with equipment types and transit windows. That's not an accident. The 840 was designed for buying parts, components, and materials, not buying truck capacity.

How does the EDI 843 response complete the quote-to-order cycle?

The supplier answers with an EDI 843, which carries the actual numbers the buyer needs to make a decision. A supplier sends it in reply to a buyer's EDI 840, and it carries everything the buyer needs to act: line-item pricing, product details, terms, availability, and quote validity dates. The transaction opens with a BQR (Beginning Segment for Response to Request for Quotation) rather than BQT, but otherwise mirrors the structure of the request it's answering. The 843 doesn't stand alone. In the standard EDI transaction chain, the 843 sits between the request and the order: 840 (RFQ) → 843 (quote) → 850 (purchase order). Before any of that business content arrives, though, a technical acknowledgment usually runs first. That 997 only says the file arrived and parsed. The business answer, the actual quote, comes back as the 843. If you're debugging a stalled quote cycle, that distinction matters: a clean 997 tells you the connection works, not that the supplier has quoted anything yet.

Why don't freight carriers use 840/843 for rate requests?

Because the 840/843 pair was never built for lane-level freight data, and almost no carrier trading partner spec supports it that way. A freight RFQ needs origin and destination pairs, equipment type, weight or pallet count, accessorials, and often multi-stop routing. The PO1 loop in an 840 wants a product ID and quantity, not a lane. You can force the mapping, but you're fighting the standard the whole way. This is also a document pair that's thin outside of a few verticals to begin with. The 840 and 843 pair is comparatively rare in live B2B trading, and it is worth being honest about that. Most quoting today happens by email, supplier portal, or a CPQ tool, not by exchanging X12 documents. Where it does show up, it's concentrated in a specific kind of buyer. The 840 tends to show up in mature procurement operations, government contracting, and industries where sourcing is already fully EDI-driven and buyers want quote responses to load straight into a bidding system. Freight procurement isn't usually one of those industries. It evolved its own separate tooling instead, built around tender and spot-rate workflows rather than the goods-procurement RFQ/RFP chain.

What do shippers actually use for carrier rate requests today?

Most shippers now run rate requests through TMS tender modules, carrier portals, or multi-carrier platforms that broadcast a single request to many carriers at once. Platforms like MercuryGate, Descartes, Transporeon, and Alpega all offer RFQ or spot-bid functionality built specifically around lane, equipment, and volume data, rather than repurposing a goods-procurement document. A comparable pattern shows up in carrier-connectivity software such as Cargoson, where query mode lets you create a transport request without specifying a carrier yet, allowing you to manually compare carrier prices and delivery times and request new spot prices before locking in a booking. That's functionally the same quote-to-order sequence the 840/843 pair handles for goods, just purpose-built for freight and typically running over API with EDI as a fallback rather than EDI-first.

Can a TMS or carrier-connectivity layer automate RFQs without classic EDI 840?

Yes, and this is how most mid-size and large shippers run freight RFQs today. A carrier-connectivity layer normalizes the rate request regardless of whether the carrier on the other end speaks API, EDI, or just logs into a portal manually. You send one request; the platform fans it out and brings responses back in a consistent format you can compare side by side. Platforms such as Cargoson, FreightPOP, Uber Freight, and Shiptify all operate on this pattern: broadcast once, normalize the response, let the shipper pick. The practical benefit is that you're not waiting on every carrier to implement an RQ840 spec before you can automate anything. For spot freight specifically, this matters because for complex shipments or special cases, carriers review your specific requirements and provide a custom quote, and that review process rarely fits neatly into a rigid X12 transaction set anyway.

Should you build 840/843 support if a trading partner specifically requests it?

Build it, but build it to spec and don't assume it generalizes to freight. If a government buyer or industrial customer mandates 840/843, follow the DPAC guidance or the relevant X12 version your partner specifies rather than guessing at segment usage. Government implementations in particular carry their own acquisition instructions layered on top of the base X12 structure. A short checklist before you commit development time:

• Confirm which X12 version the partner expects (003060, 004010, or a DPAC-specific variant) since segment usage and mandatory loops shift between versions.
• Map BQT and PO1 fields against the partner's implementation guide line by line, not against a generic 840 template, since optional segments like CUR, REF, and FOB are frequently turned on or off per partner.
• Test the full chain, not just the 840: send a test RFQ, confirm you receive a 997 functional acknowledgment, then confirm the 843 response populates pricing and validity dates correctly before going live.
• Don't extend the same mapping to freight or logistics partners. If a carrier or 3PL asks for rate requests, point that integration toward your TMS or carrier-connectivity platform instead of retrofitting the goods-procurement 840/843 pair.

The 840/843 pair isn't going away for the buyers who already rely on it. But if you're building freight RFQ automation from scratch in 2026, start with your TMS or a carrier-connectivity platform, not with an EDI transaction set designed to buy fasteners and circuit boards.