EDI 213 Shipment Status Inquiry vs EDI 214: When to Pull, Not Push

A regional LTL carrier picked up a pallet of replacement parts on Monday afternoon. By Wednesday noon the shipper's tracking screen still showed only the pickup event, the customer had called twice, and a planner was logging into the carrier's portal to copy a status by hand. The carrier had in fact scanned the freight at two terminals; its outbound status feed had simply skipped the shipper's account after a mapping change.

The EDI 213 Motor Carrier Shipment Status Inquiry exists for exactly that gap. Used selectively, it lets the shipper ask one carrier about one shipment and get a structured 214 back within minutes, instead of a phone call. Used carelessly, it becomes a polling loop that floods the carrier and the value-added network with inquiries about freight that is moving normally.

• What this guide covers: how the 213 is built, how its answer is matched, which silence rules justify a pull, how to test a carrier's support, and what rate limits and batching to agree.
• What it adds: a priced comparison of manual lookups, blanket polling and targeted inquiries in dollars and rupees, plus the India equivalent of a status pull through e-way bill and ULIP lookups.

Pull versus push: what a 213 asks and a 214 already reports

The 214 is the default and the 213 is the exception. A carrier sends 214 status messages on its own schedule whenever freight is scanned; the shipper sends a 213 only when that push has gone quiet or a decision cannot wait for the next scan. Designing the pair the other way round, with inquiries as the main feed, wastes money on both sides.

ASC X12 describes the 213 as a transaction set that can be used to request shipment status from a motor carrier, and notes that the requestor may be a shipper or consignee. The 214 is the carrier's message giving shippers, consignees and their agents the status of shipments in terms of dates, times, locations, route, identifying numbers and conveyance. One asks; the other reports, whether asked or not.

Our architecture comparison for EDI 214 status messages feeding 210 invoice approval treats the pushed status stream as the input to freight payment. This article stays on the other side of the pipe: when to ask, how to ask, and how to stop asking once the answer arrives.

Inside the 213: B11 identifiers, references and the requested reply

A usable 213 needs three things: who is asking, which shipment is meant, and how the reply should come back. In the version 4010 layout the B11 segment carries the first and third, and up to ten REF segments carry the shipment keys the carrier will search on.

• B11-01 and B11-02: the identification code qualifier (element 66) and the requestor's code. Qualifier 1 means a D-U-N-S number and 2 means a SCAC, so a shipper normally sends its D-U-N-S or a mutually defined code.
• B11-03 pickup date: optional, eight digits in CCYYMMDD form. Sending it narrows the carrier's search when PRO numbers are recycled.
• B11-04 to B11-09: paired optional fields for a quantity with its unit, a monetary amount with its qualifier, and a free-form description; the syntax notes make each pair all-or-nothing.
• B11-10 and B11-11: a service level code and a report transmission code (element 756), where values such as EL (electronically only) state how the answer should travel.
• REF segments: qualifier CN for the carrier's PRO, BM for the bill of lading number, PO for a purchase order and P8 for a pickup reference.

The optional N1 loop, repeating up to five times, names parties such as the shipper or consignee with address, contact and further references. Most carriers locate freight by PRO alone, but sending the bill of lading and consignee postal code as well protects against keying errors on the carrier's side, especially for shipments tendered on paper.

Matching the reply: tying a 214 answer back to the inquiry

An answer is only useful if the system can tell it apart from routine pushed traffic. Match each reply on the carrier PRO and SCAC first, then on the inquiry number, and close the open inquiry as soon as a matching 214 arrives, whether that 214 was prompted by the inquiry or not.

The 214 B10 segment carries the carrier's PRO in B10-01, the shipper's shipment identification number in B10-02, the SCAC in B10-03, and an inquiry request number in B10-04, defined as an identifying number assigned by the inquirer and limited to three digits. Agree in each carrier's implementation guide which 213 field carries that number, because a three-digit counter recycles quickly and must be paired with the PRO.

EDI 213 inquiry matching closes the open request when a 214 arrives with the same B10-03 SCAC and B10-01 PRO, using the B10-04 inquiry request number, which X12 limits to three digits, only as a tiebreaker; any inquiry still open after four hours goes to a planner instead of being re-sent.

