Automotive EDI: connecting customer requirements to the work on your floor

A customer sends a revised delivery schedule. Your EDI system receives it successfully. The next question is whether planning sees the right demand, shipping uses the right packaging information and someone notices an exception before the truck leaves.

That gap between receiving a message and acting on it is where automotive EDI becomes a business systems problem. Automotive EDI is one of our core competencies at Weekend Web Solutions. Our work starts with understanding what the transaction means for the people and systems that depend on it.

Translation is one part of the job

An EDI translator converts structured messages into a format another application can use. Middleware connects that exchange to your internal process: validating references, applying agreed mapping rules, updating the appropriate records and making failures visible.

Consider a fictional supplier receiving a revised schedule for a machined component. A useful integration has to distinguish the customer part number from the internal item, identify the receiving location and interpret dates and quantities correctly. It must apply the customer’s rules for whether the new information replaces or supplements earlier demand.

If that interpretation is wrong, a technically valid file can still produce the wrong production plan. A successful transfer is evidence of transport; it does not establish that the ERP accepted the transaction or that the customer accepted the resulting shipment information.

There is no single automotive customer map

Public documentation shows why “automotive EDI compatible” needs a defined scope. Requirements depend on the customer, business unit, message version and destination process.

Magna’s EDI guideline directory includes EDIFACT, VDA, ODETTE and ANSI X12 material, with separate divisional resources. Even within one group, the relevant implementation guide matters more than a broad claim to support a standard.

GM’s certification instructions distinguish message requirements by business unit and describe integration testing before production cutover. Building a parser is therefore only one step in preparing a supplier connection.

Volkswagen’s March 2023 communication guideline specifies OFTP2 over the internet as its standard transmission method and sets rules for identifying message types in transferred files. Confirm the current applicable requirements during onboarding.

These examples describe particular published programs. They do not establish that one connection or one completed test covers every brand, plant or region.

Connect the schedule, shipment and exception

For our fictional supplier, a practical workflow would link the original customer message to the internal demand record and preserve the mapping version used. If a part or destination cannot be resolved, the transaction should enter a visible exception queue with an owner.

Shipping needs the same discipline. The advance shipping notice, shipment record and physical labels should agree on the identifiers and quantities required by that customer’s process. A general inventory label generator should not be assumed to meet an automotive customer’s label specification.

Before automating the workflow, answer four questions:

• Which system owns each field and business event?
• How are revisions, cumulative quantities and partial shipments interpreted for this customer?
• Which acknowledgments or application responses establish the status you display?
• Who resolves a rejected message, and how can they retry it without duplicating the business transaction?

The answers define a useful integration more clearly than a list of supported file formats.

Middleware can fit around an existing connection

A supplier may already have a working communications provider while still relying on spreadsheets and manual entry between EDI and the ERP. Improving that handoff can be a sensible starting point.

The proposed scope might be an ERP adapter, a validation step, a shipping integration or a view that connects messages to unresolved business exceptions. The scope should identify who operates transport, who maintains maps and who supports the production workflow.

If OFTP2 is part of the solution, Odette provides software interoperability testing. That testing concerns the protocol implementation. It should not be presented as approval of every customer map, ERP integration or business process built around it.

Start with one real customer flow

Choose a specific supplier location, customer program and transaction set. Gather the current implementation guides, permitted sample messages, ERP interface details and the process for testing and cutover. Then follow a representative transaction from receipt through business acceptance.

Include awkward cases: an unknown part, a revised schedule, a duplicate transmission, a rejected shipment notice and a connection interruption. The purpose is to learn whether the integration helps people recover accurately as well as process the routine work.

If your automotive EDI connection works but the work around it still depends on copying, checking and chasing, tell us where the handoff breaks down. We can discuss the customer requirements and the systems that need to connect.

Public sources reviewed October 24, 2026. Customer requirements and onboarding procedures should be reconfirmed for the specific program before implementation.