Integrations — every data plane your books cross
Reconciliation is a multi-system problem before it is a matching problem. The data lives in ERPs, banks, payment gateways, marketplaces, and tax-authority portals — and the engine is only useful if it can read all of them without manual exports.
TransactIG ships connectors and ingestion adapters across the four data planes Indian finance teams actually work in: ERP, bank, payment-gateway and marketplace, and tax authority. Plus the statutory and NACH rails that travel alongside.
This page describes the integration surface as posture — what we connect to, the ingestion modes we support, and what a customer should expect during the integration window. It does not publish API endpoints or fabricated SDK package names.
ERP connectivity — the systems Indian books actually run on
Production integrations across the ERP estate an Indian finance team is likely to be running — large-enterprise SAP and Oracle stacks, the Microsoft mid-market, the dominant Indian SMB stack on Tally, and the modern SaaS estate (Zoho, Odoo). Each integration is a posture — file drop or direct connector, with documented field mapping and reconciliation-account scope decided per customer during the integration window.
| ERP system | Ingestion mode | Reconciliation scope | Posture notes |
|---|---|---|---|
| SAP FI / S/4HANA | Direct connector + file drop | GL posting, AR, AP, bank sub-ledger; reconciliation-account scope per company code | IDoc, BAPI, and OData surfaces supported through customer-managed integration users. Field mapping documented per reconciliation-account profile. |
| Oracle Fusion / E-Business Suite | Direct connector + file drop | GL, AR, AP, Cash Management; ledger-set and business-unit scope | Fusion REST surfaces and EBS open-interface tables both supported. Customer chooses extraction shape based on existing integration estate. |
| Microsoft Dynamics 365 / Business Central | Direct connector | GL, sales orders, purchase invoices, bank account ledger | Dataverse and Business Central API patterns used. Tenant-scoped read access; no writeback unless explicitly enabled in the integration runbook. |
| Tally Prime | File drop (XML / Excel) + Tally connector | Vouchers, ledger masters, GST returns export | Most Indian SMB and mid-market customers land on Tally. We support the day-book XML export, the GST return XML, and direct Tally ODBC where the customer has it configured. |
| Zoho Books | Direct connector | Invoices, bills, payments, bank transactions | OAuth-scoped read access against the customer Zoho org. Per-organisation, per-branch scoping supported for multi-entity customers. |
| Busy | File drop (Excel / DBF) | Sale, purchase, payment, receipt, journal vouchers | Long-running Indian Tier-2 / Tier-3 ERP. We work against the documented export shapes; field mapping is captured in the integration runbook. |
| Sage | File drop + connector | GL, AR, AP | Sage 300 and Sage Intacct customers covered through the published integration surfaces. |
| Odoo | Direct connector | account.move, account.payment, bank.statement | XML-RPC and REST patterns supported. Multi-company Odoo deployments scoped per company. |
Per-ERP deep write-ups for SAP FI, Oracle Fusion, Tally Prime, Zoho Books, Busy, Dynamics 365, Sage, and Odoo are published in the ERP integrations cluster.
Bank format coverage — 200+ statement formats
TransactIG parses 200+ Indian bank statement formats. Public-sector banks, private banks, foreign banks operating in India, payments banks, small-finance banks, and the co-operative bank long tail — across MT940, BAI2, native XLS and CSV exports, and PDF statements. Narration parsing is India-specific: UPI handles, NEFT reference codes, IMPS beneficiary patterns, and RTGS UTR formats are all first-class fields.
Public sector banks
SBI (YONO, CMP, branch PDF), PNB, Canara, Bank of Baroda, Union Bank of India, Indian Bank, Bank of Maharashtra, UCO, Central Bank, IOB, Bank of India. PSU statements are the hardest end of the long tail — branch-issued PDFs, legacy fixed-width exports, regional column ordering.
Private sector banks
HDFC Bank, ICICI Bank, Axis Bank, Kotak Mahindra, IndusInd, Yes Bank, IDFC First, RBL, Federal Bank, South Indian Bank. Multiple export formats per bank — NetBanking, Corporate Internet Banking, CMS-generated MT940, and MIS file drops are each handled as distinct parsers.
Foreign banks operating in India
Citi, HSBC, DBS, Standard Chartered, Deutsche Bank. Typically MT940 plus a bank-native XLS variant. Used heavily by mid-market exporters and Indian arms of multinationals.
Payments banks and small finance banks
Paytm Payments Bank, Airtel Payments Bank, India Post Payments Bank, FINO. Small finance banks: Ujjivan, Equitas, AU SFB, ESAF, Suryoday, Utkarsh, Jana. Cleaner exports but rising in relevance for MSME current accounts.
Co-operative bank long tail
State, urban, and district central co-operative banks — TJSB, Saraswat, Cosmos, Karnataka State Co-operative, Maharashtra State Co-operative, Tamil Nadu State Apex, and the rest of the regional tail. Inconsistent date conventions and regional-language columns are the norm here; this is where most incumbent reconciliation tools quietly fail.
The bank coverage problem is two-layered — format and narration. We solve both. See bank reconciliation software for India for the full coverage write-up.
Payment-gateway and marketplace settlement files
The reconciliation challenge here is not the net payout — it is the chain that produces the net payout. Gross order, MDR, GST on MDR, TDS withheld by the platform, reserve and hold lines, refund netting, and finally the disbursement. TransactIG reconciles every step against the order ledger and the bank credit, not just the last line.
| Gateway or marketplace | Settlement chain reconciled | Notes |
|---|---|---|
| Razorpay | Order → MDR → GST on MDR → reserve hold → net payout | Settlement report plus payment-level export reconciled together. Reserve, hold, and adjustment lines all classified as variance subtypes. |
| PayU | Transaction → MDR → TDS withheld → settlement | PayU India and PayU Money settlement files both handled. TDS withholding under Section 194-O applied where the customer is the seller and PayU is the e-commerce operator. |
| Cashfree | Order → MDR → settlement → refund netting | Cashfree Payments and Cashfree Payouts settlement surfaces are reconciled to the GL receipt and the bank credit independently. |
| CCAvenue, BillDesk | Order → MDR → GST → settlement | Long-running Indian PG estate. Heavy use in education, utilities, and government payments. Settlement reports come in vendor-specific shapes; parsers cover each. |
| Stripe (India operations) | Charge → fee → tax → payout | Stripe India settlement flows reconciled to INR bank credits. Multi-currency receipts handled where the customer operates a domestic INR account. |
| Amazon (SPN / MTR) | Gross order → Amazon commission → fulfilment fee → TCS u/s 52 → TDS u/s 194-O → reserve → net disbursement | MTR-A and MTR-B reports reconciled per order, per state, per GSTIN. Marketplace fee audit is a first-class workflow. |
| Flipkart, Meesho, Myntra, Ajio, JioMart | Order → commission → collection fee → TCS → TDS → settlement | Marketplace settlement files differ vendor-to-vendor. Each is parsed and normalised into the same variance taxonomy. |
| Quick-commerce and food aggregators | Order → platform commission → packaging → TCS → TDS → payout | BigBasket, Swiggy, Zomato, Urban Company. Daily settlement cadence. Refund and cancellation netting reconciled per cycle. |
See payment gateway reconciliation for the full per-platform breakdown — including the marketplace fee audit workflow.
Tax-authority data planes
Tax reconciliation is reconciliation, not a separate tool. The same engine that matches bank credits to invoices matches Form 26AS deductee entries to your AR ledger and GSTR-2B invoice lines to your AP. This is the India tax overlay made concrete — and it covers the 2026 TDS migration codes from day one.
TDS reconciliation pulls Form 26AS and the Annual Information Statement, then matches deductee-level entries to your AR ledger and your TDS payable ledger. Mismatches surface as deduction-without-deposit, deposit-without-credit, or quarter-shift variance.
Quarterly TDS statements reconciled against book deductions and challan deposits. Form 16A and Form 27D linkage tracked at deductee and challan level. Defaults and late-deposit interest are surfaced as named variance classes, not lost in a residual.
ITC matching against GSTR-2B per invoice, per supplier GSTIN, per tax period. Rule 36(4) compliance baked in. Mismatches typed as invoice-not-uploaded, IRN-not-linked, credit-note-pending, or amendment-shift.
Outward supply reconciliation against books and against the 3B summary. Annual GSTR-9 / 9C variance closure tracked per HSN, per place-of-supply, per rate. E-invoice IRN linkage held at the invoice level.
Payment codes 1001-1092, Form 168, Form 131, Form 141, and the tax-year / rate-by-date overlay introduced in the 2026 cycle. Cross-era ledgers reconciled without forcing the customer to keep two systems.
NACH and statutory rails
NACH, e-NACH, PF, ESI, professional tax, and MSME 43B(h) ageing — all reconciled inside the same engine, against the same audit trail. The underlying data plane is the same as bank reconciliation; treating them as separate tools is what creates the audit-trail gaps that statutory reviewers find.
NACH presentation and returns
Mandate-level reconciliation of NACH presentations against the bank credit, with NPCI return reason codes mapped to typed variance — insufficient funds, account closed, signature mismatch, mandate revoked, technical reject. Same engine, same audit trail.
e-NACH mandate lifecycle
Mandate creation, activation, suspension, and cancellation events reconciled against the lender or biller ledger. Status drift between the sponsor bank and the originating system is detected at the mandate ID level.
Statutory payment rails
PF, ESI, and professional-tax challans reconciled against the corresponding bank debit and the statutory portal acknowledgement. Late deposits surface as named variance, not as silent compliance risk.
MSME 43B(h) tracking
Section 43B(h) of the Income-tax Act ties MSME-payable timelines to the deduction window. TransactIG tracks payable ageing against the 45-day threshold so the disallowance is visible before the tax return, not after.
Ingestion modes — file, scheduled fetch, direct connector, API
Four ingestion shapes. The right one is per-source, decided during the integration window — typically a mix across the customer's sources rather than a single uniform mode. The API surface is described as posture: idempotent, versioned, role-scoped, supporting synchronous responses, asynchronous job handles, and webhook delivery. The shape and the credentials are exchanged in the integration runbook, never published on a marketing page.
File drop
SFTP, S3, and email-gateway drops for periodic batches. The most common starting mode — works against any source-system export and survives source-system upgrades that break direct connectors.
Scheduled fetch
TransactIG pulls from the customer's bank portal, ERP, or tax portal on an authorised schedule. The credential, the cadence, and the scope are all customer-controlled and documented in the integration runbook.
Direct ERP connector
For systems with a stable integration surface — SAP, Oracle Fusion, D365, Zoho, Odoo — a direct connector reads the documented APIs or open-interface tables. No file export step.
Customer-controlled API push
For source systems the customer already automates, TransactIG accepts inbound posts on an idempotent, versioned, role-scoped surface. Sync, async, and webhook patterns are all supported. The shape and the credentials are exchanged in the integration runbook, not published here.
What we do not publish
We describe the integration surface as posture, not as endpoint documentation. We do not publish TransactIG API endpoints, request shapes, response schemas, or fabricated SDK package names on this marketing page. The integration runbook, the field-mapping templates, and any SDK material a customer needs are delivered through the integration window after engagement begins.
This is the same posture TransactIQ takes on its API page. It is a deliberate choice: API contracts evolve under customer engagement, and we will not commit a shape on a public page that we then have to maintain forever or break.
What you do get on engagement: the integration runbook, field-mapping templates per source, the authentication and rotation policy, the rate-limit and idempotency contract, the async-job and webhook delivery shapes, and the sandbox credentials for the parallel-run week.
2-4 week go-live
The engineering output of the integration model. Customers go live on TransactIG in 2-4 weeks. The 24+ industry presets are what make this timeline credible — customers do not start with a blank engine. They start with a preset configured for their vertical and tune from there.
Source-system access and field mapping
Bank, ERP, gateway, marketplace, and tax-portal credentials provisioned in the customer environment. Field mapping templates filled against the industry preset for the customer's vertical.
Reconciliation logic configuration
Industry preset loaded as the starting point — typed variance classes, tolerance bands, and matching pipeline scoped to the customer's reconciliation accounts. No blank-engine configuration burden.
Parallel run
TransactIG runs alongside the existing reconciliation process. Output is compared line-for-line. Variance classification is reviewed with the finance team and the audit lead.
Cutover
TransactIG becomes the system of record for reconciliation. Audit trail goes live. Old spreadsheets are archived. The customer team starts working in the engine, not against it.
Deployment topology — managed cloud, private tenant, or on-premise — is decided in week 1 of the integration window. See deployment for the three-tier model.
Information security management system certified — controls cover organisational, people, physical, and technological domains.
Personal-data processing in TransactIG runs under documented purposes consented by the data principal, via the customer as data fiduciary.
Data localisation, vendor due-diligence, exit management, and incident reporting all aligned with the RBI Master Directions.
Hosted-tier deployments stay inside the India data plane. On-premise tenants run inside the customer estate.
See the integration plan against your actual systems
Send us the list of source systems your reconciliation crosses — ERP, banks, gateways, marketplaces, tax portals. We will come back with the integration mode, the field mapping starting point, and the realistic week-by-week go-live plan for your environment.