Key Takeaways

• The EDI 990is the ANSI X12 transaction set used by motor carriers to accept, decline, or conditionally accept a shipper’s load tender (EDI 204).
• It is a direct response document – it does not initiate a process but replies to one already started by the shipper or broker.
• The EDI 990 is primarily used in truckload (TL) and less-than-truckload (LTL) transportation, though specific usage depends on trading partner agreements.
• Implementing the EDI 990 eliminates phone calls, faxes, and emails for load acceptance, significantly reducing response times and manual errors.
• The transaction set is defined by the ANSI Accredited Standards Committee X12(ASC X12), and its specific implementation details (which segments are required, what codes are used) are governed by individual trading partner implementation guides.
• Companies without ERP systems or large IT departments can still implement EDI 990 through solutions like EDI web portalsor fully managed EDI services.

What Is EDI 990?

The EDI 990, formally known as the Response to a Load Tender, is an electronic transaction set defined within the ANSI X12 standard. It is the standardized message a motor carrier sends back to a shipper (or broker, or 3PL) to communicate whether the carrier accepts, declines, or conditionally responds to a previously received load tender.

In simpler terms: when a shipper electronically asks a carrier to haul a load using an EDI 204 (Motor Carrier Load Tender), the carrier replies with an EDI 990 to say “yes,” “no,” or “yes, but with changes.”

The EDI 990 belongs to the Transportation functional group within the ANSI X12 standard family. It is not a standalone document, it only exists as a response to an EDI 204 and references the original tender.

Important distinction: The ANSI X12 standard defines the structure and allowable content of the EDI 990. However, the specific segments used, required data elements, and business rules vary based on each trading partner’s implementation guide. Two companies may both use EDI 990, but their implementations can differ substantially.

What Is the Purpose of EDI 990?

The purpose of the EDI 990 is to provide a fast, standardized, and machine-readable response to a load tender. Before EDI, this process was handled through phone calls, faxes, or emails – all of which were slow, error-prone, and difficult to track.

The EDI 990 serves these specific functions:

• Accepting a load tender – The carrier confirms it will handle the shipment as specified in the EDI 204.
• Declining a load tender– The carrier indicates it cannot or will not accept the shipment, allowing the shipper to quickly tender the load to another carrier.
• Providing a conditional response – In some trading partner implementations, the carrier may accept with modifications or provide a counter-offer (though the specifics of conditional responses depend on individual implementation guides).

By standardizing this response, the EDI 990 removes ambiguity. The shipper’s system can automatically process the response and take the next appropriate action, whether that’s confirming the shipment in a Transportation Management System (TMS) or re-tendering to an alternate carrier.

Who Uses EDI 990?

The EDI 990 is used by multiple parties in the transportation and logistics ecosystem. The roles involved include:

Motor Carriers

Motor carriers are the primary senders of the EDI 990. When a carrier receives an EDI 204 load tender, the carrier’s system (or EDI coordinator) generates and transmits a 990 to indicate acceptance or decline. This applies to both truckload (TL) and less-than-truckload (LTL) carriers, depending on trading partner requirements.

Shippers

Shippers are the primary receivers of the EDI 990. They originate the load tender (EDI 204) and wait for the carrier’s EDI 990 response. Shippers use this response to confirm transportation plans or trigger re-tendering logic if the load is declined.

Third-Party Logistics Providers (3PLs)

3PLs often act as intermediaries managing freight on behalf of shippers. A 3PL may send an EDI 204 to a carrier on the shipper’s behalf and receive the EDI 990 response. In this role, the 3PL functions similarly to a shipper from an EDI standpoint.

Freight Brokers

Freight brokers match shippers with carriers. In EDI-enabled brokerage operations, the broker may send the EDI 204 to the carrier and receive the EDI 990 response. The broker then communicates the result back to the shipper, often through their own systems.

Logistics Service Providers and Transportation Companies

Any organization that arranges or manages freight transportation and uses EDI may be involved in the 990 exchange. The specific role (sender or receiver) depends on whether the organization is tendering loads or carrying them.

Consignees

Consignees (the parties receiving the goods) are generally not direct participants in the EDI 990 exchange. However, they may be referenced within the transaction data, and in supply chains with high visibility requirements, consignees may have downstream systems that are updated based on 990 responses.

