How to Set Up VDA 4905/4913 EDI With an Automotive OEM

What VDA 4905 and 4913 Actually Do (and Why an OEM Still Requires Them)

If you're onboarding as a supplier to a German automotive OEM in 2026, there's a good chance you'll be asked to support VDA 4905 EDI and VDA 4913 delivery notes before anyone even mentions an API. That's not because the OEM hasn't heard of REST or JSON. It's because VDA 4905 remains widely used or offered in parallel to newer formats across the German automotive supply base, and swapping it out plant by plant is a multi-year project nobody wants to own first.

VDA 4905 is a planning schedule message sent from the customer to the supplier, essentially the OEM telling you what to deliver and when, on a rolling basis. VDA 4913 runs the other direction: the supplier creates a VDA 4913 ASN message in response to the delivery schedule, and it functions as a classic delivery note. Under the hood, VDA 4913 is essentially an automotive-specific version of the EDIFACT DESADV message, which is why mapping tools treat it as a DESADV cousin rather than something built from scratch. The record-and-field structure is where VDA parts ways with EDIFACT and X12. A VDA message uses fixed-length elements instead of delimited segments, meaning the transmitted data can never exceed the defined field length. There's no separator character bailing you out if a field runs long; the position in the record is the only thing that tells the receiving system what a value means. That single design choice explains most of the go-live pain described later in this guide. Both message types have modern successors. VDA 4905 is the predecessor of the newer VDA 4984 message, and VDA 4987 replaces the legacy VDA 4913. Both newer formats are EDIFACT-based rather than fixed-length flat files. If you're a Tier 1 shipping just-in-time parts, you'll also run into VDA 4915, which complements the delivery planning sent via 4905 by communicating exact shipping times and quantities on a JIT basis. None of that changes the fact that most German OEM plants still run 4905/4913 for at least some of their supplier base, and that's the connection this guide walks you through.

Before You Start: What You Need

You cannot begin mapping until four things are in place, and getting them takes longer than the technical build itself.

• An OEM-issued supplier or station number. BMW/Steyr, for example, assigns each supplier an identification number that the orderer assigns to a supplier, referenced directly in the purchase order. Daimler works similarly but layers plant and unloading-point identifiers on top, which is its own headache (more below).
• The OEM's own implementation guideline, not the generic VDA specification. Every OEM customizes segments, and the published VDA recommendation is only a starting point. Ford, for instance, issues its own ASN specification and user guide in compliance with VDA recommendation 4913-2, marked proprietary and distributed only to its trading partners.
• An OFTP2-capable connection, either self-managed or through a provider. Daimler is a good example of how OEMs outsource this: Daimler relies on T-Systems as its external service provider for all OFTP2 services, handling the initial connection setup and ongoing certificate management. Setting up that connection starts with certificates: the required certificates must be exchanged bilaterally before an OFTP2 connection can be established, and major OEMs like Daimler expect certificates issued by a recognized certificate authority rather than self-signed ones, with ODETTE being one of the globally recognized issuing bodies.
• A mapping tool or EDI platform with VDA support baked in. SEEBURGER, EdiFabric, PartnerLinQ, Data Interchange, Cleo, TrueCommerce and Softzoll all ship ready-made VDA templates, since building a fixed-length parser from the raw VDA recommendation is not something you want to do from a PDF. PartnerLinQ, for example, positions itself as integrating VDA message types into a unified connectivity layer, automating transactions through SAP and non-SAP systems. Once the 4913 delivery note actually triggers a physical shipment, a connectivity layer like Cargoson sits downstream of the EDI exchange, handling carrier booking and track-and-trace rather than the message itself.

Step-by-Step: Connecting and Going Live

The path from "we got a purchase order" to "we're live on EDI" runs through seven stages, and skipping the parallel test phase is the single most common way suppliers end up with a rejected delivery note in week one of production.

