EDI 830 vs 862: How Planning and Shipping Schedules Work Together in Automotive Release Accounting

EDI 830 vs 862 at a glance

Both documents are part of the ANSI X12 standard, and both describe customer demand for the same parts. The difference is time horizon and purpose. If you're new to the standards themselves, start with our overview of EDI standards.

Frequency, horizon, and bucket size vary by trading partner. Each customer defines them in its own EDI implementation guide.

What is an EDI 830 (830 planning schedule)?

What the 830 tells you

The 830 gives your customer's projected requirements by part and ship-to location across a planning horizon. It separates firm quantities, which you're expected to ship, from planning quantities, which are forecasts that will change.

The most important thing to understand about an 830 is that it is a restatement, not a new purchase order. Each new 830 replaces the picture the previous one gave you. If your system treats every 830 as additional demand, quantities stack up quickly.

Key segments to understand

You don't need to read raw EDI every day, but knowing a handful of segments makes it much easier to diagnose problems. The example below is simplified and illustrative, not any customer's specification.

Why fabrication and material authorizations matter

The ATH segments are easy to overlook, and they carry real financial weight. Authorizations define how much finished product you're authorized to build and how much raw material you're authorized to buy. If you buy long-lead material beyond what's authorized and the program changes, the exposure may be yours.

The terms behind authorizations are set by each customer's contract and supplier requirements manual. Know them before your purchasing team acts on planning quantities.

What the 830 should drive in your system

• MRP and purchasing, especially for long-lead material.
• Capacity and labor planning.
• Shipping, for customers who send only an 830 with firm near-term buckets and no 862.

What is an EDI 862 shipping schedule?

What the 862 tells you

The 862 gives near-term, firm shipping requirements, usually daily and sometimes with specific delivery times. It reflects the customer's latest production reality, which is why it changes so often. Where the 830 says "here is roughly what we'll need this month," the 862 says "here is what we need on these days."

Key segments

Some customers also use a JIT segment for time-of-day requirements. The horizon dates in the BSS segment matter more than they look: they tell you exactly which dates this 862 governs.

Not every customer sends an 862

Many customers ship off the 830 alone, using firm near-term buckets. Others send both. Your system needs to handle each model on a per-customer basis rather than apply one global rule to every trading partner.

How the 830 and 862 work together

This is where most release-accounting problems start. The two documents describe the same parts over overlapping dates, and your system has to decide which one to believe for each date.

Which schedule wins when they overlap

For the dates an 862 covers, the 862 typically supersedes the 830. Beyond the 862's horizon, the 830 still governs. The most common failure is adding the two together for the same dates, which double-counts demand.

Some customers define the overlap differently, which is why this has to be confirmed customer by customer rather than assumed.

"As much as the industry is striving for a common method of communicating via EDI — it is as varied as the customers we serve."

Ship dates vs. delivery dates

A shipment-based schedule tells you the date to ship. A delivery-based schedule tells you the date the customer needs the parts at its dock. For a delivery-based schedule, you have to back off the transit days to that ship-to. Skip that step, and every shipment leaves on the date it should arrive.

Turning weekly buckets into daily shipments

A weekly 830 bucket doesn't tell you which day to ship. Ship-code logic, such as "ship on Monday" or "split evenly Monday through Friday," turns a bucket into a shipping plan. Standard pack rounding then adjusts each quantity to full containers, which is also what drives your AIAG barcode labels on the way out the door.

Where CUMs connect everything

CUM (cumulative) accounting is the thread that ties the 830, the 862, and your shipments together. It works the same way regardless of which document you're shipping to.

• Discrete vs. cumulative schedules. Some customers send quantities per date. Others send a running CUM required, the total quantity they need by each date since the CUM start.
• The core calculation. Net requirement = CUM required − supplier CUM shipped.
• Reconciliation. Compare your CUM shipped with the customer's CUM received from the SHP segment. Any gap should equal shipments that are still in transit.
• Model-year CUM resets. Many customers reset CUMs at model-year changeover, on a date the customer sets. Both sides have to reset on the same date, or every calculation after it is off.

EDI 866: when sequence matters

The X12 866 (Production Sequence) tells you the order in which parts must arrive to match the customer's build sequence. It's used in sequenced delivery and in-line vehicle sequencing (ILVS) programs.

Think of the three documents as layers. The 830 handles planning, the 862 handles daily quantities, and the 866 handles the order and timing of individual parts or sets. Sequencing raises the stakes because a sequence error shows up immediately on the customer's line, so internal sequencing, labeling, and shipping have to stay tightly aligned.

DELFOR vs DELJIT: the EDIFACT equivalents

Customers outside North America, and some global Tier 1s, use the UN/EDIFACT standard instead of X12. The concepts map closely.

Suppliers that ship to both North American and European or global customers often receive both standards. The overlap rules and CUM logic still apply; the segment structures are different, so your system has to interpret each correctly.

Five common 830/862 mistakes

1. Double-counting overlapping schedules. Adding the 830 and 862 for the same dates leads to overproduction and inventory you didn't need.
2. Treating each release as a new order. Releases are restatements. Stacking them inflates demand and sends the wrong signal to MRP and purchasing.
3. Ignoring CUM discrepancies. Small gaps left until quarter-end or model-year changeover compound into shipment disputes that are hard to trace.
4. Shipping to delivery dates. On a delivery-based schedule, skipping the transit-day offset means every shipment arrives late.
5. Re-keying releases manually. Typing releases into an ERP that wasn't built for release accounting is where typos, missed changes, and lag creep in.

Questions to confirm with every customer

Most of the mistakes above trace back to an assumption about how a customer uses its schedules. These questions close the gap. Ask them during onboarding, and again whenever a customer changes its EDI version or launches a new program.

What your system should do with 830s and 862s

Whatever software you use, these are the capabilities that keep release accounting accurate:

• Process inbound 830s and 862s automatically, without manual re-keying.
• Apply customer-specific overlap rules instead of one global rule.
• Map firm and forecast requirements separately.
• Track CUM required, CUM shipped, and CUM received to calculate net quantities.
• Apply ship-code logic, transit days, and standard pack rounding.
• Keep release history so planners can compare what changed from one release to the next.

Generic ERP systems often handle orders well but weren't designed around automotive release accounting. That's the gap AIM's automotive EDI software was built to close.

How AIM handles release accounting

The right AIM solution depends on your ERP and on which system you want to own day-to-day execution.

Frequently asked questions

EDI segment examples and quantities in this article are simplified illustrations, not any customer's implementation guide. Always follow your trading partner's published EDI specifications and supplier requirements.