Key Takeaways

• EDI 213 is an ANSI X12 transaction set used to electronically request the status of a shipment from a motor carrier.
• It replaces manual phone calls, emails, and web portal lookups with an automated, system-to-system inquiry.
• The EDI 213 typically works in tandem with the EDI 214 (Transportation Carrier Shipment Status Message), which serves as the response.
• It is used by shippers, consignees, 3PLs, freight brokers, and other logistics stakeholders who need real-time or near-real-time shipment visibility.
• Successful implementation depends heavily on trading partner agreements and the specific implementation guide each carrier publishes.
• Companies can implement EDI 213 through fully managed EDI services, web portals, or API-based integrations.

What Is EDI 213?

EDI 213 is a transaction set within the ANSI X12 standard, formally titled the Motor Carrier Shipment Status Inquiry. It provides a standardized electronic format for one party – typically a shipper, consignee, or logistics intermediary – to request the current status of a shipment from a motor carrier.

In practical terms, think of the EDI 213 as the electronic equivalent of calling a trucking company and asking, “Where is my shipment?” Instead of a phone call, the inquiry is sent as a structured electronic document from one computer system to another.

The ANSI X12 standards are maintained by the Accredited Standards Committee X12, chartered by the American National Standards Institute (ANSI). The EDI 213 falls under the Transportation subcommittee of X12, which governs transaction sets used across freight, logistics, and carrier operations.

Important distinction: The X12 standard defines the format and structure of the EDI 213 transaction set. However, the specific data elements required, optional fields supported, and business rules applied will vary based on each trading partner’s implementation guide. Always refer to your carrier’s or partner’s specific documentation before implementing.

What Is the Purpose of EDI 213?

The purpose of the EDI 213 is to automate the process of inquiring about the status of a freight shipment being handled by a motor carrier.

Before EDI, shipment status inquiries were handled through:

• Phone calls to carrier customer service departments
• Emails sent to operations contacts
• Manual lookups on carrier web portals
• Fax-based status requests

Each of these methods is slow, error-prone, and difficult to scale. When a shipper manages hundreds or thousands of shipments daily, manual status inquiries become a significant operational bottleneck.

The EDI 213 solves this by allowing the requesting party’s system (such as a TMS or ERP) to send a structured, electronic inquiry directly to the carrier’s system. The carrier’s system can then process the request and respond, typically via an EDI 214 (Transportation Carrier Shipment Status Message) without human intervention on either side.

In summary, the EDI 213 exists to:

• Request the current status of one or more shipments electronically
• Eliminate manual status inquiry processes
• Enable automated, system-to-system shipment visibility
• Support proactive exception management in transportation operations

Who Uses EDI 213?

The EDI 213 is used across the motor carrier freight ecosystem. The following parties are the most common users:

Shippers

Shippers are typically the origin party in a freight transaction (the company sending goods). Shippers use EDI 213 to inquire about the status of shipments they have tendered to motor carriers. This is especially common when a shipper’s Transportation Management System (TMS) needs to update delivery status for customer service, warehouse planning, or order management purposes.

Consignees

Consignees are the receiving parties. A consignee (or a company acting on behalf of the consignee) may send an EDI 213 to a carrier to determine when a shipment will arrive. This helps with dock scheduling, labor planning, and inventory management.

Third-Party Logistics Providers (3PLs)

3PLs manage logistics operations on behalf of shippers or consignees. Because they coordinate shipments across multiple carriers, 3PLs frequently use the EDI 213 to centralize shipment visibility. Their systems can send automated inquiries to each carrier and consolidate the responses.

Freight Brokers

Freight brokers act as intermediaries between shippers and carriers. They have a strong business need to track the status of loads they have brokered. The EDI 213 allows brokers to pull status updates from carriers without relying on manual check calls.

Motor Carriers

Motor carriers are the recipients of the EDI 213. They receive the inquiry and are expected to respond with the current shipment status, typically using the EDI 214 transaction set. Carriers must have systems in place to receive, process, and respond to these inquiries.