Which Industries Commonly Use EDI 990?

The EDI 990 is commonly used by businesses across industries that rely on motor carrier transportation and use EDI for freight tendering. It enables carriers to electronically accept or decline a load tender received through an EDI 204 transaction, helping shippers and carriers confirm transportation capacity and respond quickly to load offers.

The common factor is volume and time sensitivity. Organizations that tender large numbers of loads and need rapid, reliable carrier responses are the most likely users of the EDI 990.

Note: The specific industries listed above reflect common industry practice. Whether a particular company within these industries uses EDI 990 depends on their trading partner agreements and technology adoption.

When Should EDI 990 Be Used?

The EDI 990 should be used every time a carrier needs to respond to an electronically transmitted load tender (EDI 204). The key scenarios include:

• A carrier receives an EDI 204 and wants to accept the load.The carrier sends an EDI 990 with an acceptance response code.
• A carrier receives an EDI 204 and cannot accept the load.The carrier sends an EDI 990 with a decline response code, allowing the shipper to immediately re-tender.
• A carrier needs to respond within a required time window.Many shippers define a tender response deadline in their routing guides or trading partner agreements. If the carrier does not respond with an EDI 990 within that window, the shipper may automatically re-tender to the next carrier. The specific time windows depend on individual trading partner agreements.

The EDI 990 is not used for:

• Initiating a shipment request (that is the EDI 204)
• Providing shipment status updates (that is the EDI 214 – Transportation Carrier Shipment Status Message)
• Invoicing for freight charges (that is the EDI 210 – Motor Carrier Freight Details and Invoice)

How Does the EDI 990 Business Process Work?

The EDI 990 fits into a well-defined sequence of EDI transactions in the transportation lifecycle. Below is the typical business workflow:

Step-by-Step Workflow:

1. Shipper creates a shipment order in their Transportation Management System (TMS) or ERP system. The system determines the appropriate carrier based on routing guides, contracts, rates, or other business rules.
2. Shipper transmits an EDI 204 (Motor Carrier Load Tender) to the selected carrier. The 204 contains shipment details such as origin, destination, pickup and delivery dates/times, equipment requirements, commodity information, and weight.
3. Carrier receives the EDI 204 and evaluates whether it can fulfill the shipment. The carrier may check equipment availability, driver capacity, lane coverage, scheduling, and other operational factors.
4. Carrier transmits an EDI 990 (Response to a Load Tender) back to the shipper. The 990 references the original load tender and indicates whether the carrier accepts or declines the load.
5. Shipper’s system processes the EDI 990:
   • If accepted: The shipment is confirmed, and the carrier proceeds with the transportation. During the shipment, additional EDI transactions may be exchanged, including the EDI 214 (Transportation Carrier Shipment Status Message) to provide tracking and status updates.
   • If declined: The shipper’s TMS may automatically tender the load to the next carrier in the routing guide, restarting the 204/990 cycle with another carrier.
6. After the transportation service is completed, the carrier sends an EDI 210 (Motor Carrier Freight Details and Invoice) to submit the freight invoice and billing details.

Where EDI 990 Fits Among Related Transportation Documents

The easiest way to understand the EDI 990 is to look at its position in the transportation workflow:

EDI 204 → EDI 990 → EDI 214 → EDI 210

Load Tender → Accept/Decline → Shipment Status → Freight Invoice

The EDI 211 may also be exchanged as part of the shipment documentation process, depending on the specific trading partner relationship and implementation requirements. The EDI 997 is different because it provides a technical acknowledgment rather than a business-level response.

Technical Overview of EDI 990

This section explains the structure and key components of the EDI 990 transaction set at a high level. It is intended to help technical and business readers understand what the document contains without reproducing copyrighted standard specifications.

Disclaimer: The ANSI X12 standard is copyrighted by the Accredited Standards Committee X12. The information below describes the general purpose of common segments based on publicly available knowledge and common industry practice. For the complete and authoritative specification, refer to the official ASC X12 documentation. Trading partner implementation guides define which segments and elements are actually required for a specific exchange.

EDI 990 Transaction Set Structure

Like all ANSI X12 transaction sets, EDI 990 follows a hierarchical structure:

