Indian auto-component finance teams build receivables and invoicing logic off EDI documents they rarely see directly. Treating 830 forecasts as commitments creates phantom receivables; billing against raw 856 ASN quantity instead of OEM-confirmed received quantity creates over-invoiced positions, broken GSTR-2B reconciliation, and mismatched Section 393(1)(k) TDS deductions in Form 26AS.
Map each EDI transaction set to its correct financial event: 830 = planning context only (no revenue, no receivable); 862 = firm authorised dispatch quantity (CUM-required); 856 = dispatch trigger and ASN-to-GRN match base; OEM GRN = control-transfer event under Ind AS 115; periodic GST e-invoice = many ASNs to one IRN, billed against confirmed-received quantity for the window. Land all transports (X12, IDoc, portal JSON, API) into one structured reconciliation stream per part per scheduling-agreement number.
EDI map per OEM covering 830 (forecast horizon, planning lines), 862 (firm-from date, CUM-required, schedule lines), 856 (CUM-shipped, pack/handling-unit structure, SNP), IDoc DELFOR/DELJIT segment mapping for SAP environments, portal-to-X12 logical equivalence map for Maruti e-Nagare, Tata SRM, Bosch SupplyOn, Hyundai HMI Vaatika and Bajaj BAL Connect; part master keyed by OEM plant code, ship-to point and scheduling-agreement number with delivery tolerance and reset markers.
A per-part per-agreement reconciliation pack tying 830 forecast vs 862 firm vs 856 ASN vs GRN vs periodic tax invoice, transport-neutral across X12/IDoc/portal feeds; an audit-grade trace from each financial event back to its originating transaction set; and an exception queue for forecast-vs-firm gaps, dispatch-vs-receipt drift and many-ASN-to-one-invoice consolidation breaks.
A controller at a Bangalore-based Tier-1 transmission supplier joins a Monday operations call and hears the production planner say “the 830 is up by 18% for July, so we’re booking the extra coil.” That sentence quietly contains three finance assumptions — that the 830 is a commitment, that the steel is exposed to the index move on the booked-not-firmed quantity, and that the receivable build for July reflects the higher number. None of those assumptions are correct. The 830 is not a firm order. Steel exposure should be modelled against probability-weighted firm 862 history, not raw 830. And the receivable cannot build before the 862 firms and the 856 dispatches. Most controllers nod and move on because EDI 830 862 856 India auto component vocabulary is not on the CA curriculum and the operations team is using it correctly for their purpose. This primer fixes that gap.
Quick reference
| Transaction set | Purpose | Financial trigger | OEM-portal equivalent | SAP IDoc |
|---|---|---|---|---|
| ANSI X12 830 | Planning Schedule with Release Capability | None — planning only | Maruti e-Nagare forecast view; Tata SRM forecast; SupplyOn forecast | DELFOR |
| ANSI X12 862 | Shipping Schedule (firm call-off) | Authorised-dispatch commitment; receivable basis on dispatch | Maruti e-Nagare firm schedule; Tata SRM call-off; Hyundai HMI Vaatika delivery instruction | DELJIT |
| ANSI X12 856 | Advance Shipping Notice (ASN) | Dispatch trigger; periodic e-invoice base | Maruti e-Nagare ASN; SupplyOn ASN; Bajaj BAL Connect dispatch upload | DESADV |
| OEM GRN | Goods Receipt (OEM side) | Control-transfer event under Ind AS 115; receivable recognition | Portal GRN confirmation | MBGMCR |
| GST e-invoice (IRN) | Periodic consolidated tax invoice | Output GST event; ITC at OEM | n/a | INVOIC02 |
The ANSI X12 standard family — where 830, 862, 856 come from
ANSI X12 is the Accredited Standards Committee X12 family of EDI transaction sets, originally developed in the United States and now the default electronic-commerce standard across global automotive (along with EDIFACT DELFOR/DELJIT/DESADV in European-lineage plants). Each transaction set is a numbered document type with a defined segment structure. The auto-industry sub-set most Indian Tier-1 suppliers see:
- 830 — Planning Schedule with Release Capability. The forecast. Rolling horizon, typically 12 to 26 weeks. Carries planning quantities by date that the OEM expects to need.
- 862 — Shipping Schedule. The firm call-off. Short horizon, typically the next few days to two weeks. Carries authorised dispatch quantity by date and the CUM-required.
- 856 — Advance Shipping Notice. The dispatch notification, supplier-to-OEM. Carries what is on the truck, in what pack/handling-unit structure, with CUM-shipped.
- 820 — Payment Order/Remittance Advice. OEM payment confirmation (not in scope here but matters for settlement reconciliation).
- 810 — Invoice. The tax invoice sent over EDI. In India, this is replaced by the GST e-invoice with IRN flowing through the IRP — but the data shape is the same.
Each transaction set has a header segment, detail segments and a trailer. The 862, for example, has an ST (transaction set header), BSS (beginning segment for shipping schedule), N1 loops for the trading partner identification, LIN/UIT for the item identification, SDQ or FST for the schedule quantities by date, and SE (transaction set trailer). The CUM-required typically rides in a FST segment with a qualifier flag indicating cumulative.
The reason this matters for finance: the canonical record of every operational commitment lives in these segments, not in the screen view of the OEM portal. When a year-end audit asks “what was the firm call-off as of 31 March on agreement X?” the answer is in the 862 file, not the portal screenshot.
830 — Planning Schedule with Release Capability
The 830 is a forecast, not a commitment. The OEM is telling the supplier “based on our current production plan, here is what we expect to need.” It is not contractually binding. The supplier uses it to:
- Book raw material (steel HR/CR coil from SAIL/Tata Steel/JSW; aluminium ingot against LME; polymer resin)
- Reserve press, forge or machining capacity
- Plan workforce shifts
- Place sub-tier orders on its own Tier-2 base
The 830 typically extends 12 to 26 weeks. The first 1-2 weeks of the horizon often duplicate the 862 firm range (and may be flagged as such in the segment qualifier); the rest is planning-only.
What finance must NOT do with the 830:
- Recognise revenue against forecast quantity. Ind AS 115 control-transfer has not happened.
- Build the AR opening position off forecast. The receivable does not exist.
- Treat the 830 as the basis for any GST event. No supply has occurred.
- Treat the 830 as the basis for the Section 393(1)(k) TDS at 2% (payment code 1012) deduction expectation. The deduction is on actual paid conversion, not forecast.
What finance SHOULD do with the 830:
- Use it for cash flow forecasting — the expected billing cycle by month
- Use it to model RMPV exposure — the steel-cost variance if the JPC HR coil price moves between forecast and dispatch
- Use it to flag plan-vs-firm gaps — if the firmed 862 quantity consistently runs below the 830 forecast by 15%+, the supplier may be over-investing in capacity
862 — Shipping Schedule
The 862 is the firm call-off. It authorises dispatch. The OEM is contractually committing to take the called-off quantity within the firm window — typically the next few days to two weeks. The 862 carries:
- Part code and scheduling-agreement number
- Ship-to point (specific OEM plant and dock)
- Schedule lines: quantity by date in the firm window
- CUM-required — the running cumulative quantity the OEM expects shipped to date since the last reset (year-start, 1 April for most Indian agreements; or model-start)
- Often a “firm-from date” and a “planning-from date” that delineate the committed and planning sub-windows
For finance, the 862 is the earliest document that justifies receivable build under Ind AS 115 — but only on dispatched quantity that has crossed control to the OEM. The 862 by itself does not transfer control; it commits the OEM to take the goods when shipped.
Where finance teams go wrong on the 862:
- Treating the CUM-required as a flat target rather than a cumulative — and so missing the CUM-drift problem (see the CUM quantity drift article for the full mechanic)
- Using the 862 quantity for invoicing instead of the actual dispatched-and-received quantity — overstates output GST when the actual dispatch falls inside the tolerance band but below the 862
- Ignoring the firm-from date — billing for dispatch in a period before the call-off was firmed
856 — Advance Shipping Notice
The 856 is the supplier’s dispatch notification, transmitted at the moment goods leave the supplier dock for the OEM. It carries:
- ASN number (the unique identifier)
- Part code, ship-to, scheduling-agreement
- Shipped quantity and CUM-shipped (the supplier’s running total dispatched)
- Pack structure: the SNP (standard pack quantity per bin/handling unit), the bin count, the carton/pallet structure
- Vehicle number, dispatch date-time
- For ship-to-line (Just-in-Sequence) flows, the sequence data that the OEM’s line uses
The 856 is not a tax document. GST e-invoice and e-way bill ride alongside it. A single tax invoice in JIT supply typically consolidates many ASNs over a weekly or fortnightly window.
For finance, the 856 is the base record of physical dispatch. The periodic GST e-invoice should be raised against confirmed-received quantity for the billing window — meaning many ASNs land in one IRN, and the consolidation logic must use OEM-confirmed received quantity (driven by 856 + GRN), not raw ASN quantity. Billing on raw ASN inherits any CUM drift directly into output GST.
OEM-portal equivalents — what each Indian OEM uses
Most Indian OEMs front the same logical 830/862/856 chain through a portal rather than raw ANSI X12:
| OEM | Portal | 830 equivalent | 862 equivalent | 856 equivalent |
|---|---|---|---|---|
| Maruti Suzuki | e-Nagare | Forecast view | Firm delivery schedule | ASN upload |
| Tata Motors | Tata SRM (supplier portal) | Forecast | Call-off | Despatch advice |
| Mahindra & Mahindra | M&M supplier portal | Forecast | Delivery schedule | ASN |
| Hyundai Motor India | HMI Vaatika | Forecast | Delivery instruction | Despatch upload |
| Bosch (as system supplier) | SupplyOn | Forecast | Delivery release | ASN |
| Bajaj Auto | BAL Connect | Forecast | Call-off | Dispatch upload |
| TVS Motor | TVS supplier portal | Forecast | Call-off | Despatch advice |
The screens differ but the logical chain is identical. A portal-fed supplier is still doing EDI reconciliation — the file format is JSON or HTTP-form rather than ANSI X12 segments, but the financial events (planning vs firm vs dispatch vs receipt) and the reconciliation discipline are the same. Some suppliers run mixed estates — Bosch and global-OEM accounts on X12 over AS2, Maruti and Tata on portal. The reconciliation engine must treat both as a unified stream per part per scheduling-agreement.
The IDoc shape — what SAP sees
When EDI documents land in SAP, they arrive as IDocs (Intermediate Documents). The mappings:
- 830 → DELFOR IDoc (Delivery Forecast). Posts into the scheduling agreement as a forecast schedule (release type “F” — forecast).
- 862 → DELJIT IDoc (Delivery Just-in-Time). Posts as a firm schedule (release type “J” — JIT call). Triggers MRP and authorises dispatch.
- 856 → DESADV IDoc (Despatch Advice). Posted by the supplier; received by the OEM and matched to inbound delivery.
- OEM GRN → MBGMCR IDoc (Goods Movement Create). Confirms receipt at the OEM end.
- GST e-invoice → INVOIC02 IDoc (when invoicing flows over EDI in addition to the IRP).
Each IDoc has a control record (sender, receiver, message type, IDoc number) and a stream of data segments. For a DELJIT (862-equivalent) IDoc, a controller would typically see:
E1EDK01— control header (document type, sender plant, receiver plant)E1EDP01— item-level header (material number, scheduling-agreement number, plant)E1EDP20— schedule line (delivery date, quantity, CUM-required)E1EDL21— packaging instruction (where ship-to-line sequence matters)
For audit and reconciliation, the IDoc is the canonical record. Portal screenshots and operational dispatch logs are derivatives; if a year-end audit asks for evidence of the firm commitment as of a date, the IDoc archive is the answer.
How each transaction set translates into a financial event
| Document | Financial event | Books impact | GST event | TDS event |
|---|---|---|---|---|
| 830 | None | No entry | None | None |
| 862 | Authorised-dispatch commitment | None until dispatch | None | None |
| 856 ASN | Dispatch trigger | Inventory out (cost of goods); receivable not yet recognised | Feeds e-invoice cycle; no IRN per ASN | None |
| OEM GRN | Control transfer (Ind AS 115) | Revenue and receivable recognised | None directly | None |
| Periodic GST e-invoice | Tax-invoice event | Output GST liability; receivable confirmed at tax-invoice value | Output IGST/CGST+SGST; IRN; e-way bill | OEM deducts Section 393(1)(k) at 2% (code 1012) on conversion portion |
| OEM payment (820 remittance) | Cash receipt | AR reduction; bank in | None | TDS credit reflected in Form 26AS |
The clarifying insight: revenue and the receivable do not exist on the 830 or the 862. They exist on the 856 + GRN combination (control transfer). The output GST event is the periodic e-invoice. The Section 393(1)(k) TDS deduction happens at OEM payment. Each event has its own document trigger; collapsing them confuses the reconciliation.
Reading an 862 file — a practical guide
A controller who has never opened a raw X12 file should be able to read a 862. Here is the orientation:
ISA*00*... <- envelope start (interchange control)
GS*SS*... <- functional group start (SS = shipping schedule)
ST*862*0001 <- transaction set start (862)
BSS*00*RELEASE-ID*REQUEST-DATE*...
N1*BY*MARUTI SUZUKI INDIA*... <- buyer
N1*SE*ACME COMPONENTS*... <- seller
LIN**BP*PART-CODE <- item identification
UIT*EA <- unit of measure (each)
PRS*A <- pricing reference
REF*SI*SCHED-AGMT-NUMBER <- scheduling agreement
FST*84000*C*A*20260331 <- CUM-required 84,000 as of 31 March
FST*3000*F*W*20260403 <- firm 3,000 by 3 April
FST*3200*F*W*20260410 <- firm 3,200 by 10 April
FST*3100*P*W*20260417 <- planning 3,100 by 17 April
SE*...
GE*...
IEA*...
The FST segments are the schedule lines. The qualifier (C = cumulative, F = firm, P = planning) tells finance immediately what each line means. The CUM-required of 84,000 as of 31 March is the base; the firm lines for the next two weeks are the authorised dispatch; the planning line is non-binding.
A finance team that can read this directly (or through a structured EDI viewer) loses the dependence on the operations planner to interpret the schedule. It also makes the year-end audit position defensible — the 862 archive is the source of truth.
Worked example — tracing 5,000 units through 830 → 862 → 856 → GRN → invoice
A Tier-1 supplier ships a forged crankshaft component to a Hyundai Motor India plant at Sriperumbudur, ship-to-store, on a rolling scheduling agreement. April 1 CUM reset to 0. Monthly volume ~5,000 units. Standard pack 50 units/bin.
Day 1 (1 April). Hyundai transmits the 830 forecast through HMI Vaatika: April expected 5,000, May expected 5,400, June expected 5,600. The supplier books 1,200 kg of forging steel against the April demand at the prevailing JPC HR coil rate of ₹61,400/MT. No financial event in books.
Day 8 (8 April). Hyundai transmits the 862 firm schedule: CUM-required = 1,200 by 12 April, 2,400 by 19 April, 3,600 by 26 April, 5,000 by 3 May. The supplier sees a firm dispatch commitment. No financial event in books yet — but the production schedule is authorised.
Day 11 (11 April). Supplier dispatches the first 1,200 units in 24 bins. Transmits 856 ASN: CUM-shipped = 1,200, ASN #62, vehicle MH-12-XX-1234, sequence data attached. Books: inventory out at cost; no revenue yet (control has not transferred — goods are in transit to Hyundai’s store).
Day 12 (12 April). Hyundai’s HMI Vaatika confirms GRN at Sriperumbudur: CUM-received = 1,200. Books: revenue recognised under Ind AS 115; receivable recorded at agreed price. No GST event yet (e-invoice runs on a weekly consolidation).
Day 13–19. Three more ASNs land: CUM-shipped 2,400, 3,000, 3,600. GRNs confirm the same. Receivable position builds.
Day 20 (Monday). Weekly GST e-invoice consolidates ASNs #62–#65: invoiced quantity = 3,600 units (matching CUM-received for the week, not raw CUM-shipped). IRN obtained from IRP; e-way bill linked. Output GST raised. GST event.
Day 30 (30 April). Final ASN for the month brings CUM-shipped to 5,000. GRN confirms 4,950 (50-unit rejection at receipt). Supplier raises a Section 34 credit note on the period invoice for the 50 rejected units in the next weekly cycle.
Day 30+10 (10 May). Hyundai pays against the consolidated invoices for April, deducting Section 393(1)(k) at 2% (payment code 1012) on the conversion portion of the invoice value. Form 26AS reflects the deduction; supplier reconciles to its TDS receivable in books.
The audit trail: 830 → 862 (CUM-required 5,000) → ASNs (CUM-shipped 5,000) → GRN (CUM-received 4,950, with 50 rejected) → tax invoices (4,950 net of credit note) → payment (with TDS at 2% on conversion). Each step ties cleanly because the reconciliation engine ran against the canonical EDI/IDoc records, not derivative screens.
Cost out the EDI-to-invoice match gaps across your OEM book
Every 830-vs-862 misclassification, every ASN-vs-GRN gap, every many-ASN-to-one-invoice consolidation break shows up as an AP exception somewhere. Estimate what those exceptions are costing across your OEM accounts.
Open the Exception Cost Calculator →Tax overlay — Section 393(1)(k), GST e-invoice, and the IDoc archive
Under the Income Tax Act 2025, the OEM deducts TDS on the services component of an auto-component supply at Section 393(1)(k) — 2%, payment code 1012. Where the supply is structured as a works contract or job-work flow, Section 393(1)(a) — payment code 1002 applies instead. The legacy Section 194C reference is retained as a cross-era mapping for transitional Form 168 / Form 131 / Form 141 reconciliations only — see the TDS payment codes 1001–1092 reference and the Section 393 master guide.
The TDS deduction base is the conversion portion of the invoice value. For the deduction to reconcile cleanly to Form 26AS, the invoice itself must reconcile to OEM-confirmed received quantity — which is the 856-plus-GRN combination, not raw ASN. An invoice raised against raw CUM-shipped inherits any CUM drift directly into the TDS base, and the Form 26AS mismatch surfaces three to six months later.
GST is unchanged by the Income Tax Act 2025 — Section 17(5), Section 34 credit-note treatment, Rule 36(4), Rule 37, Rule 43 and Rule 55 still govern. The risk surface from EDI mis-mapping sits on top: an 830-driven invoicing decision creates phantom output GST; an ASN-driven invoicing decision creates over-billed positions when goods are rejected at receipt and inherits CUM drift.
For the broader stack — the OEM delivery schedule and EDI/ASN reconciliation guide sits alongside this primer; the automotive component manufacturing reconciliation sub-pillar and the manufacturing reconciliation pillar carry the full context. For OEM-portal standardisation guidance across the Indian base, see the Automotive Component Manufacturers Association of India (ACMA).
What automated reconciliation changes
A finance team that depends on the operations planner to interpret EDI files cannot defend a year-end position. Purpose-built reconciliation software India lands all transports — ANSI X12 over AS2/SFTP, SAP IDocs (DELFOR/DELJIT/DESADV), and portal payloads from Maruti e-Nagare, Tata SRM, Bosch SupplyOn, Hyundai HMI Vaatika and Bajaj BAL Connect — into one unified stream per part per scheduling-agreement, ties the periodic GST e-invoice to confirmed-received quantity, and produces an audit-grade trace from each financial event back to its originating transaction set. TransactIG ships 24+ industry presets including the OEM EDI-reconciliation 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 Tier-2 procurement equivalent, see three-way matching software India.