The reply itself is read like any 214. The AT7 segment gives a shipment status code with a reason code, or an appointment status with its reason, never both; MS1 gives city and state or coordinates. A reply carrying AT7 status X6 (en route to delivery location) with reason NS (normal status) closes the inquiry; status SD (shipment delayed) or reason codes such as AO (weather or natural disaster related) open an exception case.

Silence thresholds that justify an inquiry rather than waiting

Send a 213 only when the time since the last status exceeds what is normal for that mode, lane and stage. A single global timer either fires constantly on long-haul freight or misses stalled local deliveries, so the threshold must be set per lane and per last event.

Build the threshold from your own history. For each carrier and lane, take the gap between consecutive 214 events over the last three months and use a high percentile as the trigger. If 95% of linehaul gaps on a lane are under 20 hours, a 22-hour silence after departure is unusual; a 22-hour silence after an appointment-set event on a Friday may be normal.

• After pickup, no departure: trigger when no AF (carrier departed pickup location) event follows the pickup appointment by more than six hours.
• In linehaul, no terminal scan: trigger at the lane's 95th-percentile gap plus two hours.
• Out for delivery, no proof: trigger when X6 is older than the end of the delivery day with no D1 (completed unloading at delivery location) event.
• Customer-facing deadline: trigger once, four hours before a promised delivery window, if the last event does not support the promise.
• Never trigger: on delivered shipments, on cancelled loads, or within six hours of a previous inquiry on the same PRO.

Carrier support matrix and testing each carrier's 213 handling

Do not assume a carrier answers 213s because it sends 214s. Support is uneven, so build a short matrix per carrier and test it before switching the inquiry trigger on in production.

Collect the carrier's implementation guide and confirm which version it accepts, which identifiers it searches on, how long a reply takes, and whether replies arrive as a normal 214 or as a special response. Then run five test inquiries in the test environment: a known in-transit PRO, a delivered PRO, a PRO with a wrong digit, a bill of lading with no PRO, and a duplicate of the first request.

The onboarding steps for envelopes, control numbers and acknowledgments are the same as for any new transaction set, so reuse the syntax, business-rule and volume test cycles already run for the carrier's 214 feed. Here the extra question is commercial: whether the carrier will commit to a reply time for inquiries at all.

Rate limits, batching windows and what blanket polling costs

Cap inquiries per carrier per day and batch them into fixed windows. A cap protects the carrier's lookup service and your network charges; a batch window lets the carrier answer in one run instead of one at a time.

The arithmetic below shows why. It compares three ways of handling the same month of silent shipments for one US shipper and one Indian shipper. All unit costs are illustrative assumptions for the example, not quotes from any provider; replace them with your own contracted network charges and loaded labour rates.