• Interchange Envelope (ISA/IEA): Wraps all content exchanged between two trading partners in a single transmission.
• Functional Group (GS/GE): Groups one or more transaction sets of the same type. For EDI 990, the functional group identifier is typically “GF”(as defined by X12 for Response to a Load Tender).
• Transaction Set (ST/SE): Contains a single EDI 990 document.

Common Segments and Their Purpose

The following table describes segments commonly found in EDI 990 implementations. The specific segments required for any given exchange are defined by the trading partner implementation guide.

Important Data Elements

Key data elements commonly found in the EDI 990 include:

• Standard Carrier Alpha Code (SCAC): A unique 2-to-4 letter code identifying the motor carrier. SCACs are assigned by the National Motor Freight Traffic Association (NMFTA).
• Shipment Identification Number: References the original load tender so the shipper can match the response to the correct shipment.
• Response Code: Indicates whether the carrier is accepting, declining, or conditionally responding to the tender. The specific code values used are defined by the X12 standard and further refined by trading partner implementation guides.

Sample EDI 990 (Simplified Conceptual Example)

The following is a simplified, conceptual representation intended only to illustrate the general structure of an EDI 990. It is not drawn from copyrighted X12 specifications and should not be used as an implementation reference. Always consult your trading partner’s implementation guide and the official X12 standard for actual implementation.

ISA*00*          *00*          *ZZ*CARRIER        *ZZ*SHIPPER        *230615*1200*U*00401*000000123*0*P*>~

GS*GF*CARRIER*SHIPPER*20230615*1200*123*X*004010~

ST*990*0001~

B1*SCAC*SHIPMENT123*A~

SE*2*0001~

GE*1*123~

IEA*1*000000123~

In this conceptual example:

• ST*990*0001 — Identifies this as a 990 transaction set.
• B1*SCAC*SHIPMENT123*A – The carrier (identified by SCAC) responds to shipment “SHIPMENT123” with a code that represents acceptance.
• The actual response codes, segment requirements, and additional data elements vary by trading partner.

Note: This is a simplified illustration. Real-world EDI 990 documents may include additional segments such as N9 for reference numbers, and the specific element positions and qualifiers are governed by the X12 standard version and the trading partner implementation guide.

Benefits of Implementing EDI 990

Implementing the EDI 990 as part of an automated load tendering process provides measurable operational improvements:

• Faster carrier response times – Automated EDI processing enables carriers to respond to tenders in minutes rather than hours, reducing the risk of missed pickup windows.
• Reduced manual effort – Eliminates the need for phone calls, faxes, and email exchanges to confirm or decline load tenders. Staff can focus on exception handling rather than routine communication.
• Improved shipment planning accuracy – Shippers receive definitive accept/decline responses that their TMS can process automatically, enabling faster re-tendering and better planning.
• Fewer errors – Standardized electronic data eliminates misunderstandings, transcription errors, and lost communications that occur with manual processes.
• Better carrier performance tracking – Every 990 response creates a digital record. Shippers can analyze tender acceptance rates by carrier, lane, and time period to inform routing guide decisions.
• Automated re-tendering – When a carrier declines via EDI 990, the shipper’s TMS can automatically tender to the next carrier in the routing guide without human intervention, significantly reducing cycle time.
• Audit trail and compliance – EDI transactions are logged, creating a verifiable record of when tenders were sent and when responses were received — useful for contract compliance and dispute resolution.

Common Challenges with EDI 990

Despite its benefits, implementing and maintaining the EDI 990 process presents challenges:

• Trading partner variability – Different shippers and carriers may use different versions of the X12 standard and different implementation guides. A carrier working with 50 shippers may need to support 50 slightly different 990 configurations.
• Mapping and translation complexity – Translating data between internal systems (TMS, ERP) and the EDI 990 format requires accurate mapping. Incorrect mapping can lead to rejected transactions or mismatched shipment references.
• Response time requirements – Shippers often require carriers to respond within a specific time window (e.g., 15 minutes, 30 minutes, 2 hours – varies by trading partner). Carriers without automated systems may struggle to meet these deadlines.
• System integration – The EDI 990 must be integrated with the carrier’s dispatch or TMS system to be truly effective. Without integration, the response may still require manual intervention.
• Error handling and exception management – When an EDI 990 fails validation (e.g., the referenced shipment ID doesn’t match a known tender), the error must be identified and resolved quickly to avoid delays.
• Onboarding new trading partners – Each new shipper-carrier EDI relationship requires testing, validation, and agreement on implementation details, which can take weeks or months.
• Maintaining compliance across standard versions – The X12 standard is updated periodically. Trading partners may use different versions (e.g., 4010, 5010), requiring the ability to support multiple versions simultaneously.

