Reconciliation for Oracle Fusion in India — TDS, GST, Bank, Settlement
Oracle customers in India run Fusion Cloud ERP or E-Business Suite R12 against AP, AR, GL, and Cash Management subledgers that were built for global use. Indian TDS sits in DFFs or the Oracle Tax for India layer, GST is managed through configured registers, and bank reconciliation through Cash Management's BAI2/MT940 loader. TransactIG reads from documented Oracle exports — BI Publisher, REST APIs, or concurrent programs — and runs the matching layer that closes the gap between subledger postings and India's payment, tax, and bank reality.
What Oracle Handles Natively, and Where the India Gap Appears
What Oracle does well
Oracle Fusion and EBS R12 cover the full procure-to-pay and order-to-cash flow with strong subledger architecture. AP invoice workflow, AR receipts and applications, GL journal entry with sub-ledger drilldown, Cash Management's BAI2/MT940 bank statement loader, and the secondary ledger pattern for multi-GAAP reporting all work natively. Multi-org access control, ledger-per-LE, and the configured tax engine handle global tax cases cleanly.
For Indian customers with disciplined DFF usage and a clean tax setup, Fusion's standard period close and Account Analysis reports give a defensible audit position for the simple cases.
Where the India gap appears
Cash Management's bank statement loader expects BAI2 or MT940. CIB Excel, YONO Business, and Indian PDF statements do not fit. Narration-driven match keys — UPI VPAs, NEFT fragments, cheque numbers embedded in free text — are not parsed by Oracle's auto-reconciliation. Manual matching through Cash Management's exception screen does not scale.
Withholding configuration often pre-dates the new payment-code regime under Sections 393, 394, 413 of the Income Tax Act 2025 — the DFF or WHT code captures 194C or 194J, but Form 26AS shows 1001-1092. GSTR-2B and IMS reconciliation against AP postings is a manual reconciliation outside Oracle.
TransactIG Plug Points on Oracle
Six matching surfaces that sit alongside Oracle without modifying it, reading from documented exports or REST endpoints.
Data ingestion
BI Publisher scheduled reports to SFTP, REST API pulls for Fusion subledger and journal data, or concurrent program output for EBS R12. Read-only credentials, no schema changes.
Section 393 TDS handling
DFF-based or WHT-coded TDS lines mapped to the new payment codes 1001-1092. Reconciliation against Form 26AS and AIS at code level under Sections 393, 394, 413 of the Income Tax Act 2025.
GSTR-2B and IMS
AP invoices matched to GSTR-2B and IMS at GSTIN + invoice + tax-amount level. ITC eligibility and Rule 36(4) provisional-credit flags surfaced for the AP team.
NACH batch matching
Mandate batches submitted through Oracle Payments reconciled against bank response files. Bounce codes mapped, ageing tracked at AR or AP document level.
Platform settlements
Razorpay, PayU, Cashfree, Amazon, Flipkart settlement reports disaggregated and matched to Oracle AR receipts and invoices. Platform fees and GST on fees classified for ITC.
Bank statement ingestion
MT940, CAMT.053, CIB Excel, YONO Business, and PDF statements parsed natively, matched to Cash Management transactions or directly to AP payments and AR receipts with narration-pattern extraction.
Oracle Integration Architecture
Each row is a discrete data feed configured during implementation. Customer DBA team owns the export configuration; TransactIG owns the matching schema on the receiving side.
| Oracle source | Export method | Sync cadence | Field mapping | Variance codes |
|---|---|---|---|---|
| GL journals and balances | BI Publisher scheduled extract (Fusion) or FSG/Account Analysis (EBS R12) | Daily or per-period close | GL code combination → TransactIG voucher class | JOURNAL_UNMATCHED, BALANCE_DRIFT |
| AP invoices and payments | AP Invoice Aging Report extract, or REST API for Fusion | Daily | Supplier → counterparty, DFF section → payment code | INVOICE_OPEN, PAYMENT_VOIDED, HOLD_RELEASED |
| AR invoices and receipts | AR Aging extract, or REST API for Fusion | Daily | Customer → counterparty | INVOICE_OPEN, ADVANCE_UNAPPLIED, CREDIT_NOTE_PENDING |
| Cash Management bank transactions | BAI2/MT940 already-loaded view, or direct bank statement parse | Daily | Bank account → Indian bank narration profile | BANK_LINE_UNMATCHED, OD_INTEREST, CHARGE_UNCLASSIFIED |
| Withholding (TDS) lines | AP withholding extract, table AP_INVOICE_DISTRIBUTIONS_ALL filter | Daily | WHT code/section → new payment code (1001-1092) | TDS_NOT_IN_26AS, RATE_MISMATCH, SECTION_RECLASSIFIED |
| Tax for India / GST output | ZX subledger extract, or GST register output where configured | Per GST return cycle | AP invoice → GSTR-2B/IMS line | ITC_INELIGIBLE_2B, INVOICE_MISSING_IN_2B, RATE_DIFFERENCE |
Common Reconciliation Gaps in Oracle India Deployments
Cash Management exception backlog
BAI2 loader cannot parse Indian Excel formats; manual entry through the exception screen accumulates a backlog the period-close team has to clear by hand.
DFF-to-payment-code drift
TDS DFF captures legacy section (194C); Form 26AS shows new code (1054). Reconciliation requires a mapping layer because both sides will continue to coexist through the transition.
AP invoices missing from 2B
Vendor invoice posted; vendor has not filed GSTR-1; line missing from GSTR-2B. ITC is provisional under Rule 36(4) until 2B catches up — visibility needed at AP team level.
Multi-org intercompany drift
OU-to-OU postings drift on timing, FX, or one-sided entry. Drift visible only at consolidation; reconciliation needs to net at the document pair level.
Settlement gross vs net
Payment gateway settles net of fees; AR was raised gross. Without disaggregation, the bank credit cannot be applied at receipt level inside Oracle.
Withholding to vendor mismatch
TDS amount on the AP invoice differs from what shows on the vendor's 26AS — rate, threshold breach, or section mis-applied. Auditor-grade evidence required.
How TransactIG Works with Oracle
Ingest
BI Publisher schedules and REST pulls drop AP, AR, GL, Cash Management, and TDS lines into customer-owned SFTP or directly into the matching layer alongside bank statements, GSTR-2B, 26AS, and settlement files.
Match
Subledger lines matched to external sources. Narration parsing handles Indian bank narration; payment-code mapping aligns DFF/WHT TDS to 1001-1092 codes; GSTR-2B match aligns AP invoices to the GSTN feed.
Exception queue
Unmatched items route to a structured queue with variance codes, ageing, suggested resolution, and maker-checker workflow. Clearing journals can be posted back to GL through standard journal import where required.
Frequently Asked Questions
Does TransactIG work with Oracle Fusion Cloud and Oracle E-Business Suite R12?+
Both. Oracle Fusion Cloud ERP customers use the standard BI Publisher and OTBI scheduled report extracts delivered to SFTP, or use the REST API endpoints exposed by Fusion for subledger and journal data. Oracle E-Business Suite R12 customers (still common in Indian manufacturing and PSU contexts) use scheduled concurrent program output, the standard GL/AP/AR account analysis reports, and FNDLOAD-style configurations. TransactIG reads the same matching schema in both cases — the AP open items, AR open items, and GL journals normalise to one model.
How does TransactIG handle Indian TDS in Oracle Fusion?+
Indian TDS in Oracle Fusion is typically configured through descriptive flexfields (DFFs) on the AP invoice header and lines — TAN, deductee PAN, section, payment code, and rate. Some customers use the Oracle Tax for India offering; others maintain a manual layer in DFFs. TransactIG reads the AP invoice withholding lines, maps the configured section or DFF value to the new payment codes (1001-1092) under Sections 393, 394, 413 of the Income Tax Act 2025, and reconciles against Form 26AS and AIS at payment-code level for both deductor and deductee perspectives.
How is multi-org and multi-ledger consolidation handled?+
Large Indian Oracle customers run multiple operating units (OUs) and multiple primary ledgers — typically one per legal entity, sometimes with secondary ledgers for reporting in different accounting principles. TransactIG ingests data per OU and per ledger, runs reconciliation at the OU level (each OU has its own AP/AR/GL close), and rolls up to a consolidated view that mirrors the General Ledger Consolidation hierarchy. Intercompany open items between OUs are auto-matched on the amount-and-date pair; intercompany imbalances are flagged for FX or one-sided posting investigation.
Does TransactIG modify Oracle data or write back to subledger?+
No write-back to the subledger by default. TransactIG produces the reconciliation status (matched, exception, ageing, variance code) in its own UI and as exportable artefacts (CARO 2020 register, tax-audit 3CD evidence, ICFR control sheets). Where customers want to post clearing journals back to Oracle GL, the integration uses Oracle's standard journal import or GL_INTERFACE — never direct table writes. The customer's Oracle DBA team owns the write-back configuration and approves the journal source.
How does TransactIG handle Indian bank reconciliation against Oracle Cash Management?+
Oracle Cash Management has a Bank Statement Loader that accepts BAI2 and SWIFT MT940 formats. The challenge in India is that bank statements often arrive in Excel from CIB, YONO Business, or other portals — formats that Cash Management was not designed for — and that match keys live in the narration field rather than the structured reference. TransactIG parses MT940, CAMT.053, CIB Excel, YONO Business, and PDF natively, extracts the narration match key, and matches against Cash Management's bank transactions or against the underlying AP payment and AR receipt tables directly. The reconciliation status returns to Cash Management as an external clearing reference where required.
How long does Oracle integration take?+
2 to 4 weeks for most Oracle customers. Week one covers the export configuration — BI Publisher schedules or concurrent programs delivering AP, AR, GL, and Cash Management extracts to customer-owned SFTP, or REST-based pulls from Fusion. Week two maps the Oracle chart of accounts, DFF structure, OU hierarchy, and tax codes to TransactIG's matching schema. Weeks three and four configure narration patterns, TDS payment-code mapping, GSTR-2B alignment, and the maker-checker workflow. The Oracle DBA team's effort is bounded to scheduled export setup and SFTP credentialing.
Reconciliation that fits the way your Oracle system already runs
Read-only credentials. No subledger schema changes. 2 to 4 weeks to first reconciled close, ISO 27001:2022 certified, running from AWS Mumbai.