Transportation and Logistics Technology Companies

Companies that provide TMS platforms, freight visibility tools, or supply chain integration platforms can build EDI 213 support into their systems to offer automated status inquiry capabilities to their customers.

Which Industries Commonly Use EDI 213?

The EDI 213 is part of the transportation-specific subset of ANSI X12 standards and is applicable wherever motor carrier freight is used. Industries that commonly rely on motor carrier transportation and therefore may use the EDI 213 include:

 

Industry	Why EDI 213 Is Relevant
Retail	High volume of inbound shipments to distribution centers and stores; tight delivery windows
Manufacturing	Just-in-time supply chains require precise shipment visibility for production scheduling
Consumer Packaged Goods (CPG)	Large-scale distribution to retailers with strict compliance requirements
Food & Beverage	Perishable goods require close monitoring of transit status and timing
Automotive	Complex supply chains with many inbound components and sequenced deliveries
Wholesale & Distribution	High shipment volumes across multiple carriers
Pharmaceuticals	Regulatory and compliance needs require detailed shipment tracking
E-commerce & Fulfillment	Customer experience depends on accurate, timely delivery visibility

Note: The specific usage of EDI 213 within any industry depends on trading partner requirements and the maturity of a company’s EDI integration. Not all carriers support the EDI 213; some rely on the EDI 214 as a push-based status update instead.

When Should EDI 213 Be Used?

The EDI 213 should be used when a party needs to proactively request the status of a shipment from a motor carrier, rather than waiting for the carrier to send an update.

• Common scenarios include:
• A shipper’s TMS has not received a timely EDI 214 update and needs to determine if the shipment is still in transit, delivered, or experiencing a delay.
• A consignee needs to plan dock operations and requires an up-to-date estimated arrival time.
• A 3PL or freight broker needs to provide a status update to their customer and the carrier has not yet pushed an update.
• An exception management process is triggered – for example, a shipment is past its expected delivery date and an automated inquiry is sent.
• Regular polling for status – some organizations configure their systems to send EDI 213 inquiries at scheduled intervals (e.g., every few hours) for all active shipments.

Pull vs. Push: EDI 213 vs. EDI 214

It is important to understand the relationship between the EDI 213 and the EDI 214:

Aspect	EDI 213	EDI 214
Direction	Shipper/3PL/Broker → Carrier	Carrier → Shipper/3PL/Broker
Model	Pull (inquiry/request)	Push (proactive notification)
Purpose	Request shipment status	Provide shipment status
Trigger	Initiated by the party needing information	Initiated by the carrier at key milestones
Typical Use	When status updates are missing or needed on demand	At standard shipment events (pickup, in-transit, delivered, etc.)

In many EDI implementations, the EDI 214 is the primary mechanism for shipment status updates, with the carrier pushing updates at key milestones (e.g., picked up, arrived at terminal, out for delivery, delivered). The EDI 213 serves as a supplementary tool – a way to request information when the push updates are insufficient, missing, or when on-demand visibility is required.

Trading partner dependency: Not all motor carriers support the EDI 213. Whether a carrier accepts and responds to EDI 213 inquiries depends on the carrier’s EDI capabilities and the trading partner agreement. Always confirm support during the onboarding process.

How Does the EDI 213 Business Process Work?

The EDI 213 fits within a broader transportation lifecycle. To understand its role, it helps to see where it sits among the related EDI transaction sets commonly used in motor carrier operations.

The Motor Carrier EDI Workflow (Step-by-Step Business Process)