Best Practices for EDI 990 Implementation

With more than 25 years of experience in EDI integration and transaction management, we know that a successful EDI 990 implementation involves more than simply generating a valid X12 message. It requires careful attention to trading partner requirements, business workflows, transaction timing, validation, error handling, and ongoing monitoring.

Based on our experience working with EDI integrations, the following best practices can help carriers and logistics providers build a reliable EDI 990 process:

1. Obtain and follow the trading partner’s implementation guide. Never assume the standard defaults. Each trading partner specifies which segments, elements, and code values they require.
2. Automate the response wherever possible. Integrate the EDI 990 generation with your TMS or dispatch system so responses are triggered by business logic (capacity checks, lane acceptance rules) rather than manual review.
3. Respond quickly. Whether you accept or decline, send the EDI 990 as fast as possible. A timely decline is more valuable to a shipper than a delayed acceptance because it allows faster re-tendering.
4. Validate inbound EDI 204 data before generating the 990. Ensure the tender data is complete and correctly formatted before generating a response. This prevents downstream errors.
5. Implement proper error handling and alerting. Set up notifications for failed transactions, validation errors, and tenders that have not received a response within the required time window.
6. Test thoroughly before going live. Conduct end-to-end testing with each trading partner, including acceptance scenarios, decline scenarios, and error scenarios.
7. Maintain a clear audit trail. Log all EDI 204 and 990 transactions with timestamps. This data is essential for performance analysis, dispute resolution, and compliance reporting.
8. Monitor tender acceptance rates. Track your acceptance and decline rates by lane, shipper, and time period. This operational data supports better capacity planning and relationship management.
9. Keep your SCAC code and trading partner information current. Outdated identifiers cause transaction failures. Ensure your SCAC (assigned by NMFTA) is active and correctly referenced.
10. Plan for scalability. As you add trading partners, your EDI volume will grow. Ensure your EDI platform, communication methods (AS2, SFTP, VAN), and internal systems can handle increased volume.

Typical EDI 990 Implementation

Implementing EDI 990 typically follows a structured process. The specific steps and timeline vary depending on the organization’s size, existing technology, and the trading partner’s requirements.

Step 1: Gather Requirements

Obtain the trading partner’s EDI implementation guide for the 990 transaction set. This document specifies:

• Which X12 version to use
• Required and optional segments
• Expected code values
• Communication protocol (AS2, SFTP, VAN, etc.)
• Response time expectations
• Test procedures

Step 2: Choose an EDI Solution

The right EDI approach depends on your existing systems, internal IT resources, transaction volume, and how much of the EDI process you want to manage internally.

Step 3: Map and Configure

Map the data elements between your internal system and the EDI 990 format according to the trading partner’s implementation guide. This includes:

• Mapping your internal shipment identifiers to the tender reference numbers
• Configuring response codes
• Setting up communication endpoints

Step 4: Test with the Trading Partner

Conduct testing (often called “pilot testing” or “certification testing”) with the trading partner. This typically involves:

• Sending sample EDI 990 documents for the partner to validate
• Receiving sample EDI 204 documents and responding with 990s
• Verifying that documents are correctly parsed and processed on both sides

Step 5: Go Live and Monitor

After successful testing, move to production. Monitor the first several weeks of live transactions closely for errors, timing issues, or data mismatches.

How EDI2XML Can Help with EDI 990 Implementation

For organizations that need to implement EDI 990 but lack in-house EDI expertise or infrastructure, service providers like EDI2XML offer implementation support and managed EDI services.

EDI2XML provides several implementation approaches depending on the organization’s needs and technical environment:

• Fully managed EDI services – EDI2XML handles the mapping, translation, and transmission of EDI 990 and related transaction sets on behalf of the organization. This approach is suitable for companies that prefer to outsource EDI operations rather than build internal capabilities.
• Integration with existing ERP or TMS systems – For organizations that use enterprise systems but need EDI connectivity, EDI2XML can integrate EDI processing with the existing system, automating the flow of data between the business application and trading partners.

