ERP Data Extracts for Auto-Component Reconciliation: SAP IDocs, Oracle BIP, Tally CSV, D365 Data Entities

A ₹520 crore Indian Tier-1 forging and machining supplier has a mixed ERP landscape — SAP S/4HANA at the headquarters and main Chennai plant, where the company runs the OEM-facing scheduling-agreement supply, and Tally Prime at a satellite plant in Hosur that the company acquired through an SME purchase three years ago. The Hosur plant is being slowly migrated to SAP but the migration is at least 12 months from completion. In the meantime, the consolidated auto-component reconciliation needs to run across both ERPs — Chennai’s SAP S/4HANA invoice and ASN register plus Hosur’s Tally Prime sales register, both feeding into a unified cum-shipped position per OEM. This is the extract-layer problem. It is also the silent failure point of most reconciliation-tool implementations.

This is the ERP data extract auto component reconciliation operating reference for the IT, finance and integration teams designing the extract layer that any reconciliation tool — internal or companion — sits on top of.

Quick reference

SAP S/4HANA — the four extract patterns

IDoc-based extracts

The IDoc framework is SAP’s standard EDI subsystem and the canonical extract pattern for auto-component reconciliation tools sitting alongside SAP. The relevant message types:

• ORDERS05 — purchase order outbound and inbound
• DELFOR01 — delivery forecast (used for EDI 830 inbound from OEM)
• DELINS01 — delivery schedule (used for EDI 862 firm call-off inbound from OEM)
• DESADV01 — despatch advice (used for EDI 856 ASN outbound to OEM)
• INVOIC02 — invoice outbound to OEM and inbound from Tier-2 vendor

The ALE / EDI subsystem manages partner profiles (one per trading partner — Maruti, Tata, Mahindra, Bosch on the OEM side, Tier-2 vendors on the inbound side), message control (which message types are exchanged with which partner, in which direction), and port definitions (file port, RFC port, HTTP port). For the reconciliation-tool extract use case, IDocs are typically routed to a port that drops to a file system or to an external middleware (e.g., SAP PO / PI / CPI, or a third-party EDI subsystem) that the reconciliation tool reads from.

RFC-based extracts

Remote Function Call (RFC) is SAP’s classic synchronous protocol for invoking ABAP function modules from external systems. The reconciliation tool can call standard RFC-enabled function modules (e.g., BAPI_PO_GETDETAIL for purchase order detail, BAPI_GOODSMVT_GETDETAIL for material movements) to pull on-demand data. The advantage is real-time data; the disadvantage is the brittleness of RFC-call security models and the version-sensitivity of BAPI signatures.

OData / NetWeaver Gateway

The SAP NetWeaver Gateway exposes ABAP data through REST-style OData services. Increasingly the preferred extract pattern for cloud-based reconciliation companion products because of standardised authentication (OAuth 2.0), throttling controls, and REST-friendly tooling. Standard auto-component OData services would cover scheduling-agreement header / item / release, GRN, invoice register, withholding tax register.

Scheduled custom report exports

ABAP Z-reports (the ZSAR_* family documented in SAP ABAP custom reports auto component reconciliation India) execute on a job schedule and output to SFTP or to the SAP application server file system. The reconciliation tool reads from the drop location. This is the lowest-effort pattern but also the most fragile — Z-report changes, job-scheduler downtime, SFTP credential expiry all break the extract.

Oracle ERP Cloud (Fusion) — four extract patterns

BIP (BI Publisher) reports

The standard batch-extract pattern at an Oracle Fusion Tier-1. BIP data models join Procurement Cloud, Cost Management, AP, AR and India Localisation tables; the report outputs XML, CSV or Excel; delivery is via scheduled email, FTP, or a REST callback. Standard auto-component extracts: daily AR invoice register, daily AP invoice register, weekly BPA cum-tracking, quarterly ITC-04 base data, monthly withholding tax register.

OTBI subject areas

Oracle Transactional Business Intelligence exposes pre-built subject areas for Procurement, Inventory, Order Management, Receivables, Payables. The reconciliation tool subscribes to OTBI report subscriptions and consumes the scheduled push delivery, or queries OTBI subject-area REST endpoints on demand.

REST APIs

