Cumulative Quantity (CUM) in Automotive EDI

Automotive OEMs do not manage supplier deliveries in discrete order quantities. They manage them in cumulative totals, and if your CUM does not match theirs, you take a scorecard hit before anyone picks up the phone. Cumulative quantity accounting is the running-total system behind every automotive EDI 830 planning schedule. It sounds simple, a running sum since a start date, but the segments that carry it and the reconciliation math trip up suppliers constantly.

This is the part of the 830 that OEM implementation guides bury in appendices. Here is how it actually works.

Why CUM Instead of Discrete Quantities?

Cumulative accounting lets the OEM and supplier reconcile against one continuous number instead of hundreds of individual releases. Rather than tracking whether release 4471 for 500 units shipped complete, both parties track one figure: total units shipped against this part number since the agreed CUM start date. A single number is far harder to lose track of across thousands of daily releases.

It also lets the OEM cap its financial exposure. In a cumulative model, the OEM can authorize you to fabricate up to one point and buy raw material to a further-out point. If the program is cancelled, the OEM owes you for authorized material and fabrication up to those cumulative points, and no further. That fabrication-versus-material distinction is the whole reason the authorization segment exists.

The trade-off is precision. Because everything is a running total, one missed or double-counted shipment throws off every figure downstream until it is corrected.

The ATH Segment: Cumulative Authorizations

The ATH (authorization) segment in the 830 carries the cumulative points up to which the OEM authorizes you to commit resources. ATH01 is a type code that tells you what kind of authorization the number represents.

ATH01 code	Meaning	What it authorizes
FI	Fabrication / finished authorization	Build finished goods up to this cumulative quantity
MT	Raw material authorization	Purchase raw material up to this cumulative quantity
PQ	Prior cumulative quantity	Beginning inventory / CUM as of the start reference

The FI point is always at or behind the MT point. The OEM lets you buy material further out than it lets you build finished parts, because raw material is cheaper to hold and easier to redirect than completed assemblies. That is how the OEM limits its liability while still giving you lead time.

The PQ value is the anchor. It states the prior cumulative quantity, the beginning point from which the current figures are measured. Get the PQ wrong and every calculation built on it is wrong.

The SHP Segment: Cumulative Shipped and Received

The SHP segment reports shipped or received quantities, and its qualifiers tell you whether a figure is a discrete quantity or a cumulative total. This is the segment the OEM populates back to you, and the one you reconcile against.

• SHP01 = 01: the quantity is discrete (this shipment or this period)
• SHP01 = 02: the quantity is cumulative (running total)
• SHP03 date qualifier 011: shipped on this date
• SHP03 date qualifier 050: received on this date
• SHP03 date qualifier 051: cumulative start date (the CUM anchor date)

When you read an inbound 830, the SHP segment with SHP01 = 02 and the 051 start date tells you the OEM's view of your cumulative shipped. If that disagrees with your own records, you have a reconciliation problem to resolve before it becomes a delivery-performance ding.

The Reconciliation Math

The core check: the OEM's prior cumulative authorization plus the first firm requirement equals the total that should have shipped by the schedule generation date. Compare that against your cumulative shipped to know if you are ahead, behind, or exact. OEM 830 implementation guidelines, including Stellantis's, publish this reconciliation formula.

In segment terms:

ATH03 (prior cumulative required)  +  FST01 (current firm requirement)
   =  total that should have shipped by the generation date

(total that should have shipped)  -  SHP cumulative shipped  =  position

Read the position like this:

• 0 means you have shipped exactly what was required. On target.
• Negative (you shipped less than required) means you are behind. This is the number that generates expedite calls and premium freight.
• Positive (you shipped more than required) means you shipped ahead. Not always welcome, because it inflates the OEM's on-hand inventory.

The EDI 856 ship notice closes the loop. Your ASN references the release number, and when the OEM receives goods against it, the OEM increments its cumulative-received figure. That is why a missing or mis-referenced ASN is a top source of CUM disagreement: the parts arrived, but the OEM's running total never moved.

Where Suppliers Get Burned

When an automotive scorecard dings a supplier for delivery performance, the trail usually leads back to one of three CUM failures. A wrong PQ anchor, a double-counted or missing shipment, and an ASN that failed to reference the correct release. Any one of them desynchronizes your running total from the OEM's, and every subsequent schedule reads as ahead or behind until you find the break.

Named OEM guidelines are worth reading directly, because the qualifiers and formula vary slightly by partner. FCA/Stellantis, John Deere through the JDSN supplier network, and Volvo all publish 830 implementation guides that specify their CUM handling. The ASC X12 standard defines the base ATH, SHP, and FST segments used across all of them (x12.org transaction sets).

The EDIFACT world models the same firm-versus-forecast zones through the DELFOR delivery-plan-status data element (DE 4017): firm, commitment for manufacturing and material, commitment for material only, and planning or forecast (unece.org UN/EDIFACT directories). It is the same fabrication-versus-material cap, expressed as status codes instead of ATH types.

Catch CUM Problems Before They Hit Your Scorecard

The practical defense is to parse every inbound 830, extract the ATH and SHP figures, and reconcile them against your own shipment history automatically. Doing that by hand across hundreds of part numbers is how errors slip through.

You can inspect the ATH, SHP, and FST segments of any 830 with our free EDI Inspector to see exactly what the OEM is asserting. For the difference between the forecast document and the firm ship instruction that drives your daily CUM, read EDI 830 vs 862.

Frequently Asked Questions

What is cumulative quantity in automotive EDI?

Cumulative quantity, or CUM, is the running total of parts authorized, shipped, or received against a scheduling agreement since a fixed start date. Automotive OEMs manage deliveries by these running totals rather than by discrete order quantities, so both parties reconcile against one continuous number per part.

What does the ATH segment do in an EDI 830?

The ATH segment carries cumulative authorizations. ATH01 codes identify the type: FI is fabrication or finished authorization, MT is raw material authorization, and PQ is the prior cumulative quantity or beginning inventory. The FI and MT points let the OEM authorize building up to one cumulative point and buying material to a further-out point.

How do you calculate whether you are ahead or behind on CUM?

Add the prior cumulative required (ATH03) to the current firm requirement (FST01) to get the total that should have shipped by the schedule date. Subtract your cumulative shipped (from the SHP segment). Zero means on target, negative means behind, positive means shipped ahead.

What is the difference between fabrication and material authorization?

Fabrication authorization (ATH01 = FI) permits building finished goods up to a cumulative point. Material authorization (ATH01 = MT) permits buying raw material to a further-out cumulative point. The gap gives the supplier lead time while capping the OEM's liability to authorized material and fabrication if the program is cancelled.

Why do CUM figures get out of sync?

The three common causes are a wrong prior cumulative anchor (PQ), a shipment counted twice or missed, and an ASN that failed to reference the correct release so the OEM never incremented its cumulative-received total. Any one desynchronizes your running total from the OEM's until corrected.