EDI Web Portal for Small and Mid-Size Businesses

Companies that do not have an ERP system, TMS, or dedicated EDI infrastructure may benefit from a browser-based EDI web portal. EDI2XML offers an EDI web portal solution designed for small to mid-size businesses.

With a web portal approach:

• Users log into a web-based interface to view incoming EDI 204 load tenders.
• Users respond to tenders through the portal, and the system generates the EDI 990 in the correct format and transmits it to the trading partner.
• No EDI software installation or in-house EDI expertise is required.
• The portal handles the translation between the human-readable web interface and the EDI standard format.

This approach is particularly useful for smaller carriers or brokers that receive EDI tenders from large shippers but do not have the volume or budget to justify a full EDI software implementation.

Common Misconceptions About EDI 990

• “EDI 990 is the same as a Functional Acknowledgment (997).”This is incorrect. The EDI 997 confirms that an EDI file was received and is syntactically valid. The EDI 990 is a business-level response that communicates a decision about a load tender. They serve entirely different purposes, and both may be exchanged during a single transaction flow.
• “If I don’t send an EDI 990, the shipper will assume I accepted the load.”This depends entirely on the trading partner’s business rules. Some shippers treat the absence of a 990 as a decline and will automatically re-tender. Others may attempt to follow up. Never assume — always check the trading partner’s implementation guide and contractual terms.
• “EDI 990 is only for truckload carriers.”While truckload is the most common context, LTL carriers and other transportation providers may also use EDI 990 depending on trading partner requirements. The X12 standard does not restrict the 990 to a single mode.
• “All EDI 990 implementations are the same.”The ANSI X12 standard provides the framework, but individual trading partners define which segments, elements, and codes they require. Two shippers can have significantly different 990 requirements.

Frequently Asked Questions (FAQ)

What does EDI 990 stand for?

EDI 990 is the ANSI X12 transaction set number for the “Response to a Load Tender.” It is the standardized electronic document a motor carrier uses to accept or decline a shipper’s load tender (EDI 204).

What is the difference between EDI 990 and EDI 997?

The EDI 997 is a Functional Acknowledgment – a technical confirmation that an EDI file was received and could be parsed. The EDI 990 is a business response that communicates the carrier’s decision to accept or decline a specific load tender. They serve different purposes and are both commonly exchanged during the load tendering process.

Who sends the EDI 990?

The motor carrier (or their EDI service provider) sends the EDI 990 in response to an EDI 204 received from a shipper, broker, or 3PL.

What triggers an EDI 990?

An EDI 990 is triggered by the receipt of an EDI 204 (Motor Carrier Load Tender) from a shipper or logistics provider.

Is EDI 990 required?

Whether a carrier must respond with an EDI 990 depends on the trading partner agreement. Many large shippers require EDI 990 responses as part of their carrier compliance programs. The absence of a 990 may result in automatic re-tendering or compliance penalties, depending on the shipper’s rules.

How quickly must a carrier respond with an EDI 990?

Response time requirements are defined by each trading partner’s business rules, not by the X12 standard itself. Common response windows range from 15 minutes to several hours, but the specific deadline varies by shipper and must be confirmed in the trading partner agreement or routing guide.

Can a carrier send a counter-offer via EDI 990?

The X12 standard includes provisions for different response types. Whether a conditional or counter-offer response is supported depends on the trading partner’s implementation guide. Not all shippers accept conditional responses.

What systems are needed to send and receive EDI 990?

At minimum, you need an EDI translation capability (software, service, or web portal) and a communication method (AS2, SFTP, VAN, etc.) to exchange EDI documents with trading partners. Integration with a TMS or dispatch system is recommended for automation but not strictly required – web portal solutions enable manual processing without ERP integration.

What X12 version is used for EDI 990?

The EDI 990 has been available across multiple X12 versions. The version used in a specific implementation is determined by the trading partner agreement. Versions 4010 and 5010 are among the most commonly referenced in transportation EDI, but the specific version must be confirmed with each trading partner.

Need Help with EDI 990 Integration?

Make EDI 990 responses part of a reliable, automated freight workflow. EDI2XML can help you integrate EDI 990 with your ERP, TMS, WMS, or other business systems and connect with your trading partners.

Ready to simplify your EDI process? Book a free consultation with our EDI experts today.