Sending an EDI 753 Routing Request to Walmart

Step-by-step guide to submitting an EDI 753 to Walmart, reading the 754 response, and meeting OTIF routing deadlines without penalties.

Sending an EDI 753 Routing Request to Walmart

Miss the 4:00 PM CST cutoff on a single Walmart collect PO and you're not just late on paperwork. You've triggered a "Late Transport Notification" that follows you into the OTIF scorecard, and it stacks with every other collect shipment that goes sideways that quarter. The EDI 753 Request for Routing and its 754 response aren't optional formality for suppliers shipping collect to Walmart distribution centers. This walkthrough covers the exact segments to populate, how to read what comes back, and what to do when the timing goes wrong.

What the EDI 753/754 Exchange Actually Controls

The 753/754 pair governs collect shipments only, meaning Walmart arranges and pays the freight rather than you. Collect means Walmart arranges and pays for transportation using its own or contracted carriers. If you're shipping prepaid, where you select and pay the carrier, this transaction pair doesn't apply to you. This distinction matters because the two models are scored differently and mixing up which set of rules applies to a given PO is a common root cause of avoidable deductions.

On a collect PO, you send an EDI 753 once the shipment is ready, and Walmart responds with an EDI 754 that specifies who's picking it up and when. The deadline discipline is unforgiving: you will see a "Late Transport Notification" if the Request for Routing was not completed in a timely manner, and requests for routing should be submitted by 4:00 PM CST the day after receiving the order. That clock doesn't pause for Saturdays, either. This includes weekend days, so be sure that you're able to route all POs the day of, and the day after, any of your order review days of the week.

The stakes are real money. To remain compliant, suppliers must meet Walmart's published thresholds of 98% Collect Ready, 90% On-Time Prepaid, and 95% In-Full, and missing any of these thresholds can trigger a 3% penalty on the cost of goods for non-compliant cases, per Inymbus's breakdown of the OTIF program. A 3% chargeback on a mid-size PO adds up fast once it's happening across dozens of DCs a month.

Before You Start: Prerequisites

You need a working EDI foundation before you touch the 753/754 pair. Trying to bolt routing requests onto a partial setup is how mapping errors sneak into production.

  • An already-live trading partner connection with Walmart: 850 (PO), 855 (PO acknowledgment), 856 (ASN), and 810 (invoice) exchanging cleanly, with your ISA/GS qualifiers already assigned and tested.
  • A confirmed communication channel, whether AS2, SFTP, or a VAN, tested end to end with test/production ISA envelopes.
  • An EDI translator or managed service that supports X12 753 and 754 in the version Walmart requires. Check your trading partner spec before you build, since version mismatches (4010 vs 4030 vs 6020) change segment usage and element requirements.
  • Shipment-ready data pulled from the accepted 850/855: PO number, weight, pallet or carton count, ready date, and ship-from location.

If any of these pieces are missing or shaky, fix them first. A 753 built on stale PO data or sent through an untested AS2 connection is a guaranteed rejection, and you'll burn your window troubleshooting instead of shipping.

Step-by-Step: Building and Sending the 753

Here's the build sequence, segment by segment, for a standard EDI 753 aimed at Walmart's routing group.

  1. Pull ready-to-ship data from the accepted 850/855 pair. Only generate a 753 for POs Walmart has already confirmed through the 855. Sending a routing request against an unacknowledged PO invites a mismatch.
  2. Populate the envelope. Your ISA/GS should route to Walmart's functional group for routing. GS (RF) groups routing-related transactions, since RF indicates Routing and Freight transactions, per EDI2XML's structure guide. Follow with ST*753, which identifies the document as an EDI 753.
  3. Populate BGN. This is the routing request reference number and date. This reference number is what you'll trace back to when the 754 comes in, so make sure your translator generates it consistently and logs it.
  4. Build the two required N1 loops. One iteration of the N1 segment must be used to identify the ship-from location, and one iteration of the N1 segment must be used to identify the ship-to location, per the AAFES 753 implementation guide. Get these swapped and Walmart's system will route to the wrong facility or reject the transaction outright. This is one of the most common mapping errors on this transaction.
  5. Add N4 geographic detail, then open the LX loop. N4 carries the city/state/zip tied to each N1 party. Once that's set, LX acts as the line counter for detail loops, per EDI2XML, letting you group shipment details per PO.
  6. Set the pickup window in G62. This segment carries date/time detail covering pickup windows and must-arrive-by dates. Use it to convey your earliest and latest ready times, not just a single date, since Walmart's routing engine uses that window to consolidate your load with others on the same lane.
  7. Add AT8 for weight, quantity, and volume totals. Segment AT8 provides the total weight, quantity and volume pertaining to the shipment, per Stedi's X12 753 reference. This figure needs to reconcile with your PO cube data, since a mismatch here is a frequent rejection cause.
  8. Close with SE/GE/IEA and transmit. Log your outbound control number for reconciliation against the 997 and eventual 754. Don't skip this logging step; when a routing request goes missing, the control number is how you prove you sent it on time.
  9. Confirm your submission timing against the deadline. Every 753 needs to land before 4:00 PM CST the day after PO receipt, weekends included. Build this check into your process, not into memory.

Step-by-Step: Reading and Acting on the 754 Response