1. Load Tendering (EDI 204): The shipper sends an EDI 204 (Motor Carrier Load Tender) to the carrier, requesting that the carrier transport a shipment.
2. Tender Response (EDI 990): The carrier responds with an EDI 990 (Response to a Load Tender), accepting or declining the load.
3. Shipment Execution: The carrier dispatches a driver, picks up the freight, and begins transit.
4. Status Updates (EDI 214 – Push): At standard milestones such as pickup, arrival at terminal, departure from terminal, out for delivery, and delivery – the carrier sends EDI 214 status messages to the shipper or designated party.
5. Status Inquiry (EDI 213 – Pull): If the shipper, consignee, 3PL, or broker needs a status update between the carrier’s standard EDI 214 pushes – or if an expected EDI 214 has not arrived – they send an EDI 213 to the carrier requesting the current status.
6. Status Response (EDI 214): The carrier processes the EDI 213 inquiry and responds with an EDI 214 containing the current shipment status.
7. Freight Invoicing (EDI 210): After delivery, the carrier sends an EDI 210 (Motor Carrier Freight Details and Invoice) for payment processing.
8. Functional Acknowledgments (EDI 997): Throughout the process, each party sends EDI 997 (Functional Acknowledgment) transactions to confirm receipt of each EDI transaction set. The EDI 997 acknowledges that a transaction was received and whether it was syntactically valid – it does not confirm business-level acceptance.

Some shippers also send an EDI 211 (Bill of Lading) after the carrier accepts the load. This transaction provides the electronic BOL details required for pickup and shipment execution. Its use varies by carrier and is optional in most workflows.

Related Transaction Sets Summary

Transaction Set	Name	Role in Workflow
EDI 204	Motor Carrier Load Tender	Shipper tenders a load to the carrier
EDI 990	Response to a Load Tender	Carrier accepts or declines the tender
EDI 213	Motor Carrier Shipment Status Inquiry	Requesting party asks for shipment status
EDI 214	Transportation Carrier Shipment Status Message	Carrier provides shipment status (push or in response to 213)
EDI 210	Motor Carrier Freight Details and Invoice	Carrier invoices for freight services
EDI 997	Functional Acknowledgment	Confirms receipt and syntactic validity of any EDI transaction

Technical Overview of the EDI 213 Transaction Set

This section provides a general technical overview of the EDI 213 structure. It is not intended to reproduce the copyrighted ANSI X12 standard. For full segment and element details, refer to the official X12 documentation or your trading partner’s implementation guide.

EDI 213 Transaction Set Structure

Like all ANSI X12 transaction sets, the EDI 213 is composed of:

• Segments – lines of data, each identified by a segment identifier (e.g., ST, B11, N1)
• Data elements – individual fields within each segment, separated by element delimiters
• Loops – groups of repeating segments

The EDI 213 is wrapped within the standard X12 envelope structure:

Level	Segments	Purpose
Interchange Envelope	ISA / IEA	Identifies the sender, receiver, and interchange control information
Functional Group	GS / GE	Groups one or more transaction sets of the same type;
Transaction Set	ST / SE	Contains the actual EDI 213 inquiry data

Common Segments in EDI 213

The following are segments commonly associated with the EDI 213 transaction set. The specific segments required will depend on the X12 version and the trading partner’s implementation guide.

Segment	Name	Purpose
ST	Transaction Set Header	Marks the beginning of the transaction set; identifies it as an 213
B11	Beginning Segment for Shipment Status Inquiry	Contains key identifiers for the inquiry, such as reference numbers and date
N1	Name	Identifies parties involved (e.g., shipper, consignee, carrier)
N3	Address Information	Provides address details for the identified party
N4	Geographic Location	City, state, and postal code for the identified party
REF	Reference Identification	Carries reference numbers such as BOL number, PRO number, or PO number used to identify the shipment
SE	Transaction Set Trailer	Marks the end of the transaction set

Important Data Elements

The EDI 213 needs to provide enough information for the carrier to identify the specific shipment being inquired about. Key data elements typically include:

• Bill of Lading (BOL) number – The primary shipment document reference
• PRO number – The carrier’s progressive or freight bill number
• Purchase Order number – Used by some trading partners as a cross-reference
• Shipment identification number – May reference the original EDI 204 load tender
• Inquiry date – The date the inquiry is being made
• Reference numbers – Additional references as needed to uniquely identify the shipment