Procurement Cloud, Financials Cloud and Supply Chain Management Cloud expose REST endpoints for object-level queries (purchaseOrders, suppliers, invoices, customers). Standard pattern for on-demand reconciliation queries (e.g., “fetch all open PO lines for supplier X”).

FBDI and HCM Extracts

File-Based Data Import (FBDI) is the standard inbound load pattern; HCM Extracts is the batch-data extract framework originally built for HCM but usable for Financials data. Less commonly used for reconciliation than BIP / OTBI.

Tally Prime — three extract patterns

ODBC pull

Tally Prime exposes a built-in ODBC interface on a configurable TCP port (default 9000) that a downstream tool connects to and queries Tally objects using a Tally-specific SQL-like syntax. The standard pattern at a Tier-2 or Tier-3 on Tally is a daily ODBC pull job, running at end-of-day, extracting the previous day’s voucher register (sales, purchase, journal, delivery note, receipt note, payment, receipt), the TDS register, the GST output and the bank reconciliation status, output to CSV or to a staging database.

XML over Tally.ERP 9 protocol

Tally exposes an XML request-response interface over HTTP that returns voucher and master data. The protocol was designed for Tally.ERP 9 but continues to work on Tally Prime. Used where a tighter object-model interaction is needed than ODBC’s table-style access.

Tally Server 9

The multi-user Tally deployment exposes the same ODBC and XML interfaces with concurrent-user support. Standard at Tier-2 and Tier-3 with multiple accountants on the same Tally instance.

For the underlying Tally Prime workarounds that depend on the extract layer see Tally Prime auto component reconciliation limits India.

D365 F&O — three extract patterns

Data Entities

D365 exposes structured business objects as Data Entities — Sales Order, Purchase Order, Customer Invoice, Vendor Invoice, Inventory Transactions, Withholding Tax register, GST Output, Blanket Purchase Agreement. Data Entities are consumable via REST API for object-level queries or via the Data Management Framework (DMF) for scheduled bulk export. Standard at a mid-Tier-1 on D365.

Logic Apps

Azure Logic Apps connectors for D365 F&O provide a no-code / low-code orchestration layer for scheduled extracts. Native error-handling, retry, throttling response and credential management through Azure Key Vault. Standard pattern: a Logic Apps scheduled flow runs daily, pulls each relevant Data Entity export, drops the output to Azure Blob Storage or Azure Data Lake, the reconciliation tool reads from there.

Synapse Link

D365 F&O can stream change-data to Azure Synapse Analytics for near-real-time analytics. Less commonly used for reconciliation than Logic Apps + Data Entities, but appropriate where the reconciliation latency requirement is sub-hour rather than daily.

Format normalisation challenges across heterogeneous ERPs

When a Tier-1 has a mixed ERP landscape — SAP HQ + Tally satellite plant, or SAP + Oracle Fusion at a parent-acquired subsidiary — the extract layer must normalise format conventions across the ERPs before the reconciliation logic can run:

The normalisation layer in the staging area takes the per-ERP raw extract and outputs a single canonical format for downstream reconciliation. Most extract-layer failures at Tier-1 are normalisation failures: a date parsed wrong, a GSTIN validation failing, a decimal separator confused with thousands separator. These look small in isolation but break the reconciliation downstream — every line affected by the normalisation error becomes an unmatched exception.

Worked example — mixed SAP + Tally landscape at a ₹520 crore Tier-1

The forging-and-machining Tier-1 with SAP S/4HANA at Chennai and Tally Prime at Hosur:

SAP extract layer

• IDoc outbound for INVOIC02 to a port that drops to SFTP
• Scheduled ABAP Z-report nightly export of cum-tracking, ASN ageing, debit decomposition, RMPV claim, ITC-04 base data, free-issue Rule 55, withholding tax register — output to SFTP
• OData endpoints for on-demand reconciliation queries (BPA, GRN, supplementary invoice)

Tally extract layer

• Daily ODBC pull job from Tally Prime at Hosur at end-of-day, extracting voucher register, TDS register, GST output, bank reconciliation status — output to CSV in a staging directory

Staging area (Azure Blob or on-premise NAS depending on the company’s data residency choices)

• Per-ERP raw extracts in the source format
• Normalised canonical format files: dates as ISO-8601, decimals as ., GSTIN format-validated, document numbers padded consistently