The 754 is Walmart telling you exactly how the shipment moves. Miss a detail here and you're not just risking a scorecard hit, you're risking a shipment that shows up with the wrong carrier at the dock.

  1. Confirm receipt with an outbound 997 immediately upon parsing. This is standard functional acknowledgment hygiene, and skipping it leaves Walmart with no proof you received the routing instructions.
  2. Extract the carrier, pickup window, and delivery appointment. The retailer responds with the EDI 754 Routing Instructions document, which confirms the details on EDI 753, indicates any changes to the pickup date and time, and specifies the chosen carrier who will be making the delivery, per TrueCommerce's 754 documentation.
  3. Lock that carrier into your TMS or dispatch system exactly as specified. Treat the named carrier and SCAC as fixed. Booking a different carrier, even one that arrives inside the pickup window, moves the shipment outside the routing plan Walmart approved, and that's not a risk worth taking to save a few dollars on freight.
  4. Generate GS1-128 labels and stage freight to match the confirmed pickup window. Don't stage against your original requested window from the 753 if the 754 shifted it.
  5. Trigger the 856 ASN only after 754 confirmation, matching all routing details. Once the EDI 753 is confirmed, the retailer will send an EDI 754 Routing Instructions back to the supplier, then the supplier sends an advance ship notice before the shipment reaches the trading partner, and its details must match those of the 753 and 754, per SPS Commerce. An ASN that references a different carrier than the confirmed 754 is a mismatch that shows up downstream in your compliance reporting.

How to Know It Worked

You'll know the exchange went cleanly when a short list of checks all come back clean, ideally reviewed daily rather than after the fact.

  • A 997 accepted for both the 753 and the 754, with no negative acknowledgment.
  • The carrier on the 754 matches the carrier actually dispatched, with no substitutions.
  • The 856 ASN transmitted before physical pickup, referencing the same PO, carrier, and pickup date as the 754.
  • No Late Transport Notification or Collect Ready deduction showing up against the PO in Supplier Center.

Supplier Center is where all of this reconciles: POs, ASNs, the OTIF scorecard, item setup, fines, and disputes live there. Make it a daily habit to open the scorecard, the deduction queue, and the open PO list. The deduction queue in particular is where unbilled chargebacks land before they hit your remittance, so catching an issue there gives you a window to dispute before the money actually moves.

Failure Mode: Missed Routing Deadline or Rejected 753

When a routing request lands late, Walmart's logic is blunt about it. This means that the supplier failed to submit a request for routing by 4:00 PM CST the day after the PO was submitted by Walmart, per SupplyPike's OTIF accountability breakdown, and that failure registers regardless of why it happened.

In practice, three root causes show up repeatedly: order review day misalignment (your team assumes a Monday deadline when the PO landed Friday), weekend gaps where nobody's monitoring the queue, and mapping errors where the N1 ship-from and ship-to loops got swapped or the AT8 totals don't match the PO1 cube data, causing an outright rejection instead of a late submission.

The fix is monitoring, not heroics. Build an alert against your order management system that flags any open collect PO approaching its routing deadline, ideally with enough lead time that someone can act on it manually if the automated 753 fails to generate. If a carrier genuinely doesn't show for a scheduled pickup, you are required to submit a ticket to Walmart Transportation if a carrier does not show up for a pickup appointment in order to avoid accountability for that miss. And if a fine still lands that you believe is wrong, it's disputable through Walmart's Accounts Payable Dispute Portal (APDP) in Retail Link, with your 997 and 754 timestamps as the documentation that proves timing.

Where This Fits in a Broader Carrier Connectivity Stack

The 753/754 pair is X12-specific and retailer-controlled, which sets it apart from carrier tendering standards like EDI 204 and 990 used with contract carriers, or EDIFACT IFTMIN if you're also managing European lanes. It's a narrow, high-consequence transaction, and most companies don't build custom tooling just for it. Instead, it gets handled inside whatever translator or TMS layer already manages the rest of the EDI stack.

Tool categoryExamplesNative X12 700-series supportTypical fit
Full-service EDI/retail compliance providersSPS Commerce, TrueCommerce, CleoYesManaged mapping and monitoring for retailer-specific 753/754 conventions
Multi-carrier TMS / transport executionMercuryGate, Descartes, Transporeon, Oracle TM, SAP TMVaries by moduleTurning a confirmed 754 carrier assignment into an actual dispatch or booking without manual re-entry
Retail/supply chain platformsManhattan Active, Blue Yonder, E2open, AlpegaVaries by moduleEnterprise-wide fulfillment and network planning, with EDI as one integration layer among several
Carrier connectivity / freight visibility layersCargosonVia EDI translator integrationConsolidating carrier bookings and status across lanes once routing is confirmed
Lightweight parcel/multi-carrier shipping toolsShippyPro, Shipmondo, Sendcloud, ShipStationNoNot built for X12 700-series routing; generally paired with a dedicated EDI translator for big-box retail lanes

If you're a mid-market supplier running a lightweight parcel tool for most shipping and hitting a wall on Walmart's routing requirements, that's the expected pattern, not a sign you've picked the wrong tool. Pair it with a translator or connectivity layer that actually speaks 753/754, and keep your OTIF monitoring separate from your general shipping dashboard so a routing deadline never gets buried under parcel tracking noise.