Implementation note: The specific reference numbers and identifiers required to successfully retrieve a shipment status vary by carrier. Some carriers may require the PRO number, others may accept a BOL number, and others may support multiple reference types. This is defined in each carrier’s EDI implementation guide.

Benefits of Using EDI 213

Implementing the EDI 213 provides tangible operational benefits for organizations that manage motor carrier freight:

• Automated shipment visibility: Systems can request status updates without human intervention, keeping TMS and ERP platforms current.
• Reduced manual workload: Eliminates the need for transportation coordinators to make phone calls, send emails, or log into carrier portals to check shipment status.
• Faster exception management: Automated inquiries can be triggered when shipments miss expected milestones, allowing teams to identify and address delays sooner.
• Improved customer service: When customer-facing teams have up-to-date shipment information, they can provide accurate delivery estimates and proactive communication.
• Scalability: Manual status inquiries do not scale. A company managing 50 shipments per day might manage with phone calls; a company managing 5,000 cannot. EDI 213 scales with volume.
• Standardized communication: Using the ANSI X12 format eliminates ambiguity and ensures both parties are exchanging data in a structured, predictable format.
• Audit trail: Every EDI 213 inquiry and corresponding EDI 214 response is logged, creating a digital record of when status was requested and what information was provided.

Common Challenges with EDI 213

Despite its benefits, implementing and using the EDI 213 comes with challenges:

Limited Carrier Support

Not all motor carriers support the EDI 213. Many carriers – particularly smaller or regional carriers – may only support the EDI 214 (push-based status updates) or may not support EDI at all. Before planning an EDI 213 implementation, you must confirm that your carrier partners accept and respond to this transaction set.

Inconsistent Implementation Guides

Even among carriers that support the EDI 213, implementation guides can vary significantly. One carrier may require a PRO number to process the inquiry; another may require a BOL number. The segments used, data elements populated, and response behavior can differ from carrier to carrier.

Response Time Variability

The X12 standard defines the format of the inquiry but does not dictate how quickly a carrier must respond. Response times depend on the carrier’s system architecture, processing schedules, and internal workflows. Some carriers may respond in near real-time; others may batch-process inquiries.

Data Quality Issues

The EDI 213 is only effective if the reference numbers provided match the carrier’s records. If there are discrepancies in BOL numbers, PRO numbers, or other identifiers – due to manual entry errors, system mismatches, or timing issues – the inquiry may fail or return incorrect results.

Mapping and Translation Complexity

Implementing any EDI transaction set requires proper mapping between your internal system’s data format and the X12 standard. This requires EDI translation software, middleware, or a managed service provider. For organizations new to EDI, this can represent a significant learning curve.

Testing and Validation

Each new trading partner relationship requires testing to ensure that EDI 213 documents are generated correctly, transmitted successfully, and processed properly by the carrier’s system. This testing cycle can take weeks depending on the complexity and the responsiveness of both parties.

Best Practices for EDI 213 Implementation

Based on common industry practice, the following best practices can help ensure a successful EDI 213 implementation:

1. Confirm carrier support before development. Verify that each carrier partner supports EDI 213 and obtain their specific implementation guide before beginning any mapping or development work.
2. Use the carrier’s implementation guide as the primary reference. While the ANSI X12 standard defines the overall structure, the carrier’s implementation guide defines the specific requirements for that relationship.
3. Establish clear reference number conventions. Agree with each carrier on which reference numbers (BOL, PRO, PO, etc.) will be used to identify shipments in the EDI 213. Ensure these references are consistently captured in your TMS or ERP.
4. Implement automated triggering logic. Rather than sending EDI 213 inquiries manually, configure your TMS or integration platform to automatically send inquiries based on business rules – for example, when an expected EDI 214 update is overdue by a configurable threshold.
5. Handle errors and rejections gracefully. Build logic to handle scenarios where the carrier cannot find the shipment, the reference number is invalid, or the response is delayed. Ensure your system logs these exceptions for follow-up.
6. Test thoroughly with each carrier. Do not assume that a mapping that works with one carrier will work with another. Test the full cycle – send EDI 213, receive EDI 214 response, and validate data with each trading partner.
7. Monitor transaction flow in production. After go-live, monitor EDI 213/214 traffic to ensure inquiries are being sent, responses are being received, and data is flowing correctly into your systems.
8. Use EDI 997 functional acknowledgments. Ensure both parties are exchanging EDI 997s to confirm receipt of transactions. This provides a baseline level of delivery confirmation at the EDI level.