1. Request the OEM-specific VDA 4905 implementation guideline and register your supplier number. Don't build against the public VDA recommendation alone. Contact the OEM's EDI or MRP department, get the customized guideline for your plant relationship, and confirm your supplier number. For multi-plant suppliers, note that Daimler requires an index character in the supplier number field when a new supplier location needs an assigned index, submitted via application to the responsible Daimler AG MRP controller.
2. Provision the OFTP2 link. Apply for your X.509 certificate, exchange it bilaterally with the OEM (or their managed provider like T-Systems), and configure your SFID/SSID. Decide early whether you're running OFTP2 in-house or through a managed connectivity provider such as Softzoll, which offers connection to its EDI data center through a transmission protocol of the customer's choice, including AS2, OFTP2, and FTP/sFTP.
3. Build the inbound VDA 4905 mapping. Focus on the record chain: record 511 (header), followed by 512 through 518 carrying article codes, call-off type codes, and quantities. The record sequencing rules are strict: 512 follows 511, 513 follows 512, and 514 or 518 close out the segment group before the file terminates. Get this sequencing wrong and your parser will silently misassign fields further down the record.
4. Load the parsed forecast into your ERP/MRP system and reconcile against the previous schedule. Each new 4905 transmission is a full replacement, not a delta, so your import logic needs to overwrite rather than append. Build a diff report comparing old vs. new schedule quantities before you trust the feed in planning.
5. Build the outbound VDA 4913 delivery note. This message uses record types 711 through 719, covering header data, transport details, delivery note items, and packaging. Packaging labeling matters here: label identification code M applies to pallets while S applies to loose cartons, and nested packaging like a KLT container on a pallet needs to be represented correctly in record 715. Consignment numbering has its own trap: a consignment number may not be repeated within the same calendar year, so your numbering scheme needs a year-aware reset, not a simple incrementing counter.
6. Enter the mandatory parallel test phase. This is non-negotiable at most German OEMs. Suppliers without an EDI link always receive their schedules automatically by fax; once a supplier can receive by EDI, a line test is conducted, followed by an eight-week phase where schedules are sent in parallel by both fax and EDI. Daimler runs something structurally similar for its 4913 delivery note: after a procedure test with the EDI hotline, each supplier transmits and independently validates as many test datasets as desired against a dedicated test plant. Use this window to compare every field, not just totals.
7. Cut over and monitor OFTP2 acknowledgments before decommissioning fax or legacy feeds. Don't switch off the fax line the day the eight weeks end. Run both channels for at least one more full schedule cycle while you confirm your SFID acknowledgments are clean and consistent.

How You Know It Worked

Three signals tell you the connection is production-ready. First, record counts and quantities on the fax feed and the EDI feed match for the entire parallel test window, not just a sample week, since the whole point of the parallel phase is letting the supplier compare the information conveyed by each channel. Second, you're getting clean OFTP2 delivery confirmations with no retransmit loops or NAK responses. Third, your VDA 4913 delivery notes are accepted at the goods-receipt point without bordereau or packing-code rejections, which you confirm by checking the OEM's data quality tooling. At Daimler, that means logging into the DQM (Data Quality Management) system, where the data sender controls the correctness of the transmission and must inform the DQM contact once the test data shows green status.

Failure Mode: Fixed-Length Field Overflows and Data Mismatches

The most common go-live failure isn't a connectivity problem, it's a mapping problem hiding in plain sight. Because VDA has no delimiters, a value that's one character too long doesn't throw an error the way an oversized field would in a delimited EDIFACT segment. It gets silently truncated or, worse, pushes every subsequent field in the record out of alignment. The OEM's parser then reads garbage into fields that follow, and you get a rejected delivery note or a misread quantity that nobody notices until goods receipt disagrees with what was actually shipped.

This is exactly why the classic VDA message types in flat file format are increasingly considered too rigid for modern supply chain management, given their fixed field lengths and limited data scope. The workaround is procedural, not technical: validate every outbound field against the OEM-specific implementation guideline (never the generic VDA recommendation) before go-live, choose a mapping tool with built-in VDA field-length validation rather than relying on manual review, and if a single field fails validation during the parallel test phase, restart the count on that eight-week window rather than pushing through with a known defect. OEM goods-receipt systems are not forgiving about a partially wrong delivery note; it costs you far more in expediting and manual intervention than the extra weeks of testing would have.

Where VDA EDI Fits Alongside Modern API/TMS Tooling

The direction of travel is clear even if the timeline isn't. New VDA guidelines such as VDA 4984 and 4987 are, from a technical standpoint, EDIFACT-based formats rather than the old flat-file structure, which makes them considerably easier to map and validate. Daimler's own migration under "Project Future" illustrates the pattern: the group still uses the first-generation VDA message types, including 4905 and 4913, mainly to connect its German plant locations, while newer EDIFACT-based VDA formats are rolled out elsewhere. If you're a global Tier 1, expect to run both generations simultaneously for years, plant by plant. What's changed more than the message format is where transport execution happens once the 4913 delivery note goes out. Increasingly, carrier booking, dock scheduling and shipment visibility live outside the EDI message itself, in TMS or carrier-connectivity platforms like MercuryGate, Descartes, Transporeon, or Cargoson, which pick up once the ASN has been generated and route the actual physical movement. The VDA message and the transport execution layer aren't competing systems, they're solving different halves of the same delivery: one moves data, the other moves the truck.

Next Steps

If you're starting this project now, get the OEM-specific implementation guideline and your supplier number requested this week, since that step alone can take longer than the mapping build. Line up your OFTP2 certificate provisioning in parallel rather than sequentially, and budget the full eight-week parallel test into your go-live timeline from day one rather than treating it as a formality to compress. And if your VDA 4905/4913 connection is stable, start scoping the migration path to VDA 4984/4987 now. Retrofitting an EDIFACT-based successor onto a supplier base still running fixed-length flat files is its own project, and the OEMs pushing it aren't waiting.