Who sends it
Sent by the carrier to the shipper or broker (and sometimes onward to the end customer). It is an outbound message from the carrier’s point of view.
When it fires
Throughout the life of a committed load, from dispatch to delivery. A partner’s routing guide usually specifies which status events it requires and by when.
What it carries
- The shipment and load reference numbers tying the status to the original 204.
- A status code and, for exceptions, a reason code.
- The date, time, and location the status applies to.
- For an appointment or ETA update, the new date and time.
- Equipment and stop references so multi-stop loads report per stop.
Common shipment status codes
A representative subset of standard ANSI X12 (AT7) status codes — the exact codes and the events a partner requires are set in its implementation guideline.
| Code | Meaning |
|---|---|
X3 | Arrived at pickup location |
AF | Carrier departed pickup location with shipment |
X6 | En route to delivery |
X1 | Arrived at delivery location |
D1 | Delivered |
AG | Estimated delivery / appointment update |
SD | Shipment delayed |
A7 | Refused by consignee |
Where it breaks
- A required status not sent by the deadline in the routing guide — a common source of retailer chargebacks.
- A status with a timestamp that contradicts the delivery record, which triggers a manual review.
- Duplicate or out-of-order status messages, if the carrier’s system re-sends without sequencing.
How Trailflow handles it
Trailflow EDI (beta) can send a 214 for a load that is linked to a trading partner, so status flows from the same place dispatch works the load rather than a separate portal.
Implementation and monitoring notes
Implementation planning for EDI 214 starts with the trading-partner agreement, not only the transaction-set name. Confirm the version, implementation guideline, delimiters, envelope requirements, identifiers, required elements, acknowledgment expectations, and the person responsible for resolving rejected or delayed traffic. Two partners can use the same transaction set while requiring different qualifiers, reference values, timing, and code combinations. The partner guideline remains authoritative for the actual exchange.
A useful test plan follows the load lifecycle described above. Create a controlled example, send the smallest valid message, confirm the acknowledgment, and compare the transaction against the load and partner records that should receive it. Test missing identifiers, invalid dates, duplicate messages, out-of-order events, and a partner response that rejects an otherwise valid-looking payload. Record the message ID, timestamps, environment, and correction so the team can reproduce the failure.
Monitoring should answer more than whether a file was transmitted. An operations team needs to know whether the partner received it, whether the acknowledgment was accepted, whether the transaction changed a load state, and which human owns the next action when it fails. Keep transport health, validation errors, business exceptions, and partner timing separate; they require different fixes and different escalation paths.
Common implementation boundaries include partner-specific routing guides, code lists, security credentials, retry rules, and the difference between an accepted envelope and an accepted business message. Do not infer support for a segment, code, or transaction set from a candidate list. Verify it against the actual contract, test fixtures, and release status before documenting Trailflow behavior.
Before production, map each required field to the system that owns it and define what happens when the field is absent. Decide how corrections are sent, how duplicate messages are recognized, how acknowledgments are reconciled, and how a business exception reaches an operator. These decisions are often more important to a carrier than the existence of a parser because they determine whether a transaction can be trusted during a live shipment.
Keep an implementation record for the partner: version, test dates, sample identifiers, accepted code values, contact, and escalation path. Review it when the partner changes its routing guide or when a new customer lane introduces different requirements. A reference page can explain the standard, but only the partner agreement and tested Trailflow workflow can establish the behavior a team should expect.
For troubleshooting, begin with the smallest question: did the message leave the sender, arrive at the transport endpoint, pass syntax validation, pass partner rules, and update the intended business record? Capture the answer at each stage. This sequence prevents an operations team from treating a connectivity problem as a dispatch problem or treating a rejected business rule as a generic system outage.
Teams should also agree on the business impact of a failure. A delayed status may require a manual customer update, while a rejected tender or invoice may block the next financial step. Record the priority, owner, response window, and safe manual fallback so the integration supports the operation instead of creating another unowned queue.
That operating agreement should be reviewed alongside the partner implementation guide and the current Trailflow product release status regularly.
Keep examples and test payloads separated from production records, redact commercial and personal identifiers, and retain the partner-approved version used for validation. This makes later troubleshooting reproducible without turning a public reference into an unsupported promise about a live integration.
Trailflow EDI is described as beta on this reference family. The product handling statement above is a status-aware summary, not a guarantee that every partner, version, segment, or workflow is available. Contact the integration owner before a production rollout, retain the partner's approved implementation guide, and review the page's checked date when the partner changes its requirements.
See Trailflow EDI for the product. It is in beta; supported behavior may change.