Typical EDI 213 Implementation Process

For organizations new to EDI or adding EDI 213 to their existing capabilities, the typical implementation process follows these phases:

1. Requirements Gathering

• Identify which carrier partners support EDI 213
• Obtain each carrier’s EDI implementation guide
• Define the business scenarios that will trigger an EDI 213 inquiry
• Identify the source systems (TMS, ERP, WMS) that will send and receive the data

2. EDI Translation and Mapping

• Configure EDI translation software (or work with an EDI managed service provider such as EDI2XML) to generate EDI 213 documents in the correct X12 format
• Map internal data fields (shipment number, BOL, PRO, etc.) to the corresponding X12 segments and data elements
• Configure the inbound EDI 214 mapping to process the carrier’s response

3. Communication Setup

• Establish the communication channel with each carrier (AS2, SFTP, VAN, or other method as agreed)
• Exchange partner profiles, certificates, and connection details
• Confirm interchange and functional group identifiers (ISA/GS values)

4. Testing

• Send test EDI 213 documents to the carrier
• Validate that the carrier receives and processes the inquiry
• Verify that the EDI 214 response is received and correctly mapped into your system
• Resolve any errors identified during testing
• Obtain sign-off from the carrier that testing is complete

5. Production Go-Live

• Switch from test to production environments
• Monitor initial transactions closely
• Confirm data integrity end-to-end

6. Ongoing Monitoring and Maintenance

• Monitor EDI 213/214 transaction flow for errors or failures
• Update mappings when carriers revise their implementation guides
• Add new carrier partners as needed

Common Misconceptions About EDI 213

• “EDI 213 is required for all motor carrier shipments.” It is not. The EDI 213 is an optional transaction set. Many transportation relationships rely solely on the EDI 214 (push model) for status updates. The EDI 213 is used when a pull model is needed or preferred.
• “Every carrier supports EDI 213.” This is not the case. Carrier support for the EDI 213 varies. Many carriers support EDI 204, 210, 214, and 990, but may not have implemented the EDI 213. Always verify.
• “EDI 213 provides real-time GPS tracking.” The EDI 213 is a structured data inquiry – it requests shipment status information from the carrier’s system. It is not a GPS tracking tool. The granularity and timeliness of the response depend on the carrier’s internal tracking capabilities and system architecture.
• “EDI 213 and EDI 214 are the same thing.” They are complementary but different. The EDI 213 is the inquiry (question). The EDI 214 is the status message (answer). The EDI 214 can also be sent proactively by the carrier without an EDI 213 inquiry.

How EDI2XML Can Help You Implement EDI 213

Implementing the EDI 213 or any EDI transaction set requires EDI translation capabilities, communication infrastructure, and ongoing management. Not every organization has in-house EDI expertise or wants to build and maintain this infrastructure internally.

EDI2XML is a company that provides EDI integration services and can help organizations implement the EDI 213 along with other transportation EDI transaction sets. They offer several implementation approaches depending on your organization’s size, technical capabilities, and existing systems.

Fully Managed EDI Service

EDI2XML’s Fully Managed EDI Service handles the end-to-end EDI process on your behalf. This includes EDI translation, mapping, communication with trading partners, monitoring, and error resolution.

Best suited for: Companies that want to exchange EDI documents with carriers and other trading partners without investing in EDI software, infrastructure, or specialized staff. This is common among mid-size companies with ERP or TMS systems that need EDI connectivity but lack an internal EDI team.

EDI Web Portal

EDI2XML’s EDI Web Portal provides a browser-based interface where users can create, send, receive, and manage EDI transactions (including EDI 213) – through a web application.

