Skip to main content
How-To · 12 min read

EDI 830, 862, and 856 for Indian Auto-Component Suppliers: A Finance Team Primer

Finance teams at Indian auto-component suppliers hear 'EDI' in every operations meeting but rarely see the inside of an 830 or 862 file. The result is silent miscommunication: receivables logic gets built off planning forecasts instead of firm call-offs, periodic e-invoices get raised against ASN dispatch quantity instead of OEM-confirmed received quantity, and Section 393(1)(k) TDS reconciliation breaks. This primer walks through each ANSI X12 transaction set — 830, 862, 856 — in the structure a controller actually needs, with the OEM-portal equivalents, the IDoc shape when SAP receives them, and a worked example tracing 5,000 units through forecast, commit, ASN, GRN and invoice.

Terra Insight
Terra Insight Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published 23 May 2026
Domain expertise
TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops
Knowledge Card
Problem

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.

How It's Resolved

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.

Configuration

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.

Output

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 setPurposeFinancial triggerOEM-portal equivalentSAP IDoc
ANSI X12 830Planning Schedule with Release CapabilityNone — planning onlyMaruti e-Nagare forecast view; Tata SRM forecast; SupplyOn forecastDELFOR
ANSI X12 862Shipping Schedule (firm call-off)Authorised-dispatch commitment; receivable basis on dispatchMaruti e-Nagare firm schedule; Tata SRM call-off; Hyundai HMI Vaatika delivery instructionDELJIT
ANSI X12 856Advance Shipping Notice (ASN)Dispatch trigger; periodic e-invoice baseMaruti e-Nagare ASN; SupplyOn ASN; Bajaj BAL Connect dispatch uploadDESADV
OEM GRNGoods Receipt (OEM side)Control-transfer event under Ind AS 115; receivable recognitionPortal GRN confirmationMBGMCR
GST e-invoice (IRN)Periodic consolidated tax invoiceOutput GST event; ITC at OEMn/aINVOIC02

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:

OEMPortal830 equivalent862 equivalent856 equivalent
Maruti Suzukie-NagareForecast viewFirm delivery scheduleASN upload
Tata MotorsTata SRM (supplier portal)ForecastCall-offDespatch advice
Mahindra & MahindraM&M supplier portalForecastDelivery scheduleASN
Hyundai Motor IndiaHMI VaatikaForecastDelivery instructionDespatch upload
Bosch (as system supplier)SupplyOnForecastDelivery releaseASN
Bajaj AutoBAL ConnectForecastCall-offDispatch upload
TVS MotorTVS supplier portalForecastCall-offDespatch 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

DocumentFinancial eventBooks impactGST eventTDS event
830NoneNo entryNoneNone
862Authorised-dispatch commitmentNone until dispatchNoneNone
856 ASNDispatch triggerInventory out (cost of goods); receivable not yet recognisedFeeds e-invoice cycle; no IRN per ASNNone
OEM GRNControl transfer (Ind AS 115)Revenue and receivable recognisedNone directlyNone
Periodic GST e-invoiceTax-invoice eventOutput GST liability; receivable confirmed at tax-invoice valueOutput IGST/CGST+SGST; IRN; e-way billOEM deducts Section 393(1)(k) at 2% (code 1012) on conversion portion
OEM payment (820 remittance)Cash receiptAR reduction; bank inNoneTDS 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.

Interactive Tool

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.

Primary reference: Automotive Component Manufacturers Association of India (ACMA) — for EDI adoption guidance, OEM supplier-portal standardisation efforts, and the JIT delivery-discipline frameworks the Indian Tier-1 and Tier-2 base has adopted.

Frequently Asked Questions

What is the difference between EDI 830, 862 and 856 for an auto-component supplier?
ANSI X12 830 is the Planning Schedule with Release Capability — a rolling forecast (typically a 12 to 26 week horizon) the OEM transmits so the supplier can plan capacity and book raw material. It is not a firm order. ANSI X12 862 is the Shipping Schedule — the firm, short-horizon call-off (typically the next few days to two weeks) that authorises actual dispatch. ANSI X12 856 is the Advance Shipping Notice (ASN) — the supplier's transmission telling the OEM what has actually been dispatched, in what pack/handling-unit structure. Finance must treat the 830 as planning context only, build receivables logic off the 862, and bill against OEM-confirmed received quantity (driven by the 856 plus GRN), never against raw ASN quantity.
Which OEM portals replace raw EDI for Indian suppliers?
Maruti Suzuki runs e-Nagare for delivery schedules and ASNs. Tata Motors runs the Tata supplier portal (SRM). Bosch runs SupplyOn. Hyundai Motor India runs HMI Vaatika. Bajaj Auto runs BAL Connect. Mahindra runs the M&M supplier portal. The screens differ but the logical document chain — forecast, firm call-off, ASN, receipt — is identical to the ANSI X12 830/862/856 model. A portal-fed supplier is still doing EDI reconciliation; the file format is JSON or HTTP-form rather than X12 segments, but the financial events are the same.
How does each EDI transaction set translate into a financial event?
The 830 planning schedule is a non-financial event — it does not create a receivable, does not authorise an invoice, and does not enter the books. It is capacity-planning input. The 862 firm shipping schedule creates a contractual commitment to ship within the firm window; the supplier may begin to recognise revenue only once the 862 quantity is dispatched against an 856 ASN and received at the OEM (per Ind AS 115 control transfer). The 856 ASN triggers physical dispatch and feeds the periodic GST e-invoice cycle. The OEM GRN is the receivable recognition trigger — it confirms control transfer. The periodic tax invoice (GST e-invoice with IRN) consolidates many ASNs to one invoice for the billing window.
What does an EDI 830 or 862 look like when SAP receives it?
SAP receives EDI documents as IDocs — Intermediate Documents. The 830 typically arrives as a DELFOR IDoc (Delivery Forecast), and the 862 as a DELJIT IDoc (Delivery Just-in-Time). Each IDoc carries a control record (sender, receiver, message type) and a stream of data segments — header (E1EDP01-equivalent), part-level lines (material code, plant, scheduling-agreement number), schedule lines (date, quantity, CUM-required), and pack/handling-unit detail. The IDoc is posted into the scheduling agreement and triggers MRP and procurement events downstream. For reconciliation, the IDoc is the canonical record — not the screen view of the portal.
Should we read EDI files or use API integration with OEM portals?
Both. ANSI X12 over AS2/SFTP remains the dominant transport for global-OEM environments (Bosch, GM-lineage plants), and IDoc over RFC for SAP-to-SAP OEM-supplier integration. Newer OEM portals (Tata SRM, Hyundai HMI Vaatika) expose RESTful APIs or HTTP-form payloads. The finance reconciliation does not care which transport — it cares that the four documents (forecast, firm call-off, ASN, GRN) flow into one structured stream per part per scheduling-agreement. File-based and API-based feeds should land in the same reconciliation engine; mixing transports without unifying the data model is what breaks audit-period sign-offs.

See how TransactIG handles reconciliation for your industry

Configuration takes 2–4 weeks. No code development required. ISO 27001:2022 certified.