Reconciliation tool

• Reads from the staging area on a daily cadence
• Runs cum-shipped position per OEM consolidating SAP-side and Tally-side invoice registers
• Runs ASN ageing, RMPV claim, ITC-04 multi-hop, free-issue Rule 55 tracking — all reading from the unified staging area

Failure modes observed in the first six months of operation

• SFTP credential expired after a 90-day rotation — three Z-report drops missed before the alerting picked it up; manual re-extract and back-fill cycle of 2 days
• Tally ODBC port firewall change at Hosur — daily extract failed for 2 days; manual re-extract from Tally end-of-month state
• Format mismatch on Tally narration field — special characters not escaped consistently in CSV; downstream reconciliation flagged 60 invoice lines as unmatched until the parsing was fixed
• IDoc partner profile gap when a new OEM (Hero MotoCorp) was onboarded — three days of missing DESADV outbound until the partner profile was created

These are typical extract-layer failures. The mitigation is a disciplined daily-extract orchestration with completeness checks (number of records extracted vs expected per ERP per day), dead-letter handling for malformed records, automated re-extract on transient failure and alert-routing to the integration team for credential expiry.

Tax overlay — extract requirements for Income Tax Act 2025 and GST reconciliation

The Income Tax Act 2025 framework with codes 1001-1092 effective from 1 April 2026 changes the source-data shape of the withholding tax extract from every ERP. Specifically:

• SAP withholding tax register table WITH_ITEM now carries the new payment code in field WITHT — the extract layer needs to pull both the new code (1002 / 1012 / 1071 / 1062) and the legacy 194x code during the cross-era migration window.
• Oracle Fusion withholding tax extract via BIP needs the equivalent code-mapping output.
• Tally Prime TDS register exposes the new codes through the configured TDS nature of payment — the ODBC pull needs to extract the nature reference.
• D365 F&O withholding tax Data Entity carries the new codes from the FY 25-26 patch onwards.

See TDS payment code 1002 — Section 393(1)(a) contractor and TDS payment code 1012 — Section 393(1)(k) purchase goods for the underlying code framework. For the Form 168 challan reconciliation that depends on the withholding tax extract see Form 26AS reconciliation auto component supplier India.

GST extract requirements remain unchanged. The GST output extract per ERP needs to expose HSN code, taxable value, IGST / CGST / SGST / cess split, place-of-supply state code, supplier and recipient GSTIN, invoice number and date — standard across all ERPs.

Where this leaves an auto-component Tier-1

The extract layer is rarely the visible part of a reconciliation programme but it is consistently the silent failure point. A disciplined extract layer with per-ERP standard patterns (IDoc + Z-report SFTP for SAP, BIP + REST for Oracle, ODBC for Tally, Logic Apps + Data Entities for D365), a normalisation layer in the staging area, and daily orchestration with completeness checks is the foundation that any reconciliation tool — internal or companion — depends on. Get the extract layer right first; the reconciliation logic on top is comparatively well-understood.

What automated reconciliation changes for an auto-component Tier-1 on a mixed ERP landscape

Purpose-built auto-component reconciliation software India carries pre-built extract connectors for SAP IDoc / OData / SFTP, Oracle BIP / OTBI / REST, Tally ODBC / XML and D365 Data Entities / Logic Apps. The normalisation layer is provided as standard. TransactIG’s auto-component industry preset consumes the normalised staging area and runs the reconciliation streams (cum-drift, ASN ageing, RMPV claim, ITC-04 multi-hop, free-issue Rule 55, Section 143 alerting, Form 168 reconciliation) on a daily cadence with completeness checks and dead-letter handling built in. Customer outcomes include match-rate improvement from 51% to 88% and exception rates moving into the sub-15% band. Build is two-to-four weeks on AWS Mumbai (ISO 27001:2022). For the procurement-side three-way match see three-way matching software India.

Continue reading

Sibling articles in the auto-component cluster:

• SAP scheduling agreement reconciliation auto India
• Tally Prime auto component reconciliation limits India
• Form 26AS reconciliation auto component supplier India

Up the chain:

• Sub-pillar: Automotive component manufacturing reconciliation in India
• Money pages: auto-component reconciliation software India · three-way matching software India