CUM Quantity Drift: The Auto-Component Reconciliation Problem Nobody Talks About

A Tier-1 stamping supplier in Manesar opens its month-end Maruti delivery position and finds a 1,400-unit gap between what its dispatch log says it has shipped against a 50,000-unit scheduling agreement and what the Maruti e-Nagare portal shows as received cumulative since the 1 April reset. Nothing was lost on a truck. No quality reject explains it. Tracing the gap takes three days and lands on a single duplicate ASN three weeks earlier, when the portal timed out and the supplier’s gateway retried. The duplicate was de-duplicated at the OEM end but counted twice in the supplier’s CUM-shipped. From that day every call-off has been computed against a CUM that was permanently 1,400 ahead on the supplier side, every weekly e-invoice has billed slightly more than the OEM actually received, and the Section 393(1)(k) TDS deduction the OEM made on the conversion portion has been quietly off-base for nearly a month. This is cumulative quantity drift auto component reconciliation — the failure mode that nobody talks about because each individual delivery, looked at in isolation, looks fine.

Quick reference

What CUM accounting actually is

Indian OEMs — Maruti Suzuki, Tata Motors, Mahindra & Mahindra, Hyundai, Bajaj Auto, Toyota Kirloskar, Bosch acting as a system supplier — do not buy auto components by discrete purchase order. They run scheduling agreements: long-lived contracts against which the OEM transmits a continuous stream of releases. Each release is a delivery schedule, not a PO. The supplier never sees a “PO number per truck” — it sees a rolling schedule line that updates daily.

Because there is no discrete order, the quantity on every document in the chain is a running cumulative, not a per-shipment number. The ANSI X12 862 firm shipping schedule does not say “ship 3,000 units this week.” It says “CUM-required is 84,000 as of this date” — meaning the OEM expects the supplier to have shipped 84,000 units in total since the last reset. The 856 ASN does not say “this truck carries 600 units.” It says “CUM-shipped is 84,600 as of this dispatch.” The OEM’s goods receipt does not record a per-PO quantity. It records “CUM-received is 84,000.”

The supplier’s open delivery requirement is the difference: CUM-required minus the supplier’s own confirmation of CUM-received. Both sides reset to zero at an agreed marker — 1 April for Indian fiscal alignment in most agreements, or a model-start date when a new programme launches.

This works beautifully when the data flows are clean. It is catastrophic the moment they are not.

How a single ASN error becomes permanent drift

A discrete PO model self-heals. If you ship 590 against a 600-unit PO, you raise a backorder for 10. The OEM closes the PO when the 10 arrive. Next PO starts at zero.

CUM accounting does not self-heal. Consider the duplicate-ASN case in detail:

• Day 9 of April. ASN #41 carries 600 units. Supplier’s EDI gateway transmits it. The Maruti portal acknowledges receipt. Two seconds later the gateway sees a transient timeout flag and automatically retries. Maruti accepts the retry but its receiving system de-duplicates by ASN number and books CUM-received += 600 only once. The supplier’s dispatch log, however, has incremented CUM-shipped by 600 twice — once for the original send, once for the retry.
• Day 10. Supplier’s CUM-shipped = 12,600. OEM CUM-received = 12,000. Gap = 600. But nobody looks because the goods physically arrived and the line is running.
• Day 11. OEM transmits the next 862. It carries CUM-required = 12,800 (because the OEM’s plan needs 800 more by Day 14, computed off CUM-received = 12,000). Supplier sees CUM-required 12,800, knows it has shipped 12,600, computes “I owe 200 more” — but it has actually already shipped them in the duplicate. Supplier ships another 200.
• Day 14. Supplier’s CUM-shipped = 12,800. OEM CUM-received = 12,400. Gap is still 400. The drift has not closed; in fact, the supplier has now over-shipped 400 real units that will land somewhere — usually in the OEM’s overflow bin, eventually triggering a returnable-bin reconciliation exception or a quiet stock build at the line.
• Day 21. Supplier’s CUM-shipped = 13,800. OEM CUM-received = 13,200. Gap is 600 again, but compounded by the over-shipping spiral.