Inquiry budget per carrier per day
  Q_day = min( C_carrier , ceil( S_silent x k ) )

  S_silent  = open shipments past their lane silence threshold today
  k         = 1.0 for the first inquiry, 0 if an inquiry on the same PRO
              was sent within the last 6 hours
  C_carrier = agreed daily cap (default 2% of the carrier's open PROs)

Sample 213 sent in the 09:00 batch window (version 004010, illustrative values)
  ST*213*0412~
  B11*1*123456789*20261109~
  REF*CN*7738215604~
  REF*BM*SH-55120~
  N1*CN*NORTHSIDE PARTS DEPOT~
  N4*COLUMBUS*OH*43219~
  SE*7*0412~

The US blanket figure assumes 4,800 shipments, an average three days in transit and six polls a day, each producing an inquiry and a reply. Targeted pulls cost under 3% of that. The India column has no blanket line because most transporters do not run EDI; the pull there goes to government systems and the driver, as the next section explains.

India status pulls: e-way bill Part B, validity and ULIP lookups

India has no X12 213 equivalent in common use, so the pull pattern is applied to different sources. The shipper checks the e-way bill for vehicle updates and remaining validity, and, where it has access, queries vehicle and movement data through the Unified Logistics Interface Platform (ULIP) rather than phoning the transporter.

Under Rule 138 of the CGST Rules, an e-way bill for road movement needs Part B with the conveyance details, and when goods move from one conveyance to another the consignor, recipient or transporter must update Part B before the transfer. A Part B update on a trip that should be single-vehicle is therefore a status signal: transhipment happened. A trip with no update and fast-approaching expiry is a silence signal.

E-way bill validity under CGST Rule 138(10) is one day per 200 km for normal cargo, counted from generation with each day ending at midnight of the following day, so a 1,150 km trip receives six days; a status pull 12 hours before expiry leaves time to extend within eight hours of expiry.

The Ministry of Commerce stated in a December 2024 release that ULIP operates on a request-response mechanism and was then integrated with 39 systems of 11 ministries, providing over 1,800 data fields through 125 APIs. That request-response design suits the pull model directly: ask only for vehicles on trips that have gone quiet, not for every truck on every trip. Token handling, throttling and Part B update calls on the NIC side are covered in our guide to e-way bill API integration.

• Validity watch: compute expiry from the generation time and distance at creation, and trigger a pull 12 hours before expiry when no delivery confirmation exists.
• Part B change: treat an unexpected vehicle change as an event, not noise; it often explains a delay that the transporter has not reported.
• Vehicle data lookups: limit ULIP-based lookups to flagged trips and log the purpose, because the data concerns vehicles and drivers outside your company.
• Single-market note: the X12 213 itself is a US and cross-border practice; for Indian domestic trucking the equivalent pull runs through these portals and your transporter's own app, not through EDI.

Timeline of a stalled trailer and the inquiry that found it

The trace below follows one LTL shipment where the push feed failed and the pull rule worked. It shows why the silence threshold and the suppression timer matter more than the message itself.

1. Mon 15:42, pickup: carrier sends 214 with AT7 status X3 for PRO 7738215604 and bill of lading SH-55120; TMS records the last event.
2. Mon 17:10, departure: carrier sends AF; the lane's 95th-percentile linehaul gap is 19 hours, so the trigger is set for Tue 14:10.
3. Tue 14:10, silence rule fires: no new 214; the shipment joins the Tue 15:00 batch, and one 213 goes out with REF CN and REF BM.
4. Tue 15:04, reply: carrier returns a 214 with AT7 X4 at a cross-dock terminal, reason NS, dated Tue 03:18, proving a feed gap of nearly 12 hours; inquiry closed, carrier feed ticket opened.
5. Tue 15:20, without the rule: the earlier process would have waited for the customer's second call at Wed 10:00 and a manual portal lookup, losing almost a day of notice to the customer.

The same pattern shows up in stale tracking events and ETA uncertainty: the right response to silence is to label the estimate as old and ask the source once, not to keep refreshing a display that has nothing new to show.

Inquiry decisions coded as rules versus tasks a planner assists

Triggers, caps, suppression and matching are fixed logic that should run the same way every time. Interpretation of a confusing reply, a phone call to a terminal, or a decision to warn a customer stays with a person, with software helping to draft and summarise.

Carrier status inquiry governance keeps the trigger, the per-carrier daily cap and the six-hour suppression inside the TMS as fixed rules, while free-text K1 remarks are summarised by software and confirmed by a planner; a carrier whose inquiries reveal missed 214 events above 5% of shipments enters a feed remediation review.

Ownership needs to be written down as well. The integration team owns the 213 map and the match logic; transport planning owns the silence thresholds; carrier management owns the support matrix and the daily cap agreed with each carrier; customer service owns what is said to the customer.

Rolling out targeted inquiries one carrier at a time

Start with the carrier whose feed gaps cost the most phone time, run the rule in report-only mode for two weeks, then switch on live inquiries with a low cap. Expand only when the reply rate and the match rate both hold.

• Weeks 1 to 2, report only: the rule flags silent PROs and logs what it would have sent; planners compare the list with the calls they actually made.
• Week 3, live with low cap: inquiries go out for one carrier, capped at 1% of open PROs per day, in two batch windows.
• Week 4, measure: reply rate within four hours, match rate, share of replies that revealed a missed event, and manual lookups avoided.
• Exit criteria: at least 90% of inquiries answered within four hours and at least 98% matched automatically before adding the next carrier.
• Feedback loop: share the monthly count of revealed missed events with each carrier, because fixing their push feed is cheaper for both sides than more pulls.

Related order-level inquiries follow the same discipline. Our guide to EDI 869 order status inquiries and 870 reports applies it between buyer and supplier rather than shipper and carrier. For other transport and visibility topics, browse the Logistics and Supply Chain hub.

If you are planning carrier status integration across X12 carriers and Indian transporters and want a scoped design for triggers, caps and matching, you can send us your requirements. We will reply with a proposed rule set and test plan for your top carriers.