Best suited for: Small to mid-size businesses that do not have an ERP or TMS system capable of generating EDI documents natively. The web portal allows users to participate in EDI-based trading partner relationships without backend system integration.

EDI Web Service (REST API)

EDI2XML’s EDI Web Service / REST API allows organizations to integrate EDI capabilities directly into their own applications through API calls. Your system sends data in XML or JSON format, and the service handles the conversion to and from X12 EDI format.

Best suited for: Companies with in-house development capabilities that want to embed EDI processing into their existing applications, workflows, or custom-built TMS/ERP systems. The API approach gives the most control and flexibility.

USEFUL: Guide to choosing an EDI solution provider

Comparison of Implementation Options

Feature	Fully Managed Service	Web Portal	REST API / Web Service
EDI translation & mapping	Included	Included	Included
Trading partner communication	Managed by EDI2XML	Managed by EDI2XML	Managed by EDI2XML
ERP/TMS integration	Yes – integrated with your system	Not required	Yes – via API calls
Technical staff required	Minimal	Minimal	Development resources needed
Best for	Mid-size companies with ERP/TMS	Small businesses without ERP/TMS	Companies with custom applications
Control & customization	Provider-managed	Limited to portal features	High — full API access
Scalability	High	Moderate	High

Frequently Asked Questions (FAQ)

What does EDI 213 stand for?

EDI 213 is the ANSI X12 transaction set number for the Motor Carrier Shipment Status Inquiry. It is used to electronically request the current status of a shipment from a motor carrier.

What is the difference between EDI 213 and EDI 214?

The EDI 213 is an inquiry – it asks for shipment status. The EDI 214 is the status message – it provides shipment status information. The EDI 214 can be sent proactively by the carrier (push) or as a response to an EDI 213 inquiry (pull).

Is EDI 213 required for motor carrier shipments?

No. The EDI 213 is not a mandatory document. Its use depends on the trading partner agreement and the operational needs of the shipper, consignee, or logistics provider. Many organizations rely solely on EDI 214 push updates.

Which carriers support EDI 213?

Carrier support varies. Major national LTL and truckload carriers are more likely to support a broad range of EDI transaction sets, but support for the EDI 213 specifically should be confirmed with each carrier during the onboarding and implementation process.

What information is needed to send an EDI 213?

At minimum, you need a reference number that the carrier can use to identify the shipment – such as a Bill of Lading (BOL) number, PRO number, or shipment identification number. The specific requirements are defined in each carrier’s EDI implementation guide.

How quickly will a carrier respond to an EDI 213?

Response time is not defined by the X12 standard and varies by carrier. Some carriers process inquiries in near real-time; others batch-process them on a schedule. Response time expectations should be discussed and agreed upon during trading partner setup.

Can EDI 213 be used with LTL and truckload carriers?

Yes. The EDI 213 is applicable to both Less-Than-Truckload (LTL) and Full Truckload (FTL/TL) motor carrier operations. However, actual support depends on the individual carrier.

What EDI communication methods are used for EDI 213?

Common communication methods include AS2, SFTP, VAN (Value Added Network), and in some cases FTPS or other secure protocols. The method is agreed upon between trading partners and is not specific to the EDI 213 – it applies to all EDI transactions exchanged with that partner.

Ready to Implement EDI 213? Next Steps

EDI 213 gives transportation companies a practical way to request shipment status when they need it, rather than depending entirely on carrier-initiated updates. For organizations managing large shipment volumes, this can help improve visibility, support exception management, and keep transportation systems better informed.

If your business needs to exchange EDI 213 messages—or integrate EDI 213 with your TMS, ERP, WMS, or other business applications, EDI2XML can help.

EDI2XML provides managed EDI integration services that handle the complexity of EDI translation, connectivity, and system integration, so your team can focus on your transportation operations rather than EDI infrastructure.

Need to integrate EDI 213? Talk to EDI2XML to discuss your requirements and find the right integration approach for your business.