The drift does not net out. Every call-off the OEM transmits is computed against the OEM’s correct CUM-received, but the supplier reads it through the lens of its wrong CUM-shipped. The only fix is a joint CUM correction: both sides identify the duplicate ASN, agree the de-duplication, and the supplier reverses 600 from its CUM-shipped book. There is no “credit note” or “extra shipment” that solves it operationally because the underlying physical movement was fine.

Why CUM drift goes undetected for weeks

Each new delivery looks normal in isolation. The supplier reads the latest 862, ships the next call-off quantity, and the immediate gap to the visible CUM-required closes for that delivery. No exception fires.

The drift only becomes visible when someone explicitly compares CUM-shipped on the supplier side against CUM-received on the OEM side — which most finance teams only do at month-end, quarter-end, year-end or model-end. By then the drift has been carried for two to six weeks. Three problems compound:

1. Originating-ASN traceability is harder after three weeks. EDI gateway logs roll off. Portal timeout incidents are not flagged as exceptions because they “succeeded” on retry. The supplier ends up reverse-engineering the drift from the dispatch register.
2. GST has already been filed for an interim period if the periodic billing window closed during the drift. The supplier’s weekly or fortnightly e-invoice may have been raised against CUM-shipped (raw ASN quantity) rather than CUM-received (confirmed at the OEM end). Output GST is overstated; the OEM’s GSTR-2B will not match the supplier’s GSTR-1 on that line.
3. The OEM’s Section 393(1)(k) TDS deduction at 2% (payment code 1012) on the conversion portion has been applied to a billed quantity that does not match received quantity. Form 26AS will eventually show a TDS credit that the supplier cannot tie back to a clean delivery.

The four-way CUM match — the only control that catches it

The match every auto-component supplier needs, run per part per ship-to point per agreement:

1. 862 CUM-required — the firm authorised dispatch quantity to date.
2. 856 CUM-shipped — the supplier’s running total dispatched.
3. OEM GRN CUM-received — the OEM’s confirmation of what physically arrived (after de-duplication, rejections, returns).
4. Periodic tax invoice CUM-billed — the cumulative quantity actually invoiced under GST.

The control is not “did this week’s ASN match this week’s GRN?” That comparison gives a false-clean every time, because the per-shipment number can be right while the cumulative is wrong. The control is CUM-shipped vs CUM-received as a continuous comparison, with a CUM-drift flag raised the moment they part company and held open as a standing exception until a joint correction is recorded.

This is the auto-industry cousin of PO-GRN-invoice three-way matching in India, but with two extra dimensions: there is no PO (only a rolling schedule), and every quantity is a cumulative.

Reset markers — the only place CUM legitimately zeros

The cumulative does not reset on a calendar quarter. It resets at two agreed points:

• Year-start. Most Indian OEM scheduling agreements zero the CUM on 1 April to align with the Indian fiscal year. Some use 1 January or a programme-anniversary date. The reset must be explicitly stored in the part master per agreement.
• Model-start. When a programme launches (or a major variant transition lands), the CUM zeros against the new programme code. The old programme’s residual CUM is closed out separately.

The dangerous moment is the reset itself. If a CUM drift is sitting open on 31 March and both sides zero on 1 April without agreeing the carry-forward, the drift is buried in the closed-out residual and lost. A reconciliation discipline must produce a reset re-anchor record that formally agrees the closing CUM on both sides before the new year opens.

The cross-period close-out reconciliation pain

The same drift mechanic that hides inside a month hides spectacularly across periods. Year-end is the brutal one. Three things have to be true at 31 March:

1. The supplier’s CUM-shipped per part per agreement equals the OEM’s CUM-received within tolerance and any open drift is documented.
2. The cumulative quantity actually billed under GST equals the cumulative quantity received and accepted — not the cumulative quantity dispatched.
3. The TDS the OEM has deducted under Section 393(1)(k) at 2% (payment code 1012) on the conversion portion ties back to the same billed quantity, and Form 26AS reconciles to the books.

If any of those fail, the carry-forward into 1 April starts wrong, and the model-end close-out a year or two later inherits compounded drift. We have seen Tier-1 suppliers carry undetected cumulative drift across two annual closes before a year-end audit catches it — and at that point the unwind question is no longer “which ASN broke” but “which financial year’s GSTR-1 was misstated.”

GST risk if drift triggers a missing-invoice or over-billed scenario

The Goods and Services Tax law itself is unchanged by the Income Tax Act 2025 — Section 17(5), Section 34, Section 143 and Rule 55 still govern. The risk surface from CUM drift sits squarely on top of those rules:

• Over-billed (supplier billed more than OEM received). The supplier’s GSTR-1 carries an output that the OEM cannot claim in GSTR-2B. Reconciliation breaks; the OEM eventually issues a debit note or asks for a Section 34 credit note. The supplier’s output GST is overstated for the period and only reduces in a later period when the credit note is issued, subject to the 30 November cutoff after the close of that financial year.
• Under-billed (OEM received more than supplier invoiced). The supplier carries a deferred supply liability. If the goods are on free-issue steel moving under a Rule 55 challan, Section 143 deemed-supply can be triggered when the 180-day / 365-day return window closes against the un-billed quantity — converting the gap into a permanent GST output.
• Misaligned billing window. When a periodic tax invoice consolidates many ASNs into one IRN, the invoice must bill against confirmed-received quantity for the billing window, not raw ASN quantity. Many ASNs to one e-invoice is the norm in JIT supply; if the consolidation logic uses CUM-shipped rather than CUM-received, every weekly invoice silently inherits the drift.

TDS overlay — Section 393(1)(k) and the conversion portion

Under the Income Tax Act 2025 framework, the OEM deducts TDS on the conversion portion of an auto-component supply at the rate prescribed under Section 393(1)(k) — services component, 2%, payment code 1012 — and on the works-contract / job-work flows where applicable under Section 393(1)(a) — payment code 1002. The cross-era equivalent is the legacy Section 194C, retained only as a mapping reference in transitional Form 168 / Form 131 / Form 141 reconciliations.

The TDS base is the billed conversion value. If CUM drift has caused the bill to be raised on phantom quantity, TDS gets deducted on phantom value and the supplier’s Form 26AS shows a credit that does not tie to a clean ASN-to-GRN chain. The reconciliation control that fixes the GST output simultaneously fixes the TDS deduction base — which is why the CUM control belongs in the period-close reconciliation pack, not in the operational dispatch register.

For the full new-Act payment-code map, see the TDS payment codes 1001–1092 reference and the Section 393 master guide.

Worked example — Tier-1 supplying 12,000 units/month to Maruti

A Tier-1 stamping supplier in Manesar runs a 50,000-unit annual scheduling agreement for a stamped bracket to Maruti Suzuki at Manesar, ship-to-line, on a rolling 862. Monthly firm requirement is 12,000 units (~600/day across 20 working days). April 1 CUM reset to 0. Standard pack (SNP) = 200 units/bin. Tolerance band ±2%. Weekly consolidated GST e-invoice with IRN.

By 30 April the supplier’s dispatch log shows CUM-shipped = 12,000. Maruti e-Nagare shows CUM-received = 10,600. Gap = 1,400 units, or 7 bins. The supplier carries an invoiced quantity of 11,800 across four weekly e-invoices — meaning output GST has been raised on 1,200 units that Maruti has not booked into GRN.

