PayU Reconciliation Software for India — Settlement, MDR, GST, TDS Matching
PayU settles on T+1 to T+3 net of MDR, 18% GST on MDR, refunds from earlier periods, chargebacks, and — for marketplace operators — Section 393(1)(j) TDS at 1% on gross sales under payment code 1010. Add the PayUmoney legacy book that many merchants still run alongside PayU Biz, and the close cycle becomes an XLOOKUP marathon. TransactIG ingests both dashboard exports, rebuilds the gross-to-net waterfall per payment ID, and produces a journal-ready reconciled close.
What PayU Settles Natively, and Where the Reconciliation Gap Appears
What PayU handles natively
PayU Biz acquires UPI, debit and credit cards, netbanking, EMI, wallets, and international cards, with settlement on T+1 to T+3 depending on instrument and merchant tier. The dashboard publishes a settlement report and a transaction-level breakdown that itemises each payment, the MDR, 18% GST on MDR, refunds, chargebacks, and any TDS withheld. The legacy PayUmoney book settles separately for merchants who still have active tokens or recurring subscriptions on that platform.
For straightforward direct-to-consumer merchants on a single PayU Biz account, the dashboard answers the day-to-day cash-arrival questions.
Where the reconciliation gap appears
T+3 settlement opens a wider timing window than T+1 acquirers — the bank credit and the ERP invoice live in different periods by default. MDR varies materially by instrument. 18% GST on MDR is ITC-eligible only when PayU's monthly tax invoice appears in GSTR-2B under Rule 36(4). Refunds reverse on T+5 to T+7 from a later payout. Chargebacks carry their own lifecycle.
For marketplace operators using PayU, Section 393(1)(j) at 1% on gross sales (payment code 1010 under the Income Tax Act 2025) applies — and must reconcile to Form 26AS at payment-code level.
TransactIG Capabilities on PayU
Six matching surfaces — PayU Biz and PayUmoney handled on a single unified schema, with payout-side support where PayU Payouts is in use.
Settlement file ingestion
Scheduled PayU dashboard download to customer SFTP. Settlement report joined to transaction sidecar on settlement ID. PayUmoney legacy book ingested on the same unified schema.
MDR + 18% GST classification
MDR per instrument separated from the 18% GST on MDR. GST flagged ITC-eligible and aged against PayU's monthly tax invoice appearing in GSTR-2B under Rule 36(4).
Section 393(1)(j) TDS — code 1010
For marketplace structures: 1% on gross sales under Section 393(1)(j) of the Income Tax Act 2025 (payment code 1010, replacing legacy 194O). Reconciled to Form 26AS at code level.
Section 52 CGST TCS — 1%
Section 52 of the CGST Act 1% TCS applied by marketplace operators, reconciled against the operator's GSTR-8 filing — carried separately from income-tax TDS.
Refund / chargeback timing
T+5 to T+7 refund reversal pattern aged from original payment to bank debit. Chargebacks tracked through raised, evidence-submitted, won, lost states.
Variance taxonomy
FEE_DEDUCTION, TAX_DEDUCTION, REFUND_REVERSAL, ROUNDING, PARTIAL_PAYMENT, DUPLICATE_PAYMENT, LEGACY_PAYMENT_OPEN — structured codes with maker-checker exception queue.
PayU Integration — Settlement File Architecture
Each row is a discrete feed configured during implementation. PayU publishes via its documented dashboard exports; TransactIG owns the matching schema, fee classification, and variance taxonomy.
| Source | Ingest method | Cadence | Field mapping | Variance codes |
|---|---|---|---|---|
| Settlement report (PayU Biz) | Scheduled dashboard download to SFTP | Daily, T+1 to T+3 depending on instrument | Settlement ID → payout batch in TransactIG | PAYOUT_MISSING_IN_BANK, AMOUNT_MISMATCH |
| Transaction breakdown (sidecar) | Per-settlement CSV attached to report | Per settlement | Payment ID → order / invoice in ERP | ORDER_MISSING, PARTIAL_PAYMENT, DUPLICATE_PAYMENT |
| Legacy PayUmoney transactions | PayUmoney dashboard export (separate auth) | Daily for active legacy accounts | Legacy payment ID → unified schema in TransactIG | LEGACY_PAYMENT_OPEN, MIGRATION_DUPLICATE |
| Refunds | Refund rows in sidecar; dashboard refund report | Per refund event | Refund ID → original payment ID | REFUND_REVERSAL, REFUND_TIMING, REFUND_UNAPPLIED |
| Chargebacks / disputes | Chargeback rows in sidecar; dispute lifecycle | Per dispute event | Dispute ID → original payment ID + evidence pack | CHARGEBACK_OPEN, EVIDENCE_PENDING, CHARGEBACK_LOST |
| MDR + 18% GST | Fee + GST columns in sidecar; monthly tax invoice from PayU | Per transaction, monthly tax invoice | Fee GL + GST input GL | FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B |
| TDS withheld (marketplace) | TDS column in sidecar; quarterly 26AS download | Per transaction, quarterly 26AS | WT line → payment code 1010 (393(1)(j)) | TDS_NOT_IN_26AS, RATE_MISMATCH, SECTION_RECLASSIFIED |
| Bank credit (net payout) | MT940 / CAMT.053 / bank portal | Daily | Bank narration UTR → settlement ID | NARRATION_UNPARSED, CREDIT_TIMING, NET_AMOUNT_DIFF |
Common PayU Reconciliation Gaps
T+3 settlement straddles month-end
Card and netbanking payments captured on the 29th and 30th may settle into the next month — the receivable is unrecognised at close unless the settlement-in-transit GL is reconciled.
PayUmoney legacy book parallel to PayU Biz
Two dashboards, two settlement files, sometimes two GSTINs. Without a unified schema, recon falls back to two parallel spreadsheets.
18% GST on MDR unclaimed in ITC
The 18% GST on PayU fees is ITC-eligible input tax. Booked to expense by default — the credit is lost unless explicitly classified.
Refund timing across payout boundaries
Refund initiated today reverses from a payout T+5 to T+7. The original credit and the eventual debit appear in different settlement reports.
Multi-instrument mix on a single order
A single order may be paid via UPI for the deposit and EMI for the balance — two payment IDs, two MDR bands, one invoice. N-to-1 matching is required.
EMI subvention treatment
No-cost EMI carries an additional merchant-funded subvention that PayU deducts up-front. The discount and the MDR sit in different GL classifications.
How TransactIG Reconciles PayU
Ingest settlement file
PayU Biz dashboard export and PayUmoney legacy export both land on customer SFTP, joined to bank statements, GSTR-2B, and Form 26AS feeds.
Decompose deduction layers
Gross-to-net waterfall rebuilt per payment ID — MDR, GST on MDR, TDS where applicable, TCS, refunds, chargebacks. Each layer routed to the correct GL.
Classify variances + evidence
Unmatched items route to the exception queue with variance codes, ageing, and audit-ready evidence. Maker-checker workflow before any GL posting.
Frequently Asked Questions
What does the PayU settlement file contain and how does TransactIG ingest it? +
PayU Biz publishes a settlement report through the merchant dashboard with a transaction-level breakdown — each payment, the instrument used, MDR, 18% GST on MDR, refunds, chargebacks, and any TDS withheld. PayU operates on T+1 to T+3 settlement depending on the instrument and the merchant agreement. TransactIG ingests the dashboard export on a scheduled SFTP drop, joins it to the bank credit on the PayU-issued UTR or settlement reference, and rebuilds the gross-to-net waterfall per payment. Legacy PayUmoney accounts publish through a separate dashboard but with a comparable file shape; TransactIG handles both. No invented API endpoints — TransactIG relies on PayU's publicly documented dashboard exports.
How does TransactIG handle MDR and 18% GST on PayU fees? +
MDR varies by instrument — UPI typically zero-rated for P2M, debit and credit cards in different bands, netbanking, EMI, and international cards in their own bands. PayU deducts MDR per transaction plus 18% GST on the MDR. TransactIG separates the MDR from the GST in the journal entry, classifies the GST-on-fee component as ITC-eligible input tax (subject to the buyer's GST registration), and ages the provisional ITC until PayU's monthly tax invoice appears in GSTR-2B under Rule 36(4). Variance codes: FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B.
Where does Section 393(1)(j) TDS apply on PayU flows? +
Section 393(1)(j) of the Income Tax Act 2025 (payment code 1010, replacing legacy Section 194O) applies at 1% on gross sales where the merchant is an e-commerce operator facilitating sales of goods or services on its digital platform on behalf of seller participants. Pure payment acquiring — where PayU only acquires the payment without being the listing or fulfilling platform — does not attract 393(1)(j) on the merchant. Marketplace structures do. TransactIG distinguishes the two at onboarding and applies the correct treatment per payment ID. Aggregator commission attracts Section 393(1)(f) at 5% (payment code 1007, replacing legacy 194H).
How are refunds and chargebacks handled? +
PayU refunds reverse from a future payout, typically T+5 to T+7 from refund initiation. TransactIG matches the refund to the original payment ID, ages the refund liability until the bank debit appears in a later settlement report, and tags REFUND_REVERSAL with the expected debit date. Chargebacks move through a dispute lifecycle — raised, evidence submitted, won or lost — and TransactIG tracks each state separately, so the finance team sees the cash impact at each stage and the audit trail at year-end ties to the underlying SD billing document.
Does TransactIG handle PayU Biz and legacy PayUmoney accounts together? +
Yes. Merchants that grew up on PayUmoney and migrated to PayU Biz often run both for a period — older subscription tokens on PayUmoney, new payments on PayU Biz, refunds running off the original platform. TransactIG ingests both dashboard exports, applies a unified payment-ID schema, and matches each to the bank credit and the ERP invoice. PayU's Payouts product (vendor disbursement) integrates on the same matching layer when used.
How long does PayU reconciliation implementation take? +
2 to 4 weeks. Week one configures the dashboard scheduled export to customer-owned SFTP, maps the PayU merchant ID and sub-merchant hierarchy to the chart of accounts, and aligns the MDR rate card to the fee classification rules. Week two configures TDS treatment (marketplace versus pure acquiring), refund timing tolerance, and ITC ageing thresholds. Weeks three and four cover bank statement matching for the net payout, journal-entry generation, and the maker-checker workflow.
Reconciliation that fits PayU Biz and PayUmoney together
Unified schema across PayU Biz and the PayUmoney legacy book. ITC-classified GST on fees, Section 393(1)(j) handled where applicable. 2 to 4 weeks, ISO 27001:2022, AWS Mumbai.