How to Send a DB Schenker Transport Order via EDIFACT

DB Schenker still runs core booking and tracking on UN/EDIFACT, not REST. If your platform integrates with them at volume, you need to build a valid EDIFACT IFTMIN transport order, get it through their gateway, and correctly reconcile the CONTRL, IFTMCS and IFTSTA replies that come back. This walkthrough does exactly that, segment by segment, including what to do when the interchange bounces.

What you need before you start

You need a signed trading partner agreement with DB Schenker's EDI team, the right message directory versions confirmed in writing, and a sandbox interchange to test against before you touch production.

DB Schenker's own developer documentation lists three messages you'll be working with: an IFTMIN in S93A for booking shipments, an IFTMCS in S93A as the receipt and confirmation that the EDI is received, and an IFTSTA in D96A carrying observations that have happened, such as an STS+ANT segment meaning the shipment has arrived at a terminal. Note the version mismatch: booking and confirmation run on the older S93A syntax, while status tracking runs on D96A. If you build your parser against the wrong directory, segments will validate structurally but fail semantically. That's a silent bug, not a rejected interchange, and it's worse.

EDI onboarding at DB Schenker is handled per country, so confirm you're talking to the correct local contact before you request test credentials. You'll also need:

• Your AS2 or OFTP2 connection details: certificates, AS2-ID or OFTP2 SSID, and the gateway endpoint for your country.
• Sender and receiver identifiers (GLN or EDI ID) agreed with DB Schenker for the UNB envelope.
• A sandbox interchange number range you can burn through freely without touching production references.
• A copy of DB Schenker's IFTMIN and IFTSTA field guides, which specify their conditional and mandatory segment usage on top of the base UN/EDIFACT standard.

Step-by-step: building and sending the IFTMIN

Building a valid IFTMIN means mapping your internal shipment order onto a fixed segment sequence, wrapping it in a correct UNA/UNB/UNH envelope, validating against the directory, and transmitting it as a syntactically complete interchange.

1. Map your shipment order to IFTMIN segments. The IFTMIN message header opens with UNH and BGM, which carries the document name and reference, followed by party data in NAD, with TDT and EQD describing mode and equipment needs. Your pickup and delivery locations go in LOC segments inside segment group 1, weights and dimensions go in MEA and DIM, and your goods description goes in GDS or the GID group depending on whether you're sending a full-load or itemised consignment.
2. Add reference segments for correlation. Use RFF+SI to carry your own shipment reference. This is the field that lets you correlate everything that comes back. DB Schenker's own IFTSTA field guide confirms that the consignment reference you send is expected back unchanged in status updates, identified by AAM as either the consignment number or the waybill number DB Schenker allocates.
3. Assemble the envelope. The structure is UNA (service string advice, optional but recommended if you use non-default delimiters), UNB (interchange header with sender, receiver, date/time, and a unique interchange control reference), then UNH opening the message itself with the message type reference, e.g. UNH+ME000001+IFTMIN:D:01B:UN:EAN004'. Get the syntax identifier and version wrong here and the whole interchange fails before anyone reads your cargo details.
4. Validate against the message directory before transmission. UN/EDIFACT's own definition of the message states it provides the definition of the Instruction message to be used in Electronic Data Interchange between trading partners involved in administration, commerce and transport. That's the base spec. DB Schenker layers its own conditional/mandatory rules on top, so run your generated message through both a generic EDIFACT validator and, if DB Schenker provides one, their own test harness.
5. Transmit via AS2 or OFTP2 and require a syntax-level receipt. Don't fire-and-forget. Request a CONTRL acknowledgement on every interchange, at minimum a technical receipt confirming the envelope was readable.
6. Correlate the inbound IFTMCS against your outbound UNH/BGM reference. The confirmation message should echo your document number and consignment reference. If it doesn't match, treat it as a mismatch, not a success.
7. Consume IFTSTA events as they arrive and de-duplicate by control reference. Status feeds from a carrier the size of DB Schenker arrive continuously and occasionally twice. Store the UNB interchange control reference plus the CNI consignment reference as your dedup key, and treat replayed control references as no-ops, not new events.

How you know it worked

Success is three things lining up: a positive CONTRL confirming syntax acceptance, an IFTMCS carrying the same consignment reference you sent, and a first IFTSTA event confirming pickup.

Cross-check references end to end. Your outbound RFF+SI reference should reappear in the IFTMCS, and the same consignment identifier should surface again inside the CNI segment group of every subsequent IFTSTA. If your platform tracks freight-order or stop-level identifiers internally, carry those as additional RFF references so they come back attached to specific status events rather than just the shipment as a whole. Any break in that reference chain, an IFTMCS with a reference you don't recognise, or an IFTSTA with a consignment number that doesn't map to an open order, is a signal to quarantine the message rather than silently drop it.

Failure mode: the interchange gets rejected

A rejected interchange usually comes back as a negative CONTRL, not an application-level error message. There is no equivalent of an HTTP 400 with a JSON error body here.

The common causes are a wrong syntax version declared in UNH, a missing mandatory NAD or LOC qualifier, or a segment count in UNT that doesn't match what you actually sent. EDIFACT interchanges don't have a partial "accepted with errors" state the way X12 does: the interchange, group, or transaction set is either accepted or rejected outright. The CONTRL's UCI segment carries an action code, 8 for accepted, 7 for accepted with some rejected transaction sets, 4 for a rejection caused by an error in the UNA or UNB segment, per the EDIFACT CONTRL error code table. If the rejection is deep enough (a malformed UNB, for example) DB Schenker's system may not even be able to generate a syntactically valid CONTRL, in which case the error has to surface some other way, so don't assume silence means success.

Treat every negative CONTRL as a dead-letter case:

• Log the raw segment string, not just a parsed summary. You'll need the exact bytes to diagnose delimiter or character set issues.
• Identify the failing segment tag and data element from UCI5/UCM4 or equivalent, and fix the mapping at source.
• Replay only after correcting the underlying data. EDI has no exponential-backoff convention; blindly resending a structurally broken message just produces another rejection with a new interchange reference, burning your control number sequence for nothing.

Fitting this into a hybrid EDI/API carrier integration platform

The cleanest way to run DB Schenker's EDIFACT stack alongside API-first carriers is to wrap IFTMIN, IFTMCS and IFTSTA behind the same envelope-versus-payload abstraction you'd already use for REST webhooks, so your downstream order and tracking services never see raw segment strings.

Most shippers running DB Schenker alongside API-first carriers end up normalising both into one internal event schema rather than exposing EDI quirks to application code. That's the same pattern multi-carrier platforms use across the board.

Once IFTMIN generation and IFTSTA reconciliation are working reliably in isolation, the next step is wiring the dedup and dead-letter logic above into whatever event bus your platform already uses for API-based carriers, so a DB Schenker status update and a REST webhook from another carrier land in the same idempotent processing path.