Tracing back: on 9 April ASN #41 (600 units) hit a portal timeout and the gateway retried. CUM-shipped on the supplier side counted both; Maruti de-duplicated. ASN #54 on 18 April carried 800 units but two of the bins (400 units) were quality-rejected at receipt and the OEM booked CUM-received += 400, not 800; the rejection went to the standing quality queue but the supplier’s CUM-shipped never reversed the 400.

Operational fix:

1. The duplicate ASN #41 — joint reversal of 600 from supplier’s CUM-shipped.
2. The rejected portion of ASN #54 — supplier raises a GST credit note under Section 34 for 400 units, reducing output GST on the May-period filing (provided the cutoff is not breached), and reverses 400 from its CUM-shipped book.
3. The 1,200-unit over-billed position — supplier raises Section 34 credit notes on the affected weekly invoices, OEM reverses ITC, and the TDS already deducted under Section 393(1)(k) on the conversion portion of the credited supply is tracked for adjustment in the next monthly TDS return.
4. CUM re-anchor on 1 May. Both sides agree closing CUM = 10,600 (or 10,200 after the Section 34 credit). The next 862 transmits CUM-required against the corrected base.

If a CUM-drift control had been running, the duplicate would have flagged on 10 April and the quality reversal on 19 April — three weeks of compounded drift, four corrupted weekly e-invoices and a Form 26AS mismatch would never have happened.

The operational fix — standing exception queue plus period close-out

CUM drift is not a one-time bug. It is a continuous risk on any agreement that runs cumulative quantities. The fix has two parts:

Standing exception queue. A reconciliation control that compares CUM-shipped to CUM-received per part per day, and the moment they part company outside the delivery tolerance band, raises a CUM-drift exception that stays open until a joint correction is recorded. Each exception carries the originating ASN trace so the underlying transmission or quality event can be re-walked without forensic effort three weeks later. The queue is reviewed weekly by the supplier’s AR controller and the OEM’s vendor-management contact; closing an exception requires both signatures (or an electronic equivalent).

Period close-out reconciliation. At month-end, quarter-end, year-end (1 April reset) and model-end, the supplier runs a formal CUM close-out pack that ties:

• Supplier CUM-shipped vs OEM CUM-received per part per agreement, with every open drift listed
• Cumulative GST e-invoice billed quantity vs cumulative confirmed-received quantity
• Section 393(1)(k) TDS deducted at 2% (payment code 1012) on the conversion portion, against Form 26AS
• Any free-issue steel quantity moving on Rule 55 delivery challans against Section 143 return-window deadlines

For the cumulative-vs-discrete contrast, see the broader scheduling-agreement vs purchase-order treatment in auto and the OEM-delivery-schedule mechanics in the EDI/ASN reconciliation guide. For the EDI standards primer, see the EDI 830, 862 and 856 finance primer. For the wider stack, the automotive component manufacturing reconciliation sub-pillar sits inside the manufacturing reconciliation pillar. On the new TDS framework, the Section 393 master guide and the payment codes 1001–1092 reference carry the full deduction-code map. For the industry context on OEM supplier-portal standardisation, the Automotive Component Manufacturers Association of India (ACMA) publishes adoption guidance.

What automated reconciliation changes

Hand-tracking CUM drift across dozens of parts, several OEMs and multiple scheduling agreements is what makes the problem invisible in the first place — by the time a controller spots it at month-end, the originating ASN is buried. Purpose-built reconciliation software India treats the 862-856-GRN-invoice chain as a structured cumulative stream, runs the CUM-shipped vs CUM-received comparison continuously, surfaces drift the day it appears with originating-ASN trace intact, and ties the periodic tax invoice and Section 393(1)(k) TDS base to confirmed-received quantity rather than raw ASN. TransactIG ships 24+ industry presets including the OEM cumulative-quantity preset. Customer outcomes include match-rate improvement from 51% to 88%. Build is two-to-four weeks on AWS Mumbai (ISO 27001:2022). For the inbound-procurement equivalent at the Tier-2 interface, see three-way matching software India.