Reconciliation FAQs for Indian Finance Teams

A Bank Reconciliation Statement is a document that explains the difference between the cash book balance (the bank balance per the company's own records) and the bank statement balance (the balance per the bank's records) as at a specific date. The difference arises from timing items — cheques issued but not yet presented to the bank, deposits recorded in the books but not yet credited by the bank, and bank charges not yet recorded in the books. The BRS is a standard internal control document required for statutory audit.

The standard BRS format starts with either the cash book balance or the bank statement balance, then adds or deducts timing items to arrive at the other. Starting from cash book balance: add unpresented cheques (issued but not cleared), deduct deposits in transit (added to books but not yet credited by bank), add/deduct bank errors, deduct direct bank charges not recorded in books = Bank statement balance. The BRS is dated as at the period-end date and signed by the preparer and a reviewer.

The most common BRS items for Indian companies are: (1) NEFT/RTGS payments that clear the next business day — timing difference between initiation and bank debit; (2) cheques issued to vendors that have not been presented — outstanding cheques; (3) bank charges and service fees debited by the bank but not yet recorded in the books; (4) direct credits from debtors (NEFT) that appear in the bank statement before the AR team has booked the receipt; (5) TDS deducted at source appearing as bank debits that the tax team needs to record.

Statutory auditors expect a BRS as at the last day of the financial year (March 31) for all bank accounts. For mid-year review, a BRS as at each quarter end (June 30, September 30, December 31) is typically requested. For companies with high transaction volumes, monthly BRS preparation is standard practice — it prevents the accumulation of unidentified items that become difficult to explain at year-end.

Outstanding cheques should clear within 3 months of issuance (cheques in India are valid for 3 months). If a cheque has been outstanding for more than 3 months, it has expired and the payable should be reversed. Deposits in transit should clear within 1–3 business days for NEFT/RTGS. Items that remain in the BRS for more than 30 days without explanation are typically flagged as audit observations.

Cash flow reconciliation is the process of confirming that the net change in cash and cash equivalents shown in the cash flow statement equals the difference between opening and closing bank balances in the books. If the bank reconciliation is complete and the AR/AP ledgers are reconciled, the cash flow statement should balance. Differences indicate either an unreconciled bank item, an unreconciled non-cash adjustment (depreciation, provisions), or a classification error between operating, investing, and financing activities.

The direct method shows actual cash receipts (from customers) and cash payments (to suppliers, employees, taxes) in the operating section. The indirect method starts with net profit and adjusts for non-cash items (depreciation, provisions) and working capital changes (AR increase, AP increase, inventory change). Ind AS 7 permits both; most Indian companies use the indirect method because it is easier to prepare from standard accounting outputs. The direct method requires a full breakdown of actual bank receipts and payments.

The most common reasons a cash flow statement does not balance: (1) bank reconciliation is incomplete — unresolved bank entries that are not in the books cause the bank balance to differ from the book cash balance; (2) TDS receivable is shown as cash receipt rather than advance tax; (3) intercompany flows are not eliminated in group entities; (4) a capital expenditure is misclassified as an operating expense, distorting operating vs investing cash flow.

TDS deducted on receivables reduces the cash received from customers — but the gross amount of the invoice is the revenue. In the indirect method cash flow, the TDS receivable appears as an increase in current assets (working capital outflow), reducing operating cash flow from the net profit figure. In the direct method, only the net cash received (after TDS) appears as operating inflow. Reconciling TDS receivable movements to the cash flow is an often-missed step in year-end cash flow preparation.

PE investors and boards focus on free cash flow quality: whether operating cash flow is genuinely from operations, or includes proceeds from asset sales, customer advances, or delayed supplier payments (AP stretching). Reconciling cash flow requires showing: operating cash flow excluding non-recurring items, capex reconciled to the fixed asset addition schedule, and working capital movement reconciled to AR, AP, and inventory ledgers. Unreconciled items in any of these reduce the credibility of the reported cash position.

For most UPI merchants, payments collected during a day are settled to the merchant's bank account on the next business day (T+1). The settlement is typically a single bulk credit on the bank statement — for example, a ₹48,750 credit representing 23 individual UPI payments. The reconciliation task is to disaggregate this bulk credit into individual transactions using the settlement report from the payment aggregator (Razorpay, PayU, Cashfree, PhonePe Business, etc.).

Merchant Discount Rate (MDR) is the fee charged by the acquiring bank for POS (point-of-sale) card processing. For credit cards, MDR ranges from 1.5–2.5% of the transaction value. For debit cards and RuPay, MDR is zero per government mandate. The POS settlement file from the acquirer shows the gross transaction value and the MDR deducted — the net credit to the bank is gross minus MDR. Reconciliation must account for the MDR deduction, not just match the gross invoice amount.

Manual UPI reconciliation fails at scale because: (1) the bank statement shows only the settlement total, not individual transaction details; (2) the settlement report from the payment aggregator uses internal transaction IDs, not the UTR visible to customers; (3) chargebacks and refunds may reduce the settlement amount without a separate bank debit; and (4) multiple payment aggregators' settlements may arrive on the same day as separate bank credits. Matching requires the aggregator's settlement file as an intermediate source.

For most standard UPI merchant payments, no TDS / TCS applies directly. E-commerce marketplace sellers receive payments through the operator net of e-commerce-operator TDS at 0.1% — under legacy Section 194O, and from 1 April 2026 under Section 393(1) Sl. 8(v) at payment code 1035. The marketplace's settlement statement shows the deduction — this must be reconciled to Form 26AS / Form 168 and recorded as a TDS receivable. Note: Section 206C(1H) (TCS on sale of goods) is inapplicable since 1 April 2025 and has no successor TCS code under the Income-tax Act 2025.

Standard POS settlement timelines in India: T+1 for most acquiring banks and payment processors. Some banks offer same-day settlement for premium merchant accounts. Weekend and holiday settlements may be delayed to the next business day. The reconciliation must account for these timing differences — a POS terminal's end-of-day settlement on Friday may only credit the bank account on Monday, creating a 3-day timing difference.

A chargeback is a forced reversal of a card payment initiated by the card issuer on the cardholder's behalf — typically because the cardholder disputes the transaction. From a reconciliation perspective, a chargeback appears as a deduction from a future settlement statement: the gateway deducts the original transaction amount (and often a chargeback processing fee) from the next settlement. The finance team must match this deduction to the original transaction, reverse the revenue, and record any chargeback fee.

Card network rules (Visa, Mastercard) allow chargebacks up to 120 days (Visa) or 120 days (Mastercard) after the transaction date for most dispute types. In India, RBI regulations require banks to resolve disputes within 30 days (extendable). This means a transaction from 3–4 months ago may generate a chargeback in the current period — requiring the reconciliation to match a current deduction against a transaction from a prior accounting period.

A chargeback for a transaction from a prior accounting period should be treated as a current-period P&L charge (chargeback expense or bad debt) rather than a prior-period revenue adjustment — unless the amount is material. For material chargebacks (above ₹1 lakh or 0.1% of revenue), the prior-period nature should be disclosed in the notes. The GST adjustment may also require a credit note in the current period, which should be matched to the original invoice's GST return.

A chargeback ratio is chargebacks divided by total transactions (by count) in a month. Card networks set thresholds: Visa's standard threshold is 0.9%; Mastercard's is 1.0%. If a merchant exceeds these thresholds, the gateway may impose higher MDR rates, withhold a rolling reserve, or terminate the merchant account. The rolling reserve (typically 5–10% of daily settlements held for 90–180 days) must be reconciled separately — it is a receivable from the gateway, not settled cash.

Payment gateways and acquirers charge a fee per chargeback — typically ₹500–₹2,000 per dispute. This fee appears as a separate line item in the settlement statement, distinct from the chargeback reversal amount. Both must be reconciled: the reversal amount is matched to the original transaction and revenue reversed; the chargeback fee is posted to a fee expense account. Missing the fee creates a small but recurring expense understatement.

Daily reconciliation is operationally required for: NBFCs with daily NACH collections (bounce rate must be updated in the LMS same day), payment aggregators (daily settlement from nodal account to merchant accounts under RBI guidelines), e-commerce platforms (daily settlement to sellers), and banks and MFIs (daily loan account reconciliation). It is also strongly recommended for any business with daily average transactions above ₹1 crore in settlement volume.

Daily reconciliation requires: (1) automated data ingestion — bank statements via API or SFTP, not manual download; (2) a matching engine that can process the day's transaction volume in under 60 minutes; (3) an exception routing workflow that notifies the correct reviewer within the same business day; and (4) a sign-off process that completes within the day. Manual daily reconciliation is operationally unsustainable above 200 daily transactions.

Monthly reconciliation is viable for a company with ₹5 crore GST turnover if: transaction volume is below 1,000 per month, there are fewer than 20 active TDS deductors, and there is no NACH, platform settlement, or marketplace activity. Above these thresholds, monthly reconciliation creates a backlog that is difficult to clear before the 20th (GSTR-3B deadline) — resulting in ITC being claimed before GSTR-2B matching is complete.

Move in stages: (1) Week 1-2 — automate bank statement ingestion; reconcile daily bank vs cash book without changing other processes; (2) Week 3-4 — add daily platform settlement matching; (3) Month 2 — add daily exception routing with SLAs; (4) Month 3 — add daily TDS posting for incoming payments. The month-end close becomes a sign-off exercise rather than a matching exercise once all daily matching is in place.

The hybrid approach applies daily reconciliation to high-volume, high-risk transaction types and monthly reconciliation to low-volume types. Typical hybrid: daily for bank and platform settlements (high volume, daily settlement lag), weekly for TDS receivable updates (Form 26AS updates 3-7 days after challan deposit), monthly for GSTR-2B matching (only available on 14th of each month). This approach balances operational efficiency with the risk profile of each reconciliation type.

Bank reconciliation matches your cash book against the bank statement — confirming actual cash receipts. Debtors reconciliation matches your accounts receivable ledger against the customer's accounts payable ledger — confirming that both sides agree on what is owed. A customer may have paid, but if their payment is recorded against the wrong invoice in your books, the bank reconciliation will pass but the debtors reconciliation will show a mismatch.

AR reconciliation with counterparties should be done at minimum quarterly for amounts above ₹5 lakh. For high-value customers (above ₹25 lakh outstanding), monthly confirmation is best practice. Statutory auditors expect confirmation of balances from debtors representing more than 5% of total AR — if these are not reconciled regularly, the audit process becomes more time-consuming.

Age-wise analysis classifies AR by the number of days since the invoice date — typically in buckets: 0–30, 31–60, 61–90, 90–180, and 180+ days. Under GST rules, if a buyer does not pay within 180 days of the invoice date, the ITC claimed on that purchase must be reversed (Section 16(2)(b) of the CGST Act). Age-wise analysis identifies invoices approaching the 180-day threshold and triggers ITC reversal before the compliance deadline.

A disputed invoice creates a difference between your AR ledger and the customer's AP ledger — you show an outstanding receivable; they show nothing (or a reduced amount pending dispute resolution). Disputed invoices must be separately classified in the AR ledger — not aged with normal receivables — and the dispute terms documented. If the dispute results in a credit note, the credit note must be reconciled to both the original invoice and the GST credit note in GSTR-1.

A balance confirmation letter is a written statement from the counterparty confirming the outstanding balance in their books as of a specific date. Statutory auditors under SA 505 (External Confirmations) require confirmation letters from debtors representing significant AR balances — typically above ₹10 lakh per debtor, or the top 10 debtors by balance. Confirmation letters must be sent by the auditor directly (not by the management) to be effective as audit evidence.

A reconciliation exception is any transaction that did not match automatically after all matching passes were applied. This includes: amount mismatches (bank credit of ₹90,000 vs invoice of ₹1,00,000 where TDS was not accounted for), reference mismatches (NEFT credit with a narration that does not match any invoice reference), missing items (invoice in the ledger with no bank credit), and excess items (bank credit with no corresponding invoice). Each type requires different resolution logic.

Exceptions should be classified by type before routing for review. Standard classification for Indian reconciliation: TAX_DEDUCTION (TDS or TCS deducted — expected, generates receivable entry), FEE_DEDUCTION (MDR, platform commission — expected, no further action), TIMING_DIFFERENCE (amount correct, wrong period — carry forward), AMOUNT_MISMATCH (genuine discrepancy — investigate), and MISSING_CREDIT (payment made, no bank confirmation — follow up with bank). Named classifications route exceptions to the right resolver automatically.

Standard resolution SLAs for Indian finance teams: TAX_DEDUCTION exceptions — 2 business days (verify against Form 26AS or GSTR-2B); TIMING_DIFFERENCE — 5 business days or carry to next period; AMOUNT_MISMATCH — 3 business days for amounts above ₹10,000 (escalate to finance manager); MISSING_CREDIT — 1 business day (contact bank with UTR); FEE_DEDUCTION — auto-resolve within same day. All exceptions above ₹1 lakh should have CFO or controller visibility within 24 hours.

Root cause analysis for recurring exceptions requires looking at patterns across multiple periods: if the same TDS deductor generates monthly exceptions, they are likely filing with the wrong PAN or section code (fix: send correction request once; add to watch list). If platform settlement exceptions recur monthly for the same gateway, the MDR rate in your system may be wrong (fix: update the rate; reconcile retroactively). Exception pattern analysis over 3 months typically identifies 3–5 systemic causes that account for 70–80% of total exceptions.

An exception prevention system uses the patterns from historical exceptions to prevent new ones. Examples: (1) a counterparty watch list — deductors who have historically filed with wrong PAN are auto-flagged before their TDS entry is posted; (2) a rate validation rule — if MDR charged differs from contracted rate by more than 0.05%, flag before posting; (3) a duplicate detection rule — if a credit with the same UTR has been processed before, block the entry. Prevention reduces new exceptions; it does not eliminate the need for exception management on the residual.

Fixed asset reconciliation is the process of confirming that the fixed asset register (listing of all assets, their cost, accumulated depreciation, and net book value) agrees with the general ledger FA account, that depreciation calculated matches the depreciation charge in the P&L, and that assets physically exist and are in the condition recorded. In India, it also includes reconciling GST ITC on capital assets and confirming that the depreciation method (WDV or SLM) is consistently applied under Schedule II of the Companies Act.

Written Down Value (WDV) method applies the depreciation rate to the net book value each year — so the depreciation amount decreases each year as the book value reduces. Straight Line Method (SLM) applies the rate to the original cost — so depreciation is constant each year. Schedule II of the Companies Act prescribes useful lives for different asset classes; the depreciation rate depends on whether WDV or SLM is used. Reconciliation must confirm which method is applied per asset class and that it has been applied consistently.

GST ITC on capital goods (fixed assets) must appear in GSTR-2B for the period the asset was purchased. Under the ITC rules, there are specific restrictions on capital goods ITC: vehicles used for passenger transport are blocked under Section 17(5), and certain categories of capital goods have ITC restrictions. Reconciliation confirms that ITC claimed on capital goods matches GSTR-2B, that blocked ITC has been reversed, and that any proportional reversal under Rule 43 (for assets used for both taxable and exempt supplies) has been applied.

Discrepancies between physical count and the register require investigation: (1) assets in the register but not found physically — may have been disposed of, scrapped, or stolen; these must be written off with proper documentation (disposal approval, GST credit note if applicable, income tax treatment of capital loss); (2) assets found physically but not in the register — may be expensed items above the capitalisation threshold, or additions not yet posted; these must be capitalised at cost and the GST ITC claim reviewed.

Fixed asset reconciliation must be completed before the statutory auditor begins the audit. The auditor performs procedures including: tracing additions to purchase invoices and capital expenditure approval; confirming depreciation calculations against the Schedule II useful life table; and attending or reviewing the physical verification (SA 501 requires auditors to attend inventory counts; the same principle applies to significant fixed assets). Any reconciliation gaps discovered during audit extend the audit timeline and may result in observations.

The three main challenges are: (1) exchange rate differences — the invoice is raised in USD at one rate, the bank credits INR at a different rate on the actual settlement date, creating an exchange difference that must be posted to P&L; (2) NOSTRO account reconciliation — for companies with foreign currency accounts, the NOSTRO balance must be reconciled to the bank's statement in foreign currency; (3) forward contract settlements — if the company hedged the receivable with a forward contract, the settlement reconciliation must match the forward contract rate against the actual settlement rate.

An Indian IT company raises an invoice for USD 10,000 when the exchange rate is ₹83.50. The invoice is booked at ₹8,35,000. When payment arrives 45 days later, the exchange rate is ₹84.20 — the bank credits ₹8,42,000. The ₹7,000 difference is a foreign exchange gain and must be posted to the P&L under Ind AS 21. The reconciliation must identify the invoice rate vs settlement rate difference and route the variance to the correct P&L account.

A NOSTRO account is a foreign currency account maintained by an Indian bank on behalf of a company for receiving foreign payments. The NOSTRO balance appears on the company's books in INR (converted at the current rate) and on the bank's statement in foreign currency (USD, EUR, GBP, etc.). NOSTRO reconciliation involves: matching the bank's foreign currency statement to the ledger foreign currency balance, then revaluing the ledger balance at the period-end RBI reference rate and posting the revaluation gain or loss.

For foreign payments received by Indian residents — typically export income — TDS is generally not applicable as the foreign payer is not subject to Indian TDS obligations. However, if an Indian company receives a payment from an Indian subsidiary of a foreign company, the Indian subsidiary is subject to TDS rules and must deduct accordingly. Section 195 governs TDS on payments to non-residents made from India. The reconciliation logic differs depending on whether the payment is from a domestic or foreign entity.

Form 15CA is a declaration filed online by an Indian entity making a payment to a non-resident, and Form 15CB is a CA certificate accompanying it for payments above a threshold. These forms govern the remittance of payments out of India under FEMA. For reconciliation purposes, each outward foreign payment must be matched to the corresponding Form 15CA filing — if Form 15CA was not filed before the payment, the payment is a FEMA violation and must be reported to the bank.

Yes. Under Section 7(1)(c) of the CGST Act, supply between distinct persons (different GSTINs of the same legal entity or different group companies) is treated as supply even without consideration. The value is determined under Rule 28 of the CGST Valuation Rules — for related parties, the value must be the open market value or the cost-plus margin acceptable under GST rules. Failing to charge GST on intercompany supplies is a common compliance gap in Indian group companies.

Yes. TDS provisions apply to all payments between Indian entities regardless of group relationship. A holding company paying a subsidiary for professional services must deduct TDS under Section 194J at 10%. A subsidiary paying a parent for technical consultancy is similarly liable. Group company status does not exempt any party from TDS obligations — a common misconception that leads to TDS demand notices.

In group consolidation under Ind AS or Companies Act, intercompany transactions must be eliminated — the holding company's receivable from the subsidiary must equal the subsidiary's payable to the holding company. If both sides of the intercompany balance are not identical (due to timing differences, currency, or GST treatment), elimination entries create residual balances in the consolidated statements. Reconciling intercompany balances before consolidation prevents these residuals.

Transfer pricing requires that intercompany transactions are priced at arm's length value. The actual transaction amounts must reconcile with the pricing documented in the transfer pricing study. If actual charges differ from the study rates — due to volume changes, cost center adjustments, or currency movements — the transfer pricing documentation must be updated, and the difference may trigger a transfer pricing adjustment notice from the Income Tax Department.

The most common error is timing differences: Company A records an intercompany sale in March, but Company B records the purchase in April (next financial year). This creates a balance that eliminates in one company's books but not the other's — resulting in a consolidation difference. The solution is an agreed intercompany cut-off date (typically the last working day of February) with both sides recording transactions by the same date for FY close purposes.

In India, TDS is deducted at source by the payer — not by the payee. When an invoice of ₹1,00,000 is paid with 10% TDS deducted, the bank credit is ₹90,000. A generic matching system that tries to match ₹90,000 against a ₹1,00,000 invoice fails — creating a ₹10,000 exception. The correct approach splits the match: bank credit of ₹90,000 + TDS receivable of ₹10,000 = gross invoice of ₹1,00,000. This requires the matching logic to know the applicable TDS section and rate.

Under Section 194J, TDS is deducted at 10% on fees for professional services (including technical services in most cases). A ₹1,00,000 professional services invoice results in a ₹90,000 bank credit and a ₹10,000 TDS receivable. For pure technical services or call centre services, the rate may be 2% — resulting in a ₹98,000 credit and ₹2,000 receivable. The correct section code determines which rate applies.

Section 194C applies to contract payments at 1% (individual/HUF) or 2% (others). A ₹5,00,000 contract payment to a company results in a ₹4,90,000 bank credit and a ₹10,000 TDS receivable. The matching logic for 194C requires: identifying the client as a payer subject to 194C deduction, applying 2% to the invoice gross, and flagging the resulting net credit for TDS receivable generation.

If a deductor applies 10% under Section 194J on what should be a 2% technical services payment under 194J (using the post-Finance Act 2020 rate), the bank credit will be lower than expected: ₹90,000 instead of ₹98,000 on a ₹1,00,000 invoice. This creates both a cash flow difference and a Form 26AS mismatch. The resolution requires the deductor to file a correction return — and the payee to carry the excess TDS receivable until it appears in Form 26AS.

Partial TDS deductions occur when a client deducts TDS on only part of the invoice — often when the invoice covers both taxable and non-taxable components. The matching logic must support partial TDS allocation: match the bank credit against the taxable portion of the invoice net of TDS, and the non-taxable portion at gross, producing a blended match. This requires the matching engine to parse invoice line items, not just invoice totals.

SEBI's ICDR Regulations require three years of restated financial statements — balance sheet, P&L, and cash flow statement — with a reconciliation between the originally reported figures and the restated figures. Finance teams must also reconcile: TDS receivable to Form 26AS for all three years, ITC claimed to GSTR-2B for all years, related party transaction disclosures, and working capital as at the date of filing.

Restated financials adjust the prior-year audited financials for material errors, changes in accounting policy, and adjustments identified during the IPO due diligence process. The restatement reconciliation must explain every line-item difference between the originally audited figures and the restated figures — this reconciliation is reviewed by SEBI and is included in the DRHP.

All TDS receivable must be reconciled to Form 26AS for each year covered by the DRHP. Outstanding TDS demands or unrecognised TDS credits must be disclosed or resolved before filing. TDS demand notices received during the DRHP period are material disclosures under SEBI's risk factor requirements.

IPO reconciliation should begin at least 12–18 months before the anticipated DRHP filing date. This provides time to resolve Form 26AS mismatches (which require deductor correction returns), settle pending GST demands, clear intercompany balances, and produce clean restated financials. Companies that start reconciliation in the final 3 months before filing typically find material items that delay the DRHP.

Unreconciled GST — excess ITC claimed, pending GSTR-9 reconciliation, or unresolved GST demands — must be disclosed in the DRHP as contingent liabilities. GST demand notices received in the last 12 months are typically highlighted in the statutory auditor's report and reviewed closely by SEBI. Material unreconciled amounts can delay IPO approval.

Rule 36(4) ties Input Tax Credit availability for a recipient to the reflection of the corresponding supplier invoice in the recipient's GSTR-2B. Effectively, ITC can be availed only on those invoices where the supplier has filed GSTR-1 within the supplier's monthly or quarterly filing cycle, the invoice has flowed through GSTR-2B auto-population on or before the recipient's filing deadline, and the recipient has not rejected the invoice through the IMS dashboard. If the supplier files late, the credit shifts to a later period — lagged ITC. If the supplier never files, the credit is permanently lost — permanent leakage.

Permanent ITC leakage is the rupee amount the recipient has paid GST on, but will never be able to claim — because the supplier has wound up without filing GSTR-1, the invoice was issued past the supplier's annual return cutoff (30 November of next FY for most cases), or the invoice carries a structural defect like an invalid GSTIN that cannot be rectified. Lagged ITC leakage is the rupee amount that does not appear in GSTR-2B in the original period because the supplier filed GSTR-1 late, but will reflect in a future-period 2B once filed; the recipient absorbs the working-capital cost of the lag but does eventually claim the credit. The split is typically 25-35% permanent, 65-75% lagged in a healthy mid-market supplier base.

The Invoice Management System dashboard moved recipient-side action from passive 2B-consumption to active accept / reject / pending classification of every supplier-pushed invoice. Done right, IMS shifts the recipient from a once-monthly 2B reconciliation into a daily acceptance workflow that surfaces missing invoices earlier, allows targeted supplier escalation while the supplier's GSTR-1 filing is still open, and prevents the late-rejection wave that traditionally lands at the recipient's filing deadline. The catch is adoption: many recipients still treat IMS as optional and only consult it at month-end, which forfeits the early-warning advantage.

Section 50 of the CGST Act runs interest at 18% per annum on ITC wrongly availed (claimed without GSTR-2B support and not reversed) and on ITC reversed under Rule 37 (supplier unpaid past 180 days). In a Rule 36(4) leakage context, the interest exposure attaches in two scenarios: (1) the recipient claimed ITC in the original period anticipating the supplier filing, the filing did not materialise, and the recipient now must reverse with interest from the original claim date; (2) the recipient claimed under Rule 37 ageing and the supplier was never paid, requiring reversal under Rule 37(4) with Section 50 interest from the original credit-availment date until the reversal date. The interest cost is permanent — not refundable even if the credit is later re-availed.

Recovery on lagged ITC typically runs 70-85% within two quarters of starting a structured workflow. The four buckets are: day 0-5 from supplier's GSTR-1 deadline (soft prompt to AP-AR contact), day 5-20 (formal escalation with invoice list), day 20-45 (CFO-office escalation citing recipient-side interest exposure), day 45+ (supplier-side rectification request via GSTR-1A or the next period's filing). The 15-30% residual lagged leakage typically converts into permanent leakage at the supplier's annual return cutoff. Permanent leakage is harder — recovery requires either tracking down the supplier to file the missing return, or filing a Section 73/74 demand request that is rarely commercially worthwhile below ₹5 lakh per supplier.

A company with 5 bank accounts, 30 active TDS deductors, and GST turnover above ₹5 crore typically spends 8–15 staff days per month on manual reconciliation — covering bank reconciliation, Form 26AS matching, GSTR-2B vs purchase register, and platform settlement matching. This is equivalent to 1–1.5 FTEs doing reconciliation work only.

Spreadsheet-based matching typically achieves 51–65% auto-match rates for Indian transaction sets, with the rest requiring manual review. Errors in manual reconciliation are most common at three points: TDS rate application (wrong section rate used), GSTR-2B timing (prior-month invoices matched to current GSTR-2B), and partial payment allocation (amount split across multiple invoices incorrectly).

Manual reconciliation remains viable when: monthly transaction volume is below 300 items, the company has a single bank account, there are fewer than 10 active TDS deductors, and GST turnover is below ₹2 crore. Above these thresholds, spreadsheet-based matching produces error rates and staff costs that exceed the cost of purpose-built tooling.

ROI = (Staff hours saved × blended hourly cost) + (ITC recovered that would have been missed) + (TDS credits recovered) + (Penalty avoidance value) — divided by annual software cost. For a company saving 8 staff days per month at ₹2,500/day, the staff saving alone is ₹2,40,000/year. Add ITC recovery and penalty avoidance, and most organisations see payback in 6–12 months.

The fastest transition follows three steps: (1) map all current data sources — bank statements, TRACES Form 26AS, GSTR-2B, and platform settlement files; (2) define matching rules for each reconciliation type before switching tools; (3) run manual and automated processes in parallel for one full month to validate match accuracy before going live. Most deployments complete in 2–4 weeks.

For a company with 3–5 bank accounts, 20–40 TDS deductors, and monthly GST turnover above ₹2 crore, month-end reconciliation should take 3–5 working days with manual processes. With automated matching, the matching phase compresses to 4–8 hours, with 1–2 days reserved for exception review and sign-off. Close cycles taking more than 7 days typically indicate a process problem — volume, tool limitations, or unresolved prior-month exceptions.

Bank reconciliation should be completed within 3 working days of month-end — by the 3rd or 4th of the following month. This allows time for GSTR-3B filing (due 20th of the following month) to be based on accurate tax liability figures. Outstanding cheques and deposits in transit from month-end should be documented and followed up within 5 working days.

GSTR-3B is due on the 20th of the month following the tax period (18th for quarterly filers under QRMP scheme). ITC reconciliation against GSTR-2B must be completed before filing, since excess ITC claimed carries 18% interest under Section 50 of the CGST Act. This means GSTR-2B vs purchase register reconciliation must be complete by the 15th of each month to allow time for GSTR-3B preparation.

A month-end reconciliation sign-off should document: the date of final bank reconciliation for each account, the outstanding exception count and materiality classification, TDS mismatches pending deductor correction returns, ITC reversals made in GSTR-3B, platform settlement variances carried forward, and the name and designation of the approving authority. This documentation serves as the audit trail for the month.

Platform settlements (Razorpay, PayU, Cashfree) have a T+1 to T+3 settlement lag, meaning revenue collected on the 30th of a month may arrive in the bank account on the 1st or 2nd of the next month. Month-end reconciliation must account for these in-transit credits and match them against the settlement files — not the bank statement — to avoid revenue recognition timing errors.

Indian companies typically maintain multiple bank accounts for operational separation: a primary current account for vendor payments, a dedicated NACH mandate collection account (required by NPCI for NACH debits), a salary disbursement account (for payroll processing via NEFT/RTGS), a GST refund credit account (some companies prefer to segregate these credits), and escrow accounts for regulatory requirements (RERA, marketplace nodal accounts). Each account has different reconciliation requirements and frequency.

The biggest challenge is inter-bank transfers — when money moves from one company account to another (for example, sweeping collections from the NACH account to the main operating account). An inter-bank transfer appears as a debit in one account and a credit in the other. Without a matching process across both accounts, the transfer appears as an unmatched debit in account A and an unmatched credit in account B — creating false exceptions in both reconciliations.

Inter-bank transfers must be matched across accounts, not just within each account. The matching logic: identify the transfer reference (UTR number for NEFT/RTGS), match the debit in account A to the credit in account B using the UTR, mark both as reconciled. The UTR is the linking key — it appears in both the sending account's debit record and the receiving account's credit record. Transfers that do not match within 1 business day are investigated for system errors or failed transfers.

Cash pooling is an arrangement where a group of bank accounts maintains a zero balance at end of day — all balances are automatically swept to a master account overnight. The next morning, sub-accounts are funded from the master account as needed. Each sweep creates a debit in the sub-account and a credit in the master (or vice versa). Reconciliation must match all pool sweeps, which may number 15–30 per day across all accounts in the pool.

A consolidated cash position requires real-time or near-real-time data from all bank accounts. Options: (1) bank API integration — the reconciliation system pulls the current balance from each bank's API; (2) MT940 SWIFT messages — banks send the previous day's statement in MT940 format each morning; (3) manual download — each account's statement is downloaded and uploaded to the reconciliation system. API integration is the most accurate; manual download introduces a 1-day lag.

Netting is the offsetting of amounts owed between two parties — where instead of each party paying the other separately, only the net difference is settled. In reconciliation, netting creates a mismatch: the bank statement shows the net settlement amount, but the books show the gross receivable and gross payable separately. Reconciliation must match the net bank credit against the appropriate combination of individual transactions.

TDS receivable (amounts deducted on payments received) and TDS payable (amounts to be deducted on payments made) cannot be netted against each other for remittance purposes. TDS payable must be deposited in full by the 7th of the following month against the correct challan codes. TDS receivable is claimed as a credit against advance tax. The two operate in different regulatory frameworks and cannot be offset at the treasury level.

Marketplace platforms net payable commissions against receivable settlements. For example, a seller on a platform may be owed ₹1,00,000 in GMV share while owing ₹8,000 in commission — the platform settles ₹92,000 (net). The seller's finance team must reconcile the gross ₹1,00,000 receivable, the ₹8,000 commission payable, and the ₹92,000 bank credit as three separate entries — not just match the net settlement.

GST must be charged on the gross invoice value — not on the netted amount. If a company is both a customer and supplier to the same counterparty, both invoices must be raised at full value with full GST. The netting arrangement only applies to the cash settlement. Attempting to raise a net invoice (net of the offsetting transaction) violates GST invoice rules and results in incorrect ITC claims for both parties.

Group company netting arrangements must be documented with: a formal netting agreement signed by both entities, a monthly netting statement showing the individual transactions, the gross amounts, and the net settlement, confirmation of the net amount by both entities' finance teams, and bank-level confirmation of the settlement. The statutory auditor will request netting agreements as part of the related party transaction review.

A nodal account is a dedicated bank account maintained by a payment aggregator or marketplace to hold buyer funds collected from online transactions, before settling them to merchants. RBI regulations require payment aggregators to maintain all collected funds in a nodal account with a scheduled commercial bank — the funds cannot be commingled with the aggregator's own funds. Settlement to merchants must occur within T+1 (for small merchants) or T+2 (standard) of the transaction date.

RBI's guidelines for payment aggregators require: (1) daily reconciliation of the nodal account balance against collected but unsettled funds; (2) daily settlement of merchant payouts from the nodal account within the prescribed timeline; (3) maintenance of a transaction-level ledger showing each buyer payment, the corresponding merchant, and the settlement date; (4) monthly reporting to RBI on the nodal account balance and settlement performance. The nodal reconciliation must demonstrate that the account holds no excess funds (only unsettled merchant payouts).

RERA Section 4(2)(l)(D) requires real estate developers to deposit at least 70% of collections from home buyers into a dedicated RERA escrow account. Withdrawals from the escrow are permitted only for land costs, construction costs, and services for the project — supported by architect certificates. Escrow reconciliation must track every deposit (70% of each flat payment), every withdrawal (with documentary evidence), and the closing balance must agree to the RERA authority portal's registered escrow balance.

If a payment aggregator's nodal account does not have sufficient balance to settle merchants on schedule, this is a regulatory violation. RBI can impose penalties, suspend the aggregator's licence, and require immediate settlement. The reconciliation control that prevents this: daily comparison of the nodal balance against the outstanding merchant settlement obligation. A nodal balance below the settlement obligation is a same-day escalation to the CFO and compliance team.

Yes — RERA escrow accounts can earn interest, and under RERA, the interest must be treated as project income (credited to the project and withdrawn only per RERA withdrawal rules). For payment aggregator nodal accounts, RBI guidelines allow interest to accrue — the treatment depends on the specific nodal account agreement. Escrow interest reconciliation must track the interest credited, the applicable tax (TDS on interest under Section 194A if above threshold), and the regulatory treatment.

OEM short-pay is the cash variance between the invoice value raised by a Tier-1 or Tier-2 supplier on an automotive, capital goods, or appliances OEM and the actual amount credited at settlement, after the OEM applies its standing deduction calendar. Standard deduction categories include Raw Material Price Variance (RMPV) pending, quality debit against rejected lots, line-stop charges where the supplier caused the OEM's production line to halt, FOMP (formula-based pricing) adjustments, freight-on-own-account if the supplier shipped under wrong incoterm, and advance-recovery against earlier supplier advances. Most categories are contractually valid; the leakage arises from the categories that should not have been applied or were applied at the wrong rupee.

Three reasons. First, the OEM applies the debit at month-end in a single net entry, not against individual invoices — so the supplier sees a ₹4.7 crore credit instead of ₹4.95 crore but no line-level deduction note. Second, the OEM's debit-note workflow lags the cash debit by 30-60 days, by which time the supplier's AR controller has already closed the invoices against the credit and the ageing trail is broken. Third, the standard OEM-supplier contract gives the supplier 90 days to dispute the debit, but the supplier's debit-recognition window often runs to 30-60 days post-month-end — leaving 30-60 days for dispute. Without a reconciliation engine that auto-classifies the cash variance by debit category, more than half of disputable debits age out.

On the supplier-receivable side the ageing runs from invoice date, with the cash credit as the closing event. At day 60, any uncovered receivable is checked against the OEM's debit-note register for the period — if no debit note is found, the receivable is structurally short-paid (no contractual reason). At day 90, the supplier's dispute window typically opens; raise a formal debit-note dispute with the OEM AR-AP desk citing invoice, expected value, credited value, and required debit-note reference. At day 150, escalate to the OEM CFO office; prepare the Section 34 credit-note arithmetic so the dispute can be resolved either by an OEM-side debit-note withdrawal or by a supplier-side credit note that aligns with the actual settlement. At day 180, the receivable is at high working-capital risk and the Rule 37 ITC reversal clock on the supplier's payables side may have started (see the linked article).

Disputable short-pay has a contract anchor and a debit-note reference but the rupee is wrong. Example: a quality debit was applied at ₹4 lakh for 1,200 rejected units when the contract priced quality debit at ₹250 per unit, implying ₹3 lakh — ₹1 lakh is disputable. Structural short-pay has no contract anchor and no debit-note reference — the OEM simply settled at a lower value with no documented reason. Disputable short-pay typically recovers 65-80% within the dispute window; structural short-pay recovers 35-50% only if the supplier has the contractual leverage to formally invoice for the unpaid residual under Section 73 of the Indian Contract Act.

If the OEM short-pays and the supplier accepts the lower value as final settlement, the supplier must raise a Section 34 credit note to align the GSTR-1 with the actually-realised value — otherwise the supplier pays output GST on the original invoice value but recovers less cash. The Section 34 window closes by 30 November of the next FY. If the credit note is not raised, the supplier permanently pays GST on the short-paid portion — typically 18% of the short-pay amount as an additional class of leakage layered on the cash short-pay. The reconciliation engine has to flag short-paid invoices for Section 34 credit-note generation within the window.

A partial payment is when a client pays an amount less than the full invoice value — for example, paying ₹85,000 against an invoice of ₹1,00,000. The ₹15,000 difference remains as an outstanding balance. In India, partial payments are complicated by TDS: if the client deducts 10% TDS, the correct interpretation is ₹90,000 payment (gross) less ₹10,000 TDS = ₹80,000 bank credit. Distinguishing between a genuine partial payment and a TDS-net payment is the primary reconciliation challenge.

TDS is calculated on the amount actually paid, not on the invoice total. If a client pays ₹80,000 against a ₹1,00,000 invoice and deducts TDS at 10%, the TDS is ₹8,000 (10% of ₹80,000), and the bank credit is ₹72,000. The TDS receivable is ₹8,000. The remaining open balance on the invoice is ₹20,000. When the remaining ₹20,000 is paid later, TDS of ₹2,000 is deducted, and the bank credit is ₹18,000.

When a client makes a single payment that covers multiple invoices — for example, paying ₹4,50,000 against three invoices of ₹1,50,000 each — the allocation logic must: (1) identify which invoices the payment applies to (using remittance advice or client reference); (2) allocate the payment amount to each invoice; (3) apply TDS proportionally if the payment is net of TDS; (4) close invoices that are fully settled and update open balances for partially settled ones. Without a remittance advice, the allocation is ambiguous and requires client confirmation.

Incorrect partial payment allocation does not directly affect the GST payable (which is liability-based on invoice date), but it affects the accounts receivable balance — which in turn affects the working capital statement, the debtors' age analysis, and the calculation of bad debt provisions. If partial payments are systematically misallocated, the AR ledger will show incorrect outstanding balances and the bad debt provision will be incorrect.

A credit note reduces the invoice outstanding balance before any cash payment is allocated. If a ₹1,00,000 invoice has a ₹10,000 credit note applied, the net outstanding is ₹90,000. A subsequent payment of ₹81,000 (with 10% TDS on ₹90,000) fully settles the invoice: ₹81,000 bank credit + ₹9,000 TDS receivable = ₹90,000 net outstanding. The reconciliation must apply credit notes before applying payments.

PE investors typically require: monthly close completed by day 5 of the following month, board pack with reconciled financials delivered by day 10, variance analysis explaining deviations from budget and prior month, TDS receivable reconciled to Form 26AS quarterly, GST ITC reconciled to GSTR-2B monthly, and bank statements reconciled at month-end for all accounts. These are minimum standards — many PE funds require weekly cash reporting and daily settlement reconciliation.

The most common reconciliation gap in founder-led companies pre-PE is the absence of a continuous reconciliation process — most run batch reconciliation at year-end for the audit, not monthly. The result is that the PE investor's first 90-day financial review uncovers TDS mismatches, unreconciled platform settlements, and GSTR-2B mismatches that were never caught. The cleanup cost of 2–3 years of backlog is typically borne by the company in the first 6 months post-investment.

PE due diligence teams typically request 12 months of bank reconciliation statements, Form 26AS vs TDS receivable reconciliation for the last 2–3 years, GSTR-2B vs purchase register reconciliation for the last 12 months, and platform settlement reconciliation for any marketplace or payment gateway channel. Gaps in any of these are marked as post-investment action items and may affect the valuation or deal structure.

Board-ready reconciliation requires: bank reconciliation completed by day 2, platform settlements reconciled by day 3, AR and AP ledgers updated by day 4, GSTR-2B matched against the prior month's purchase register by day 5, and TDS receivable updated by day 5. This timeline requires continuous reconciliation running through the month — not a day-1 batch run.

A reconciliation pack is the supporting documentation behind the board pack financials — typically a set of schedules showing: bank reconciliation for all accounts, AR ageing with reconciliation to the ledger, AP ageing with reconciliation, TDS receivable balance reconciled to Form 26AS, ITC claimed reconciled to GSTR-2B, and platform settlement summary. The reconciliation pack is what the auditor reviews at year-end — and what the next PE investor reviews in the next round's due diligence.

Contracted MDR is the rate stated in the merchant agreement with the payment aggregator — typically 1.95% to 2.4% for cards, lower for UPI. Platform fee leakage is the variance between what that contracted rate would compute on the per-transaction gross and what the settlement file actually deducts. It arises from instrument-mix repricing (a card type silently moved to a higher slab), undisclosed convenience fees, GST on MDR not netted clearly, paise rounding consistently in the aggregator's favour, currency conversion margin on cross-border settlements, and the occasional chargeback fee that was contractually free but invoiced anyway. None of this is theft. It is structural opacity at the per-transaction fee level.

An aggregated settlement for a single day looks like a clean inflow into the merchant's bank: gross transactions, less fees, less tax, plus or minus adjustments, net credit. The fee line aggregates dozens of distinct fee components — slab-wise MDR, premium-instrument surcharges, refund-handling charges, payout fees if the merchant uses split-settlement, chargeback workflow fees. Without the per-transaction breakdown, a 0.07% leakage on 38,000 monthly transactions disappears into the daily reconciliation as 'rounding' or 'fee variance accepted.' The audit recovery only works at the per-transaction fee-column level.

Payment aggregators charge GST at 18% on the MDR component of their fee. Two patterns generate leakage. Pattern one: the aggregator presents the MDR as inclusive of GST in some interpretations and exclusive in others, with the merchant booking it differently across periods. Pattern two: the merchant claims ITC on the MDR-GST through the standard Rule 36(4) workflow, but the aggregator's GSTR-1 filing does not match the merchant's claim record because the consolidated invoice from the aggregator is at month-end while the merchant booked per-transaction. The reconciliation engine has to align the aggregator's monthly tax invoice against the per-transaction settlement file.

Instrument-mix repricing happens when an aggregator silently moves transactions from a lower-fee slab to a higher-fee slab. Common cases: a 'standard credit card' transaction reclassified as a 'premium credit card' (typically 0.4% higher), a domestic UPI transaction reclassified as 'UPI-Premium' (0.2-0.4% higher), a debit card transaction reclassified mid-month because the BIN range was updated. The merchant's daily settlement file may show 12% premium-card mix in January and 19% in February with no corresponding change in customer behaviour. The reconciliation flag is the month-on-month mix drift on the same payment-channel base — anything beyond 2 percentage points warrants an aggregator query.

For an Indian D2C brand running 30,000 to 80,000 monthly transactions across one or two payment aggregators, structured per-transaction fee audit recovers 0.05% to 0.25% of monthly settlement volume in the first two quarters. Recovery comes through: chargeback dispute filings within the platform's 60-90 day window, contracted-rate recalculations applied retrospectively for instrument-mix errors, GST-ITC alignment that recovers credits previously written off, and contractual amendments tightening the disclosure schedule. A D2C brand running ₹4.2 crore monthly volume on a 0.12% recovered band sees ₹6.05 lakh of annual recovered cash.

Under the Income Tax Act, books of account and supporting documents must be retained for 8 years from the end of the relevant assessment year (Section 44AA). Under GST law, records must be retained for 6 years from the last date of filing the annual return for the financial year (Rule 56 of CGST Rules). For companies under the Companies Act, records must be retained for 8 years from the end of the financial year. The effective minimum retention period for reconciliation records is 8 years.

CBDT expects: a reconciliation of TDS receivable per books to Form 26AS for each assessment year, with named exceptions documented; evidence that correction return requests were filed for mismatched TDS entries; and a reconciliation of advance tax paid to TDS credit claimed. For companies subject to tax audit under Section 44AB, the reconciliation must be available for review by the tax auditor within 30 days of the audit commencement date.

A GST audit officer conducting scrutiny under Section 65 or investigation under Section 67 will request: the purchase register for the audit period, the GSTR-2B downloads for the same period, and the reconciliation statement showing how ITC claimed in GSTR-3B was derived from GSTR-2B. They will also request evidence of reversals made for ITC claimed without GSTR-2B support, and the basis for any proportional ITC reversal under Rules 42 and 43.

A spreadsheet can serve as an audit trail only if it is tamper-evident, dated, and version-controlled. In practice, spreadsheets do not meet these requirements — rows can be deleted, formulas changed, and dates edited without a record of the change. Statutory auditors and GST officers increasingly require system-generated audit trails, not spreadsheet exports, especially for organisations with monthly transactions above 500.

A digital audit trail is generated automatically by the reconciliation system — every match, every exception classification, every override is time-stamped and user-attributed. A paper audit trail is printed output signed by the finance manager. Digital trails are superior for regulatory purposes because they are immutable, searchable, and can be exported on demand. Under the DPDP Act and GST rules, digital records with appropriate access controls meet the requirements for electronic record-keeping.

For an organisation processing 1,000+ transactions per month, reconciliation automation typically delivers 300–500% ROI over 3 years. The primary drivers are staff cost savings (8–12 days/month → 1–2 days), ITC recovery (systematic GSTR-2B matching recovers 0.5–2% of purchases annually), and TDS credit recovery (unmatched TRACES credits). Payback period for mid-size companies is typically 6–12 months.

Calculate: (Hours per month spent on reconciliation matching) × (Blended hourly rate of finance staff). For a 10-person finance team spending 30% of their time on reconciliation tasks, that is 3 FTE-equivalents. At ₹40,000/month per analyst, that is ₹1.2 lakh/month in staff cost attributable to reconciliation — or ₹14.4 lakh/year before salary growth.

Indian businesses with monthly purchases above ₹1 crore typically have 1–3% of purchase invoices with GSTR-2B timing issues — supplier filed late, GSTIN mismatch, or credit note not processed. At 18% GST on ₹1 crore monthly purchases (₹18 lakh/month ITC), even a 1% recovery improvement recovers ₹18,000/month or ₹2.16 lakh/year in ITC that would otherwise have been written off.

Calculate: (Average excess ITC claim per year at risk of notice) × 18% interest rate + expected penalty. For an organisation with ₹5 lakh in excess ITC claims discovered annually in audit, the interest alone is ₹90,000/year. Add a 25% penalty (₹1.25 lakh) and the penalty avoidance value is ₹2.15 lakh/year. This is a conservative estimate — actual notices often cover multiple years.

A three-year model adds: Year 1 = staff savings + ITC recovery + penalty avoidance − software cost − implementation cost. Year 2 = same benefits, no implementation cost. Year 3 = same benefits. For a company saving ₹18 lakh/year in combined benefits and paying ₹6 lakh/year for software (₹3 lakh implementation in Year 1), the three-year net benefit is ₹33 lakh. Three-year ROI = 183%.

A good match rate for bank reconciliation is 90% or above for auto-matching (before manual review). Companies using bank API or MT940 integration typically achieve 92–96% auto-match rates. Companies relying on manual CSV downloads typically achieve 80–88%. A match rate below 80% indicates systematic issues: narration format mismatches, multiple payment channels not configured, or a high volume of NACH credits not being disaggregated.

GSTR-2B match rates of 80–88% are typical for well-run Indian finance teams. The 12–20% that does not auto-match consists primarily of supplier filing delays (invoices not yet in GSTR-2B), GSTIN mismatches (supplier filed with wrong GSTIN), and rate differences (supplier applied a different GST rate than the purchase order). A match rate below 75% typically indicates a vendor master data quality issue — incorrect GSTINs or section codes in the system.

For a company with 5 bank accounts, 30 TDS deductors, and ₹5 crore+ GST turnover: manual reconciliation typically takes 8–12 days; automated reconciliation (matching phase) takes 1–2 days, with 1–2 days for exception review = 3–4 days total. Closing reconciliation by day 5 of the following month is achievable with automated matching. Closing by day 10 is achievable manually for mid-size companies. Closing after day 15 indicates a process problem.

Standard exception resolution SLAs for Indian reconciliation: TAX_DEDUCTION exceptions (TDS/TCS) — 2 business days; TIMING_DIFFERENCE — 5 business days or carry to next period; AMOUNT_MISMATCH above ₹10,000 — 3 business days; MISSING_CREDIT — 1 business day; FEE_DEDUCTION — same-day auto-resolution. Exceptions remaining unresolved after 30 days are a high-risk item — many ITC claims have a 30-day window before they require manual follow-up with suppliers.

Manual reconciliation: a senior finance analyst can process approximately 200–300 invoices per day in matching mode (before exceptions). For exception review, approximately 30–50 exceptions per day at ₹5,000–₹50,000 each. Automated reconciliation shifts the analyst's role from matching to exception review — the same analyst can review 80–100 classified exceptions per day vs manually matching 200–300 transactions. The productivity improvement is 3–5x, not in the number of transactions processed, but in the quality of time spent.

Reconciliation debt is the accumulation of unmatched or unresolved financial transactions in your books — TDS credits in Form 26AS that have not been matched to the ledger, ITC in GSTR-2B that has not been reconciled against purchases, or bank credits sitting in a suspense account. Unlike financial debt, reconciliation debt grows without producing any corresponding asset — it represents potential future write-offs, penalties, and audit findings.

Reconciliation debt accumulates when the matching process is deferred — typically because the team is overwhelmed by volume, the matching tools are inadequate, or the process runs monthly instead of continuously. Each deferred month adds new unmatched items on top of unresolved prior items. TDS entries older than the ITR filing deadline become unrecoverable. ITC older than the GSTR-9 deadline requires reversal with interest.

Industries with the highest reconciliation debt are those combining high transaction volume with complex deduction structures: e-commerce (platform settlements with TCS and MDR), healthcare (TPA settlements with Section 194J TDS), IT services (multiple 194J deductors with different section interpretations), and real estate (buyer TDS under Section 194IA across hundreds of units).

TDS credits from prior years can generally be recovered if the deductor filed the TDS return correctly and the credit appears in Form 26AS for the relevant assessment year. You can claim these credits by filing a revised ITR or through a refund claim, subject to the limitation period under the Income Tax Act (typically 4–6 years). ITC missed beyond the September return of the following year is generally irrecoverable under GST rules.

Calculate reconciliation backlog by adding: (a) TDS receivable in books not matched to Form 26AS, (b) ITC claimed without GSTR-2B support, (c) bank suspense account balance, (d) accounts receivable older than 180 days without invoice confirmation. The total is the gross reconciliation debt. The recoverable portion depends on whether correction returns can still be filed and whether ITC claim deadlines have passed.

The most common cause is ITC claimed in GSTR-3B that does not appear in GSTR-2B for the same period. Under Rule 36(4) of the CGST Rules, ITC can only be claimed for invoices appearing in GSTR-2B. Claims above this amount trigger an automated GSTR-2A/2B mismatch notice from the GSTN system. The solution is to reconcile GSTR-2B against the purchase register before filing GSTR-3B each month.

TDS under Section 194C is deducted on the taxable value of a supply — not on the GST-inclusive amount. If TDS is incorrectly deducted on the total (taxable value + GST), the excess deduction creates a discrepancy in the buyer's books and may trigger a notice for excess TDS deduction under the Income Tax Act as well as a GST on reverse charge discrepancy. The correct deduction basis is the taxable value only.

ITC claimed without GSTR-2B support is treated as excess ITC under Section 50 of the CGST Act. Interest is charged at 18% per annum from the date of excess claim to the date of reversal. There is no minimum threshold — even a ₹1,000 ITC claim without GSTR-2B support attracts interest. Additionally, if the claim is found in an audit, a penalty of up to 100% of the excess ITC may apply under Section 122.

A supplier who files the same invoice twice in GSTR-1 creates a duplicate entry in the buyer's GSTR-2B. If the buyer claims ITC on the duplicate without noticing, the total ITC claimed exceeds the actual supply value. When the supplier subsequently corrects the duplicate, the GSTR-2B update removes the entry — and the buyer's GSTR-3B shows ITC claimed that is no longer in GSTR-2B, triggering a mismatch notice.

On receiving a mismatch notice, you have 30 days to respond. Steps: (1) download the notice details and identify the specific invoices in dispute; (2) check whether the difference is a timing issue (supplier filed late) or a genuine discrepancy; (3) for timing differences, reverse the ITC in the current GSTR-3B and re-claim when the GSTR-2B is updated; (4) for genuine discrepancies, contact the supplier to file a correction return and provide a written response to the GST officer with supporting documentation.

Reconciliation infrastructure is a configurable platform — not a fixed-function tool — that handles multiple reconciliation types (TDS, GST, bank, NACH, platform settlements) through a shared matching engine. It is 'infrastructure' in the sense that it is embedded in the finance operations layer and works across business types and data sources, rather than solving a single specific matching problem. Industry presets configure it for healthcare, NBFC, real estate, or e-commerce without custom code.

Reconciliation software is a point solution: a bank reconciliation tool, a TDS matching tool, or a GST ITC tool. It solves one problem well but requires a separate tool for each reconciliation type. Reconciliation infrastructure is a unified platform: one matching engine, one exception queue, one audit trail — configured for all reconciliation types through rules and presets. As the business adds new reconciliation requirements (new payment gateways, new compliance forms), infrastructure scales without adding new tools.

API-first reconciliation infrastructure connects to data sources programmatically — pulling bank statements via bank API, GSTN data via API (where available), ERP data via SAP RFC or Oracle API — rather than requiring manual file downloads and uploads. This enables near-real-time matching (daily or intraday) rather than monthly batch matching. For NBFCs, payment aggregators, and e-commerce companies processing thousands of daily transactions, API-first is the only viable architecture.

Industry presets encode the matching logic specific to a sector without requiring custom code for each deployment. A healthcare preset knows that a TPA settlement represents multiple patient claims and applies the correct split-matching logic. An NBFC preset knows that a NACH batch credit must be disaggregated against individual loan account mandates. Without presets, configuring these rules requires development work — adding weeks to deployment and cost to implementation.

Reconciliation infrastructure configured with industry presets typically deploys in 2–4 weeks — including data source connection, rule configuration, and parallel run validation. Point solutions deploying for a single reconciliation type may be faster. Custom-built solutions without presets typically take 3–6 months. The deployment window is relevant to the business case: a 2-week deployment means the first full month of operation captures ROI starting in month 2.

The six most important reconciliation KPIs for Indian finance teams are: (1) overall auto-match rate — percentage of transactions matched without human intervention; (2) days to close — business days from period end to completed reconciliation; (3) exception resolution rate — percentage of exceptions resolved within SLA; (4) exception aging — percentage of open exceptions older than 30 days; (5) ITC leakage rate — percentage of eligible ITC not claimed due to reconciliation failure; (6) TDS credit recovery rate — percentage of Form 26AS TDS credits successfully claimed.

Auto-match rate = (Transactions matched automatically ÷ Total transactions) × 100. For example: 850 of 1,000 transactions matched automatically = 85% auto-match rate. Calculate this separately for each reconciliation type — bank, TDS, GSTR-2B, platform settlement — because the baseline and benchmark differ by type. Track month-over-month trend, not just point-in-time value. A declining match rate is a leading indicator of process deterioration.

ITC leakage rate = (ITC available in GSTR-2B − ITC claimed in GSTR-3B − ITC pending from prior periods) ÷ ITC available in GSTR-2B × 100. A leakage rate above 2% warrants investigation — it means more than 2% of eligible input tax credit is being lost, either because invoices are not in GSTR-2B (supplier filing delay), the purchase register has errors (wrong GSTIN), or ITC was reversed due to excess claim. Each rupee of ITC leakage is a direct P&L charge.

TDS credit recovery rate = (TDS credits claimed in ITR ÷ TDS credits booked in TDS receivable ledger) × 100. A rate below 90% indicates that some TDS receivable is not being recovered — either because the deductor filed incorrectly (wrong PAN, wrong section), the correction return was not filed in time, or the TDS receivable ledger has errors. Track this rate quarterly (aligned with ITR and advance tax filing timelines) rather than monthly.

Match rate and exception aging should be reviewed weekly by the finance controller and monthly by the CFO. Close cycle time is reviewed monthly. ITC leakage rate and TDS credit recovery rate are reviewed quarterly (aligned with GST quarterly review and advance tax instalment calculation). Annual review covers the full-year trend, benchmark comparison, and KPI target setting for the next financial year.

ERPs handle the accounting layer — recording transactions, generating trial balances, and producing standard reports. They do not handle the external verification layer: matching the AR ledger against Form 26AS (TRACES), matching the purchase register against GSTR-2B (GSTN), or matching bank accounts against bank-issued statements via MT940. These external matches require a reconciliation layer that connects to government portals and bank systems — not just the ERP's internal data.

GSTR-2B is generated on the 14th of each month for the prior month's transactions, and GSTR-3B is due on the 20th. That gives finance teams 6 days to complete GSTR-2B vs purchase register reconciliation and file GSTR-3B. For organisations with 500+ purchase invoices per month, 6 days is insufficient if reconciliation has not been run continuously. Monthly batch reconciliation consistently results in ITC being claimed before GSTR-2B matching is complete — creating excess claims and interest exposure.

Reconciliation failures have direct P&L consequences: lost TDS credits reduce the advance tax offset, ITC leakage increases the effective cost of goods, and GST penalties affect cash flow. These are CFO-level concerns, not back-office administrative matters. Organisations that treat reconciliation as a back-office task typically under-invest in tooling and understaff the function — producing exactly the audit findings and penalty exposure that CFOs consider strategic risks.

Manual review is more contextually accurate for genuine exceptions — a human can evaluate whether a ₹5,000 variance is a rounding error or a genuine discrepancy better than a rule-based system. But manual review is not more accurate than automation for the matching phase itself. Automation applies rules consistently across thousands of transactions without fatigue errors. Manual matching at scale introduces errors that accumulate — the same analyst who correctly resolves one exception makes errors on the 50th exception of the day.

Reconciliation debt cannot be sustainably managed — it can only be eliminated and prevented from re-accumulating. Managed reconciliation debt grows: each month's unresolved items add to the prior backlog, and ITC claim deadlines expire while TDS correction windows narrow. An organisation that decides to 'manage' ₹20 lakh in reconciliation debt for 3 months will typically find it has grown to ₹60 lakh by month 3, with portions becoming unrecoverable.

CFOs should review five reconciliation metrics monthly: (1) overall match rate by reconciliation type (bank, TDS, GST, platform) — target above 85%; (2) exception aging — what percentage of open exceptions are older than 30 days; (3) reconciliation debt balance — total value of unresolved items; (4) high-value exceptions — any single exception above ₹5 lakh; (5) close cycle time — days from period end to completed reconciliation. These five metrics predict audit risk and cash leakage before they materialise.

A declining match rate — GSTR-2B match rate dropping from 82% to 71% over 3 months, for example — typically signals one of three things: transaction volume has grown faster than the matching capacity of the current process; a supplier or deductor has changed their filing behaviour (new PAN, different section code, delayed filing); or a data source has changed format and the matching rules have not been updated. A declining match rate predicts an increasing exception backlog 2–3 periods ahead.

Reconciliation debt accumulates in layers. Month 1: 50 unresolved exceptions from GSTR-2B mismatch. Month 2: 50 new + 20 carry-forward = 70 exceptions. Month 3: the 20 month-1 items approach the ITC claim deadline — resolution becomes urgent. By month 4, some month-1 items are past the deadline and the ITC is permanently lost. The debt converted to a P&L charge. This pattern repeats unless the root cause is addressed.

An exception aging report categorises open reconciliation exceptions by how long they have been unresolved: 0–7 days (within SLA), 8–30 days (approaching deadline), 31–90 days (at risk), and 90+ days (likely unrecoverable for ITC; correction return window for TDS may be closing). CFOs who review exception aging monthly catch the 31–90 day bucket before it becomes 90+. CFOs who do not see this report discover the problem at the audit.

TDS-heavy industries (IT services, professional services, staffing) see the highest TDS exception rates — Section 194J and 194C mismatches are the dominant pattern. Marketplace and e-commerce businesses see platform settlement exceptions as the primary pattern — MDR deductions, TCS withheld, and bulk credit disaggregation. Manufacturing businesses with high purchase volumes see GSTR-2B matching as the primary exception source. The pattern determines the reconciliation investment priority.

SAP's India localisation (SAP S/4HANA for India) includes TDS deduction and posting capabilities, but does not natively connect to TRACES or download Form 26AS for automated matching. Finance teams using SAP typically export TDS receivable data from SAP and match it manually against Form 26AS downloads — or use a third-party reconciliation layer connected to SAP via RFC or file export.

Tally Prime (TallyPrime 3.0 onwards) includes GSTR-2B import and reconciliation functionality. However, the reconciliation is at the invoice level and requires the supplier's GSTIN to be correctly entered in Tally. For organisations with 200+ purchase invoices per month, the Tally GSTR-2B reconciliation process still requires manual exception handling, particularly for invoices with GSTIN mismatches or debit/credit note adjustments.

Oracle Fusion Financials includes India localisation for TDS (Oracle Tax Withholding) and GST (Oracle GST for India), but the GSTR-2B matching functionality requires Oracle's GST module to be configured and the GSTR-2B JSON to be uploaded manually each month. Oracle does not have a direct GSTN API integration in standard deployments — reconciliation against GSTR-2B still requires a separate process step.

An ERP is not enough when: (1) transaction volume exceeds the ERP's matching performance (typically 1,000+ transactions/month), (2) the organisation uses multiple payment gateways whose settlement files do not integrate into the ERP, (3) NACH batch reconciliation is needed (most ERPs have no NACH-specific matching), or (4) the organisation requires continuous reconciliation rather than month-end processing.

Integration approaches vary by ERP: SAP integration uses RFC calls or file-based export (BAPI or SAP FTP export in FBL1N/FBL5N format). Oracle integration uses Oracle API Gateway or scheduled exports from Oracle BI Publisher. Tally integration uses the Tally XML API or CSV export from standard Tally reports. Most reconciliation platforms support all three through pre-built connectors or configurable file-based ingestion.

Revenue leakage is any rupee a business has earned, billed, or is statutorily entitled to claim, that never lands in its bank account or its tax-credit register. It is not bad-debt — that is a customer-side credit decision. It is not fraud — that is malicious. Leakage is the structural, repeated, system-design loss that finance teams quietly absorb: a TDS deduction that never reaches Form 26AS, an ITC entry that lapses past the supplier filing window, a Razorpay settlement where the fee column does not reconcile to the contract, a NACH bounce where the recovery charge never gets back-billed. Seven classes cover almost every real instance: fee deduction, tax deduction, discount, rounding, short settlement, penalty / interest, and unexplained variance.

Three reasons. First, India's statutory mesh — TDS under Section 393 / 394 of the Income Tax Act 2025, GST under the CGST Act, NACH under NPCI's circular framework — generates more recoverable rupees per crore of revenue than most jurisdictions because each tax has a forward credit mechanism. Second, the platform-settlement layer (Razorpay, PayU, Cashfree, Amazon, Flipkart, Meesho, Stripe for cross-border) was built for transaction volume, not finance-side reconciliation, so fee opacity is structurally higher than in card-era reconciliation. Third, MSME and mid-market finance teams in India run with 2–6 person reconciliation desks against 30,000–200,000 monthly transactions; without a class-based variance taxonomy, leakage is closed by guesswork every month-end.

Tax-deduction leakage. A ₹50 crore IT services business with 1.5–2% TDS deducted at source on most of its revenue sees ₹75 lakh to ₹1 crore of TDS-bearing receivables a year. Industry pattern data shows roughly 8–14% of that never converts to a claimed credit because of Form 26AS mismatches (wrong PAN, wrong section code, wrong period), the deductor never filing the quarterly TDS return on time, or the credit ageing past the rectification window. That is ₹6 to ₹14 lakh a year on a single ₹50 crore revenue line, with no offsetting recovery unless a reconciliation engine ages each TDS receivable against the actual Form 26AS / Form 168 record.

Five signals tell you leakage is real before you build any infrastructure. (1) Your books show ₹X TDS receivable, but Form 26AS / Form 168 shows less than ₹X — the delta is your TDS leakage. (2) Your GSTR-2B for any period contains fewer invoices than your purchase ledger for the same period — the delta is your ITC at risk under Rule 36(4). (3) Your platform-settlement file contains a 'fees' column whose total does not match the contracted rate applied to gross — the delta is fee leakage. (4) Your NACH bank statement contains debit entries labelled return / bounce charges that do not appear in any customer recovery invoice — the delta is penalty leakage. (5) Your month-end JV register contains 'write-off — unidentified' or 'variance — adjustment' lines above ₹10,000 — every one is unexplained leakage by definition.

It is the public-facing customer-benefit form of TransactIG's internal variance taxonomy (patent filed in India on the classification engine). The seven labels — FEE_DEDUCTION, TAX_DEDUCTION, DISCOUNT_APPLIED, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, UNEXPLAINED — are the public taxonomy used in the Discovered Money view to classify every reconciliation variance so nothing is closed by guesswork. They are described in customer language at the Stop Revenue Leakage pillar page, and every Tier C insight article in this leakage series ties back to exactly one of the seven.

Industry benchmark for mid-size Indian companies (₹50–200 crore turnover) is 3–5 working days from month-end. A close cycle consistently exceeding 7 working days indicates a reconciliation process problem — either volume has outgrown the tools, or prior-month exceptions are not being resolved before the next cycle starts. Best-in-class organisations with automated reconciliation close in 1–2 days.

Any GSTR-2B mismatch notice represents a preventable reconciliation failure — there is no acceptable baseline of 'some notices.' However, in practice, organisations receiving more than 2 demand notices or mismatch letters per financial year have a systematic reconciliation gap that needs process intervention, not just individual notice responses.

Weekend work for month-end close is a leading indicator that the reconciliation process is broken — volume has outgrown the team's capacity within a normal work week. It indicates either that the matching is manual (and scales with transaction volume rather than being automated), or that prior-month exceptions are consuming time that should go to the current month's close.

A suspense account is used to temporarily park transactions that cannot be immediately classified — bank credits with no matching invoice, NACH credits not yet allocated, or cash receipts pending identification. A suspense account balance above ₹1 lakh that persists for more than 10 days indicates that reconciliation is being deferred rather than completed. A persistently large suspense balance is an audit observation under the Companies Act.

Frequent audit qualifications on reconciliation typically arise from: bank reconciliation statements not prepared within 15 days of period end, TDS receivable not reconciled to Form 26AS, accounts receivable not confirmed with counterparties for amounts above ₹10 lakh, and suspense account items older than 30 days without documentation. Each of these is a standard statutory auditor check that a functioning reconciliation process prevents.

Form 26AS continues as the legacy annual TDS-credit statement for assessment periods that pre-date the 2026 migration of Sections 194x into the consolidated Section 393 / 394 framework. Form 168 is the post-migration statement architecture used for deductions made under the new payment-code dictionary 1001 to 1092. For most mid-market businesses today, an FY runs across the cutover, so the deductee will see TDS receivable showing partly in 26AS (under the cross-era 194x reference) and partly in 168 (under the corresponding 1001-1092 code). The reconciliation engine must aggregate both statements per PAN per period for a true credit position.

Four root causes account for more than 90% of cases. (1) The deductor never deposited the TDS — the amount was deducted on the invoice payment but not credited to the government within the Section 416 window; the deductee has the receivable on books, but no government record exists. (2) The deductor deposited but never filed the quarterly TDS return, so no entry hits 26AS / 168. (3) The deductor filed but used the wrong PAN of the deductee — the credit lands in a different taxpayer's statement. (4) The deductor used the wrong section code — code 1026 (technical fees) instead of 1027 (professional fees), or a cross-era 194J reference when §393(1) Sl. 6(iii).D(b) code 1027 should have been used — and the credit is technically present but mis-classified. Each root cause has a different recovery action.

The 2026 migration consolidated more than 30 individual Section 194x TDS provisions into the Section 393 framework — with §393(1) covering most resident payments, §393(2) covering the non-resident catch-all, and §393(3) covering specified TDS items such as partner remuneration and cash withdrawal. TCS is consolidated under Section 394. Each transaction carries a four-digit payment code in the 1001-1092 range mapped to its Section 393 schedule reference: code 1027 for professional fees (former 194J at 10%), code 1026 for technical fees (former 194J at 2%), code 1031 for purchase TDS above ₹50 lakh aggregate in FY (former Section 194Q), code 1057 for the non-resident catch-all (former Section 195), code 1023 / 1024 for contractor TDS by deductee type (former 194C), and so on. Reconciliation engines must hold a cross-era mapping table so that a legacy 194J payment in FY24-25 is correctly reconciled against its 1027 / 1026 successor for any cross-period adjustment.

Every TDS receivable is aged from the date of deduction (taken from the customer's payment advice or the invoice settlement record). At day 30, the deductor is expected to have deposited the amount within the Section 416 window — if the receivable does not appear in the deductor's draft quarterly return preview, raise the first follow-up. At day 60, the quarterly return must have been filed for periods ending within the bucket — re-confirm in the deductee 26AS / 168 statement. At day 90, escalate to the deductor's CFO office for any receivable still missing — the rectification clock is now ticking. At day 180, the receivable is at high risk of rectification-window lapse; file Form 131 (legacy) or Form 141 (new era) rectification at the deductor's TRACES login, with the deductee's PAN, period, and payment code documented. Beyond day 180, recovery probability drops materially.

Recovery rates depend on the standing leakage at start. A finance team running ad-hoc 26AS / 168 checks once a year typically has 8 to 14% of TDS-bearing receivable in leakage. A structured 30/60/90/180-day workflow with deductor escalation recovers 60 to 80% of that standing leakage within the first three quarters of operation. The residual 20 to 40% is structural — deductors that have wound up, periods past the rectification window, or PAN mismatches that cannot be resolved without a deductee-side correction. The recovered band — typically 5 to 11% of TDS-bearing receivable — is permanent additional cash inflow.

Tolerance matching is the practice of automatically resolving reconciliation differences that fall within a pre-defined threshold — for example, auto-resolving any variance of ₹5 or less as a rounding difference, without requiring human review. Tolerance rules reduce exception queues by handling the high-volume low-value variances that are predictable in Indian reconciliation (TDS rounding, MDR calculation differences, GST rounding).

TDS is calculated as a percentage of the gross payment amount. At low invoice values, this creates rounding differences of ₹1–₹5 depending on the calculation method (round half up vs round half down). A tolerance of ₹5 per TDS deduction is generally appropriate for auto-resolution. For high-value invoices where 1% TDS generates ₹200–₹500 in rounding differences, a percentage-based tolerance (0.5% of TDS amount) may be more appropriate.

GST amounts are calculated on invoice totals and rounded to the nearest rupee per the CGST Act. GSTR-2B may show amounts rounded differently from the purchase invoice. A tolerance of ₹2 per invoice line for GST amount differences is generally appropriate for auto-resolution. However, tolerance should not apply to GSTIN mismatches or invoice number mismatches — these require human review regardless of the amount.

Tolerance matching is appropriate for bank reconciliation differences arising from bank charges that vary slightly from expected (for example, bank charges of ₹118 instead of ₹120 in a month where charges typically run at ₹120). It is not appropriate for unexplained bank differences above ₹100 or any difference involving an unidentified credit or debit. The principle: tolerance applies to expected minor calculation differences, not to unexplained items.

Tolerance-resolved exceptions must be logged with: the original amount in each source, the variance amount, the tolerance rule applied, the date of auto-resolution, and the total monthly volume of tolerance-resolved items. Auditors review the tolerance resolution log as part of the reconciliation audit trail. The total amount auto-resolved under tolerance rules should be disclosed in the reconciliation sign-off documentation.

A virtual account number (VAN) is a unique account number assigned to a specific customer or purpose, which routes incoming payments to a single physical bank account. When a customer pays using their assigned VAN via NEFT or RTGS, the bank automatically identifies the payment as coming from that customer — no narration parsing required. The physical bank account receives the credit, but the bank's system tags the credit with the VAN, enabling automatic reconciliation.

When a payment is received on a VAN, the bank generates an event notification (via API webhook) containing: the VAN, the amount, the UTR, the payer account number, and the timestamp. The reconciliation system receives this webhook, looks up which customer is assigned to this VAN, and automatically creates the receipt entry against the appropriate AR ledger record. If the amount matches an open invoice, the invoice is closed. If not, the receipt is flagged for allocation.

Three types: (1) Bank-issued VANs — assigned by banks like HDFC, ICICI, or Yes Bank as part of a cash management service; (2) Payment gateway VANs — issued by Razorpay, PayU, or Cashfree for NEFT collection; (3) NACH virtual accounts — used by NBFCs and lenders to receive EMI payments, where each borrower's mandate routes to a unique VAN. Each type has different API formats and different reconciliation events.

The main failure modes are: (1) customer pays from a different account than expected and the bank identifies the payer incorrectly; (2) customer pays an amount that does not match any open invoice (overpayment or underpayment); (3) the VAN webhook fails to reach the reconciliation system due to a network timeout; (4) multiple customers share a VAN due to a configuration error (this creates misattribution at scale). Each failure requires different resolution logic.

When a client pays via VAN and deducts TDS, the VAN credit is the net amount (gross invoice minus TDS). The reconciliation system receives the VAN credit and must determine whether the shortfall from the invoice amount is due to TDS deduction or a partial payment. This determination requires either: (1) remittance advice from the client specifying TDS deduction, or (2) automated TDS detection based on the client's known TDS deduction pattern (section and rate).

Financial reconciliation is the process of confirming that two sets of financial records agree — for example, that your bank statement balance matches your cash ledger, or that TDS shown in Form 26AS matches the TDS receivable in your books. In India, reconciliation must cover bank accounts, TDS deductions, GST credits, and platform settlements — each requiring separate matching logic.

India's reconciliation complexity comes from three tax-at-source mechanisms running simultaneously: TDS (deducted on payments received), GST (with ITC matching across GSTR-2A, GSTR-2B, and purchase register), and TCS (collected by e-commerce operators). Each creates a timing mismatch between the transaction date and the date the tax record appears in a government portal — requiring continuous reconciliation rather than a one-time match.

Unreconciled TDS results in lost credits that may not be claimable after the ITR filing deadline. Unreconciled GSTR-2B mismatches result in ITC reversals with 18% interest under Section 50 of the CGST Act. Bank reconciliation failures obscure the true cash position and can lead to incorrect financial statements — a statutory audit risk for companies under the Companies Act.

Accounting records transactions (receipts, payments, invoices, expenses). Reconciliation confirms that those recorded transactions match an independent external source — a bank statement, a government portal (Form 26AS, GSTR-2B), or a counterparty's records. A journal entry creates a ledger balance; reconciliation verifies that ledger balance is accurate.

Manual monthly reconciliation for 3 bank accounts and 30 TDS deductors typically takes 2–4 working days. Adding GST reconciliation (GSTR-2B vs purchase register) adds another 1–2 days. With automated matching, the matching phase compresses to under 4 hours — the remaining time is spent on exception review and resolution.

A reconciliation engine is a software component that automatically matches financial transactions across two or more data sources using configurable rules. It applies matching logic — exact match, tolerance-based match, pattern-based match — in multiple sequential passes, classifies unmatched items by exception type, and routes them to reviewers. It differs from a spreadsheet in that it can process hundreds of thousands of transactions in minutes and applies consistent logic without human intervention.

A multi-pass engine applies increasingly flexible matching criteria in sequence. Pass 1 attempts exact matches on primary reference fields (UTR, invoice number). Pass 2 applies tolerance-based matching for rounding differences (±₹1 or ±1%). Pass 3 applies pattern-based matching for known deduction types (TDS at 10% = 194J). Items unmatched after all passes become genuine exceptions requiring human review — a much smaller set than the full transaction volume.

Variance taxonomy is the classification system a reconciliation engine uses to describe why an item did not match. Common variance codes include: FEE_DEDUCTION (MDR or platform fee), TAX_DEDUCTION (TDS), TIMING_DIFFERENCE (amount correct but dates differ), AMOUNT_MISMATCH (genuine discrepancy), and ROUNDING (sub-rupee difference). A named variance is actionable; an unnamed exception requires investigation from scratch.

The transition point is typically 500–800 monthly transactions, or when any single reconciliation type (bank, TDS, or GST) consistently takes more than 2 days per month. Below 300 monthly transactions, a well-structured spreadsheet remains viable. Above 1,000 transactions, spreadsheet-based reconciliation produces systematic errors that cost more to fix than the software investment.

A reconciliation engine does not replace an ERP — it complements it. The ERP records transactions; the reconciliation engine verifies them against external sources (bank, TRACES, GSTN). Most ERPs have limited built-in reconciliation capability, especially for Indian-specific requirements like TDS section-level matching and GSTR-2B comparison. A reconciliation engine connects to the ERP via API or file export and handles the matching layer.

India has three simultaneous tax-at-source mechanisms that directly affect payment amounts: TDS (payer deducts before remitting), TCS (e-commerce operators collect before settling), and GST with ITC matching across government portals. Each creates a gap between the transaction amount and the received amount, requiring additional matching logic that generic accounting tools do not handle natively.

When a client pays an invoice of ₹1,00,000 for professional services under Section 194J, they deduct 10% TDS and remit ₹90,000. The bank credit is ₹90,000, the invoice is ₹1,00,000, and a TDS receivable of ₹10,000 should appear in Form 26AS on TRACES within 3–7 days of the deductor depositing the TDS challan. Matching all three — bank credit, invoice, and TRACES credit — is what makes Indian reconciliation structurally different.

Under the GST framework, ITC can be claimed in GSTR-3B only to the extent it appears in GSTR-2B, which is generated on the 14th of each month based on suppliers' GSTR-1 filings for the prior month. A supplier who files late causes the buyer's ITC to appear one or two months after the invoice date — creating a persistent mismatch between the purchase register and GSTR-2B.

Platform aggregation means a single bank credit represents multiple underlying transactions. A Razorpay settlement of ₹5,23,477 might represent 312 individual orders, minus MDR on each, minus GST on MDR, minus TCS at 1% on the merchant's gross sales. Reconciling this credit requires unpacking the settlement statement line-by-line — not matching the bulk credit to a revenue figure.

Reconciliation software is a standalone tool for a specific matching task — bank reconciliation or TDS matching. Reconciliation infrastructure is a configurable platform that handles all matching types (TDS, GST, bank, NACH, platform settlements) through a shared engine with industry-specific presets. Infrastructure scales across transaction types without requiring a separate tool for each.

Working capital leakage is the cash cost a business absorbs because reconciliation delay traps receivable cash longer than necessary. The structure is simple: from the date a customer pays to the date the supplier closes the invoice in books and the cash is operationally available for redeployment, every intervening day is a day the cash is invested in working capital at the supplier's cost-of-capital. For a ₹140 crore receivable base, an 18-day reconciliation cycle traps roughly ₹6.9 crore of cash relative to a 6-day cycle. At a 10% MCLR-anchored cost-of-capital, that is ₹46 lakh per year of pure leakage — not on any conventional P&L line, but real.

Days-recon-delay is the average number of days between the date the customer's payment hits the bank and the date the supplier's books reflect the invoice as fully closed against that payment. The measurement requires two timestamps per receivable: the bank credit date from the bank statement, and the invoice-closed date from the AR system. Average across the receivable base over a quarter. A mature reconciliation operation runs at 2 to 4 days. A typical mid-market manual operation runs at 14 to 22 days. The variance between mature and typical is the working-capital leakage band.

Two channels. Channel one: trapped cash. Until the receivable is closed, the cash sits in a reconciliation suspense state. Most treasuries cannot redeploy it into operating cash or short-term placements until books are clean. Channel two: financing substitution. Businesses on bank-financed working capital lines are paying MCLR-anchored interest on bank-borrowed cash that could have been displaced by the trapped receivable cash. The economic cost in both channels is the cost-of-capital on the trapped-days amount.

Use the realistic cost the business actually faces on its marginal funding source. For businesses on bank-financed working capital lines, this is the MCLR plus the spread — typically 9.5 to 11.5% currently. For businesses on operating cash without bank funding, use a conservative reinvestment rate — typically the AAA short-tenor placement rate of 6.5 to 7.5%. For businesses with active NCD or commercial paper programmes, use the average issuance yield. The point of the framework is to compute leakage at the business's actual marginal rate, not a theoretical risk-free rate.

Working capital leakage is the cross-cutting financing cost of all delays in the other classes. It compounds the TDS leakage (every day of TDS receivable stuck is a day of trapped cash), the ITC leakage (lagged ITC traps working capital until the supplier's GSTR-1 reflects), the fee-deduction leakage (disputed fees take 45-90 days to recover), the OEM short-pay leakage (90-180 day dispute cycles), and the NACH bounce recovery (where the recharge takes 30-60 days). In a quarterly leakage pack, the working-capital line is the financing-cost overlay on every other class.

GSTR-9 for a financial year is typically due by 31 December of the following year. For FY 2024-25, the due date is 31 December 2025. However, the GSTR-9 reconciliation process should begin in April after the FY close, not in December — starting early prevents last-minute ITC reversals and penalty exposure.

Download your Form 26AS from the TRACES portal (tdscpc.gov.in) and match each TDS entry against your receivable ledger. For mismatches, identify whether the deductor filed an incorrect PAN, wrong amount, or wrong section code. Contact the deductor to file a correction return (Form 26QB/27A) before March 31 — corrections filed after year-end affect the current assessment year, not the prior one.

Input Tax Credit for invoices of FY 2024-25 can be claimed up to the earlier of: the due date of the September 2025 GSTR-3B return (typically 20 October 2025), or the date of filing the annual return GSTR-9 for FY 2024-25. Reconciliation of GSTR-2B against the purchase register must be completed before this deadline to avoid permanent ITC loss.

Statutory auditors under the Companies Act require: bank reconciliation statements for all accounts as at March 31, TDS receivable reconciled to Form 26AS, accounts receivable and payable confirmation of balances, fixed asset register reconciled to book value, and GSTR-2B vs purchase register reconciliation. Gaps in any of these typically result in audit observations.

For a company with 5–10 bank accounts, 50+ active TDS deductors, and GST turnover above ₹5 crore, manual year-end reconciliation typically takes 10–15 working days. Automated matching with structured tooling compresses the matching phase to 1–2 days, leaving the team to focus on exception resolution and audit documentation.

Advertising services attract 10% TDS under Section 194J when the invoice includes creative work, content production, campaign strategy, or branded content. Section 194H at 2% applies only to pure commission on media buying — for example, a 15% agency commission retained from a media vendor payout. The Income Tax Act 2025 classifies advertising as a professional service under Section 402(28), confirming the 194J treatment for the full creative invoice.

Pure media buying commission arises when an agency earns a percentage from a media owner for placing ads — typically 2% to 15% of the media spend. This is 194H at 2%. Creative advertising services cover strategy, copy, artwork, film production, digital campaign build, and branded content. These are 194J at 10%. A single agency invoice often bundles both, which is the root cause of misclassification.

The conservative practice is to deduct 10% under 194J on the full creative and production component and 2% under 194H on the separately identified commission line. If the invoice does not split the lines, most Indian deductors apply 194J at 10% on the full amount, because under-deduction risk is higher than over-deduction risk. Agencies benefit from invoicing creative and commission as separate line items with distinct SAC codes.

Yes. Digital marketing agencies — running Google Ads, Meta Ads, SEO, content marketing, or performance campaigns — typically fall under 194J at 10% because the service involves strategy, creative, and analytics work, not pure commission. Pure ad-spend passthrough with a separate management fee is the only portion that may arguably be technical services under 194J at 2% or commission at 194H; the agency's own fee is 10% professional services in almost all engagement structures.

Media agencies that historically billed under 194H often continue to post TDS receivable at 2% in their ledger. When clients correctly deduct at 10% under 194J, Form 26AS shows excess credit against the ledger. Reconciliation requires reclassifying the expected rate in the ledger to 10%, matching against Form 26AS entries under section 194J, and clearing the 8% ledger gap. For an agency with ₹8 crore annual billing, this gap is ₹64 lakh in TDS receivable timing that shifts between quarters.

Yes, but with different priorities. AIS is now the primary statement and drives Section 143(1) intimation processing. Form 26AS is now supplementary but still contains TDS entries that feed into AIS Part B. The reconciliation sequence should be: first reconcile AIS against your books, then cross-check any TDS entries in 26AS against the corresponding AIS Part B entries. If the same TDS entry appears in both but with a discrepancy, the AIS figure is what the tax department will use in automated processing.

Use the Feedback mechanism in the AIS portal on the income tax e-filing portal (www.incometax.gov.in). Against the specific AIS entry, select the feedback type — options include 'Income is not mine', 'Income is already included in ITR', 'Income is partially correct', or 'Duplicate entry'. After submitting feedback, the information source (bank, deductor, or reporting entity) has 15 days to confirm or deny the correction. The TIS processed value updates once feedback is accepted, which changes the ITR prefill values.

After a taxpayer submits feedback on an AIS entry, the information source is notified and has 15 days to respond. If the source confirms the correction, the AIS entry is updated and the TIS processed value changes within a few days. If the source does not respond within 15 days, the feedback is deemed accepted by default. In practice, banks and large financial institutions tend to respond faster; individual deductors may take the full 15 days. File the ITR with TIS processed values after feedback is submitted — do not wait for the source response if the ITR deadline is approaching.

Yes. If your ITR reports income lower than the AIS reported figure for any category, the centralised processing system at CPC Bengaluru will issue a Section 143(1)(a) intimation flagging the discrepancy. Even if your ITR is factually correct and the AIS entry is wrong, the notice still issues. The resolution process requires submitting a response to the 143(1) notice with supporting documentation — such as the AIS feedback trail, books of account, or bank statements — explaining the variance. Early AIS reconciliation and feedback submission before filing reduces this risk significantly.

AIS data is not automatically final — it is the tax department's consolidated view based on information reported by third parties (banks, deductors, exchanges, registrars). A taxpayer can dispute AIS entries through the Feedback mechanism, and after the resolution cycle, the TIS processed value is used for ITR prefill. However, if a taxpayer files an ITR that conflicts with AIS without submitting feedback, the CPC uses the AIS figure in the 143(1) comparison. The practical implication: always reconcile AIS against your books before filing, and submit feedback on any inaccurate entries.

The process has five steps: (1) Download Form 26AS from TRACES for each PAN — or obtain the consolidated 26AS data via the TRACES API. (2) Export the TDS receivable ledger from the ERP (Tally, SAP, Oracle) showing TDS amounts by deductor TAN, section, and quarter. (3) Match each Form 26AS entry to the corresponding ledger entry on three dimensions: TAN, TDS section, and quarter. (4) Classify mismatches by type — short deduction, wrong section, wrong quarter, PAN error, or challan delay. (5) Raise deduction correction requests with clients for short-deduction or wrong-section mismatches, and track pending entries for the next quarter's Form 26AS update.

The five most common mismatch causes are: (1) Short deduction — the deductor applied a lower rate than required, often because the vendor has a lower-deduction certificate under Section 197 that the accounts team did not receive. (2) Wrong section — the deductor filed TDS under 194C instead of 194J or vice versa. (3) Cross-quarter credit — TDS deducted in Q3 but deposited after the Q3 cutoff date, appearing in Q4 in Form 26AS. (4) PAN error — deductor filed against an incorrect PAN, so the credit does not appear in the correct vendor's Form 26AS. (5) Challan delay — the deductor deposited TDS but TRACES has not yet reflected it due to bank processing lag.

This is common for large clients with multiple GST registrations or state-level operations. Each TAN appears as a separate entry in Form 26AS. The reconciliation must map each TAN to the specific invoices it relates to — typically by matching the TDS amount and section to invoice records by state or business unit. Automation handles this by maintaining a TAN-to-client master table that maps multiple TANs to a single client entity, aggregating TDS credits at the client level while preserving TAN-level audit detail.

TRACES does not provide a real-time API for third-party tools. The integration is typically through structured file uploads: the finance team downloads the 26AS XML or the TDS certificate file from TRACES and uploads it to the reconciliation platform. The platform then maps deductor TANs, matches at section and quarter level, and produces an exception report. TransactIG's TDS reconciliation module handles net-of-TDS receipt matching natively — linking the bank receipt (net of TDS) with the Form 26AS entry and the original invoice in a single match.

Manual TDS reconciliation for an organisation with 60 to 80 active deductors across multiple sections typically takes 3 to 5 staff days per quarter, and 2 to 3 weeks for year-end March closing. The time is spent downloading data, cleaning format mismatches, and resolving ambiguous entries. With automated matching, the structured ingestion and match run complete in hours. Finance teams shift from row-by-row matching to reviewing a pre-classified exception list — typically reducing active reconciliation time to 2 to 4 hours for the same deductor volume.

Cross-era TDS reconciliation is the process of matching TDS receivable and TDS payable records that span both the Income Tax Act 1961 and the Income Tax Act 2025 classification systems. From April 1, 2026 until the FY 2025-26 correction window closes on March 31, 2029, the same reconciliation run will need to handle transactions with old section codes (194C, 194J, 194I, and others) alongside transactions with new payment codes in the 1001 to 1092 range. Cross-era matching treats the equivalent pairs, for example Section 194J (professional fees) and payment code 1027 under Section 393(1) Sl. 6(iii).D(b), as referring to the same transaction type.

Under current TDS correction rules, a deductor can revise TDS returns for up to six years from the end of the relevant financial year. This means corrections to FY 2025-26 returns can be filed until March 31, 2029, with the revised statements retaining old section codes because they refer to transactions under the 1961 Act. Practically, finance teams should plan for cross-era reconciliation capability through at least FY 2028-29, covering Q4 FY 2025-26 credits that surface late, client correction statements that update old-code entries in Form 168, and Form 16A reissues for FY 2025-26.

Form 16A certificates for Q4 FY 2025-26 (January to March 2026 deductions) are due from the deductor by 15 June 2026. When that certificate arrives in May or June, it carries Section 194J or Section 194C in the section field because the underlying deduction occurred under the 1961 Act. Your TDS receivable ledger must book the credit against the original March invoice under the old section code, even though newer invoices in your ledger carry new payment codes. The reconciliation engine must treat both identifiers as matchable to the same vendor's receivable account.

Yes. Form 168, which replaces Form 26AS from April 1, 2026, will carry historical entries in their original classification. A deduction made in February 2026 and reported in the Q4 FY 2025-26 return will appear in Form 168 under Section 194C or 194J (or whichever old section applied), even though the deductee downloads Form 168 in June 2026. Entries for deductions from April 1, 2026 onwards will appear under the new payment codes. A single Form 168 download for a mid-size company will routinely show both code systems for at least two financial years.

Correction returns for FY 2025-26 and earlier years continue to use old section codes because the original return and the underlying deductions fall under the 1961 Act. A revision to a Q2 FY 2025-26 return filed in September 2027 will still reference Section 194J or 194C in the corrected entries. Correction returns for FY 2026-27 onwards use new payment codes. Finance teams preparing corrections during the transition must select the correct era by financial year, not by the calendar date the correction is being filed.

Form 131 is issued quarterly by every deductor, following the same cadence as Form 16A. For non-salary deductions under Chapter XX, the certificate must be issued within 15 days of the due date for filing the quarterly TDS return. For Q1 (April-June) the return is due by July 31 and the certificate by August 15. For Q4 (January-March) the return is due by May 31 and the certificate by June 15.

Late issuance or non-issuance of Form 131 attracts a penalty of ₹100 per day per certificate under the continuing default provisions of the Income Tax Act 2025, capped at the total TDS amount for the period. A deductor issuing 500 certificates that are 10 days late carries ₹5 lakh penalty exposure. The deductee can also escalate to the Assessing Officer if certificates are withheld beyond the due date.

Form 131 carries the new payment code (1001 to 1092) in place of the legacy section code (194C, 194J, etc.). It labels the period as Tax Year rather than Assessment Year. It introduces an enriched metadata block that includes the deductor's TAN, the PAN of the deductee, invoice or payment reference numbers where applicable, and the Form 168 reference line. The overall purpose — certifying TDS deducted and deposited — is unchanged.

No. The credit claim is validated against Form 168, not against Form 131. Form 131 serves as the deductor-issued certificate that supports the deductee's reconciliation — if a credit appears on Form 131 but not on Form 168, the deductee must escalate to the deductor for a correction statement. The income tax return credit schedule must match Form 168 entries, not Form 131 entries alone.

Form 131 is one of the primary supporting documents for TDS receivable balances during statutory audit under CARO 2020. Auditors typically require both Form 131 (deductor-issued) and Form 168 (government-issued) for every material TDS receivable. A mismatch between the two is a flagged exception that must be either resolved before sign-off or disclosed as an unreconciled item in the audit working papers.

Form 141 consolidates four legacy forms from April 1, 2026: Form 26QB (TDS on sale of immovable property under Section 194-IA), Form 26QC (TDS on rent exceeding ₹50,000 per month under Section 194-IB), Form 26QD (TDS on specified contractor and professional payments by individuals or HUFs under Section 194M), and Form 26QE (TDS on transfer of virtual digital assets under Section 194S). All four scenarios now file through a single challan-cum-statement.

Form 141 retains the 30-day filing window of the legacy forms. It must be filed within 30 days from the end of the month in which the deduction was made. For a property purchase transaction where the payment was made on May 10, 2026, Form 141 must be filed by June 30, 2026. Late filing attracts a fee of ₹200 per day under Section 234E, capped at the TDS amount.

No. Like the forms it replaces, Form 141 is designed for transactions where the deductor is typically an individual or HUF who does not hold a Tax Deduction Account Number. The PAN of the deductor is used as the identifier, and the PAN of the deductee is required. This allows property buyers, tenants, and small specified payers to meet their TDS obligation without registering for a TAN.

Form 141 is filed one filing per transaction per deductee for property and virtual digital asset scenarios, mirroring the Forms 26QB and 26QE rule. For recurring rent under Section 194-IB, the legacy one-time annual filing cadence is retained — a single Form 141 covers the full tenancy year. For Section 194M specified contractor payments, the 30-day-per-payment filing rule applies as it did under Form 26QD.

Each Form 141 filing generates a corresponding certificate — Form 131A for property, Form 131B for rent, Form 131C for specified contractor payments, and Form 131D for virtual digital assets. These sub-variants of Form 131 carry the payment code, transaction reference, and deductee PAN, and are downloadable from the e-filing portal after the Form 141 is processed. The deductor must issue the certificate to the deductee within 15 days of the Form 141 filing.

No. The Income Tax Department's return processing system validates TDS credit claims against Form 26AS, not against Form 16. If Form 16 shows ₹80,000 TDS but Form 26AS shows ₹60,000, and you claim ₹80,000 in your ITR, the system will generate a demand notice under Section 143(1) for the ₹20,000 difference. Claim only what appears in Form 26AS. If the employer's figure is correct, the resolution path is to ask the employer to file a correction return so Form 26AS updates before you file the ITR.

Contact the HR or payroll department and ask them to verify: (1) that the quarterly TDS return was filed on time for the relevant quarter; (2) that the challan BSR code and serial number in the return match the actual bank challan; and (3) that the PAN entered for you in the TDS return is correct. If any of these is wrong, the employer must file a correction return on TRACES. Provide them with the specific quarter and amount in question, and track the correction return status through TRACES.

Form 26AS typically updates within 3–7 business days after the correction return is processed by the TDS CPC. Check Form 26AS after 7 business days. If unchanged, ask the employer to confirm the correction return status on TRACES. You should verify Form 26AS is fully updated before filing your ITR — do not rely on the employer's timeline estimate alone.

Form 26AS is the government's authoritative record of TDS credits linked to a PAN. Form 16 is the employer's certificate of TDS deducted and deposited — a useful document, but secondary to Form 26AS for ITR purposes. When the two conflict, the Income Tax Department treats Form 26AS as the primary source. If Form 16 shows higher TDS than Form 26AS, the resolution must come from the employer correcting the underlying TDS return and challan data, not from accepting Form 16 at face value.

AIS (Annual Information Statement), accessible from the Income Tax e-filing portal at incometax.gov.in, provides transaction-level data reported by financial institutions: interest income from banks, dividend receipts, securities transactions, mutual fund activity, and foreign remittances. Form 26AS aggregates TDS by deductor TAN at quarterly level. For TDS reconciliation — specifically verifying whether employer TDS is credited — Form 26AS remains the relevant document. AIS is more useful for verifying completeness of income disclosure across all sources.

Form 168 takes effect from April 1, 2026, applying to Tax Year 2025-26 onwards. Transactions deducted from that date will appear in Form 168, not Form 26AS. Historical Form 26AS data for FY 2025-26 and earlier will remain accessible on the e-filing portal, but new tax year credits will only be reflected on the Form 168 statement.

Form 168 is a single unified annual statement that consolidates tax credit data previously split between Form 26AS and the Annual Information Statement. It includes TDS, TCS, advance tax, self-assessment tax, refunds, and high-value financial transactions in one document keyed to PAN. Form 26AS remained structured in Parts A through F with AIS as a separate statement; Form 168 merges the two into one statement with a unified schema.

Yes. Every entry in Form 168 carries a payment code (1001 through 1092 range) that identifies the nature of the payment under Chapter XX of the Income Tax Act 2025. This replaces the legacy section code field (194C, 194J, etc.) used in Form 26AS. For reconciliation, finance teams must map each payment code back to the equivalent legacy section during the cross-over year.

Form 168 is updated within 3 to 7 working days after a TDS challan is processed by the authorised bank and flows through the Tax Information Network. Quarterly return data — which adds deductee-level PAN and payment code details — appears within 7 to 10 working days after the return is processed by the TDS CPC. Tax Year 2025-26 March quarter data typically stabilises in late May or early June.

Yes. From Tax Year 2025-26, the Income Tax Department will match ITR TDS and TCS credit claims against Form 168 entries. Any credit claimed in the return that does not appear in Form 168 will be flagged and can trigger a demand notice. The credit must also match on PAN, payment code, Tax Year, and amount — not just on total aggregate.

Form 16A is a TDS certificate issued by the deductor—the party that deducted tax at source—to the deductee for non-salary payments. It is generated from the TRACES portal and covers deductions under sections such as 194J (professional fees at 10%), 194I (rent at 10% or 2%), 194C (contractor payments at 1% or 2%), 194A (interest at 10%), and 194H (commission at 5%). A manually prepared Form 16A is not valid for ITR purposes.

Form 16A must be issued within 15 days from the due date of filing the quarterly TDS return. For Q1 (April–June), the return is due 31 July and Form 16A is due by 15 August. For Q4 (January–March), the return is due 31 May and Form 16A is due by 15 June. Failure to issue Form 16A within the due date can attract a penalty of ₹100 per day under Section 272A.

Differences arise from three causes: (1) the deductor filed the TDS return under the wrong section code—for example, 194C instead of 194J—causing 26AS to show a different section than Form 16A; (2) the deductor's challan was not mapped correctly to the deductee's PAN in the TDS return; or (3) the deductor filed a partial return and the balance deduction is shown in a subsequent quarter's return. Each case requires a different remediation path.

The deductee should first check Form 26AS to confirm whether the deductor has deposited and filed the challan. If the TDS appears in 26AS but Form 16A has not been issued, the deductee can request the certificate directly from the deductor—referencing the TRACES-generated unique certificate number. If the TDS does not appear in 26AS, the deductor has likely not filed the quarterly return, in which case the deductee can only claim the credit by establishing the deduction through other documentation.

If the PAN on Form 16A does not match the deductee's actual PAN, the corresponding entry will not appear in the deductee's Form 26AS—making the credit unclaimed without correction. The deductee must request the deductor to file a TDS correction return via TRACES to correct the PAN. This must be done before the ITR is filed; credit cannot be claimed on the basis of a physical Form 16A with an incorrect PAN.

Manpower supply and staffing services fall under Section 194C, not 194J. CBDT's long-standing position treats the supply of warm bodies to work under the client's supervision as a work contract. The rate is 1% for individual or HUF vendors and 2% for companies, firms, and LLPs. The Income Tax Act 2025, effective 1 April 2026, codifies this by explicitly including manpower supply in the definition of work under Section 402(47).

The common misapplication traces to ERP vendor masters that tag any service invoice as professional fees. A ₹10,00,000 staffing invoice deducted at 10% instead of 2% creates an ₹80,000 over-deduction. The vendor must then either recover via a correction return on TRACES or claim the excess through the ITR refund cycle, which takes 6 to 14 months after financial year close.

The practical test is three-part: does the vendor supply named individuals under a Statement of Work with hourly or monthly bill rates, does the client direct and supervise the work, and does the vendor charge a markup over salary cost rather than a fixed project deliverable fee. If all three are yes, the contract is 194C manpower supply. If the vendor owns the outcome, carries delivery risk, and bills milestones, 194J may apply.

First, request the client to file a correction statement on TRACES changing the section from 194J to 194C and refiling with the correct rate. Processing takes 7 to 15 working days. If the correction is refused, the vendor can claim the full deducted amount in the ITR — the higher credit will match Form 26AS, and any refund is released once the return is processed, typically within 30 to 90 days of filing.

GST classification is independent of TDS section. Manpower supply attracts GST at 18% under SAC code 998513 regardless of whether the client deducts TDS under 194C or 194J. However, a 194J misclassification often signals that the client has recorded the expense under professional fees in the ledger, which can affect ITC eligibility checks and internal expense approval limits.

TRACES will maintain backward compatibility for historical returns (FY 2025-26 and earlier), which will retain old section codes. New transactions filed from April 1, 2026 onwards must use the new section codes under the Income Tax Act 2025. Attempting to file a Q1 FY 2026-27 return with old section codes (194C, 194J, etc.) is expected to generate validation errors on the updated TRACES portal.

The Income Tax Bill 2025 (Bill No. 11 of 2025), introduced in Lok Sabha on February 13, 2025, is scheduled to take effect from April 1, 2026, applying to FY 2026-27 and onwards. The Finance Act 2025 confirmed this implementation date. All TDS deductions, challan deposits, TDS certificates, and quarterly returns for transactions from April 1, 2026 must reference the new section numbering.

Form 26AS and the Annual Information Statement (AIS) will show the new section codes for transactions deducted on or after April 1, 2026. Historical entries (deductions up to March 31, 2026) will retain the old section codes. This means any cross-year reconciliation between FY 2025-26 receivables and FY 2026-27 Form 26AS entries will involve both code sets simultaneously.

No. TDS returns for FY 2025-26 and earlier remain valid under the old section numbers. There is no requirement to refile historical returns using new section codes. The new numbering applies only to transactions deducted on or after April 1, 2026. However, correction statements for FY 2018-19 through FY 2022-23 must be filed before March 31, 2026, as those years become time-barred after that date.

The Income Tax Bill 2025 is primarily a restructuring and consolidation exercise. TDS rates and thresholds are expected to carry over from the 1961 Act. For example, Section 393(1) Sl. 6(i) (replacing 194C) is expected to retain the 1%/2% rate (with D(a) for Individual/HUF deductees and D(b) for other deductees) and the ₹30,000 per-transaction and ₹1,00,000 aggregate thresholds. Confirm final rates at the Income Tax India e-filing portal once the Act is formally notified.

Section 194T mandates TDS at 10% on salary, remuneration, commission, bonus, and interest paid by a firm to its partners. The threshold is ₹20,000 in aggregate during a financial year. If the partner does not furnish a PAN, the rate escalates to 20% under Section 206AA.

Section 194T is effective from April 1, 2026, applying to all payments made to partners from Tax Year 2026-27 onwards. Under the Income Tax Act 2025, it maps to Section 393(3), Table Serial No. 7, with Payment Code 1067. Firms must begin deducting from the first payment that causes the aggregate to cross ₹20,000.

Yes. Section 194T applies to every firm as defined under the Indian Partnership Act, 1932, and to every Limited Liability Partnership under the LLP Act, 2008. Both traditional partnership firms and LLPs must deduct TDS on partner salary, remuneration, interest, commission, and bonus exceeding the ₹20,000 annual threshold.

The firm becomes an assessee-in-default under Section 201(1), liable to pay the TDS amount from its own funds plus 1% interest per month from the date the TDS was deductible. Additionally, the entire partner remuneration or interest expense is disallowed under Section 40(a)(ia) at 30% of the payment amount, increasing the firm's taxable income.

Under the Income Tax Act 2025, Section 194T deductions are reported in Form 140, which replaces the earlier Form 26Q. The TDS certificate issued to partners shifts from Form 16A to Form 131. Quarterly filing deadlines remain unchanged: 31 July, 31 October, 31 January, and 31 May for the respective quarters.

Yes. Section 194C of the Income Tax Act 1961 — which governs TDS on contractor and sub-contractor payments — is replaced by Section 393(1) Sl. 6(i) of the Income Tax Act 2025, effective April 1, 2026. The rates (1% for individuals/HUF, 2% for companies/firms) and thresholds (₹30,000 per transaction or ₹1,00,000 aggregate per year) are expected to remain the same. However, all challans, Form 16A certificates, and quarterly returns (26Q) for deductions made from April 1, 2026 must reference Section 393(1) Sl. 6(i), not Section 194C.

Effectively yes. From April 1, 2026, your reconciliation system must maintain a dual-code reference: old section codes for any transaction deducted up to March 31, 2026 (which will continue to appear in Form 26AS and TDS certificates for those periods), and new Section 393 sub-clause codes for all transactions from April 1, 2026 onwards. For any cross-year reconciliation — comparing FY 2025-26 receivables against FY 2026-27 credits — both code sets will appear in the same matching run.

Bank NEFT narrations for TDS challan payments — which typically read 'OLTAS TDS 194J' or 'TDS ON PROF FEES 194J' — are not standardised and depend on the originating ERP or payment system. Banks do not automatically update narration formats when legislation changes. After April 1, 2026, narrations may continue to show old section codes if the originating system has not been updated, or may show the new codes if it has. This makes bank narration an unreliable source for section code identification post-transition — reconciliation systems should rely on the TRACES return data rather than bank narrations for section classification.

Q4 FY 2025-26 (January–March 2026) TDS returns have a filing deadline of May 31, 2026 for Form 26Q and 27Q. These returns cover deductions made up to March 31, 2026 and must use old section codes (194C, 194J, etc.) because they relate to transactions under the old Act. Even though they are filed after April 1, 2026, they retain old section numbering. The new Section 393 codes apply only to deductions made on or after April 1, 2026.

For organisations that receive TDS under multiple sections — common for IT services companies receiving TDS under both 194C (project work) and 194J (consulting) — the reconciliation change is significant. Before April 1, 2026, the TDS receivable ledger categorises credits by 194C and 194J. After April 1, new credits will arrive categorised under 393(1) Sl. 6(i) and 393(1) Sl. 6(iii). A ledger that cannot store both code sets simultaneously will show reconciliation gaps even when the underlying credits are correct. The mapping table must be maintained at the ledger level, not just in the return filing system.

Section 194I of the 1961 Act — TDS on rent — maps to Section 393(1) Sl. 2(ii) of the 2025 Act. The rate structure is preserved: 10% for rent of land, building, or furniture; 2% for rent of plant, machinery, or equipment. The annual threshold of ₹2,40,000 also continues. From April 1, 2026, lessors should expect their Form 26AS rent credits to show '393(1) Sl. 2(ii)' in place of '194I'. For real estate-heavy organisations and large landlords, this also affects the rent-roll reconciliation against tenant-side deductor returns.

The principle of higher TDS for specified non-filers — at twice the applicable rate or 5%, whichever is higher — is retained in the 2025 Act, but it sits within a different section number. Reconciliation systems that maintain a 'specified person' flag against the deductee master should keep the flag intact across the transition, because the underlying compliance check (TRACES Compliance Check API) remains the same lookup. The rate-doubling logic must continue to apply on top of whichever Section 393 sub-clause is the base rate.

No. Section 195 of the 1961 Act, which governs TDS on payments to non-residents (royalty, fees for technical services, interest, dividends), maps to a separate section in the 2025 Act — typically referenced as Section 393(2) — not Section 393. This is because non-resident TDS depends on Double Taxation Avoidance Agreement (DTAA) treaty rates and PE/withholding-certificate logic that are structurally different from the resident TDS framework. Reconciliation systems should maintain Section 195 / Section 393(2) as a parallel track to the Section 393 framework, not collapse them into one.

Pull Form 26AS as separate financial-year files: one for FY 2025-26 (which will continue to carry old section codes for that year's entries even when downloaded after April 1, 2026), and one for FY 2026-27 (which carries the new Section 393 sub-clauses). Tag each row with the deduction date and let your matching engine route on date, not on code. A single combined-year pull can mix old and new codes in the same dataset and confuse rate validation if the matching engine assumes one code set.

No. Form 16A certificates for FY 2025-26 are issued based on Q4 FY 2025-26 quarterly returns (filed by May 31, 2026 with old section codes) and continue to reflect old section codes — 194C, 194J, 194I, etc. — because the underlying deduction event was governed by the 1961 Act. Deductors do not need to re-issue or re-stamp historical certificates. The new Section 393 codes apply only to certificates for deductions made on or after April 1, 2026.

Tax Year refers to the period in which income is earned, matching what was previously called Financial Year. Assessment Year was the following year — the year in which that income was assessed. Under the Income Tax Act 2025, the two-label system ends. FY 2025-26 (April 1, 2025 to March 31, 2026) becomes Tax Year 2025-26. What would have been AY 2026-27 under the 1961 Act is simply Tax Year 2025-26 under the new act.

Yes. The Tax Year under the Income Tax Act 2025 runs from April 1 to March 31, matching the existing Financial Year. There is no change in the fiscal calendar. Tax Year 2025-26 means the period from April 1, 2025 to March 31, 2026. The change is purely terminological — one label replaces the two labels used in the 1961 Act.

All new forms under the Income Tax Act 2025 reference Tax Year. This includes Form 168 (replacing Form 26AS), Form 131 (replacing Form 16A), Form 141 (the unified challan-cum-statement), and the updated ITR forms from Tax Year 2025-26 onwards. Historical filings and Form 26AS downloads for periods up to FY 2025-26 retain the Assessment Year label.

Finance systems should maintain a dual-label view during the cross-over period. A TDS receivable booked against AY 2025-26 (FY 2024-25) must be reconcilable against a Form 26AS labelled for that Assessment Year, while new bookings for FY 2026-27 must be reconcilable against Form 168 labelled as Tax Year 2026-27. A translation table that converts AY to the corresponding Tax Year prevents mismatches in cross-period trend reports and audit working papers.

Yes. From Tax Year 2025-26 onwards, the ITR forms drop the Assessment Year field and use Tax Year. A taxpayer filing the return for income earned in FY 2025-26 (what would previously have been AY 2026-27) now selects Tax Year 2025-26 on the portal. The filing due dates remain unchanged — July 31 for non-audit cases and October 31 for audit cases, assuming no deadline extensions.

Tour operators must collect TCS at 5% on overseas tour packages for amounts up to ₹7 lakh per individual per financial year. Above ₹7 lakh, the rate increases to 20%. Effective April 2025, the Finance Act 2025 raised the higher slab threshold to ₹10 lakh for tour packages, with 20% applying above that amount. TCS must be deposited by the 7th of the following month.

The Reserve Bank of India permits individuals to remit up to USD 250,000 per financial year under the Liberalised Remittance Scheme. This covers education, medical treatment, overseas investments, gifts, and general remittances. The TCS obligation under Section 206C(1G) applies on top of the LRS limit — banks and forex dealers must collect TCS at applicable rates regardless of whether the individual has exhausted their LRS quota.

The forex dealer must maintain a running total of remittances per PAN per financial year. The first ₹7 lakh in remittances is exempt from TCS for most categories. Once cumulative remittances cross ₹7 lakh, TCS at the applicable rate (0.5%, 5%, or 20% depending on purpose) must be collected on amounts above the threshold. This requires a PAN-indexed ledger updated with every transaction, which becomes unmanageable beyond 200-300 active remitters without a system.

Yes. TCS collected under Section 206C(1G) appears in the buyer's Form 26AS and Annual Information Statement (AIS). The buyer claims credit against their total income tax liability when filing their ITR. If the TCS exceeds the tax liability, the excess is refundable. The credit is available only if the collector has deposited the TCS and filed Form 27EQ correctly with the buyer's PAN.

The tour operator faces interest at 1% per month under Section 206C(7) from the date TCS should have been collected to the date of actual deposit. Additionally, non-collection can trigger prosecution under Section 276BB. The penalty for late filing of Form 27EQ is ₹200 per day under Section 234E, capped at the total TCS amount for the quarter.

Section 206C(1F) requires sellers to collect TCS at 1% on the sale of motor vehicles where the value exceeds ₹10 lakh. This applies to every qualifying sale — there is no aggregate annual threshold. The seller must deposit the TCS with the government by the 7th of the month following collection and report it in Form 27EQ for the relevant quarter.

Section 206C(1H) was abolished effective April 1, 2025 by the Finance Act 2025. It has been replaced by expanded TDS provisions under Section 194Q. However, transactions that occurred before April 2025 still require reconciliation, and any TCS collected under 206C(1H) for prior periods must be matched against Form 27EQ filings and buyer credits in Form 26AS.

If a seller fails to collect TCS, the buyer is not absolved of the tax liability. However, the seller faces prosecution under Section 276BB of the Income Tax Act for non-collection. Additionally, interest at 1% per month is levied from the date the TCS should have been collected to the date of actual deposit under Section 206C(7).

Match each vehicle sale above ₹10 lakh against three data points: the TCS amount collected from the buyer at the time of sale, the challan deposit confirming remittance to the government, and the corresponding entry in Form 27EQ. Common mismatches include wrong buyer PAN, incorrect section code (206C(1F) vs 206C(1H)), and late challan deposits that shift the credit to the next quarter.

Form 27EQ follows the same quarterly deadlines as TDS returns: Q1 (April–June) by July 31, Q2 (July–September) by October 31, Q3 (October–December) by January 31, and Q4 (January–March) by May 31. Late filing attracts a fee of ₹200 per day under Section 234E, capped at the total TCS amount.

Form 15CB is mandatory when the remittance is taxable in India and exceeds ₹5 lakh in aggregate in a financial year under a single remittance purpose code, or where a treaty benefit is being claimed. The CA certifying Form 15CB must assess the nature of income, the applicable DTAA rate, and whether TDS has been correctly computed. Form 15CB must be uploaded on the income tax portal before Part C of Form 15CA is filed.

Payments for use of software — classified as royalty under Section 9(1)(vi) — are subject to TDS under Section 195 at 10% plus surcharge and cess (effective rate approximately 10.92% for corporate non-residents in many cases). However, if the applicable DTAA between India and the payee's country provides a lower rate, and the payee submits a Tax Residency Certificate and Form 10F, the treaty rate applies. Some DTAA articles define software payments as business profits rather than royalties, which may eliminate withholding entirely.

Section 195 payments must be reported in Form 27Q, which is the quarterly TDS return for payments other than salaries made to non-residents. Form 27Q is filed quarterly with due dates of 31 July, 31 October, 31 January, and 31 May. This is separate from Form 26Q (resident payments) and Form 24Q (salaries). The 15CA acknowledgement number must be referenced in the Form 27Q filing.

Under Rule 37BB, the authorised dealer bank (AD bank) is required to receive the 15CA acknowledgement number before processing any covered foreign remittance. Remittances made without Form 15CA — where it is required — expose the remitter to prosecution under Section 276B for failure to comply with TDS provisions, as well as potential demand for TDS not deducted and interest under Section 201(1A) at 1.5% per month.

There is no specific retention period prescribed solely for 15CA/15CB records, but since they relate to TDS compliance under Section 195, the standard 7-year retention period applicable to financial records under the Companies Act 2013 and the Income Tax Act applies. The records must be available for production during any scrutiny assessment or TDS survey, which can be initiated up to 6 years after the relevant assessment year.

All critical migration steps must be completed before the first payroll cycle and the first vendor payment cycle of April 2026. The hard deadline is the April 7, 2026 challan deposit due date for March TDS deductions, which will be the final challan window using old section codes for most companies. April payroll TDS and the first post-April-1 vendor payment must deposit under new payment codes, so ERP master data, GL codes, challan interface configuration, and TRACES integration must all be ready by March 31, 2026. Reconciliation configuration should be tested on dummy data at least one week before go-live.

Correction windows for FY 2018-19 through FY 2022-23 become time-barred on March 31, 2026 under the six-year correction rule. Any TDS mismatch or incorrect entry in those years must have a correction statement filed by that date. FY 2023-24, FY 2024-25, and FY 2025-26 correction windows remain open beyond April 1, 2026 but must be handled through the legacy classification system. Before the migration, run a full correction audit for FY 2018-19 to FY 2022-23, file statements for any outstanding errors, and confirm TRACES acceptance receipts are received before close of business on March 31, 2026.

Sections 206AB and 206CCA, which imposed higher TDS and TCS rates on non-filers of income tax returns, are abolished under the Income Tax Act 2025. Any ERP vendor master flag, compliance screening workflow, or monthly non-filer check against the compliance portal should be decommissioned effective April 1, 2026. Before decommissioning, retain a read-only archive of 206AB status history for FY 2025-26 and earlier years, because correction statements for those years, which can be filed until 2029, still require the old higher rate where it applied. The active filter logic, however, can be switched off on April 1.

For a mid-size Indian enterprise with 80 to 200 active vendors and a single-entity structure, a TDS cut-over weekend typically runs 16 to 24 hours of elapsed time across ERP master data updates, GL code additions, reconciliation system configuration, and end-to-end test runs. For group entities with multiple legal entities and shared services, cut-over extends to a full weekend of 40 to 48 hours. The critical path is return preparation utility testing: the updated FVU validator for Q1 FY 2026-27 returns must be installed, tested on a sample file, and confirmed working before the first live challan deposit in April.

It is operationally needed, not legally mandated. No provision of the Income Tax Act 2025 requires a deductor to run both legacy and new classifications in parallel. Dual-mode reporting is required because the same finance team in FY 2026-27 is simultaneously responsible for current-period filings under the 2025 Act (new payment codes) and correction statements for FY 2025-26 and earlier under the 1961 Act (old section codes). Reconciliation systems that cannot produce both classifications from a single source of truth will force the team to maintain two parallel sets of records, which creates audit risk and close-of-book delays.

Download Form 26AS from TRACES or the Income Tax e-filing portal and compare each entry against your TDS receivable ledger. If an expected credit is absent or shows a different amount, ask your deductor to log into TRACES and verify the challan BSR code, serial number, and deposit date against the OLTAS record. A mismatch between the TDS return entry and the OLTAS challan record is confirmed when the challan status on TRACES shows 'unmatched'.

After the deductor files a C2 correction return on TRACES and it is accepted, Form 26AS typically updates within 3–7 business days. The exact timing depends on TRACES processing load, which is higher near quarterly filing deadlines. Check Form 26AS after 7 business days and, if unchanged, verify on TRACES that the correction return status shows 'processed'.

Claiming TDS credit that is absent from Form 26AS is inadvisable. The Income Tax Department's processing system validates ITR claims against Form 26AS data, and a discrepancy will generate a demand notice under Section 143(1). The safer approach is to wait for Form 26AS to update after the deductor files the correction return, or to write to the jurisdictional Assessing Officer with supporting evidence — deductor's challan, TDS certificate, and bank confirmation — before filing the ITR.

A C2 correction return is filed on TRACES by the deductor to correct challan details in an already-filed TDS return. It is required when the BSR code (the 6-digit branch code of the bank where TDS was deposited) or the challan serial number was entered incorrectly in the original return. The C2 correction links the TDS return entry to the correct challan record in OLTAS, allowing Form 26AS to update for the affected deductees.

The deductor is solely responsible for filing the correction return on TRACES. The deductee cannot access or modify the deductor's TDS return. The deductee's role is limited to identifying the mismatch through Form 26AS, notifying the deductor with specific details (expected amount, TAN, quarter, section), and following up until TRACES shows the correction return as processed. Documenting all communication is recommended if the deductor is unresponsive.

TDS deducted during March must be deposited by 30 April 2026. This is an exception to the standard rule — for all other months (April through February), TDS must be deposited by the 7th of the following month. The extended deadline for March applies to both government and non-government deductors.

Section 234E imposes a fee of ₹200 per day for each day the TDS return is filed after the due date. The fee is capped at the total TDS amount for that quarter — so it cannot exceed what was deducted. For a quarterly return with ₹5 lakh TDS and a 30-day delay, the Section 234E fee would be ₹6,000 (30 days x ₹200). This is in addition to any interest payable under Section 201(1A).

Form 16A must be issued within 15 days of the due date for filing the TDS return for that quarter. For Q1 (April-June), the return is due 31 July, so Form 16A must be issued by 15 August. For Q4 (January-March), the return is due 31 May, so Form 16A must be issued by 15 June. Form 16 for salary TDS has a different deadline — 15 June following the end of the financial year.

Section 201(1A) charges interest at 1.5% per month (or part of a month) from the date TDS was deducted to the date it is actually deposited. If TDS of ₹1 lakh deducted on 15 April is deposited on 20 June — a delay of two months and a part month — interest would be 1.5% x 3 months = 4.5%, i.e., ₹4,500. This is separate from Section 234E penalties for late return filing.

There are three structured reconciliation windows in the TDS compliance calendar: (1) after each quarterly return — compare Form 26AS entries for the quarter against the TDS receivable ledger; (2) after Form 16A issuance — confirm deductee certificates match your books; (3) March year-end close — reconcile full-year TDS receivable against Form 26AS and AIS before finalising the balance sheet. Reconciling only at year-end leaves discrepancies unresolved past the deductor's quarterly correction deadline.

Log into TRACES (https://www.tdscpc.gov.in) with the deductor's TAN credentials. Download the original accepted TDS return in FVU format from the 'Download Conso File' section. Open the file in NSDL's RPU (Return Preparation Utility), locate the incorrect PAN row, and correct the PAN. Validate the file using the FVU tool, which generates a corrected .fvu file. Upload this file on TRACES as a C1 correction. After submission, TRACES will process the correction within 3–7 business days. Form 26AS for the deductee with the corrected PAN will update once processing is complete.

Yes. There is no time limit that prevents filing a correction return after the original has been processed. Even if Form 26AS has already updated with the original return data, a correction return can be filed to fix the error. After the correction is processed (3–7 business days), Form 26AS will update to reflect the corrected information — crediting the correct PAN and removing the credit from the incorrect one in the case of a C1 correction.

There is no statutory limit on the number of correction returns that can be filed for a single original TDS return. Each correction return builds on the most recently processed version (not on the original). If a C1 correction has been processed, the next correction must be filed against the C1 version, not the original. This means each correction must be filed and processed sequentially — two corrections cannot be uploaded simultaneously and processed in parallel.

Filing a correction return itself does not attract a penalty. If the original TDS return was filed on time, no late-filing fee under Section 234E applies to the correction. However, if the original return was filed late, the ₹200/day Section 234E penalty applied from that point and is not reversed by the subsequent correction. The correction addresses the data errors in the return but does not affect penalties already assessed for the original late filing.

NSDL RPU (Return Preparation Utility) is a Java-based tool provided by NSDL TIN for preparing and validating TDS returns and correction returns. It is downloaded from the TRACES portal or the NSDL TIN website. To prepare a correction, download the consolidated statement file (Conso file) from TRACES for the quarter to be corrected, open it in RPU, make the required changes, and then validate the output using the FVU (File Validation Utility) tool. The FVU produces a .fvu file that is then uploaded to TRACES for submission.

No. TDS correction statements for FY 2018-19 through FY 2022-23 become permanently time-barred after March 31, 2026 under the limitation period applicable to Section 200 of the Income Tax Act 1961. After this date, the TRACES portal will not permit correction statement filing for these years. Any challan mismatches, PAN errors, or amount discrepancies for these years that are not corrected by March 31, 2026 become irrecoverable from a TDS compliance standpoint.

Uncorrected TDS mismatches for time-barred years can result in demand notices under Section 200A for short deduction, interest under Section 201(1A) at 1.5% per month from the date of deduction to the date of payment, and disallowance of the underlying expense under Section 40(a)(ia) for contractor/professional fee payments. For amounts that were deducted but not deposited or deposited with incorrect PAN, the deductee may also be unable to claim the TDS credit in their income tax return.

Download your Form 26AS or Annual Information Statement (AIS) from the Income Tax e-filing portal or TRACES. Compare the TDS entries against your TDS receivable ledger for each financial year. Entries that appear in your ledger but not in 26AS, or where amounts differ, indicate a potential mismatch requiring a correction statement from the deductor. For FY 2018-19 through 2022-23, any deductor-side correction must be filed before March 31, 2026.

FY 2023-24 and FY 2024-25 correction windows remain open after March 31, 2026. You can file correction statements for these years through TRACES subject to the applicable limitation period. Q4 FY 2025-26 returns and correction statements will also be available. Only the five years from FY 2018-19 through FY 2022-23 are closing on March 31, 2026.

A deductee cannot directly file a correction statement — only the deductor (the party that deducted and deposited the TDS) can do so through TRACES. However, the deductee can raise a grievance on the income tax e-filing portal under the 'TDS Mismatch' category, which can trigger a communication to the deductor. For FY 2018-19 through 2022-23, the deductee should contact the deductor immediately given the March 31, 2026 deadline.

Section 154 rectification can be filed within 4 years from the end of the financial year in which the original assessment order was passed. For example, an assessment order for AY 2023-24 passed on March 31, 2024 can be rectified until March 31, 2028. The rectification must involve a mistake apparent from the record, meaning the AO should be able to verify the TDS credit from Form 26AS or the deductor's TDS return without further inquiry.

CBDT Instruction No. 5/2013 directs Assessing Officers to verify TDS credit by examining the deductor's TDS return, the challan payment details, and the deductee's bank statement showing the net-of-TDS receipt. If the AO is satisfied that TDS was genuinely deducted, credit must be granted even if Form 26AS does not show it. This instruction operationalises the Section 205 bar, which prohibits the department from recovering the same tax from the deductee when the deductor has already deducted it.

An updated return filed within 12 months of the end of the relevant assessment year attracts an additional tax of 25% on the aggregate of tax and interest payable. If filed between 12 and 24 months, the additional tax rises to 50%. For example, an updated return for AY 2024-25 filed by March 31, 2026 attracts 25% additional tax, while one filed by March 31, 2027 attracts 50%. An ITR-U cannot be filed if the total tax liability decreases.

Yes. Section 205 of the Income Tax Act bars the department from demanding the same tax from the deductee if TDS was deducted by the deductor. The obligation to deposit lies solely with the deductor, and the deductee cannot be penalised for the deductor's default. CBDT Instruction No. 5/2013 reinforces this by directing AOs to verify and grant credit based on documentary evidence including bank statements and invoices.

A demand notice issued under Section 143(1) for disallowed TDS credit must be responded to within 30 days from the date of service. The response is filed on the Income Tax e-filing portal under the 'Response to Outstanding Demand' section. If the demand is not addressed within 30 days, interest under Sections 234B and 234C begins to accrue on the outstanding amount, and the AO may initiate recovery proceedings.

Section 200A empowers the Income Tax Department to process a TDS return and send an intimation raising a demand for short deduction, interest under Section 201(1A) at 1% per month from deduction date to deposit date (or 1.5% per month from deposit date to payment date), late filing fees under Section 234E at ₹200 per day, or adjustments for PAN or challan mismatches.

Section 201(1A) prescribes interest at 1% per month (or part of a month) from the date TDS was deductible to the date it was actually deducted, and 1.5% per month from the date TDS was deducted to the date it was deposited. Both components accumulate separately and are shown as distinct line items in the Section 200A intimation.

Section 234E imposes a fee of ₹200 per day for each day of delay in filing the TDS return, subject to a maximum equal to the TDS amount itself. The fee accrues from the due date of the quarterly TDS return — typically 31 July, 31 October, 31 January, and 31 May for the respective quarters.

A challan mismatch arises when challan details entered in the TDS return — BSR code, challan serial number, deposit date, or amount — do not match OLTAS records. Rectification requires filing a correction statement through TRACES. After the correction is processed, typically within 3–7 working days, the mismatch is resolved and the demand is revised.

Yes. Where TRACES records show correct deduction and deposit but the intimation is erroneous, the deductor may file a rectification application under Section 154 on the income tax portal. The rectification must be filed within 4 years from the end of the financial year in which the intimation was issued.

TDS is deducted at the time of exercise (vesting and exercise are often contemporaneous in Indian ESOP structures). Under Section 17(2) read with Section 192, the perquisite arises when the employee exercises the option and acquires shares. TDS is not deducted at grant (since no benefit has transferred) or at sale (capital gains tax applies at that stage, not TDS). The taxable perquisite value is (FMV on date of exercise minus grant price) multiplied by the number of shares.

For shares of unlisted companies, the Income Tax Rules require that FMV be determined by a registered merchant banker as on the date of exercise. The merchant banker issues a valuation certificate using SEBI-recognised methods (typically discounted cash flow or comparable company multiples). The valuation certificate date must be within 180 days of the exercise date. For listed companies, FMV is the average of the opening and closing price on NSE or BSE on the exercise date.

If an employee has vested ESOPs but leaves without exercising them, the unvested options lapse and there is no TDS obligation. For vested but unexercised options, the treatment depends on the ESOP plan: most plans lapse unvested and unexercised options within 30 to 90 days of resignation. If the employee exercised options before resignation, the TDS would already have been deducted and deposited at the time of exercise. The employer's TDS liability ends at the point of departure.

Form 16 Part B must show the ESOP perquisite value under the head 'Value of perquisites under Section 17(2)'. The perquisite value is added to gross salary for the purpose of computing the employee's total income and TDS. Employers must ensure the perquisite value is reflected in both the TDS return (Form 24Q) for the relevant quarter and in Form 16 Part B issued at year-end. Omitting ESOP perquisite from Form 24Q creates a mismatch when the employee files their ITR.

When a foreign parent company grants ESOPs to employees of its Indian subsidiary, the TDS obligation falls on the Indian employer under Section 192. The Indian entity is treated as having derived a benefit from the parent (the share issuance), and it must include the perquisite value in the employee's salary and deduct TDS accordingly. If the Indian entity does not have a formal arrangement with the parent for cost reimbursement, the tax department may still hold the Indian entity liable for TDS on the perquisite.

Applications are filed online through the TRACES portal (https://www.tdscpc.gov.in) using Form 13. The applicant submits projected income, estimated total tax liability, existing TDS and advance tax payments, and the TDS sections for which a lower rate is sought. The application is reviewed by the Assessing Officer (AO) of the applicant's jurisdictional income tax office. If satisfied, the AO issues the certificate specifying the lower rate and the sections to which it applies. The certificate is valid for the financial year stated in it—not beyond.

The statutory deadline for the AO to respond is 30 days from the date of application. In practice, processing takes 4–8 weeks, particularly at peak periods before April and October when filings are highest. Applications submitted in February or March for the next financial year face longer queues. Applicants expecting a new-year certificate should apply by January to allow processing time.

No. A deductor who applies a lower TDS rate without a valid Section 197 certificate on file remains liable for the difference between the standard rate and the lower rate applied, plus interest under Section 201. The deductor must verify the certificate on TRACES before the first payment at the reduced rate, and should retain a copy of the certificate with the date of TRACES verification. If the certificate is later found to be invalid, the deductor bears the shortfall risk.

Form 26AS reflects the rate actually deducted, which will be the lower certificate rate rather than the standard section rate. A recipient holding a 194J certificate at 2% (instead of the standard 10%) will see 2% entries in Form 26AS Part A. The TDS receivable ledger in the recipient's books must be updated to record the expected TDS at the lower rate—failing to do this creates a phantom shortfall in the ledger that takes time to investigate and write off.

Yes. The certificate issued by the AO is presented by the recipient to each deductor separately. Each deductor independently verifies the certificate on TRACES using the certificate number before applying the lower rate. There is no limit on the number of deductors to whom the same certificate can be furnished, provided the certificate's aggregate amount limit is not exceeded across all deductors in the financial year.

Section 194J applies to professional fees and technical services at 10% (or 2% for technical services). Section 194C applies to contracts and sub-contracts at 1% for individuals/HUFs and 2% for others. The correct section depends on the nature of engagement. A professional service engagement — legal, consulting, medical, architectural — falls under 194J. If a client misclassifies and deducts under 194C, the rate difference creates a mismatch between TDS deducted and TDS expected in the recipient's books.

If a deductor files their quarterly TDS return after the due date, the TDS entry will appear in the recipient's Form 26AS only after the return is processed. This means the recipient's 26AS may be incomplete at the time of advance tax computation or ITR filing. The recipient can claim the TDS credit in the ITR even if 26AS is not yet updated, but the refund or tax payable amount will be subject to verification against the deductor's filing.

An employee who joins a new employer mid-year must disclose previous salary and TDS deducted by the former employer by submitting Form 12B to the new employer. The new employer aggregates the total income for the year and deducts TDS under Section 192 on the balance. Without Form 12B disclosure, the new employer deducts TDS only on their portion, resulting in total annual TDS that is less than required, and the employee faces a demand when the ITR is processed.

No. A 26AS entry with no matching income in the recipient's books typically indicates a deductor error — they may have entered the wrong PAN and the TDS belongs to a different entity. The recipient should not claim this credit and should report the discrepancy to the deductor for correction through a TRACES correction statement. Claiming credit for TDS on income not recorded in books can trigger scrutiny during ITR processing.

There is no regulatory deadline for internal reconciliation, but practical reconciliation must be complete before the ITR due date — 31 July for non-audit cases and 31 October for audit cases. For companies, the audit ITR deadline is 31 October. Reconciliation performed after ITR filing cannot change the filed return without a revised return, which must be filed before 31 December of the assessment year.

No. CBDT Circular No. 23/2017 clarifies that TDS under Chapter XVII-B of the Income Tax Act is not deductible on the GST component of an invoice. TDS must be computed only on the base value (the amount before GST). This applies to all TDS sections including 194C, 194J, 194H, and 194I.

The excess TDS gets deposited against the vendor's PAN and appears in their Form 26AS. However, the excess amount represents tax deducted on the GST portion — which the vendor already pays to the government separately. The vendor cannot claim the excess TDS as a credit against income tax, making it an erroneous entry that requires a correction return from the deductor.

File a correction return (Form 26Q or 27Q as applicable) through TRACES. In the correction, revise the TDS amount to reflect deduction on the base value only. If the excess TDS has already been deposited, you can adjust the excess in a subsequent challan or claim a refund through TRACES. The vendor's Form 26AS will update once the correction is processed — typically within 7 to 10 working days.

Under RCM, the buyer pays GST directly to the government rather than to the vendor. The vendor receives the full base invoice amount without a GST charge on the invoice. TDS is still computed on the base invoice value only. Even if the buyer is paying GST separately under RCM, the TDS computation does not change — it remains on the contractual service value.

The deductor should ask the vendor to issue a revised invoice that separately discloses the base value and the GST component. If the vendor cannot provide a breakup, the deductor should compute TDS on the estimated base value (total divided by 1 plus the applicable GST rate). For an 18% GST invoice of ₹1,18,000, the base value is ₹1,00,000 and TDS should be deducted on ₹1,00,000.

Under Section 206AA, if a deductee fails to furnish a valid PAN, TDS must be deducted at the highest of three rates: the rate specified in the relevant section (e.g., 2% under 194C or 10% under 194J), the rate in force under the Finance Act, or 20%. For most vendor payments, the 20% floor applies. This rate applies per transaction — there is no threshold below which 206AA can be ignored.

If a vendor's PAN becomes operative after Aadhaar linking and TDS was already deducted at 20% under Section 206AA, the deductor cannot reverse the deduction retroactively for past payments. Going forward, once the PAN is operative and validated on TRACES, the correct section rate applies. The vendor can claim the excess TDS as a refund when filing their income tax return, provided the deductor has quoted the PAN correctly in the filed TDS return.

TRACES provides a 'PAN Verification' facility under the 'Statements/Payments' section. Upload a CSV file with the vendor PANs you want to verify, and TRACES returns a status for each: valid, invalid, inoperative, or not found. Run this check before each quarterly return filing — not just before year-end. An inoperative PAN status confirmed before filing allows you to deduct at 20% and document the TRACES output as the audit evidence.

Yes. For non-resident vendors without an Indian PAN, Section 206AA requires TDS at 20% or the applicable treaty rate plus applicable surcharge and cess, whichever is higher. An exception exists under Rule 37BC: if a non-resident provides details including name, address, email, and country of residence, and no PAN is available, the 20% rate under 206AA does not apply — provided the payment is under a treaty and Form 10F is furnished.

An invalid PAN does not exist in the Income Tax Department's database — it may be a fabricated or incorrectly quoted number. An inoperative PAN exists but has been deactivated because it was not linked to Aadhaar by 31 May 2024. Both are treated identically for TDS purposes under the Finance Act 2023: deductions must be made at the Section 206AA higher rate. TRACES PAN verification will return 'inoperative' for the latter, giving the deductor a clear audit record.

TDS payment code 1006 is the four-digit identifier under Section 393(1) Sl. 1(ii) of the Income Tax Act 2025 for tax deducted on commission or brokerage payments made to resident parties, excluding insurance commission (which sits at code 1005 under Section 393(1) Sl. 1(i)). It applies from April 1, 2026 and replaces the legacy Section 194H reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code covers sales commission, marketing commission, agency commission, sub-broker brokerage, and platform commissions where the underlying transaction is not an e-commerce operator payout (which sits at code 1035 under Section 393(1) Sl. 8(v)).

Payment code 1006 carries a flat 2% rate on the gross commission or brokerage amount. The threshold is ₹15,000 in aggregate per deductee per financial year — the first ₹15,000 of cumulative commission payments to the same recipient in a financial year is exempt, and TDS applies on subsequent payments and retrospectively on the breaching payment. No PAN triggers 20% non-PAN deduction.

Payment code 1006 replaces Section 194H of the Income Tax Act 1961. The 2% rate (revised from 5% to 2% with effect from October 1, 2024 under the Finance (No. 2) Act 2024, and carried into Section 393(1) Sl. 1(ii)) and the ₹15,000 aggregate threshold persist under the new regime. The exclusion for insurance commission (governed separately at code 1005) also carries forward. The 2025 Act is largely a renumbering exercise; the substantive rate and threshold for commission TDS now align with the post-October-2024 position.

Form 168 lists each commission TDS credit with the deductor TAN, deductor name, payment code 1006, parent section 393, payment description (Commission and brokerage), date of deduction, gross commission amount, tax deducted at 2%, status (booked / pending / under processing), and challan CIN. To reconcile commission receivables for sales agents, distributors, or platform partners, filter Form 168 by payment code 1006 and join against your commission-payable ledger or invoice register.

Four issues recur for code 1006. First, the boundary between commission (code 1006, 2%) and professional fees (code 1027, 10%) for service-based agents — a distribution agent on commission is 2%, a marketing consultant on retainer is 10%. Second, the threshold lapse — commission is often a small per-transaction amount but rolls up across many small payments to cross ₹15,000 quickly. Third, gross-versus-net commission — TDS applies on gross commission before any chargeback or claw-back adjustment. Fourth, the e-commerce operator overlap (code 1035, 0.1% under Section 393(1) Sl. 8(v)) — platform commissions paid to sellers as participant payouts go under 1035, not 1006.

TDS payment code 1009 is the four-digit identifier under Section 393(1) Sl. 2(ii).D(b) of the Income Tax Act 2025 for tax deducted on rent paid to a resident landlord for land, building (including factory building), or furniture and fittings let along with the building. It applies from April 1, 2026 and replaces the legacy Section 194-I(b) reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code covers office rent, warehouse rent, retail store rent, factory rent, and any other rent on immovable property where the recipient is a resident.

Payment code 1009 carries a flat 10% rate on the gross rent paid to a resident landlord for land, building, or furniture let with the building. The threshold is ₹2,40,000 in aggregate per deductee per financial year — equivalent to ₹20,000 per month — below which no TDS applies. No PAN triggers 20% non-PAN deduction. Note: rent on plant and machinery is a separate sub-clause (Section 393(1) Sl. 2(ii).D(a), code 1008) with a 2% rate (formerly 194-I(a)).

Payment code 1009 replaces Section 194-I(b) of the Income Tax Act 1961 — specifically the land-and-building branch of Section 194-I. The 10% rate and the ₹2,40,000 annual aggregate threshold carry over unchanged into Section 393(1) Sl. 2(ii).D(b). The Income Tax Act 2025 is a renumbering exercise; the substantive rate and threshold for rent TDS on immovable property remain identical. The plant-and-machinery branch of 194-I sits at code 1008 under Section 393(1) Sl. 2(ii).D(a) with the 2% rate.

Form 168 lists each rent TDS credit with the deductor TAN, deductor name, payment code 1009, parent section 393, payment description (Rent on land, building, furniture), date of deduction, gross rent paid, tax deducted at 10%, status (booked / pending / under processing), and challan CIN. For a typical landlord with one tenant, Form 168 will show 12 monthly entries per FY. To reconcile rent receivables, filter Form 168 by payment code 1009 and join against the rent ledger on deductor TAN, deductee PAN, and month-of-deduction.

Four issues recur for code 1009. First, threshold trigger month — the ₹2,40,000 aggregate is annual, so a tenant paying ₹15,000 monthly does not trigger TDS but a tenant paying ₹25,000 monthly triggers from month one. Second, the joint owner split — a property co-owned by two individuals must have rent split for TDS purposes and the per-co-owner threshold checked separately. Third, advance rent and security deposit — security deposit (refundable) is not rent and not subject to code 1009; advance rent (non-refundable) is rent and is. Fourth, GST on rent gross-up — TDS under code 1009 is on gross rent before GST.

TDS payment codes 1023 and 1024 are the four-digit identifiers under Section 393(1) Sl. 6(i) of the Income Tax Act 2025 for tax deducted on payments made to resident contractors and sub-contractors. Code 1023 (under sub-clause D(a)) applies when the contractor is an individual or HUF and carries a 1% rate. Code 1024 (under sub-clause D(b)) applies when the contractor is a company, firm, LLP, AOP, BOI, or any other entity and carries a 2% rate. Both codes apply from April 1, 2026 and replace the legacy Section 194C reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The codes cover civil works, transport contracts, supply contracts, advertising contracts, catering, manpower supply, and most other works-contract relationships with resident parties.

Payment code 1023 carries a 1% rate (contractor is an individual or Hindu Undivided Family). Payment code 1024 carries a 2% rate (contractor is a company, firm, LLP, AOP, BOI, or any other entity). The threshold for both codes is ₹30,000 for any single payment OR ₹1,00,000 in aggregate to the same contractor in a financial year — whichever is breached first triggers deduction on all subsequent payments and retrospectively on the breaching payment. No PAN means deduction at 20% under the standard non-PAN penalty rule.

Payment codes 1023 and 1024 replace Section 194C of the Income Tax Act 1961. The rate structure (1% / 2%), the per-transaction threshold (₹30,000), and the aggregate threshold (₹1,00,000 per FY) all carry over unchanged. The transport contractor exemption — no TDS if the contractor owns ten or fewer goods carriages and furnishes a declaration with PAN — also carries over. What changes is the identifier on the challan and the return: April 2026 onwards deductions key off 1023 (individual/HUF) or 1024 (other), while March 2026 and earlier deductions remain under 194C.

Form 168 lists each contractor TDS credit with the deductor TAN, deductor name, payment code (1023 or 1024), parent section 393, payment description (Contractor and sub-contractor payments), date of deduction, gross amount paid, tax deducted, status (booked / pending / under processing), and challan CIN. To reconcile contractor receivables, filter Form 168 by payment codes 1023 and 1024 and join against your TDS receivable ledger on deductor TAN plus quarter. Aggregate amounts on Form 168 should reconcile to invoice-level TDS in your accounting system.

Four issues recur for codes 1023 and 1024. First, rate mismatch — a deductor applied code 1024 at 2% to an individual contractor (should be code 1023 at 1%), or code 1023 at 1% to a partnership firm (should be code 1024 at 2%), which surfaces as an under-deduction or over-deduction on Form 168. Second, threshold miscount — the aggregate ₹1,00,000 was tracked per invoice rather than per financial year. Third, transport contractor declaration not collected, causing TDS to be deducted on payments that qualified for the ten-vehicle exemption. Fourth, classification error — a payment that should sit under code 1027 (professional fees, 10%) was coded as 1024 (contractor, 2%), shorting the deduction.

TDS payment code 1027 is the four-digit identifier under Section 393(1) Sl. 6(iii).D(b) of the Income Tax Act 2025 for tax deducted on professional fees, royalties, and non-compete payments made to resident parties. It applies from April 1, 2026 and replaces the legacy Section 194J (professional services portion) reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code covers lawyers, chartered accountants, consultants, doctors, architects, engineers, and any other professional service relationship with resident parties. The technical-services portion of legacy 194J is now a separate code — 1026, at 2%, under Section 393(1) Sl. 6(iii).D(a).

Payment code 1027 carries a 10% rate for professional services, royalty, and non-compete fees. The threshold is ₹30,000 per category per financial year. Technical services — formerly the 2% sub-rate within legacy 194J — are now coded separately as 1026 under Section 393(1) Sl. 6(iii).D(a), with its own ₹30,000 counter. So the ₹30,000 floor applies separately to code 1027 (professional) and code 1026 (technical) from the same deductee. No PAN triggers a 20% non-PAN deduction rate on code 1027.

Payment code 1027 replaces the professional-services portion of Section 194J of the Income Tax Act 1961 — specifically the 10% rate for professional services, royalty, and non-compete fees. The technical-services 2% sub-rate that lived inside 194J after the 2020 Finance Act amendment is now a separate code (1026) under Section 393(1) Sl. 6(iii).D(a). The ₹30,000 per-category threshold carries over unchanged. The Income Tax Act 2025 splits what was a single section with two rates into two distinct codes under one Sl. No., one for each rate band.

Form 168 lists each professional fee TDS credit with the deductor TAN, deductor name, payment code 1027, parent section 393, payment description (Professional services), service sub-type (professional / royalty / non-compete), date of deduction, gross amount paid, tax deducted, status (booked / pending / under processing), and challan CIN. Filter Form 168 by payment code 1027 to see all 10% professional / royalty / non-compete credits; filter by code 1026 to see the 2% technical services credits. Reconcile by joining on deductor TAN, quarter, and deductee PAN — and remember the two codes will appear as separate Form 168 lines for the same deductor even if they came from one consolidated invoice.

Four issues recur for code 1027. First, the 1027 (professional 10%) versus 1026 (technical 2%) sub-classification — a software development contract may be technical (code 1026, 2%) but a software licensing fee with knowledge transfer could be royalty (code 1027, 10%). Second, the dual-code threshold counter — ₹30,000 for code 1027 runs separately from ₹30,000 for code 1026, so an ERP that aggregates both into a single threshold counter under-deducts. Third, the boundary between code 1024 (contractor other, 2%) or code 1023 (contractor Ind/HUF, 1%) and code 1027 (professional, 10%) for service-based payments. Fourth, code 1027 versus code 1057 (Section 393(2) Sl. 17, NR catch-all) for cross-border professional services to a non-resident — the latter is governed by treaty rates and Form 15CA/CB.

TDS payment code 1031 is the four-digit identifier under Section 393(1) Sl. 8(ii) of the Income Tax Act 2025 for buyer-deducted TDS on purchase of goods from a resident supplier. It applies from April 1, 2026 and replaces the legacy Section 194Q reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code applies only where the buyer's gross turnover, sales, or receipts in the immediately preceding financial year exceeded ₹10 crore AND the buyer's annual purchases from the same supplier exceed ₹50 lakh.

Payment code 1031 carries a flat 0.1% rate on the purchase value above ₹50 lakh from the same supplier in a financial year. The compound threshold requires both: (a) the buyer's prior-year turnover above ₹10 crore, and (b) cumulative purchases from a single resident supplier above ₹50 lakh in the current FY. Once both conditions are met, the buyer deducts 0.1% on every rupee of purchase value above ₹50 lakh from that supplier for the rest of the FY. No PAN triggers 5% non-PAN deduction (a softer rate than the usual 20%, specific to legacy 194Q carried into code 1031).

Payment code 1031 replaces Section 194Q of the Income Tax Act 1961, introduced from July 1, 2021 to bring large-value goods purchases into the TDS net and to complement Section 206C(1H) TCS on sales of goods. The 0.1% rate, the ₹10 crore buyer-turnover trigger, the ₹50 lakh per-supplier annual threshold, and the priority rule (194Q overrides 206C(1H) when both apply) all carry over into Section 393(1) Sl. 8(ii). The 2025 Act is a renumbering exercise; the substantive rate, threshold, and priority rules remain identical. Note that Section 206C(1H) itself is inapplicable since 1 April 2025 under the Finance Act 2025 proviso; under the Income-tax Act 2025 there is no successor TCS code for goods sale, and Section 194Q / code 1031 / §393(1) Sl. 8(ii) remains the operative TDS provision.

Form 168 lists each goods-purchase TDS credit with the deductor TAN (the buyer's TAN), deductor name, payment code 1031, parent section 393, payment description (Purchase of goods), date of deduction, taxable purchase value (above the ₹50 lakh threshold), tax deducted at 0.1%, status (booked / pending / under processing), and challan CIN. For a supplier with one large buyer, Form 168 will show TDS lines starting from the point in the FY when cumulative purchases by that buyer crossed ₹50 lakh.

Four issues recur for code 1031. First, the legacy overlap with TCS Section 206C(1H) — when both 194Q (now 1031) and 206C(1H) historically applied, 194Q/1031 took priority and the seller was exempt from TCS; 206C(1H) is now inapplicable from 1 April 2025 with no successor code, so the priority question is largely moot going forward but still relevant for cross-era reconciliation of FY 2024-25 and earlier records. Second, the ₹50 lakh threshold trigger month — once cumulative purchases cross ₹50 lakh, TDS applies on the breaching purchase and retrospectively on the amount above ₹50 lakh. Third, GST-inclusive versus exclusive base — TDS on goods purchase is on the value of purchase including GST. Fourth, year-on-year buyer-turnover qualifier reset — the ₹10 crore prior-year turnover must be re-checked every April.

TDS payment code 1035 is the four-digit identifier under Section 393(1) Sl. 8(v) of the Income Tax Act 2025 for tax deducted by e-commerce operators on payments to e-commerce participants — the sellers, restaurants, drivers, or service providers who transact through a marketplace platform. It applies from April 1, 2026 and replaces the legacy Section 194O reference on challan ITNS 281, Form 26Q quarterly returns, Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code covers Amazon, Flipkart, Meesho, Myntra, Zomato, Swiggy, Ola, Uber, Urban Company, and any other marketplace that aggregates supply and processes consumer payments to participant sellers.

Payment code 1035 carries a flat 0.1% rate on the gross transaction value (the consumer-side order amount inclusive of GST). There is effectively no threshold for business participants — TDS applies on every transaction. For an individual or HUF participant, an exemption applies if gross sales through the platform do not exceed ₹5,00,000 in the financial year AND the participant furnishes PAN/Aadhaar. No PAN triggers the standard 5% non-PAN rate (lower than the usual 20% for participant payouts under the legacy 194O regime, carried into 1035).

Payment code 1035 replaces Section 194O of the Income Tax Act 1961, which was introduced from October 1, 2020 to bring e-commerce participants into the TDS net. Under the 1961 Act the rate was originally 1% before being reduced to 0.1% by subsequent Finance Act amendments. The 2025 Act consolidates the rate at 0.1% on the gross-transaction-value base (including GST), and the individual-participant exemption with the ₹5,00,000 threshold carries over into Section 393(1) Sl. 8(v). The 2025 Act renumbering preserves the substantive rate (now 0.1%), base, and threshold rules.

Form 168 lists each e-commerce participant payout TDS credit with the deductor TAN (the marketplace's TAN), deductor name, payment code 1035, parent section 393, payment description (E-commerce participant payouts), date of deduction (typically the date of customer-side transaction settlement), gross transaction value, tax deducted at 0.1%, status (booked / pending / under processing), and challan CIN. For an active seller on a marketplace, Form 168 will show one line per settlement batch (typically daily or weekly). Volumes for high-velocity sellers can run to thousands of lines per quarter.

Four issues recur for code 1035. First, GST-inclusive versus GST-exclusive base — TDS is on gross transaction value including GST, so the seller's TDS receivable base will look larger than the taxable sales figure. Second, returns and refunds — TDS is on the original sale value; refunds and returns do not trigger TDS reversal in the same quarter but may surface in the next quarter's settlement reconciliation. Third, dual TDS exposure — payments may also attract code 1006 (commission) at 2% if the marketplace structure includes a separate commission payout. Fourth, multi-marketplace seller reconciliation — a seller on Amazon, Flipkart, and Meesho gets three TAN-keyed streams in Form 168, all under code 1035, and must reconcile each separately.

A TDS payment code is a four-digit numeric identifier in the 1001 to 1092 range that classifies the type of payment subject to TDS or TCS from April 1, 2026. Payment codes replace the legacy section references (194C, 194J, 194H, and so on) as the primary classification key on challan ITNS 281, on the new Form 131 certificate (replacing Form 16A), and on the updated Form 168 (replacing Form 26AS). Each payment code sits under one of three parent sections: 392 for salary TDS, 393 for non-salary TDS, and 394 for TCS.

No. The Income Tax Act 2025 is a consolidation exercise, not a rate reset. The 1% and 2% rates under the contractor payment code carry over from Section 194C. The 10% rate for professional fees carries over from Section 194J. The ₹30,000 per-transaction and ₹1,00,000 aggregate thresholds under the contractor bucket remain the same. What changes is the identifier shown on the challan and the return; the rate table behind it is structurally unchanged, subject to the final notification.

Payment codes 1001 to 1092 apply to all TDS and TCS deductions made on or after April 1, 2026. A contractor payment processed on April 3, 2026 must be deposited with a challan that carries the corresponding payment code under Section 393, not the legacy 194C reference. Deductions made up to March 31, 2026, even if the challan is deposited in April by the standard 7th-of-month deadline, continue to use old section codes because the underlying deduction falls under the 1961 Act.

Section 194T, introduced by the Finance Act 2024, levies 10% TDS on partner remuneration (salary, commission, interest, bonus) above ₹20,000 in a financial year. Under the Income Tax Act 2025, this is absorbed into the 393 parent section with its own payment code, likely in the 393(1) sub-clause range alongside other non-salary TDS. The first applicable year is FY 2025-26, so Q4 returns filed in May 2026 will carry Section 194T using old numbering, while Q1 FY 2026-27 filings will carry the new payment code for the same payment type.

Sections 206AB and 206CCA, which applied higher TDS and TCS rates to non-filers of income tax returns, have been abolished under the Income Tax Act 2025. There is no successor payment code for non-filer penalties in the 1001 to 1092 range. Finance teams that maintain separate vendor flags or master data columns for 206AB screening should decommission those filters from April 1, 2026 and stop running the non-filer check through the compliance portal as part of the monthly TDS workflow.

The challan now requires the four-digit payment code in the section identifier field instead of the legacy section dropdown. The bank's e-payment portal — whichever authorised bank handles your TDS deposits (HDFC, ICICI, SBI, Axis, and others) — has been updated to surface the new payment codes. The OLTAS challan acknowledgement (CIN) records the payment code, and that code becomes the join key for TRACES challan-to-return matching. A challan deposited with the wrong payment code can still go through OLTAS but will not match cleanly to the corresponding line in the quarterly return.

Form 168 (which replaces Form 26AS for FY 2026-27 and beyond) lists each TDS or TCS credit with these columns: deductor TAN and name, payment code (e.g. 1003), parent section (392 / 393 / 394), payment description (e.g. Professional and technical services), date of deduction, amount of credit, status (booked / pending / under processing), and challan CIN. The payment code is the new primary classifier — you filter the statement by payment code to see all credits of a given type aggregated across deductors. Reconciliation against your TDS receivable ledger should join on payment code rather than the legacy section number.

Many mid-market ERPs released payment code patches between January and March 2026, but some — especially smaller localised systems — are still on legacy section codes. Until the patch lands, the workaround is to maintain an external mapping table (a spreadsheet or a lightweight database) that translates the ERP's section output into the correct payment code at the point of challan preparation and return filing. The ERP's underlying ledger entries can continue to carry the legacy section code; the translation layer applies at the integration boundary. This is an acceptable bridge for a quarter or two but is not sustainable longer term — push the ERP vendor for a patch with a firm timeline.

TCS — Tax Collected at Source — sits under Section 394, with payment codes in the 1071+ range. The mechanics differ: TCS is collected by the seller from the buyer (rather than deducted from a payment outflow), and the buyer claims credit in their own Form 168. Common TCS payment codes cover scrap and forest produce (former 206C(1)), motor vehicles above ₹10 lakh (former 206C(1F)), and remittances under LRS / overseas tour packages (former 206C(1G)). Note that Section 206C(1H) (TCS on sale of goods) is inapplicable since 1 April 2025 under the Finance Act 2025 proviso and has no successor TCS code under the Income-tax Act 2025; Section 194Q / code 1031 / §393(1) Sl. 8(ii) remains the operative TDS provision on the buyer side. Reconciliation logic is similar to TDS — match the seller's TCS line against your buyer-side TCS expense — but the parent section and code range are distinct, so the ledger should keep TCS in its own bucket rather than mixing with non-salary TDS.

If the wrong payment code went onto the challan, file a challan correction request through the deductor's TRACES profile within the quarterly return preparation cycle (before May 31 for Q1 FY 2026-27). The correction reassigns the deposit to the correct payment code, and the corrected entry flows through to the deductee's Form 168 once the return is filed. If the wrong code only affects the internal ledger but the challan and return are correct, fix the ledger entry directly and re-run reconciliation — there is no government-side action needed. The most damaging case is when the challan is correct but the return preparation tool used the wrong payment code; that creates a TRACES challan-to-return mismatch that surfaces as a default notice and needs a return correction filing.

Late deposit of TDS attracts interest at 1.5% per month under Section 201(1A), calculated from the date of deduction to the date of actual deposit. The interest is computed on a per-month basis — even a one-day delay counts as a full month. For ₹1 crore in monthly TDS, a systematic one-day delay generates ₹1.5 lakh per month or ₹18 lakh annually in interest.

Non-deduction triggers three concurrent consequences: the deductor becomes an assessee-in-default under Section 201(1) and must pay the TDS from own funds, interest accrues at 1% per month from the date TDS was deductible, and 30% of the payment amount is disallowed as a business expenditure under Section 40(a)(ia). For a ₹10 lakh professional fee payment where TDS was not deducted, the combined exposure is approximately ₹1.87 lakh in the first year.

No. The Supreme Court in Hindustan Coca-Cola Beverages Pvt. Ltd. v. CIT (2007) and the more recent US Technologies International v. CIT (April 2023) held that Section 271C penalty applies only to failure to deduct TDS, not to delayed deposit after deduction. Late deposit consequences are limited to Section 201(1A) interest and potential prosecution under Section 276B.

Section 234E imposes a fee of ₹200 per day for every day the TDS return remains unfiled after the due date. The fee is capped at the total TDS amount reported in the return. Additionally, Section 271H allows the Assessing Officer to levy a penalty between ₹10,000 and ₹1,00,000 if the return is not filed within one year of the due date or contains incorrect information.

Yes. Under Section 278B of the Income Tax Act, when a company commits an offence under Section 276B (failure to deposit TDS), every person who was in charge of and responsible for the conduct of the company's business at the time of the offence is deemed guilty. This includes managing directors and finance directors. The Supreme Court upheld director-level prosecution in Sasi Enterprises v. ACIT (2014) 5 SCC 139, confirming imprisonment of 3 months to 7 years with rigorous imprisonment and fine.

TDS payment code 1057 is the four-digit identifier under Section 393(2) Sl. 17 of the Income Tax Act 2025 for tax deducted on any sum paid to a non-resident, foreign company, or foreign entity that is chargeable to tax in India. It applies from April 1, 2026 and replaces the legacy Section 195 reference on challan ITNS 281, Form 27Q quarterly returns (the non-resident equivalent of Form 26Q), Form 131 deductee certificates, and Form 168 (the new Form 26AS). The code covers foreign professional fees, royalties, fees for technical services, interest paid to non-residents, capital gains on transfer of Indian assets by non-residents, and payments to foreign OTAs, foreign vendors, and foreign group entities under cost-allocation agreements.

Payment code 1057 has no fixed rate or threshold. The rate is determined by either the relevant Double Taxation Avoidance Agreement (DTAA, also called a tax treaty) between India and the country of residence of the recipient, or by the Income Tax Act 2025 rate for the specific income type — whichever is lower. Typical rates: 10% to 15% on royalty and fees for technical services under most treaties; 10% to 20% on interest; 20% to 30% on capital gains depending on asset type and holding period. No PAN or tax residency certificate (TRC) means the treaty benefit is unavailable and Act rates apply (often 20% or higher).

Payment code 1057 replaces Section 195 of the Income Tax Act 1961, which has governed cross-border TDS since 1961. The treaty-rate-versus-Act-rate principle, the Form 15CA/15CB workflow (chartered accountant certification of cross-border remittances), the tax residency certificate (TRC) requirement under Section 90(4)/(5), and the lower-deduction certificate application under Section 197 all carry over into Section 393(2) Sl. 17. The 2025 Act is a renumbering exercise; the substantive treaty mechanics for cross-border TDS remain identical, subject to the most-favoured-nation clauses and CBDT clarifications on specific treaties.

Form 168 lists each non-resident payment TDS credit with the deductor TAN, deductor name, payment code 1057, parent section 393(2) Sl. 17, payment description (Payment to non-resident), income type (royalty / FTS / interest / dividend / capital gain / other), country of residence of the deductee, date of deduction, gross amount paid, tax deducted at treaty rate, status (booked / pending / under processing), challan CIN, and Form 15CA/15CB reference. Cross-border deductees often do not have Indian PAN; in that case the line appears in the deductor's Form 27Q return but not in any deductee Form 168 — only Indian-resident deductees see Form 168 statements.

Five issues recur for code 1057. First, the treaty-rate-versus-Act-rate determination — if the deductee fails to furnish a valid TRC and a Form 10F self-declaration, Act rates apply and the deduction is higher than the treaty rate. Second, Form 15CA/15CB workflow — every cross-border remittance above ₹5,00,000 cumulative per FY requires CA certification on Form 15CB before the bank releases funds. Third, equalisation levy overlap (digital advertising, e-commerce services) — equalisation levy is not TDS and does not go through code 1057. Fourth, royalty versus FTS classification — different treaties may classify the same payment differently. Fifth, beneficial ownership — payments to a treaty-country intermediary that is not the beneficial owner can be denied treaty benefit.

The Q4 TDS return (Form 26Q or 27Q for non-salary; Form 24Q for salary) is due on 31 May. Other quarters: Q1 (April–June) is due 31 July; Q2 (July–September) is due 31 October; Q3 (October–December) is due 31 January. These deadlines apply to the return filing, not the challan deposit. TDS must be deposited by the 7th of the following month (30 April for the March deductions).

Start at least 10–15 working days before the deadline. The most common error in quarterly filing is rushing data validation in the final 2–3 days: deductee PANs are unverified, challan serial numbers are copied from the previous quarter, and section codes are incorrectly assigned. Starting early allows time to resolve PAN invalidation errors (which NSDL's FVU rejects) and to verify challan deposits against OLTAS before the return file is prepared.

A late filing fee of ₹200 per day applies under Section 234E, from the day after the due date until the return is filed, subject to a maximum of the total TDS amount for that quarter. This is a mandatory fee, not a penalty that can be waived — it is calculated automatically and reflected in the TRACES demand. In addition, Form 26AS for all deductees in that return will not update until the return is filed and processed, delaying their credit claims.

Yes. Correction returns are filed on TRACES. The type depends on the error: C1 corrects deductee PAN, C2 corrects challan BSR code or serial number, C3 corrects salary/deduction details in Form 24Q. Multiple corrections can be filed, each building on the previous corrected version. There is no limit on the number of corrections, but each correction takes 3–7 business days to process, so catching errors before filing is significantly more efficient.

Log into the TRACES portal (https://www.tdscpc.gov.in) with the deductor TAN and check the return filing status. A processed return will show the status as 'processed' with a statement token number. Additionally, after processing, Form 26AS for the listed deductees will begin updating — you can verify this by checking one or two deductee PANs. If status shows 'pending' after 10 business days, contact TRACES helpdesk for the specific statement token.

Two rates changed on October 1, 2024. Section 194H (commission and brokerage) dropped from 5% to 2%. Section 194-O (e-commerce operator deduction) dropped from 1% to 0.1%. Any payment made on or after October 1, 2024 must be deducted at the new rate. Payments before that date must retain the old rate. Reconciliation systems that apply a flat annual rate generate false variances across the boundary.

The Finance Act 2025 raised two thresholds effective April 1, 2025. Section 194J (professional and technical services) saw its threshold raised from ₹30,000 per payment to ₹50,000 per payment. Section 194A (interest other than from banks for senior citizens) saw its threshold raised from ₹50,000 to ₹1,00,000 per financial year. Deductions in April 2025 onwards must apply these new thresholds; FY 2024-25 deductions retain the older thresholds.

When a single annual rate is applied to every transaction, deductions in the earlier half of the year are effectively over-deducted (or under-deducted) compared to the correct rate for that date. This produces three failure modes: ledger-to-certificate variances where the amount differs by the rate delta, Form 168 variances where the government statement does not match the deductor certificate, and income tax notices where the ITR credit claim cannot be validated. The resolution requires re-running deductions with the correct rate applied by payment date.

For TDS rate selection, the payment date is the earlier of credit to the payee's account or actual payment — the same test used to determine when TDS liability arises under the Income Tax Act. An invoice dated September 28, 2024 that is paid on October 5, 2024 (for a Section 194H commission) attracts the new 2% rate because the payment occurred after the October 1 effective date. An invoice credited on September 30 and paid October 5 attracts the old 5% rate because the credit date is earlier.

Under-deduction attracts interest at 1% per month from the date TDS should have been deducted to the date of actual deduction, under Section 201(1A) of the 1961 Act (equivalent provision under Chapter XX of the 2025 Act). The deductor is also treated as an assessee in default and may face penalty up to the amount of TDS not deducted under Section 271C. For a company with 500 Section 194H transactions mis-deducted at 5% instead of 2% after October 1, 2024, the excess deducted must be refunded or adjusted in subsequent quarters, and the reconciliation variance must be resolved before Form 26AS for FY 2024-25 can be finalised.

Under the accrual basis of accounting, the invoice is recorded gross (including the TDS component) on the invoice date. The TDS receivable is recognised as a separate asset at this point, representing the expected tax credit. However, the TDS credit can only be claimed in the ITR when it appears in Form 26AS — which depends on the deductor depositing the challan and filing the quarterly return. The accounting entry and the claimable credit are therefore on different timelines, making reconciliation between the TDS receivable ledger and Form 26AS essential.

After 3 months without a Form 26AS credit, initiate a structured follow-up: (1) Contact the deductor and request the TDS certificate (Form 16A) and challan details for the relevant payment. (2) Ask the deductor to verify on TRACES that the quarterly return for that period has been filed and processed. (3) Check whether the deductor's TDS return shows your PAN correctly — an invalid or incorrect PAN is a frequent cause of missing credits. If the deductor confirms the return is filed but the credit is still absent, escalate to verify the challan BSR code and serial number.

No. The Income Tax Department's return processing system validates TDS credit claims directly against Form 26AS data. A claim that exceeds Form 26AS will generate a demand notice under Section 143(1). The TDS receivable ledger is an internal accounting document; it has no standing as evidence for credit claims. If a credit is in the ledger but not in Form 26AS, the resolution path is to obtain the correction from the deductor — not to claim the amount and explain it later.

Aggregate the expected TDS by client PAN first to get the total credit expected from that client. Then split the Form 26AS entries by each of the three TANs to verify that the combined credit equals the ledger total. Form 26AS displays TDS by deductor TAN, so each branch will appear as a separate entry. At the invoice level, record the expected TAN alongside each receivable entry — this enables TAN-level matching when Form 26AS is downloaded, and identifies which specific branch's return has a problem when a credit is missing.

Capture the deductor's TAN at the invoice or purchase order level, not just at the vendor master level. Tag the applicable TDS section code on each invoice (since the same vendor may be subject to different sections for different service types). Configure the export report to group TDS receivable by TAN and quarter — this mirrors the structure of Form 26AS and eliminates a manual restructuring step when running the reconciliation. If the ERP allows, store the Form 16A certificate reference number against the corresponding ledger entry when the certificate is received.

IT services companies are primarily subject to Section 194J. Professional services (consulting, advisory, software customisation) attract 10% TDS. Technical services (standard software maintenance, data processing) attract 2% following the CBDT amendment effective April 2020. If a client misclassifies services as a works contract under Section 194C (2%), the vendor must raise a correction request because the Form 26AS credit will be lower than expected.

First, review the client's purchase order and service agreement to confirm whether the engagement is professional services (194J at 10%) or technical services (194J at 2%). If 194C is incorrect, issue a formal written clarification to the client citing the nature of services. The client must file a correction return for the relevant quarter to revise the section code. Until corrected, the lower TDS credit in Form 26AS creates a receivable shortfall that must be disclosed at ITR time.

Download the Form 26AS for the relevant financial year from the Income Tax portal and reconcile each entry against your invoice register and TDS receivable ledger. Common causes: client has not yet deposited the deducted amount (timing lag), client filed under the wrong section, or the client's TAN is incorrect. Contact the client with the specific invoice and quarter details, request their TDS return acknowledgement, and if the gap persists, escalate to a correction return before your ITR filing deadline.

Automated reconciliation software that ingests Form 26AS data via the TRACES API and matches entries to the invoice register using TAN, amount, and period reduces 3-week manual cycles to under a day. The matching engine must handle net-of-TDS amounts — linking a ₹90,000 bank credit to a ₹1,00,000 invoice and a ₹10,000 TDS entry as a single transaction. Exceptions (section mismatches, missing credits) are surfaced as work items rather than buried in spreadsheet columns.

NBFCs deduct TDS on interest payments to resident depositors at 10% if the depositor furnishes a valid PAN. If PAN is not furnished, the rate increases to 20% under Section 206AA. For interest payments to non-residents, Section 195 applies instead of 194A — the withholding rate depends on the applicable Double Taxation Avoidance Agreement (DTAA) or the Income Tax Act rate, whichever is beneficial. The threshold for mandatory TDS deduction under 194A for NBFCs is above ₹5,000 per annum per depositor.

Depositors below the basic exemption limit (Form 15G for those below 60 years) or senior citizens (Form 15H) submit declarations to the NBFC requesting nil TDS deduction. The NBFC must log the submission date, validate that the depositor's declared income is within the eligible limit, and ensure the TDS system excludes those accounts from deduction for the applicable financial year. NBFCs are required to submit these declarations electronically on the TRACES portal each quarter. A reconciliation gap occurs when a depositor submits the form mid-year after TDS has already been deducted — the NBFC cannot reverse the deduction but must issue a revised Form 16A reflecting the corrected position.

When a depositor fails to furnish a valid PAN, Section 206AA requires TDS at 20%, double the standard rate. If the depositor later furnishes PAN in the same financial year, the NBFC must file a correction return for the relevant quarter on TRACES to revise the deduction from 20% to 10%. A revised Form 16A is then issued to the depositor. If the correction return is not filed, the depositor cannot claim the excess TDS credit in their ITR — creating a compliance liability for both parties. Automating PAN validation at account opening and at each interest payout cycle reduces the frequency of 20% deductions at source.

In a co-lending arrangement, an NBFC and a bank jointly disburse a loan. When the borrower repays interest, the allocation between the bank and NBFC must be tracked separately. If the bank is the primary lender on record, the bank may deduct TDS under 194A on the NBFC's share of interest income received. The NBFC must reconcile this TDS deduction (appearing in Form 26AS under the bank's TAN) against its interest income ledger for each co-lending partner. NBFCs with five or more co-lending partners face a multi-TAN reconciliation exercise each quarter that requires systematic TAN-to-partner mapping to avoid misattribution.

After the ITR is processed under Section 143(1) and a refund is determined, CPC Bengaluru typically issues the refund within 20–45 days of the intimation date for electronically verified returns. Refunds are credited directly to the bank account registered and pre-validated on the income tax portal. Processing times can extend where the return is selected for scrutiny or where there is an outstanding demand in any prior year that the department applies the refund against under Section 245.

Section 245 empowers the Income Tax Department to adjust a refund due for one year against an outstanding tax demand for any other year before issuing the refund. The taxpayer receives a notice under Section 245 before the adjustment is made and has 30 days to respond. If the outstanding demand is disputed, the taxpayer should respond within the notice period with evidence of the dispute or payment. Failure to respond results in automatic adjustment of the refund.

Yes. A taxpayer can claim TDS credit in the ITR even if the entry does not yet appear in Form 26AS, provided the income corresponding to that TDS has been declared in the return. However, the refund or tax credit will be granted only after verification — which requires the deductor's TDS return to be on record. If the deductor has not filed, the taxpayer's refund may be held or reduced until the deductor's filing is complete.

CPC Bengaluru attempts to credit the refund to the bank account pre-validated on the income tax portal. If the account details are incorrect or the account is closed, the credit will fail. The taxpayer must update and pre-validate the correct bank account on the portal and request a refund reissue through the grievance or refund reissue module. This process can add 30–60 days to the refund timeline.

Section 197 allows a taxpayer to apply for a certificate from the Assessing Officer directing deductors to apply a lower or nil TDS rate. If the certificate is obtained but not submitted to the deductor in time — and TDS is deducted at the full rate — the excess TDS becomes part of the refund claimed in the ITR. The Section 197 certificate number, validity period, and applicable rate must be tracked separately and reconciled against the actual TDS deducted by each deductor.

Section 192 does not prescribe a fixed rate. The employer calculates the employee's estimated annual tax liability based on their income slab under the applicable tax regime (old or new), then divides this equally across the remaining months of the financial year. Rates effectively range from nil for income below ₹3 lakh (new regime) to 30% for income above ₹15 lakh, plus applicable surcharge and health and education cess at 4%.

For government employers, TDS must be deposited on the same day of deduction. For non-government employers, TDS deducted during any month of April through February must be deposited by the 7th of the following month. TDS deducted in March must be deposited by 30 April.

Form 24Q is the quarterly TDS return filed by employers for salary payments under Section 192. It is due on 31 July (Q1), 31 October (Q2), 31 January (Q3), and 31 May (Q4). Annex II of the Q4 Form 24Q is particularly critical—it contains the full year salary details used to generate Form 16 Part A from TRACES.

The employer re-estimates the employee's annual tax liability in January–March after accounting for actual bonus, arrears, perquisites (ESOP, car), and any LTA or HRA claims declared via Form 12BB. If the re-estimate exceeds the cumulative deductions made in Q1–Q3, the shortfall is recovered in Q4 months, causing a visible spike in March payslip TDS.

Interest under Section 201(1A) accrues at 1.5% per month or part thereof from the date of deduction to the date of actual deposit. Additionally, late filing of Form 24Q attracts a penalty of ₹200 per day under Section 234E, subject to a maximum of the TDS amount involved.

Section 194 requires TDS at 10% on dividends paid to resident individuals and Hindu Undivided Families where the aggregate dividend in a financial year exceeds ₹5,000 per shareholder. If the shareholder does not furnish a PAN, Section 206AA requires TDS at 20%.

No. Before 1 April 2020, dividends were covered by the Dividend Distribution Tax (DDT) regime and were exempt in the hands of shareholders. Section 194 TDS applies only to dividends declared or paid on or after 1 April 2020, following the abolition of DDT under the Finance Act 2020.

A company paying dividends to resident shareholders files TDS returns in Form 26Q on a quarterly basis. For dividends paid to non-resident shareholders under Section 195, the relevant form is Form 27Q. Form 16A is issued to shareholders as the TDS certificate.

Under Section 195, TDS on dividends to non-residents is 20% plus applicable surcharge and cess, resulting in an effective rate of up to 23.296% for non-corporate non-residents. If the shareholder's country has a DTAA with India and provides a lower rate, that treaty rate applies, provided the shareholder submits Form 10F and a Tax Residency Certificate.

The receiving company should match dividend income recorded in the profit and loss account against dividend warrants or bank credits, then verify the TDS amount against Form 26AS or the Annual Information Statement (AIS). The TDS credit must appear in 26AS before it can be claimed in the advance tax computation or ITR filing.

Yes. Interest paid on a fixed deposit with a Non-Banking Financial Company (NBFC) is subject to TDS at 10% under Section 194A when the annual interest exceeds ₹5,000. This is materially different from interest on bank FDs, where the TDS threshold is ₹40,000 per year (₹50,000 for senior citizens). A company earning ₹20,000 interest on an NBFC FD will have TDS deducted at ₹2,000, whereas the same amount from a scheduled bank would not attract TDS.

TDS under 194A is triggered on credit (accrual) or payment, whichever is earlier. Many banks and NBFCs credit interest quarterly to the account and deduct TDS at that point, even if the depositor does not withdraw. In Form 26AS, the TDS entry appears in the quarter when the interest was credited. In the depositor's books, the interest income may be recognised on an accrual basis that does not align with the quarterly credit schedule. Reconciliation requires mapping Form 26AS quarter-by-quarter entries to the accrual schedule in the books.

Yes, if the landlord pays interest on the security deposit. Some commercial lease agreements provide for the landlord to pay interest on the security deposit at a specified rate (for example, 6% per annum). If this interest exceeds ₹5,000 in a financial year, the tenant-turned-interest-recipient does not deduct TDS — rather, the landlord as payer must deduct TDS at 10% under Section 194A before paying the interest. This scenario is common in large commercial property leases with multi-crore security deposits.

For a company receiving interest from a non-bank source (NBFC, cooperative society, inter-company loan, builder's deposit), the TDS threshold is ₹5,000 per year per payer. For interest from a scheduled bank or cooperative bank on a fixed deposit or recurring deposit, the threshold is ₹40,000 per year (₹50,000 for senior citizens aged 60 and above). Savings account interest is excluded from 194A entirely and is instead reported under Section 194A(3)(i) exemptions.

Section 194A TDS appears in the income source's books (lender deducts from interest paid to borrower), whereas 194J appears in the service provider's books (client deducts from fees paid). The volume and matching pattern also differ: 194A entries are typically low-volume (one or two entries per quarter per lender) with exact amounts, while 194J may involve 30–100 entries per quarter from multiple clients with partial payments and rate disputes. For inter-company loans in a conglomerate, 194A entries may appear in both the subsidiary (paying interest, which is the deductor) and the parent (receiving interest, which sees the credit in Form 26AS).

Payments to a company or firm attract TDS at 2% under Section 194C. The threshold is ₹30,000 per single payment or ₹1,00,000 in aggregate during the financial year. TDS must be deposited by the 7th of the following month (30 April for March deductions).

The most frequent cause is rate misinterpretation: a deductor applies 1% (the individual/HUF rate) to a company contractor, or vice versa. Other causes include a wrong TAN being quoted, the deductor mapping the transaction to Section 194J instead of 194C, or a challan deposit being delayed beyond the 7th of the month so it does not appear in the same quarter's Form 26AS.

A correction statement filed on TRACES (https://www.tdscpc.gov.in) is typically processed within 5–7 working days for structural corrections (wrong TAN, wrong section) and up to 15 working days if the underlying challan itself needs to be corrected. The corrected credit appears in Form 26AS within 3–7 days of processing.

Section 194C applies to work contracts — manufacturing, construction, transport, catering, labour supply. Section 194J applies to professional or technical services. The rates differ: 194C is 1% or 2% depending on payee type, while 194J is 10% for professional services and 2% for technical services. Misclassifying a software development contract from 194J to 194C results in an 8% shortfall in deduction, which the deductor is liable to make good.

Large enterprises often register separate TANs for each branch, state, or legal entity. Form 26AS aggregates credit by PAN but lists each deductor TAN separately. To reconcile, extract all TAN-level rows from Form 26AS for the financial year, then map each row to the corresponding invoice or purchase order. An organisation with 8 active client branches may see 8 separate 194C deductor entries for a single project.

Yes. Insurance companies deduct TDS at 5% on commission paid to agents under Section 194H when the aggregate commission in a financial year exceeds ₹15,000. For a life insurance agent earning ₹80,000 commission annually, the TDS deducted is ₹4,000. Insurance companies typically consolidate monthly commission payments and deposit a single monthly TDS challan, which appears in Form 26AS with the insurer's TAN.

Section 194H applies when the payment is commission or brokerage — that is, a fee for arranging or facilitating a transaction, typically calculated as a percentage of deal value. Section 194J applies when the payment is for professional services rendered — fees for expertise, not transaction facilitation. A travel agent earning commission from an airline is covered by 194H at 5%. A travel consultant charging a fixed professional fee for itinerary design may fall under 194J at 10%.

Variable commission creates a different amount each month, making amount-based one-to-one matching unreliable. The correct approach is to reconcile at the quarter level: sum all commission invoices for the quarter, calculate expected TDS at 5%, and match the total against the single quarterly entry in Form 26AS. Certificate numbers in Form 16A (downloadable from TRACES) confirm the deductor TAN and quarter, serving as the authoritative match key.

No. Platform commissions charged by e-commerce operators (Flipkart, Amazon, Meesho, and similar marketplaces) to sellers are covered by a distinct set of provisions — Section 194O for TDS on e-commerce payouts and GST TCS under Section 52 of the CGST Act. Section 194H does not apply to marketplace platform fees. Misclassifying marketplace deductions as 194H is a common error in seller reconciliation that leads to incorrect ledger entries.

Real estate brokerage payments to channel partners (property dealers, DSAs) attract TDS at 5% under Section 194H when aggregate payments exceed ₹15,000 in a financial year. A developer paying ₹3,00,000 brokerage on a ₹60,00,000 property deal must deduct ₹15,000 TDS. The TDS must be deposited by the 7th of the following month and reported in the quarterly TDS return (Form 26Q).

TDS on office rent (land, building, furniture, and fittings) is 10% under Section 194I. For plant, machinery, or equipment hire, the rate is 2%. The threshold in both cases is ₹2,40,000 per year per landlord, which means any monthly rent above ₹20,000 triggers the TDS obligation. TDS is deducted at the time of credit to the landlord's account or actual payment, whichever is earlier.

In most interpretations, co-working space charges are treated as service charges rather than rent, making Section 194J (technical services, 2%) more applicable than Section 194I. The distinction is whether the arrangement grants exclusive possession of a defined space (rent, 194I) or access to shared facilities with additional services such as internet, housekeeping, and reception (service, 194J). Most co-working providers structure their agreements as service contracts specifically to avoid the 194I classification.

Large institutional landlords — real estate investment trusts, commercial property companies — often maintain separate TANs for each property or state registration. As the tenant, your books show one rent expense account but Form 26AS (if you are the deductor) shows one entry per TAN. Reconciliation requires mapping each monthly rent payment to the correct TAN before matching. If you are the landlord receiving rent, each corporate tenant has a unique TAN and Form 26AS shows a separate row per tenant.

No. TDS under Section 194I applies only to rent — periodic payments for use of property. Security deposits are refundable amounts held as collateral and do not constitute rent. Deducting TDS on a security deposit is an error. If a deductor incorrectly deducts TDS on the deposit, the landlord must request a correction return from the deductor to remove the erroneous entry from Form 26AS, since the deposit amount will never appear as rental income in the landlord's ITR.

Yes. If rent increases from ₹30,000/month to ₹35,000/month from July onwards, the TDS calculation for each month changes. April–June TDS is ₹3,000/month (10% of ₹30,000) and July–March TDS is ₹3,500/month (10% of ₹35,000). The annual total against which the ₹2,40,000 threshold is checked is the revised aggregate: 3×₹30,000 + 9×₹35,000 = ₹4,05,000, which exceeds the threshold, so TDS applies from the first payment.

IT consulting services are taxed at 2% under Section 194J if they qualify as technical services, following the Finance Act 2020 amendment effective from 1 April 2020. If the engagement involves professional advisory — strategy, legal opinion, or domain expertise — the rate is 10%. The ₹30,000/year threshold applies in both cases. Clients who were deducting at 10% on software services before FY 2020-21 must now confirm reclassification in their ERP.

Yes, software development services generally qualify as technical services and attract 2% TDS under Section 194J. However, if the engagement includes significant professional advisory, design authority, or intellectual property creation (for example, custom algorithm development billed as consultancy), a client may argue 10% applies. Disputes on this boundary are the most common 194J reconciliation issues for Indian IT exporters receiving domestic contracts.

Many large deductors consolidate 194J payments and deposit a single quarterly TDS challan rather than monthly. Form 26AS shows the deduction at the quarter level — for example, Q1 shows a single entry even if three monthly invoices were raised. To reconcile, sum the TDS amounts from all invoices in the quarter and match that total against the Form 26AS quarterly entry. Certificate numbers in Form 16A, downloadable from TRACES, link the challan back to individual deductee records.

If a deductor applies 194C (2% for company) instead of 194J (10% professional or 2% technical), the TDS credit in Form 26AS will be tagged with the wrong section code. Even if the amount matches, the section mismatch may cause issues at ITR processing if the income is declared under the correct head. The correct remedy is to ask the deductor to file a correction return on TRACES changing the section from 194C to 194J. The corrected credit typically reflects in Form 26AS within 7–10 working days.

A mid-size IT services company with 30–50 active domestic clients will typically process 90–150 invoices per quarter attracting 194J TDS. If each client deducts quarterly instead of monthly, Form 26AS shows 30–50 entries against 90–150 invoice rows in the accounts receivable ledger. The 3:1 ratio between ledger rows and Form 26AS rows is the primary reason quarterly 194J reconciliation takes 3–4 working days without automation.

Per bank. All accounts held at the same bank—current, savings, cash credit, overdraft—are aggregated when computing the ₹1 crore annual threshold. A business with three current accounts at the same bank has all three accounts' withdrawals pooled. If the same business has accounts at two separate banks, each bank tracks its own ₹1 crore limit independently.

Yes. Section 194N applies to all account types including business current accounts, savings accounts, cash credit accounts, and overdraft accounts. The section does not distinguish between individual and business account holders; it applies based on withdrawal volume alone.

194N TDS appears in Form 26AS Part A1. The deductor is the bank branch, identified by the bank's TAN (not your company's TAN). The section code is 194N. You can download Form 26AS from TRACES at https://www.tdscpc.gov.in after the bank files its quarterly TDS return. The update typically appears 3–7 days after the return is processed.

Yes. TDS deducted under 194N is treated as advance tax. When you file your income tax return for the year, the 194N TDS credit from Form 26AS is set off against your total tax liability. If TDS deducted exceeds your tax due, the surplus is refunded by the Income Tax Department, typically within 30–60 days of return processing.

The 5% rate applies when the account holder has not filed income tax returns for all three preceding financial years for which the ITR filing deadline has passed. It is not applied retroactively; it takes effect from the date the bank determines that the ITR non-filing condition is met, and continues for the remainder of that financial year.

No. Section 194Q applies only when the buyer's gross turnover in the preceding financial year exceeds ₹10 crore. A buyer with ₹8 crore turnover does not deduct TDS under 194Q, regardless of purchase volume from any single seller.

Historically, when both could apply, Section 194Q took precedence — the buyer deducted TDS at 0.1% and the seller did not collect TCS. Note that Section 206C(1H) (TCS on sale of goods) is inapplicable since 1 April 2025 under the Finance Act 2025 proviso, and under the Income-tax Act 2025 there is no successor TCS code for goods sale; Section 194Q (now §393(1) Sl. 8(ii) at code 1031 from 1 April 2026) is the operative TDS provision on goods purchase.

Cumulative purchase value must be tracked per seller PAN across the financial year. Most buyers configure an alert in their ERP or accounts payable system to flag when purchases from a single vendor approach ₹48–49 lakh. Once cumulative purchases cross ₹50 lakh, TDS at 0.1% applies on every subsequent payment to that seller for the remainder of the financial year.

TDS under 194Q is deducted on the invoice value exclusive of GST. CBDT's FAQ circular clarified that where GST is shown separately on the invoice, TDS should be calculated only on the taxable value, not on the GST component.

The seller sees the TDS in Form 26AS Part A1, with the buyer's TAN appearing as the deductor. The section code is 194Q. Sellers—particularly smaller manufacturers—should verify Part A1 each quarter, since many receive payments net of 0.1% TDS without prior notice from buyers who crossed the threshold mid-year.

The rate is 1% on the gross amount paid or credited to the seller by the e-commerce operator. For individual and HUF sellers with PAN on record, the rate is 1%. Without PAN, TDS is deducted at 5% under Section 206AA.

For individual and HUF sellers, the section applies only when aggregate payments in the financial year exceed ₹5 lakh. There is no threshold for companies and firms—TDS applies from the first rupee of credit or payment by the e-commerce operator.

The e-commerce operator reports TDS under Section 194O in Form 26QE, filed quarterly with the Income Tax Department. The seller sees the deduction in Form 26AS under the relevant part and can verify it through the AIS on the income tax portal.

The operator deducts TDS on the gross payment including GST components of fees or commissions, while the seller books revenue and fees net of GST. This creates a structural difference. Additionally, 26AS reflects deductions only after the operator files Form 26QE, which can lag the actual deduction by 30–60 days.

Each operator files and deducts separately. The seller must download Form 26AS or AIS and split entries by deductor TAN—Amazon's TAN, Flipkart's TAN, and Meesho's TAN are each distinct. Each platform's cumulative deduction must be matched independently against that platform's settlement statements for the quarter.

Yes, if the fair market value of product samples given to a single distributor exceeds ₹20,000 in a financial year. CBDT clarified that samples whose aggregate value stays within ₹20,000 per recipient per year are below the threshold and attract no TDS. Above ₹20,000, TDS at 10% applies on the full value, not just the excess.

The deductor must use the grossing-up mechanism. Since TDS cannot be recovered from a physical gift, the company providing the benefit must deposit the TDS from its own funds. For a ₹50,000 gift, the tax at 10% is ₹5,000—the company deposits ₹5,000 as TDS and the full gift of ₹50,000 is given to the recipient. The TDS cost becomes an additional business expenditure for the deductor.

The TDS appears in the recipient's Form 26AS Part A1, with the benefit-provider as deductor and the section code 194R. Since the recipient received a non-cash benefit, they must recognise the benefit value as business income and claim the Form 26AS TDS credit against their tax liability. The reconciliation task is to match the Form 26AS entry to the specific benefit received in the books.

Yes. If a company sponsors a dealer or distributor to attend a conference—paying for flights, accommodation, and registration—and the cost exceeds ₹20,000 for that dealer in the year, TDS at 10% applies under 194R. The deductor is the sponsoring company. CBDT has specifically cited sponsored travel as within the scope of Section 194R.

No. The company depositing 194R TDS on a non-cash benefit receives no input credit. The TDS paid is a cost to the deductor. The benefit of the credit goes entirely to the recipient, who claims it in Form 26AS as advance tax paid on the benefit income they must declare in their income tax return.

The rate is 1% on the consideration paid for the transfer of any virtual digital asset. For specified persons—individuals or HUFs with business turnover below ₹1 crore or professional receipts below ₹50 lakh in the preceding year—TDS applies only when aggregate VDA consideration in the financial year exceeds ₹50,000. For all other taxpayers, the threshold is ₹10,000.

Crypto exchanges file TDS returns in Form 26QF on a quarterly basis. Other deductors—such as corporate buyers or P2P platform operators—file in Form 26Q under Section 194S. The deductee sees the TDS credit in Form 26AS and the Annual Information Statement (AIS) on the income tax portal.

Yes. TDS credit under Section 194S can be claimed in the ITR regardless of whether the VDA transaction resulted in a profit or loss. Section 115BBH prohibits offsetting VDA losses against other income, but it does not restrict the TDS credit claim. The credit reduces overall tax liability, even if the underlying VDA income is taxed separately at 30%.

In a peer-to-peer transfer facilitated by a P2P exchange platform, the platform itself is responsible for deducting TDS if it acts as the facilitator. In a direct off-platform P2P trade, the buyer is the deductor. The buyer must have a TAN, deposit the TDS, and file a return in Form 26Q. Failure to deduct makes the buyer a defaulter under Section 201.

TDS under Section 194S is calculated on the full consideration paid for the VDA transfer, regardless of whether it is in cash, crypto, or a combination. If the consideration is in kind (e.g., one cryptocurrency exchanged for another), the fair market value of the VDA received is used as the base. The deductor must convert this to INR at the applicable rate on the date of transfer.

Not for every payment. Payments below ₹5 lakh per financial year, and certain specified categories listed in Rule 37BB (such as imports, airline tickets, and shipping freight), are exempt from Form 15CA/15CB. For all other remittances, Form 15CA must be filed online and Form 15CB (CA certificate) must be obtained before the bank processes the transfer.

The lower of the DTAA rate or the domestic Section 195 rate applies. For example, India's DTAA with Singapore specifies 15% on royalties, whereas the domestic rate is 20%—so 15% is applied. If the non-resident has a Permanent Establishment in India, the business income may instead be taxed as Indian-sourced income, potentially at a higher rate.

The non-resident must furnish a Tax Residency Certificate (TRC) from their home country's tax authority and a self-declaration in Form 10F. Once these are provided to the Indian payer, the DTAA rate or nil rate applies. For reconciliation, maintain a file linking each payment to the TRC/Form 10F on record, and verify that Form 26AS Part A reflects the reduced rate actually deducted.

It depends on characterisation. If the subscription grants a right to use software (the user cannot access or reproduce the underlying code), Indian courts and CBDT circulars have held it is business income, not royalty—TDS may not apply if the US company has no Permanent Establishment in India. If the arrangement grants a licence to the underlying IP, it may be taxed as royalty at 15% under the India-US DTAA. Each contract must be reviewed individually.

The Indian payer (deductor) deposits the TDS using their own TAN and files a TDS return for Section 195. The entry appears in the non-resident's Form 26AS Part A, identified by the deductor's TAN, PAN of the non-resident (if they have one), section code 195, and quarter. The update lag is typically 3–7 days after the quarterly return is processed on TRACES.

A vendor is a specified person under Section 206AB if two conditions are both met: first, they have not filed income tax returns for both of the two financial years immediately preceding the current year (for which the return filing due date under Section 139(1) has passed); and second, the aggregate TDS and TCS in their account was ₹50,000 or more in each of those two years. Both conditions must be satisfied — a vendor who missed filing for only one of the two years, or whose TDS was below ₹50,000 in either year, is not a specified person.

The rate for a specified person is the highest of three: twice the rate specified in the relevant TDS section, twice the rate in force under the Finance Act, or 5%. For Section 194J (professional fees at 10%), twice the rate is 20%, which is higher than 5%, so 20% applies. For Section 194C (contractor payments at 1–2%), twice the rate is 2–4%, which is below 5%, so 5% applies. Always compare the doubled rate against 5% and apply the higher figure.

TRACES recommends running the Compliance Check before each payment cycle for vendors above the relevant threshold. In practice, a vendor's specified person status can change between financial years — a vendor who was non-compliant in FY 2022-23 and FY 2023-24 may have filed returns by the time FY 2025-26 payments are processed, which would remove their specified person status. Running the check annually is insufficient; it should be part of the payment authorisation workflow for each vendor where TDS applies.

Section 206CCA applies the same higher-rate principle to Tax Collected at Source (TCS) rather than TDS. It applies to sellers who are required to collect TCS but are dealing with buyers who are specified persons. The threshold conditions are identical to 206AB: two preceding years of non-filing and TDS/TCS of ₹50,000 or more in each year. The higher rate for 206CCA is twice the applicable TCS rate or 5%, whichever is higher.

If the deductor applies the standard section rate to a vendor who is a specified person, the shortfall is treated as short deduction under Section 201. The deductor is treated as an assessee in default and is liable for interest under Section 201(1A) at 1% per month on the shortfall from the date it should have been deducted, plus penalty under Section 271C equivalent to the amount of the short deduction. The TRACES Compliance Check output serves as the primary defence — it documents that the deductor took reasonable steps to verify status before payment.

The TCS rate on scrap under Section 206C(1) is 1% of the sale consideration. This applies when any person sells scrap to a buyer. There is no minimum threshold for scrap—TCS applies from the first rupee of the transaction value.

The Finance Act 2023 increased the TCS rate on remittances under the Liberalised Remittance Scheme (LRS) to 20% effective 1 October 2023, for purposes other than medical treatment and education. Remittances for medical treatment and education remain at 5%. Overseas tour packages are taxed at 20% regardless of purpose.

TCS collectors file quarterly returns in Form 27EQ. The filing deadlines are 15 July (Q1), 15 October (Q2), 15 January (Q3), and 15 May (Q4). The TCS certificate issued to the buyer is Form 27D, which must be generated from TRACES.

The buyer can claim the TCS deducted by the seller as a credit against their income tax liability, similar to TDS. The credit appears in Form 26AS Part C. The buyer must match the TCS amount, the collector's PAN/TAN, and the section code in Form 26AS against the purchase invoice and Form 27D certificate before filing.

Historically, when both Section 194Q (TDS by buyer) and Section 206C(1H) (TCS by seller) could apply to the same goods transaction, Section 194Q took precedence. Section 206C(1H) is inapplicable since 1 April 2025 under the Finance Act 2025 proviso, and under the Income-tax Act 2025 there is no successor TCS code for goods sale; Section 194Q (now §393(1) Sl. 8(ii) at code 1031 from 1 April 2026) is the operative TDS provision on goods purchase, and the seller does not collect TCS on goods sale. For legacy entries from pre-1-April-2025 periods, the overlap remains relevant in audit and correction-statement workflows.

Form 26AS is the Tax Credit Statement — it shows TDS deducted by each deductor (identified by TAN), the amount deposited to the government, and the credit available against the deductee's tax liability. AIS (Annual Information Statement) is a broader document that includes Form 26AS data plus information from Statement of Financial Transactions (SFT) sources, such as bank interest, mutual fund redemptions, and high-value transactions. For TDS reconciliation, Form 26AS is the primary document; AIS is used to cross-check completeness and to catch cases where TDS appears in AIS before the deductor's return has updated Form 26AS.

Log into TRACES as a deductee (using PAN credentials). Navigate to 'My Account' and select 'View Form 26AS'. Choose the relevant financial year and the file format (PDF for review, XML for structured data extraction). For bulk reconciliation, the XML format is preferable — it can be parsed into columns by section, TAN, quarter, and amount, matching directly against the TDS receivable ledger in your ERP. The PDF version is password-protected with the date of birth of the PAN holder.

Yes. Deductors should verify challan status on TRACES before filing each quarterly TDS return. Log into TRACES as a deductor (TAN credentials), go to 'Statements/Payments', and select 'Challan Status'. Enter the BSR code and challan serial number, or the challan date range, to confirm whether each deposit is reflecting in OLTAS. If a challan shows 'unmatched', the BSR code or serial number in the return entry must be corrected before filing — otherwise the return will contain mismatches that require a C2 correction later.

After a TDS return is accepted by the TRACES processing system, the data typically becomes available for download (Form 16A, challan status, 26AS updates) within 3–5 business days. During peak periods — around quarterly return deadlines (31 July, 31 October, 31 January, 31 May) — processing may take up to 7 business days. For deductees, Form 26AS reflects the deductor's quarterly return data after TRACES processes the return, not at the time of challan deposit.

The TRACES Compliance Check for Section 206AB/206CCA allows deductors to upload a list of vendor PANs and receive a status for each: compliant or specified person (non-filer triggering higher TDS). It should be run before each payment cycle for vendors above the relevant section threshold, not just at the start of the financial year. A vendor's ITR filing status can change during the year, and the check date and result must be retained as audit evidence for the rate applied at each payment.

TDS deducted during March 2026 must be deposited by 30 April 2026. This is the only month where the deposit deadline extends beyond the standard 7th-of-the-following-month rule. The Q4 TDS return (January–March) is then due by 31 May 2026.

Section 40(a)(ia) disallows 30% of any expense where TDS was required to be deducted or deposited but was not. The disallowance applies for the year in which the expense was booked. During year-end reconciliation, finance teams must confirm that every expense above the TDS threshold — contractor fees, professional fees, rent, interest — has TDS either deducted or covered by a lower deduction certificate under Section 197. Any gap at 31 March creates a 30% disallowance risk on that expense.

Yes, but with a reconciling item. Form 26AS reflects TDS only after the deductor files the quarterly return — which is due 31 May for Q4. At 31 March, TDS deducted in Q4 by counterparties will not yet appear in Form 26AS. Finance teams should book the receivable based on supporting evidence (TDS certificates, payment advice, agreements) and create a reconciling item noting that TRACES reflection is pending. AIS and Form 26AS should be reviewed again after 31 May to confirm the credit appears.

TDS deducted on 31 March must be deposited by 30 April. At the March 31 balance sheet date, this amount sits as TDS payable — a current liability. Confirm the challan was deposited before 30 April and that OLTAS reflects the deposit. If the deposit is delayed past 30 April, interest under Section 201(1A) at 1.5% per month accrues from 31 March, and this should be provisioned in the year-end accounts.

Advance payments made in Q4 where TDS was deducted create a timing issue: the TDS deduction is recorded in the Q4 return, but the expense may be capitalised or carried as an advance in the balance sheet rather than recognised as an expense in FY 2025-26. In this case, TDS payable is correctly accounted for in Q4, but the corresponding expense deduction under Section 40(a)(ia) applies only when the expense is recognised. Document the advance nature and the TDS deduction separately to avoid incorrect disallowance treatment.

For volumes above 500 inward invoices a month, daily IMS pulls are recommended. Suppliers file GSTR-1 throughout the month, so invoices appear in IMS on a rolling basis. Daily processing spreads the exception-handling load across 20 working days instead of compressing it into the 14th-to-20th window. For volumes below 500, a twice-monthly cadence (around the 10th and the 14th) is workable.

Yes — until GSTR-3B is filed for that month. An Accept can be changed to Reject, a Reject to Accept, and Pending to either decision. Once GSTR-3B is filed, the IMS state for that period is locked. Any subsequent change requires the supplier to file a GSTR-1 amendment, which then re-surfaces the invoice in a later IMS cycle.

The audit trail must link each ITC claim in GSTR-3B Table 4 to a purchase register entry, a corresponding IMS Accept decision, the resulting GSTR-2B line, and proof of supplier payment within 180 days under Rule 37. The IMS Accept timestamp from the portal is the new evidence element added by the October 2024 regime. Software-generated audit packs typically bundle these four artefacts per invoice.

The GST portal exposes a separate IMS dashboard per GSTIN. A consolidated workflow pulls each dashboard via the portal, normalises the data into a single decision queue keyed on supplier GSTIN plus invoice number, applies the same purchase-register-match logic for each entity, then posts decisions back to the relevant GSTIN. Shared service centres typically maintain one purchase master with a GSTIN-to-state mapping table.

The invoice will not appear in IMS or GSTR-2B for the current month. Three options: hold the ITC claim and follow up with the supplier for next month's filing, defer the ITC until the supplier files (within the Section 16(4) time limit), or escalate to the supplier-management team for repeat offenders. ITC cannot be claimed in GSTR-3B against an invoice that is not in GSTR-2B.

Section 17(5) of the CGST Act, 2017 is a non-obstante clause that lists specific categories of goods and services where input tax credit is permanently blocked — meaning ITC cannot be claimed even if the purchase is used in the course or furtherance of business. The blocked list includes motor vehicles, food and beverages, outdoor catering, health and fitness services, travel benefits like LTC, club memberships, and works contracts for immovable property.

No. ITC on motor vehicles used for transporting employees to and from their workplace is blocked under Section 17(5)(a). The exception applies only when the vehicle is used for transporting goods, transporting passengers as a taxable service (e.g., a cab aggregator), running a driving school, or for motor vehicle testing. A company providing a company cab to employees cannot claim ITC on that vehicle purchase or GST paid on the cab service.

Generally no. ITC on food, beverages, and outdoor catering is blocked under Section 17(5)(b). The sole exception is when the provision of such food is a statutory obligation — for example, canteens maintained under Section 46 of the Factories Act, 1948 for factories employing more than 250 workers. In that case, ITC on canteen services at the 5% GST rate is available. For all other employee meal or event catering expenses, the credit is blocked.

Blocked ITC must be reversed in GSTR-3B Table 4(B)(1), labelled 'ITC Available but Not Availed (Others)'. If the credit was already posted to the electronic credit ledger in a prior month, a reversal entry in Table 4(B) is required in the current month. A reconciliation of GSTR-2B credits against Section 17(5) categories should be performed before every GSTR-3B filing, since GSTR-2B reflects what the supplier reported — not whether the expense is eligible under your business.

Wrongly claimed ITC under Section 17(5) is treated as erroneous refund or excess ITC under Section 74 (if fraud or suppression is alleged) or Section 73 (if no intent). Interest under Section 50(3) is levied at 24% per annum on the excess ITC from the date of claim. A penalty of 10% of the tax amount (minimum ₹10,000) applies under Section 73; under Section 74, the penalty can be 100% of the tax involved. Additionally, the supplier's GSTIN can be flagged during departmental audit.

DRC-01B is a system-generated intimation issued on the GST portal when the output tax liability declared in GSTR-1 (and IFF, where applicable) for a tax period materially exceeds the tax actually paid in GSTR-3B for the same period. Rule 88C of the CGST Rules, introduced via Notification 26/2022-CT, codifies the threshold and procedural flow. Part A is the auto-generated intimation; Part B is the taxpayer's reply.

Per Rule 88C, DRC-01B is triggered when the GSTR-1 vs GSTR-3B liability gap for a tax period exceeds both an absolute floor and a percentage floor as notified — currently a gap above ₹25 lakh and above 20 percent of the GSTR-3B tax paid. Both conditions must be satisfied. Smaller gaps do not draw DRC-01B but may still surface during audit or in DRC-01C-style ITC checks.

Seven days from the date of intimation. Within that window the taxpayer must either pay the differential tax along with interest under Section 50 through Form DRC-03 and report the payment in Part B, or file a reasoned reply in Part B explaining why no short payment exists. Failure to act within 7 days blocks GSTR-1 filing for the next tax period and opens the path to a Section 73 or Section 74 demand.

Yes. If the Part B reply is not filed within 7 days, or if the officer is not satisfied with the explanation, the matter is taken up under Section 73 (non-fraud) or Section 74 (fraud, suppression, wilful misstatement). The proceedings end in a DRC-07 summary order quantifying tax, interest, and penalty. DRC-01B is best treated as a self-correction window before formal adjudication begins.

A period-wise reconciliation of GSTR-1 outward liability against GSTR-3B Table 3.1, broken down by tax head (IGST, CGST, SGST, cess); credit note linkage to original invoices; amendments filed in later periods that explain the gap; DRC-03 challan if differential tax was paid; and the reply narrative quoting Rule 88C. Keep this bundle for at least six years to cover the Section 74 limitation.

No. DRC-01B is a pre-adjudication notice that gives you an opportunity to explain the liability mismatch between GSTR-1 and GSTR-3B before a formal demand is raised. If you reply within seven days with a valid explanation — or make the payment via DRC-03 — no further action is taken for that period. If you do not reply within seven days, the GST department may proceed to issue a proper demand notice under Section 73 (non-fraud) or Section 74 (fraud or suppression) depending on the nature of the discrepancy.

Yes. In your DRC-01B Part B reply, you can select option (c) — Other reasons — and provide a detailed explanation of why the apparent mismatch does not represent an actual liability shortfall. Common legitimate reasons include an ITC adjustment in GSTR-3B that reduced net liability, credit notes issued to customers that reduced taxable turnover, or a data entry difference between GSTR-1 and GSTR-3B that has already been corrected in a subsequent amendment. Supporting documents should be retained even if not submitted with the reply.

You have seven days from the date the DRC-01B is issued to file your reply on the GST portal. The reply is filed as DRC-01B Part B under Services → Returns → DRC-01B. Missing this seven-day window does not automatically result in a demand notice, but it removes the opportunity to present your explanation before the department initiates adjudication proceedings under Section 73 or 74.

DRC-01B is triggered when the tax liability declared in GSTR-1 (or IFF for QRMP filers) exceeds the tax paid in GSTR-3B by more than ₹1 lakh OR more than 20% of the GSTR-3B liability amount, whichever is lower. If your GSTR-3B liability is ₹4 lakh and GSTR-1 shows ₹5 lakh, the difference is ₹1 lakh (25% of 3B liability). Since ₹1 lakh equals the rupee threshold, DRC-01B would be triggered. Organisations with consistently high throughput and minor month-end adjustments are most frequently triggered.

DRC-01B covers the liability mismatch — it is triggered when your GSTR-1 output tax liability is higher than the tax paid in GSTR-3B. DRC-01C covers the ITC mismatch — it is triggered when the ITC you claimed in GSTR-3B is higher than the ITC available in GSTR-2B. Both are auto-generated by the GST system after GSTR-3B filing, both require a reply within seven days, and both can escalate to Section 73/74 demand proceedings if unanswered. An organisation can receive both notices in the same period if they have both a liability underpayment and an excess ITC claim.

Yes, IGST paid on imports does not appear in GSTR-2B — it is reflected in ICEGATE records and must be claimed via Table 4A(1) of GSTR-3B separately. If you claim IGST import ITC in GSTR-3B without the corresponding entry in GSTR-2B, the difference can trigger DRC-01C. In your DRC-01C reply, use option (b) — claiming that the excess ITC is eligible under IGST on imports — and provide the Bill of Entry reference numbers and ICEGATE acknowledgement as supporting evidence.

If you do not reply to DRC-01C within seven days, the GST department may initiate adjudication proceedings under Section 73 (non-fraud) or Section 74 (fraud/suppression). Section 73 proceedings can result in a demand for the excess ITC amount plus 18% interest per annum and a 10% penalty on the tax due. Section 74 proceedings (invoked when suppression or misstatement is alleged) carry a 100% penalty. Proactive reply within seven days, even with option (c) — other reasons — preserves the opportunity to explain the claim before a demand order is passed.

DRC-01C is triggered when ITC claimed in GSTR-3B exceeds ITC available in GSTR-2B by more than ₹1 lakh OR more than 20% of GSTR-2B ITC, whichever is lower. For example, if GSTR-2B shows ₹8 lakh of ITC and you claimed ₹10 lakh in GSTR-3B, the excess is ₹2 lakh (25% of GSTR-2B). Since ₹1 lakh is lower than ₹2 lakh, the ₹1 lakh threshold applies and DRC-01C is triggered. The notice is issued from FY 2024-25 onwards after each GSTR-3B filing.

Rule 88D triggers a system-generated DRC-01C Part A when the ITC claimed in Table 4A of GSTR-3B exceeds the ITC available in GSTR-2B for a tax period by more than ₹25 lakh in absolute terms OR by more than 20% in percentage terms — whichever threshold is lower for that taxpayer's profile. The GSTN compares the two values automatically after GSTR-3B filing.

Seven days from the date of intimation. The reply is filed electronically in Form DRC-01C Part B on the GST portal. Failure to reply within seven days triggers Rule 59(6) — the GSTR-1 (or IFF) for the subsequent tax period cannot be filed until either the differential is paid or the Part B reply is submitted.

Either (a) pay the differential ITC amount along with interest under Section 50 by reporting it in DRC-03 and quoting the ARN in Part B, or (b) furnish a reasoned explanation for the mismatch with supporting reconciliation — for example, supplier filed GSTR-1 late, credit note timing, ineligible credit reversed in a later period, or genuine supplier non-filing being pursued.

No. The DRC-03 payment is the financial settlement, but Part B of DRC-01C must still be filed on the portal quoting the DRC-03 ARN. Until Part B is submitted, Rule 59(6) restrictions remain active and the case stays open in the officer's dashboard for potential follow-up scrutiny.

If the excess ITC was never actually utilised against output liability — for example, it sat in the electronic credit ledger and the supplier's GSTR-1 was filed in the following month — Section 50(3) interest at 18% applies only to the period of wrongful availment of utilised credit. Documenting the ledger movement is essential to defend a no-interest position in Part B.

Taxpayers above the notified turnover threshold must generate an Invoice Reference Number on the IRP within 30 days of the invoice date. Notification 17/2022 and subsequent notifications staged the threshold downward (currently INR 5 crore aggregate turnover). Invoices issued without an IRN within this window are treated as not issued under Rule 48(5), and the recipient cannot claim ITC.

An IRN can be cancelled on the IRP within 24 hours of generation, and only if no active e-Way Bill exists against it. After 24 hours, cancellation on the IRP is not permitted. The invoice must instead be reversed in books through a credit note, which itself must be reported to the IRP.

Yes. IRNs reported to the IRP flow into the GSTN system and pre-populate the relevant tables of GSTR-1 (B2B, exports, credit/debit notes). Taxpayers must still verify and file GSTR-1, but the auto-flow reduces manual entry. Any IRN missing from the IRP repository will also be missing from auto-populated GSTR-1.

There are six designated IRPs (NIC IRP-1, NIC IRP-2, and four GSTN-authorised private IRPs). If one IRP is unavailable, taxpayers can fall back to another. Documented IRP downtime is recognised by CBIC for relief in genuine cases, but the 30-day window itself is not extended by routine outages.

Pull the IRP cancellation register for the period, match each cancelled IRN back to the ERP invoice document number, and verify that the ERP entry has been reversed by credit note or void. Any cancelled IRN still live in the ERP is a revenue overstatement and a GSTR-1 mismatch waiting to surface.

An e-invoice in India is a JSON-format invoice uploaded to the Invoice Registration Portal (IRP), which validates the data and returns a unique Invoice Reference Number (IRN) and a digitally signed QR code. The e-invoice mandate is currently applicable to businesses with annual aggregate turnover exceeding ₹5 Crore (threshold effective August 1, 2023). B2C transactions, financial credit notes, and certain exempt supplies are outside the e-invoice mandate.

No. E-invoicing auto-populates the supplier's GSTR-1 and the buyer's GSTR-2B, which reduces data entry errors. However, it does not eliminate reconciliation. New mismatches arise from cancelled IRNs that remain in GSTR-2B until a credit note is processed, invoices from multiple IRP portals that need to be consolidated, and B2C or exempted supplies that are not covered by e-invoicing and still require manual matching.

An e-invoice can be cancelled within 24 hours of IRN generation through the IRP. After 24 hours, cancellation through the IRP is not possible; the supplier must issue a credit note. If the IRN was cancelled within 24 hours, the entry should not appear in the buyer's GSTR-2B. If cancellation happened after auto-population to GSTR-1, the supplier must amend GSTR-1 and the corresponding GSTR-2B entry of the buyer will be adjusted in the next GSTR-2B cycle (generated on the 14th of the following month).

No. Once an IRN is generated by the IRP, the e-invoice data is locked. Amendments to invoice value, GST rate, or supply details cannot be made to the original IRN. The correct process is to issue a credit note (for reduction) or a debit note (for increase) referencing the original IRN. The credit or debit note must itself be e-invoiced if the supplier is within the e-invoice mandate threshold of ₹5 Crore turnover.

As of August 1, 2023, e-invoicing is mandatory for all registered taxpayers with annual aggregate turnover exceeding ₹5 Crore in any preceding financial year from 2017-18 onward. The threshold has been progressively reduced from ₹500 Crore (October 2020) to ₹100 Crore (January 2021), ₹50 Crore (April 2021), ₹20 Crore (April 2022), ₹10 Crore (October 2022), and ₹5 Crore (August 2023). Further reductions to ₹1 Crore or below are anticipated.

GSTR-9 is the annual GST return that consolidates all monthly or quarterly returns filed during a financial year. Filing is mandatory for registered taxpayers with annual aggregate turnover exceeding ₹2 Crore. Composition taxpayers file GSTR-9A (not GSTR-9). Input service distributors, casual taxable persons, non-resident taxable persons, and persons deducting TDS under Section 51 are exempt from GSTR-9.

GSTR-1 is a monthly outward supply statement filed by the 11th of each month; GSTR-3B is a monthly summary return filed by the 20th. GSTR-9 is the annual consolidation of both — it requires all 12 GSTR-1 and GSTR-3B figures to be reconciled and summarised into a single annual return. GSTR-9 also captures final ITC reversals under Rule 42 and 43 for the full year, which may differ from month-wise provisional reversals.

GSTR-9 must be filed by 31 December of the year following the financial year. For FY 2024-25, the deadline is 31 December 2025. The deadline has historically been extended by CBIC notification, but businesses should target the statutory date. Late filing attracts a fee of ₹200 per day (₹100 CGST + ₹100 SGST), subject to a maximum of 0.25% of annual turnover.

GSTR-9C is a reconciliation statement between the audited annual accounts and GSTR-9. From FY 2020-21 onward, GSTR-9C is self-certified (no CA/CMA signature required) for taxpayers with turnover between ₹5 Crore and ₹10 Crore. For taxpayers with turnover exceeding ₹10 Crore, GSTR-9C must be certified by a chartered accountant or cost accountant. GSTR-9C is mandatory for all taxpayers with annual aggregate turnover exceeding ₹5 Crore.

ITC differences arise when credits were claimed in GSTR-3B but are not reflected in GSTR-2B for the corresponding period, or when Rule 42/43 provisional reversals during the year differ from the annual final calculation. Any excess ITC shown in GSTR-9 Table 7 (ITC Reversals) over what was reversed in GSTR-3B must be paid as tax with interest at 18% per annum. Short-claimed ITC from prior months can be corrected in GSTR-9 up to the November return of the next financial year — the annual return is the final opportunity.

A GST credit note is a document issued under Section 34 of the CGST Act when the taxable value or GST amount on a previous supply is reduced — typically due to goods return, post-sale price revision, or discount agreed after invoice. The supplier must issue a credit note when the original supply value decreases, and the buyer must correspondingly reverse the ITC already claimed on the original invoice.

Under Section 34, a credit note for any supply in a financial year must be issued before the earlier of: (a) September 30 of the following financial year, or (b) the date on which the annual return for that year is filed. For example, a credit note for an April 2025 supply must be issued by September 30, 2026 (or the GSTR-9 filing date for FY 2025-26, if earlier).

No. A credit note appears in the buyer's GSTR-2B only if the supplier links it to the original invoice reference when reporting it in GSTR-1. If the supplier reports the credit note without the original invoice reference — or with an incorrect document number — it appears as an unlinked credit note in GSTR-2B, which is harder for the buyer to match to their purchase register. The buyer still has the ITC reversal obligation but must identify the match manually.

The reconciliation requires 3-way matching: (1) credit note received from supplier (physical/email document), (2) credit note appearance in buyer's GSTR-2B (negative ITC entry), and (3) ITC reversal posted in buyer's GSTR-3B Table 4(B). All three must reflect the same amount and tax head. If the GSTR-2B credit note appears in month N but the buyer's accounts team posts the reversal in month N+2, the intervening GSTR-3B filings will have an excess ITC claim — which is taxable with 18% interest.

If the buyer has claimed ITC on the original invoice and the supplier's credit note reduces that supply, but the buyer has not reversed the proportional ITC in GSTR-3B by the annual return filing date, the unreconciled ITC becomes a recoverable demand. GSTR-9 includes a specific reconciliation of ITC claimed versus ITC reversals — a discrepancy triggers a notice under Section 73 or Section 74 of the CGST Act, with interest at 18% per annum on the excess ITC from the date of claim.

No. The portal is structurally per-GSTIN. Each GSTIN has its own login or sub-login and its own IMS dashboard. A consolidated view is created outside the portal — a reconciliation tool pulls each dashboard, normalises the data, and presents a unified decision queue. Decisions are then posted back to the respective GSTIN dashboard.

Inter-state stock transfers within the same legal entity attract IGST and appear in IMS as inward invoices on the receiving GSTIN. They should always Accept since the dispatching GSTIN filed them. Internal controls should flag any IGST-bearing inward invoice that does not have a matched inter-state transfer on the dispatching side. Mismatches usually indicate one side filed and the other did not record the transfer in time.

Shared service centre: central AP team handles IMS for all GSTINs, running the same decision engine and posting to each dashboard. Decentralised: state finance teams own their GSTIN's IMS dashboard and apply local decision-making. Hybrid: central runs auto-recommendations, state teams override exceptions. The hybrid model is most common for groups with 5+ GSTINs.

Each supplier GSTIN files its own GSTR-1, even within the same PAN. A vendor with operations in Maharashtra, Karnataka, and Delhi files three separate GSTR-1s under three GSTINs. They appear as three separate suppliers in the buyer's IMS across the relevant buyer GSTINs. PAN-level consolidation happens in vendor master data, not in the GSTR-1 or IMS feed.

Rule 36(4) compliance is per-GSTIN. Each GSTIN's audit pack must independently link purchase register, IMS Accept timestamp, GSTR-2B line, and GSTR-3B Table 4 figure. The audit pack is typically structured as one per GSTIN per month, with a group-level consolidation report on top. The actor identity captured in each Accept must reflect the authorised user for that GSTIN.

Section 9(3) is a permanent reverse charge on a closed list of notified categories (GTA, advocates, director's remuneration, sponsorship, security services from non-body-corporate, import of services, and others under Notification 13/2017-CTR). Section 9(4) is a conditional reverse charge that applies when a registered recipient procures from an unregistered supplier, but it is currently restricted to notified classes of recipients — principally real-estate developers under Notification 7/2019-CTR.

Yes. Rule 46(c) of the CGST Rules requires the recipient liable to pay tax under reverse charge to issue a self-invoice when the supplier is unregistered. For Section 9(3) procurements from registered suppliers, the supplier issues the invoice marked as RCM applicable. Either way, a documented invoice must exist before ITC can be claimed.

No. Section 49(4) explicitly prohibits using the electronic credit ledger to discharge tax payable under reverse charge. RCM must be paid in cash through the electronic cash ledger. The ITC corresponding to that RCM payment can then be claimed in the same month, subject to the Section 17(5) blocked credit list.

Notification 7/2019-CTR requires real-estate promoters under the new rate scheme to procure at least 80 percent of inward supplies of goods and services by value from registered suppliers in a financial year. Any shortfall against the 80 percent threshold attracts RCM at 18 percent. Cement procured from unregistered suppliers attracts RCM at 28 percent regardless of the 80 percent test, and is excluded from the threshold computation.

Yes, where the supplier is covered by the e-invoice mandate and the transaction is a B2B supply notified under Section 9(3), the supplier must generate an IRN. For self-invoices raised under Rule 46(c) for purchases from unregistered persons, the recipient is not currently required to generate an IRN, but the self-invoice must still meet Rule 46 disclosures.

The main categories are: (1) zero-rated exports — with IGST payment or under Letter of Undertaking (LUT); (2) inverted duty structure — where input tax rate exceeds output tax rate causing ITC accumulation; (3) excess balance in the electronic cash ledger; (4) refund on finalisation of provisional assessment; and (5) refund of tax paid under wrong head (e.g., IGST paid but CGST+SGST was applicable).

A provisional refund of 90% of the claim amount must be sanctioned within 7 days of the acknowledgement date for export refunds. The final refund order must be issued within 60 days of the RFD-01 filing date. If the final refund is not issued within 60 days, interest at 6% per annum accrues on the delayed amount under Section 56 of the CGST Act.

The GST officer may partially reject a refund claim if the claimed ITC is disputed, the export documentation is incomplete, or the officer finds that certain inputs are not eligible. A partial sanction order (RFD-06) is issued specifying the rejected portion and the grounds. The taxpayer can appeal within 3 months of the order date. The sanctioned amount is credited separately; the rejected portion remains in the credit ledger pending appeal.

Yes. Under Section 56 of the CGST Act, if the refund is not paid within 60 days of the RFD-01 filing date, interest at 6% per annum is payable from the date immediately after the expiry of 60 days. For cases of fraudulent refund claims later recovered, Section 50 applies a higher 24% interest rate on recovery.

Exporters must match each shipping bill number and port code with the corresponding export invoice in GSTR-1. The ICEGATE system transmits export data to the GST portal automatically for zero-rated supplies. A mismatch in invoice value, GSTIN, or shipping bill date between GSTR-1 and the customs record blocks the automated refund. IT services exporters using LUT must additionally reconcile FIRC (Foreign Inward Remittance Certificate) amounts with the invoiced value to confirm realisation within the RBI-prescribed timeline.

GST TCS (Tax Collected at Source under Section 52 of the CGST Act) is collected by e-commerce operators — Amazon, Flipkart, Meesho, Swiggy, Zomato — on the net taxable value of supplies made by sellers through their platforms. The operator deducts TCS before releasing the seller's payout and deposits it against the seller's GSTIN.

The TCS rate is 1% of the net taxable value. For inter-state supplies, 1% IGST is collected. For intra-state supplies, 0.5% CGST and 0.5% SGST are collected separately. A seller in Maharashtra fulfilling orders to Karnataka customers will see 1% IGST TCS, while Maharashtra-to-Maharashtra orders attract 0.5% CGST + 0.5% SGST.

TCS credit appears in two places: (1) the seller's GSTR-2B, auto-populated from the operator's GSTR-8 filed by the 10th of the following month; and (2) Form 26AS Part F, which consolidates TCS credits across both income tax and GST frameworks for the seller's PAN.

Once the credit appears in GSTR-2B, the seller claims it by adjusting the TCS credit against output tax liability in GSTR-3B. The credit reduces net tax payable. If output tax is insufficient to absorb the credit in a given month, the balance carries forward to subsequent months — there is no direct cash refund mechanism for TCS credit under normal circumstances.

A mismatch means either the operator filed GSTR-8 with an incorrect taxable value, or the seller's own payout records are incomplete. The seller must raise a discrepancy with the operator's seller support team and obtain a corrected GSTR-8 before the 10th of the following month. Under Section 52, operators can revise GSTR-8 to correct errors, which then flows through to an updated GSTR-2B.

The most common causes are: (1) invoices uploaded in GSTR-1 but tax not paid in GSTR-3B for the same period — often because 3B was filed in a hurry using an estimated figure; (2) tax paid in GSTR-3B without filing the corresponding GSTR-1, typically when a business realises it has underpaid tax and tops up via 3B; (3) amendments filed in GSTR-1 via the amendment tables (9A, 9B, 9C) that are not mirrored in a corrected 3B; (4) e-invoices generated late in the period that missed the 3B but were included in GSTR-1 the following month. For a company with ₹5 crore monthly turnover, even a 1% misreporting variance amounts to ₹5 lakh in output tax exposure.

Yes. GSTR-1 can be amended in the next period using the amendment tables — Table 9A for B2B invoice amendments, 9B for credit note amendments, 9C for unregistered supply amendments. GSTR-3B cannot be amended directly; the correction is made by adjusting the output tax in the next period's 3B. If the mismatch resulted in short payment of tax, interest at 18% per annum is applicable from the due date of the original 3B until the date of payment. The filing deadline for GSTR-3B is the 20th of the following month, so a mismatch identified before that date can be corrected without any interest liability.

If GSTR-1 declares more output tax than GSTR-3B pays, GSTN treats this as short payment. The department can issue a ASMT-10 scrutiny notice requesting explanation, followed by a DRC-01 demand notice for the differential tax plus interest at 18% per annum and, in cases of deliberate suppression, a penalty of up to 100% of the tax amount. If the difference is due to a genuine data entry error in GSTR-1, the invoice should be amended in the next GSTR-1 using Table 9A and the corresponding tax should be adjusted in 3B. If it is a genuine short payment, the tax plus interest should be paid immediately via Form DRC-03.

Monthly, without exception. The GSTR-1 filing deadline is the 11th of the following month; GSTR-3B is due on the 20th. This nine-day gap between the two deadlines is the natural reconciliation window — finance teams should run the comparison after filing GSTR-1 on the 11th and before finalising GSTR-3B on the 20th. Businesses with more than 500 invoices per month should automate this comparison using purpose-built GST reconciliation software rather than rely on manual VLOOKUP matching, which does not scale and introduces its own reconciliation errors.

Yes. GSTN's ADVAIT analytics system compares GSTR-1 declared supply values with GSTR-3B tax payment values for every taxpayer every month. Discrepancies beyond a threshold (which varies by taxpayer risk profile) trigger automated scrutiny. The first communication is typically an ASMT-10 notice asking for reconciliation details. If the response is unsatisfactory or the discrepancy persists across multiple periods, a DRC-01 demand notice is issued. As of FY 2024-25, GSTN has significantly increased the frequency of automated scrutiny notices, meaning persistent mismatches that were ignored in earlier years are now being actively pursued.

GSTR-2A is a dynamic statement that updates in real time each time a supplier files their GSTR-1 or GSTR-5 return. It reflects all inward supply invoices reported against the taxpayer's GSTIN at any given moment and can change multiple times during a month. GSTR-2B is a static monthly snapshot generated on or around the 14th of the following month. It captures only invoices filed by suppliers up to the GSTR-1 deadline (11th of the month) and does not change once generated. Since the Finance Act 2022, GSTR-2B — not GSTR-2A — is the operative document for ITC claims under Rule 36(4) of the CGST Rules.

No. Under Rule 36(4) as amended effective 1 January 2022, ITC is restricted to amounts reflected in GSTR-2B for the period. If an invoice appears in GSTR-2A (because the supplier filed after the cut-off) but not in GSTR-2B, the ITC cannot be claimed for the current month. It will flow into the following month's GSTR-2B when that month's snapshot is generated — provided the supplier's late-filed GSTR-1 is captured before the next cut-off. Claiming ITC based on GSTR-2A alone constitutes excess ITC claiming, which attracts interest at 18% per annum on the excess amount.

GSTR-2B is generated by GSTN on the 14th of the month following the return period (for example, the GSTR-2B for March 2025 is available from 14 April 2025). The statement is compiled from supplier GSTR-1 and GSTR-5 filings that were submitted up to the 11th of the month (the GSTR-1 filing deadline for monthly filers). For QRMP scheme taxpayers, GSTR-2B is generated quarterly and reflects IFF filings for months 1 and 2, and the full GSTR-1 for month 3 of the quarter.

If a supplier files their GSTR-1 after the GSTR-1 deadline of the 11th (and after the GSTR-2B cut-off on or around the 13th), the invoices they report will not appear in the current month's GSTR-2B. They will instead appear in the next month's GSTR-2B. The recipient therefore cannot claim ITC on those invoices in the current period and must wait until the following month. This is a common situation with smaller vendors and subcontractors who are habitual late filers — each month of late filing defers ITC by one full month. For a business buying ₹50 lakh worth of taxable services monthly from a consistently late supplier at 18% GST, this deferral is ₹9 lakh of ITC per cycle.

Yes, but for a different purpose. GSTR-2A is still useful for: (1) monitoring supplier filing behaviour during the month — finance teams can check GSTR-2A mid-month to identify which suppliers have not yet filed; (2) chasing suppliers before the 11th GSTR-1 deadline to ensure invoices appear in the current month's GSTR-2B; (3) dispute resolution — if a supplier claims they have filed but the invoice is absent from GSTR-2B, GSTR-2A shows whether the filing was made before or after the cut-off. GSTR-2A is a monitoring tool; GSTR-2B is the compliance instrument. Both should be part of a structured monthly ITC reconciliation workflow.

GSTR-2B is generated on the 14th of each month and incorporates all IMS decisions taken up to that point. Decisions taken between the 14th and the 20th (GSTR-3B filing deadline) update GSTR-2B before it is used for ITC claim. After the 20th, the GSTR-2B for that period is locked. Any subsequent change requires a supplier-side GSTR-1 amendment that creates a new entry in a later IMS cycle.

An invoice marked Pending in IMS sits in the buyer's review queue for up to 30 days from the date it appears in IMS. If no Accept or Reject decision is taken within 30 days, the invoice is treated as Accepted by default and flows into the next GSTR-2B. This is the deemed-accept mechanism — it prevents indefinite deferral. Finance teams must therefore work the Pending queue at least monthly to avoid losing the Reject option.

Reject removes the invoice from the current and future GSTR-2B unless the supplier files an amendment. Pending defers the decision by up to 30 days, after which deemed-accept kicks in. The timing risk of Pending is that an unwatched invoice can quietly become Accepted past the 30-day mark, claiming ITC the buyer would otherwise have rejected. Reject is final and explicit; Pending is provisional and time-bound.

Supplier files GSTR-1 by the 11th of the month (or rolling earlier). The IMS dashboard is populated by the 12th with all such filings. Buyer reviews and acts on each invoice before the 14th cut-off. GSTR-2B is generated on the 14th reflecting current IMS state. Buyer can continue to act on IMS through the 20th, updating GSTR-2B before GSTR-3B filing. The five-stage timing is filing → dashboard population → action window → generation → final action window.

Pre-IMS, ITC in GSTR-3B was claimed against the auto-populated GSTR-2B. Post-IMS, ITC is claimed against the IMS-decided GSTR-2B — only invoices Accepted (explicitly or by 30-day default) appear and are eligible. Rejected invoices are excluded. Pending invoices not yet aged into deemed-accept are also excluded. The mechanical formula is the same; the upstream content of GSTR-2B is now controlled by buyer decisions.

GSTR-2B is auto-drafted on the 14th of the month following the tax period. It captures supplier filings between the 12th of the prior month and the 11th of the current month, and remains static for that tax period — invoices uploaded by suppliers after the 14th flow into the next month's 2B.

No. Section 16(2)(aa) of the CGST Act requires the invoice to be reflected in GSTR-2B before ITC can be claimed. The provisional 10 percent rule under Rule 36(4) was withdrawn from 1 January 2022, so any invoice missing from 2B must be parked until the supplier files and it appears in a later 2B.

Under Section 16(4), ITC on an invoice can be claimed up to the 30th of November of the financial year following the year of the invoice, or the date of filing the annual return, whichever is earlier. After this cut-off the credit is permanently lost.

From October 2025, IMS lets buyers explicitly accept, reject, or keep pending each invoice that suppliers upload. The 2B is generated based on those actions. Rejection or pending status means the invoice will not appear in 2B for that tax period, and the buyer cannot claim ITC against it.

Check the filing window — if the supplier filed after the 11th, the invoice will appear only in the next month's 2B. Also verify the GSTIN, invoice number, and date format match exactly. If the supplier filed against a wrong GSTIN, they must amend through GSTR-1A or the next month's amendment table.

GSTR-9C is mandatory for every registered person whose aggregate turnover during a financial year exceeds ₹5 crore. The reconciliation statement must be self-certified by the taxpayer from FY 2020-21 onwards. Prior to that, it required certification by a Chartered Accountant. The due date aligns with GSTR-9, which is typically 31 December of the following financial year, though extensions are common.

Table 12A captures ITC as per the audited financial statements or books of account. Table 12E captures ITC as declared in the GSTR-9 annual return. Table 12F shows the unreconciled difference between 12A and 12E. Table 13 requires the taxpayer to provide reasons for every difference reported in 12F. These four tables together form the core of the three-way reconciliation that GSTR-9C enforces.

Excess ITC that does not appear in GSTR-2B attracts interest at 18% per annum under Section 50(1) of the CGST Act from the date of availment to the date of reversal. Section 122(1)(ii) imposes a penalty of ₹10,000 or the tax amount involved, whichever is greater, for claiming ITC without an invoice or valid document. For fraud cases, Section 74 allows a 100% penalty on the tax amount, and Section 132 provides for criminal prosecution where the ITC amount exceeds ₹5 crore.

IMS, live since October 2024, adds an accept/reject/pending status to every inward invoice before it flows into GSTR-2B. This creates a fourth data point in the reconciliation chain: the IMS action status must now align with the GSTR-2B inclusion, the GSTR-3B claim, and the books entry. An invoice accepted in IMS but not reflected in GSTR-2B due to the supplier's filing delay, or an invoice rejected in IMS but still claimed in GSTR-3B, creates a mismatch that surfaces in GSTR-9C.

Running the three-way match monthly rather than at year-end prevents the accumulation of unresolvable differences. A monthly cadence allows the finance team to identify supplier GSTR-1 amendments, credit note mismatches, and IMS status discrepancies while correction is still possible. At year-end, many of these differences become permanent because the amendment window under Section 37 closes after the September return of the following year.

The place of supply rules under the IGST Act determine the applicable tax. If the supplier's state and the buyer's state are different, the supply is inter-state and IGST applies. If both are in the same state (or union territory), the supply is intra-state and CGST + SGST (or CGST + UTGST for union territories) applies. For services, the place of supply is typically the recipient's location; for goods, it is the delivery location.

No. CGST ITC cannot be used to offset SGST liability. Under the ITC set-off rules amended by the Finance Act 2019, CGST ITC can offset CGST liability first, and then IGST liability. Similarly, SGST ITC can offset SGST liability first, then IGST. Cross-utilisation of CGST against SGST (or vice versa) is explicitly prohibited.

Each GSTIN operates as an independent tax entity with its own GSTR-1, GSTR-3B, and electronic ledgers. The reconciliation requires: (1) verifying that each inter-state supply between two GSTINs of the same entity is declared as an IGST transaction; (2) confirming that ITC on inter-GSTIN stock transfers (taxable at the applicable GST rate) is correctly claimed in the destination GSTIN; and (3) ensuring GSTR-3B for each GSTIN uses the correct offset sequence without cross-head utilisation.

If an inter-state supply is incorrectly taxed as CGST+SGST, the buyer receives CGST and SGST ITC in GSTR-2B, which cannot offset IGST liability. Additionally, the GST department may issue a demand for the correct IGST while the incorrectly deposited CGST and SGST sit in the wrong government account. Rectification requires the supplier to issue a credit note for the incorrect invoice, raise a new IGST invoice, and file a revised GSTR-1. Refund of incorrectly paid CGST+SGST requires a separate RFD-01 application.

Under the Finance Act 2019 amendment, the mandatory ITC offset sequence is: IGST ITC must first offset IGST liability, then CGST, then SGST (any remaining). CGST ITC must first offset CGST liability, then IGST. SGST ITC must first offset SGST liability, then IGST. This sequence is enforced in the GSTR-3B portal — taxpayers cannot manually choose a different order.

Under the IMS rules, an invoice in Pending status for more than 30 days from first appearance is treated as Accepted by default. The system flows it into the next applicable GSTR-2B and makes the ITC available. The buyer loses the option to Reject the invoice after this point. This is the deemed-accept mechanism, and it is the single most important timing rule in the IMS workflow.

Use Reject when you are confident the invoice does not belong to you — wrong GSTIN, fictitious supplier, amount you never agreed to, goods you never received. Reject is final unless the supplier files a GSTR-1 amendment. Use Pending when you need time to investigate — supplier follow-up needed, GRN not yet posted, internal approval pending. Pending is provisional and has a 30-day clock.

Yes. Until GSTR-3B for the period is filed (by the 20th of the month), IMS decisions can be changed in any direction. An Accept can be changed to Reject, a Reject to Accept, and Pending to either. Once GSTR-3B is filed, the IMS state is locked for that period and any change requires a supplier-side amendment in a later cycle.

The audit examines the linkage from purchase register entry to IMS decision timestamp to GSTR-2B line to GSTR-3B Table 4 figure. For Rejected invoices, the audit also examines the rejection reason. For Pending invoices that aged into deemed-Accept, the audit examines why the buyer did not actively decide within 30 days. Spreadsheet workflows rarely capture the IMS decision timestamp; automated workflows do so by default.

A common pattern: AP analysts post Accept on auto-recommended matches (no override authority on Reject), an AP manager posts Reject and reviews Pending decisions, and the finance controller has override authority on disputed items. The split prevents a single analyst from rejecting valid invoices and causing irreversible ITC loss. The audit trail captures the actor identity per decision.

Type 9 is an amendment of a B2B invoice filed in the current tax period — used when a supplier corrects an invoice within the same monthly cycle. Type 9A is an amendment of a B2B invoice filed in a prior tax period — used when the supplier corrects an invoice from an earlier month, subject to the Section 16(4) time limit. Both types flow into the buyer's IMS as amended entries requiring re-action.

The amendment surfaces in your IMS as a new entry with a reference to the original. You must re-act on the amended entry: Accept the amended version (rolls back the original Accept), Reject the amendment (keeps the original Accept), or mark Pending. If you Accept the amended version, GSTR-2B reflects the amended amount; the original is treated as superseded. The ITC differential flows through GSTR-3B accordingly.

Typically same-day or next-day. A supplier filing a Type 9 amendment by 5 PM sees it in their GSTR-1 immediately; the buyer's IMS dashboard updates within 24 hours. Type 9A amendments to prior periods follow the same timing but flow into the current month's IMS, not the original month's. This means a January invoice amended in May will appear in the May IMS cycle for buyer re-action.

When a supplier amends an invoice that the buyer previously Rejected, the original Reject does not automatically apply to the amendment. The amendment appears as a new actionable entry. If the buyer ignores it, the 30-day deemed-Accept clock applies to the amendment, potentially flowing it into GSTR-2B against the buyer's original Reject intent. Ghost invoices are the result of unwatched amendment queues.

Yes. Section 16(4) sets the deadline for claiming ITC on an invoice — generally the earlier of November 30 of the following financial year or the annual return filing date. Amendments do not extend this deadline. If a supplier amends an invoice in October 2026 for a financial year 2025-26 transaction, the buyer must still ensure the resulting ITC is claimed within the Section 16(4) window. Amendments that surface after the window are effectively unclaimable.

The IMS engine treats no-action records as deemed Accept. The invoice flows into your GSTR-2B and ITC becomes available, subject to Section 16(2)(aa) supplier-filing conditions. This is the single most common cause of unintended ITC claims on disputed invoices, which is why pre-2B review is critical.

Yes, but only until GSTR-2B is generated for that period (typically on the 14th of the following month). Once 2B is locked, you must coordinate with the supplier to re-issue or amend the invoice in a later period. Reject and Pending are both reversible within the open window; the dashboard allows action changes until the cut-off.

Reject signals to the supplier that the invoice is wrong or disowned and removes it from your 2B permanently for that period. Pending defers the invoice — it does not enter the current 2B but stays available for action in subsequent months, useful when goods are in transit or supporting documents are awaited.

IMS replaces the provisional ITC mechanics of Rule 36(4) for invoices flowing through the dashboard — only accepted invoices count toward ITC. Rule 88C and 88D mismatch notices continue to apply downstream when 3B claims exceed 2B-available ITC. Disciplined IMS action reduces the surface area for both notice types.

Run a daily pull across all GSTINs into a single workbench, classify invoices using a consistent ruleset (PO match, GRN match, supplier filing status), and push the actions back via bulk action where supported. Centralised governance prevents one GSTIN auto-accepting an invoice another GSTIN has already rejected for the same supplier.

Linear-time decision logic per invoice does not scale linearly in human review time. At 1,000 invoices, a 5 percent exception rate produces 50 manual reviews. At 5,000 invoices, the same exception rate produces 250 reviews — far more than a 2-person AP team can complete in the six-day window. Volume above 2,500 invoices typically requires a dedicated reconciliation tool with exception triage.

Marketplace sellers receive thousands of B2B invoices from marketplace operators (commission, logistics, advertising) and from category-level vendors. Each marketplace operator files GSTR-1 with the seller's GSTIN as recipient. These appear in the seller's IMS dashboard for accept/reject/pending action. Sellers must reconcile marketplace-issued invoices against marketplace settlement reports — a separate reconciliation that flows into the same IMS decision.

Operationally, yes. A retailer might auto-Accept invoices from category-A strategic suppliers (above ₹10 lakh, three-way matched), apply manual review to category-B mid-tier suppliers (₹1-10 lakh), and apply tight tolerance to category-C tail vendors (below ₹1 lakh). The GST portal does not distinguish — all decisions are uniform from the portal's view — but the internal decision engine can apply category-specific rules before posting.

Retail ITC is a working-capital input. An invoice held Pending in IMS defers ITC by one month, increasing GST cash outflow on GSTR-3B by the deferred amount. For a retailer with ₹50 crore monthly inward purchases, a 10 percent Pending rate represents ₹90 lakh of deferred ITC (assuming 18 percent GST) — direct working-capital impact tied to the inventory turnover cycle.

Each state of operation requires a separate GSTIN with its own IMS dashboard. A retailer with stores in 10 states maintains 10 dashboards. The reconciliation tool pulls each dashboard, applies a common decision engine against a unified purchase master, then posts decisions back to each GSTIN. State-level finance owners typically retain override authority on their GSTIN even when central operations runs the engine.

Yes. GSTR-2B reflects the net of your IMS decisions. An invoice you Reject in IMS is excluded from GSTR-2B entirely. An invoice you Accept appears in GSTR-2B and makes the ITC available for that month's GSTR-3B. The GSTR-2B is generated on the 14th and reflects whatever IMS status each invoice holds at that point — so actions taken between the 14th and the 20th (GSTR-3B filing deadline) update GSTR-2B before it is used for ITC claims.

The effective window is from the 14th (when GSTR-2B is generated and IMS is populated) to the 20th of the month (standard GSTR-3B filing deadline). That is a six-day window. Taxpayers under the QRMP scheme have until their quarterly filing date, but IMS is still populated monthly. For organisations with high invoice volumes, automating the purchase register vs IMS comparison is the only way to complete actions within this window.

No. IMS applies to inward supplies from October 2024 onwards. Invoices from suppliers who filed GSTR-1 before October 14, 2024 follow the old GSTR-2A / GSTR-2B process without an IMS layer. Any unresolved ITC from pre-October 2024 periods should be handled through the GSTR-2A vs GSTR-2B mismatch resolution process and, if within the time limit, through the supplier filing a correction GSTR-1 amendment.

GSTR-2A is a dynamic real-time statement that updates whenever a supplier files or amends their GSTR-1. It is read-only — you cannot take action on it. IMS is an actionable layer where you Accept, Reject, or mark invoices as Pending before they lock into GSTR-2B. For reconciliation, GSTR-2A remains useful for monitoring supplier filing compliance in real time throughout the month, while IMS is the mechanism that determines what actually appears in your GSTR-2B.

The IMS regime went live on October 14, 2024. From that date, all inward supplies appearing in GSTR-1 filings (from October 2024 onwards) flow through the IMS layer before populating GSTR-2B. Invoices for tax periods before October 2024 follow the legacy auto-populated GSTR-2B model and are not subject to IMS action.

Under the traditional model, ITC on ₹5 crore at 18 percent GST (₹90 lakh) was claimable in the same month's GSTR-3B as long as suppliers filed GSTR-1 by the 11th. Under IMS, the same ₹90 lakh ITC requires explicit Accept before the 14th-to-20th window — if Pending status is not resolved, ITC defers by one month, creating a one-month working-capital lock of ₹90 lakh on the affected portion.

Total mismatches are similar — supplier errors, amount differences, and GSTIN typos occur at the same rate. What changes is when they surface. Traditional model: mismatches discovered after GSTR-2B generation, resolved next month. IMS model: mismatches surfaced in the IMS dashboard before GSTR-2B locks, resolvable within the same cycle via Reject or Pending. The IMS model gives preventive control where the traditional model only allowed corrective control.

Traditional model: Rule 36(4) required ITC claim only against invoices in GSTR-2B. Audit trail: purchase register, GSTR-2B, GSTR-3B Table 4. IMS model: same Rule 36(4) requirement, but GSTR-2B is now the IMS-decided subset. Audit trail adds the IMS Accept timestamp as the fourth artefact. The compliance bar is operationally higher because the buyer's active decision is now part of the evidence chain.

No. The IMS regime is mandatory for all GST-registered taxpayers from October 2024 onwards. There is no opt-out. Buyers who do not actively decide on IMS invoices have those invoices flow into GSTR-2B via the 30-day deemed-Accept mechanism — but the IMS decision step is unavoidable. The traditional auto-populated GSTR-2B model is closed for current-period invoices.

IMS is available to all GST-registered recipients whose suppliers file GSTR-1. Taking action in IMS (Accept, Reject, or Pending) is not legally mandated for every invoice, but the default treatment if no action is taken is 'Pending,' which defers the invoice to the next month's GSTR-2B. For businesses that need ITC in the current month's GSTR-3B, deliberate IMS actions before the 20th filing deadline are necessary.

If you take no action, the invoice is treated as 'Pending' by default and excluded from the current month's GSTR-2B. The invoice will roll forward to the next month's GSTR-2B generation cycle on the 14th. This means ITC is deferred by one month, which affects cash flow and may require you to fund the GST payment from working capital in the interim period.

Once GSTR-3B is filed, the IMS actions for that month's cycle are locked. You cannot reverse an Accept or Reject after the 3B has been submitted. This is why reconciling your purchase register against IMS before the GSTR-3B deadline (typically the 20th of the month) is critical. Incorrect accepts or rejects must be corrected through the next month's cycle via supplier amendments.

No. GSTR-2A remains active as a dynamic statement that updates in real time as suppliers file. IMS is a separate actionable layer that sits between GSTR-2A and GSTR-2B. Think of IMS as the confirmation mechanism: GSTR-2A shows what suppliers have filed, IMS allows you to Accept or Reject before the invoice locks into the static GSTR-2B on the 14th of each month.

Only invoices you Accept in IMS (or leave as default Accepted) will appear in your GSTR-2B. Invoices you Reject will be excluded from your GSTR-2B entirely. Invoices marked Pending will be excluded from the current month's GSTR-2B and moved to the next month's cycle. Because GSTR-2B is the basis for ITC claims under Rule 36(4), incorrect IMS actions directly alter the ITC available in your return.

Rule 42 of the CGST Rules requires reversal of ITC on inputs and input services that are used partly for taxable supplies and partly for exempt supplies or non-business purposes. The reversal is calculated using a two-part formula: D1 represents the exempt-supply proportion of common ITC (common ITC × exempt turnover ÷ total turnover), and D2 represents the non-business proportion (5% of common ITC, per the rule). The total reversal each month is D1 + D2. For example, if a company has ₹10 lakh of common ITC, ₹2 crore exempt turnover, and ₹8 crore total turnover, D1 = ₹10L × 20% = ₹2L, D2 = ₹10L × 5% = ₹50,000. Total reversal = ₹2.5 lakh, reported in GSTR-3B Table 4(B)(1).

Mixed-use ITC reversal under Rule 42 uses the turnover ratio method. The formula is: T1 (exclusively taxable ITC) is fully claimable; T2 (exclusively exempt ITC) is fully reversed; T3 (blocked under Section 17(5)) is fully reversed; T4 (remaining common ITC) is apportioned. From T4: D1 = T4 × (exempt turnover ÷ total turnover), D2 = T4 × 5% for non-business use, and the balance (T4 − D1 − D2) is eligible. The classification of each invoice into T1, T2, T3, or T4 requires a mapping of each input or input service to its use — which is the reconciliation challenge. Common services like office maintenance at ₹18% GST where the company has both exempt and taxable revenue always land in T4.

Rule 42 covers inputs and input services (recurring purchases — raw materials, professional fees, software subscriptions). The reversal is calculated monthly using the current period turnover ratio and reported immediately. Rule 43 covers capital goods (machinery, servers, vehicles purchased for business use). Because capital goods have a useful life of 60 months under GST, the ITC credit is spread across 60 months at 1/60th per month, and the exempt-proportion reversal is applied each month on the 1/60th amount. A ₹30 lakh server purchased at 18% GST generates ₹5.4 lakh ITC, which is spread at ₹9,000 per month over 60 months. If 25% of usage is for exempt supplies, the Rule 43 reversal is ₹2,250 per month.

Both Rule 42 and Rule 43 reversals are reported in GSTR-3B Table 4(B) — 'ITC Reversed'. Within Table 4(B), Rule 42 reversals go in row (1): 'As per Rule 42 and 43 of CGST/SGST Rules'. Rule 43 reversals for the monthly 1/60th portion are also included in the same row. Reversals under Section 17(5) (blocked credits) go in row (2). Reversal of IGST credit on import of goods goes in row (3). Any other reversals are in row (4). A common error is combining Rule 42 and Section 17(5) reversals without segregating them, which makes the GSTR-9 reconciliation at year-end significantly more difficult.

Monthly Rule 42 reversals are calculated using provisional turnover ratios — the turnover for that specific month. At year-end, the actual annual turnover ratio (exempt ÷ total for the full financial year) may differ from the sum of monthly provisional ratios. GSTR-9 requires the taxpayer to compute the final Rule 42 reversal for the entire year using the actual annual ratio and compare it to the sum of monthly GSTR-3B reversals. If the annual computation requires more reversal than was done monthly, the differential must be reversed in the March GSTR-3B (or the year's last return). If the annual computation shows over-reversal, the excess can be reclaimed in the March 3B or reported in GSTR-9C. For a company with ₹50 crore total ITC and 15% exempt proportion, a 2% variance in the exempt ratio between provisional and actual generates ₹1 crore in adjustment.

ITC must be reversed in the GSTR-3B return for the tax period immediately following the expiry of 180 days from the invoice date. For example, if an invoice is dated January 15, 2024, the 180-day period expires on July 13, 2024. If payment has not been made by that date, the ITC must be reversed in the GSTR-3B for July 2024, filed by August 20, 2024. The reversal is proportionate to the unpaid amount.

Rule 37 requires proportionate reversal. If 60% of the invoice value has been paid within 180 days and 40% remains outstanding, only the ITC attributable to the 40% unpaid amount must be reversed. The calculation is straightforward: ITC reversed = Total ITC on invoice multiplied by (unpaid amount divided by total invoice value including GST).

Interest at 18% per annum under Section 50 of the CGST Act applies if the ITC was utilised before reversal. If the ITC was merely availed (credited to the electronic credit ledger) but not utilised to discharge any tax liability, no interest is payable on reversal. The distinction between availment and utilisation is critical for computing the interest liability accurately.

Yes. Rule 37A explicitly permits re-availment of reversed ITC once the supplier files the pending GSTR-3B. There is no time limit for this re-availment, and Section 16(4) does not apply to re-claims of previously reversed ITC. The buyer should re-avail the credit in the GSTR-3B for the period in which the supplier's filing is confirmed in the buyer's GSTR-2B.

DRC-01C is an auto-generated notice issued when ITC claimed in GSTR-3B exceeds the ITC available in GSTR-2B. While Rule 37 and Rule 37A require reversal based on payment and supplier filing status respectively, DRC-01C targets the aggregate ITC mismatch at the GSTIN level. A buyer who has not reversed ITC under Rule 37A (because the supplier has not filed) may simultaneously receive a DRC-01C notice for the same excess ITC. The response deadline is 7 days from the date of notice.

For an invoice dated March 15, 2024, the ITC must be claimed in GSTR-3B filed on or before November 30, 2024, or the date of filing the annual return (GSTR-9) for FY 2023-24, whichever is earlier. If the GSTR-9 for FY 2023-24 is filed on October 15, 2024, the deadline accelerates to October 15, 2024. After this date, the credit is permanently forfeited with no recovery mechanism.

No. The Section 16(4) time limit applies only to the initial availment of ITC. ITC that was legitimately claimed, subsequently reversed under Rule 37 (180-day non-payment) or Rule 37A (supplier non-filing), and then re-availed upon the condition being met, is not subject to the Section 16(4) deadline. There is no statutory time limit for re-claiming reversed ITC.

If the supplier files GSTR-1 late and the invoice appears in the buyer's GSTR-2B only after the November 30 deadline, the ITC is permanently lost to the buyer. Section 16(2)(aa) requires the invoice to appear in GSTR-2B as a precondition for claiming ITC, and Section 16(4) imposes the hard deadline. The buyer's only recourse is commercial recovery from the supplier for the lost credit amount.

Rule 36(4) was amended effective January 1, 2022 to restrict ITC claims to the amount appearing in GSTR-2B with zero tolerance. No provisional or excess ITC claim is permitted. This means the buyer must wait for the invoice to appear in GSTR-2B before claiming ITC, while simultaneously tracking the Section 16(4) deadline. If the supplier delays filing beyond November 30 of the following FY, the buyer loses the credit permanently.

The GST Council's annual report for FY 2024-25 noted ₹1.79 lakh crore in ITC fraud detected across 44,938 cases over the preceding 5 years. Industry estimates suggest 5-10% of total ITC claimed by mid-size enterprises faces temporary blocking due to GSTR-2B mismatches each quarter. For an enterprise claiming ₹50 lakh ITC per month, a 5% mismatch rate means ₹2.5 lakh per month at risk of permanent loss if not resolved before the Section 16(4) deadline.

The five conditions are: possession of a tax invoice or debit note, receipt of goods or services (or both), the tax charged has been actually paid to the government by the supplier, the recipient has filed the relevant GSTR-3B return, and payment to the supplier within 180 days from invoice date. All five must be satisfied for an ITC claim to be valid. The IMS regime adds explicit acceptance as a Rule 36(4) compliance step on top of these.

No. The IMS Accept timestamp is an additional Rule 36(4) compliance artefact, not a replacement for the five Section 16 conditions. A buyer must still hold a valid tax invoice, have received the goods or services, ensure the supplier has paid the tax (which the GSTR-1 filing implicitly evidences), file GSTR-3B, and pay the supplier within 180 days. The IMS Accept confirms the buyer's positive action on the invoice — it sits alongside, not in place of, the five conditions.

Rule 37 of the CGST Rules requires the buyer to reverse ITC if the supplier has not been paid within 180 days from the invoice date. The reversal happens in GSTR-3B Table 4(B). If the buyer subsequently pays the supplier, the ITC can be re-claimed. The IMS workflow is independent of Rule 37 — an invoice can be Accepted in IMS, ITC claimed, and then reversed under Rule 37 if payment is delayed. The audit trail must capture both the IMS Accept and the Rule 37 reversal where applicable.

The audit defence is a five-artefact chain per invoice: tax invoice in possession (PDF or digital copy), goods receipt or service-acceptance evidence (GRN, delivery note, service report), supplier GSTR-1 filing evidence (visible in IMS and GSTR-2B), IMS Accept timestamp from the portal, and supplier payment evidence within 180 days (bank statement or remittance proof). The audit pack ties these together with the GSTR-3B Table 4 line item where the ITC was claimed.

If all five Section 16 conditions are met but the buyer has not Accepted the invoice in IMS, the invoice does not appear in GSTR-2B for the current month and ITC cannot be claimed in current GSTR-3B. The buyer must Accept in IMS first. If the invoice ages to day 31 in Pending, deemed-Accept fires and the ITC becomes claimable in the next GSTR-2B. The mechanical sequence is: Section 16 conditions plus IMS Accept plus GSTR-2B presence plus GSTR-3B filing plus 180-day payment.

Amazon deducts TCS (Tax Collected at Source) at 1% of the net taxable value of each transaction from marketplace seller payouts under Section 52 of the CGST Act (0.5% CGST + 0.5% SGST for intra-state transactions, or 1% IGST for inter-state). Amazon files GSTR-8 by the 10th of the following month, and this data auto-populates in the seller's GSTR-2B. Sellers must reconcile TCS shown in the Amazon settlement report against GSTR-2B Part II (TCS amounts) and Form 26AS Part F each quarter. Any mismatch must be resolved before crediting TCS against output liability.

Amazon India marketplace settlements for sellers follow a weekly cycle, typically 7 days after the order shipment confirmation date, subject to Amazon's payment hold policies for new sellers. The settlement includes sales proceeds minus Amazon's referral fee, fulfilment fees (for FBA sellers), advertising charges, return adjustments, and 1% TCS. Settlement timing differs from pure payment gateway products like Razorpay (T+2) due to the marketplace's additional deduction structure.

When Amazon Pay is used as a checkout option on a non-Amazon website (Amazon Pay for external merchants), it operates as a standard payment gateway: T+2 settlement, MDR deducted, GST on MDR charged at 18%, settlement report available in the Amazon Pay dashboard. TCS under Section 52 does not apply because the external merchant is not selling through Amazon's marketplace platform. The reconciliation is structurally identical to Razorpay or PayU settlement reconciliation.

TCS collected by Amazon under Section 52 appears in: (1) the seller's Amazon settlement report as a line item deduction, (2) the seller's GSTR-2B Part II after Amazon files GSTR-8 by the 10th of the following month, and (3) the seller's Form 26AS Part F. Sellers claim TCS as a credit against their GST output liability in GSTR-3B. The TCS amount in GSTR-3B must match GSTR-2B exactly — over-claiming based on the settlement report before GSTR-8 is filed is a compliance error.

Amazon marketplace settlement exceptions include: TAX_DEDUCTION when TCS in the settlement report differs from GSTR-2B (timing mismatch if GSTR-8 has not yet been filed), FEE_DEDUCTION when referral fee percentage applied differs from the category rate, PARTIAL_PAYMENT when a return adjustment reduces a settlement without a traceable order ID in the OMS, ROUNDING on sub-rupee fee calculations, and UNEXPLAINED when a settlement credit cannot be matched to any order in the seller's system.

Yes. Cashfree offers T+1 settlement — settlement initiated one working day after payment capture — as a standard feature for eligible merchants, without additional fees. This differs from Razorpay and PayU, where T+1 is typically available on request or for established merchants only. T+2 is available as a fallback. Merchant eligibility for T+1 depends on Cashfree's risk assessment.

Cashfree assigns a settlement_id to each settlement batch, visible in the Cashfree Dashboard under the Settlements section. The settlement report CSV contains the settlement_id, settlement date, and net amount alongside individual transaction rows. The settlement_id is used to match the Cashfree settlement batch to the corresponding NEFT credit in the bank statement. The bank narration will typically show a Cashfree nodal account reference with a UTR.

Cashfree charges MDR on transactions (0% for UPI, approximately 1.5–2% for cards depending on plan) and applies 18% GST on the MDR. Cashfree issues a monthly GST invoice to the merchant's registered GSTIN. The GST on MDR amount in the settlement report should match the invoice total for the corresponding period. GST-registered merchants can claim ITC on this amount after matching the invoice in GSTR-2B.

Cashfree Payouts is a separate product for bulk disbursements — vendor payments, refunds, salary transfers, and similar outgoing transactions. It is distinct from Cashfree Payments (the collection/gateway product). Payouts reconciliation matches outgoing transfer records in the Cashfree Payouts dashboard to debit entries in the merchant's bank account and to the corresponding liability or expense in the ERP. These two reconciliation tracks should not be combined.

Common exceptions in Cashfree settlement reconciliation: FEE_DEDUCTION when the MDR applied differs from the agreed rate by instrument; TAX_DEDUCTION when the GST on MDR in the settlement report does not match the monthly invoice; PARTIAL_PAYMENT when a refund processed through Cashfree reduces the gross-to-net bridge but the originating Order ID falls in a different accounting period; and UNEXPLAINED when a transaction in the settlement report has no match in the OMS, which may indicate a test-mode payment that was not filtered.

No. A chargeback won does not create a credit note under Section 34 of the CGST Act. The original supply was legitimate — the customer's dispute failed — so the value of the taxable supply is unchanged. The recovery is a receipt of the amount previously provisioned as a chargeback loss. No ITC reversal is required and no credit note is issued. Reconciliation systems that auto-generate a credit note whenever a positive gateway credit references a prior dispute produce incorrect GST filings.

Under the RBI Chargeback Framework, the issuer must file the chargeback within 120 days of the transaction date for most card-not-present disputes. The acquirer notifies the merchant, who has 30 days to submit representation evidence. The card network then adjudicates — typically within 15 to 45 days. If the merchant wins, funds are re-credited in the next settlement cycle, usually T+1 to T+3 from the network's decision. End to end, a Filed→Represented→Won cycle commonly spans 60 to 180 days from original transaction.

Payment gateway settlement files often use a single 'adjustment' or 'refund_reversal' field to report both refund cancellations and chargeback recoveries. Without a distinct transaction_type code for chargeback_reversed, the reconciliation engine either lumps it under refund analytics — polluting the refund rate KPI — or treats it as a generic settlement adjustment with no linkage to the original dispute case. The result is a ledger that shows the money but loses the story.

At Filed, debit Chargeback Receivable (from acquirer) and credit Bank/Settlement Clearing with the disputed amount. At Represented, no accounting entry — the case is open. At Won, reverse the receivable: debit Bank/Settlement Clearing and credit Chargeback Receivable. If the merchant had provisioned a chargeback loss expense at Filed under a conservative policy, the Won state also requires a debit to Chargeback Loss Provision and a credit to Chargeback Recovery Income. At Lost, the receivable is written off to Chargeback Loss expense.

No adjustment is needed if the original tax invoice was raised correctly and no credit note was issued during the dispute. The supply remains valid and the output tax liability is unchanged. Where the merchant had prematurely issued a credit note when the chargeback was filed — a mistake — that credit note must be cancelled or reversed in the GST filing for the period the recovery is confirmed, restoring the output tax and any ITC that was reversed.

The dispute window given by the acquiring bank or payment gateway is typically 5–10 business days from the date of chargeback notification. The underlying card network rules (Visa and Mastercard) allow cardholders to raise chargebacks within 120 days of the original transaction date.

A refund is initiated by the merchant and appears as a negative line item labelled with the original payment_id or order_id. A chargeback is initiated by the cardholder's issuing bank and appears as a separate deduction — often without a direct reference to the original order — requiring manual matching to identify the source transaction.

If the merchant's representment (counter-dispute with evidence) is rejected, the chargeback amount is permanently debited from the merchant's settlement account. There is no further appeal through the gateway — the loss is final and must be written off in the books.

Not automatically. A chargeback is a forced reversal of payment, not a return of goods. Whether a credit note is required depends on whether the underlying supply was reversed. If the goods were returned or the service was not rendered, a credit note under Section 34 of the CGST Act is required. If the chargeback was fraudulent and the merchant disputes it, no credit note is issued.

A merchant using a single payment gateway receives one settlement file per settlement cycle (typically daily or T+2). Multi-gateway merchants — for example, running Razorpay for UPI and PayU for credit cards — must reconcile chargeback deductions across both files separately, since chargebacks appear only in the gateway that processed the original transaction.

Flipkart deducts marketplace commission (which varies by category — typically 5–20%), TCS at 1% under GST Section 52, return adjustments for orders reversed in the settlement period, and shipping charges where applicable. The bank credit is the net amount after all four deductions. A seller must reconstruct gross sales from this net figure before filing GSTR-3B.

Flipkart deducts TCS at 1% of the net taxable value of supplies. For intra-state orders it is 0.5% CGST + 0.5% SGST; for inter-state orders it is 1% IGST. Flipkart files GSTR-8 by the 10th of the following month, which auto-populates the seller's GSTR-2B. The credit also appears in Form 26AS Part F under the seller's PAN.

Flipkart's standard settlement cycle is T+7 — seven days from delivery confirmation in standard categories. The seller receives a weekly bank credit covering all orders confirmed delivered in that window. Settlement reports are downloadable from Flipkart Seller Hub with order-level detail including each deduction line.

Return deductions appear when customers return items during a settlement cycle. Flipkart nets the return credit against forward sales in the same settlement period. To reconcile correctly, the seller must match each return order ID in the settlement report to the original forward sale in their ERP, reverse the revenue recognition, and check whether TCS was already credited to GSTR-2B for the original transaction — if so, that TCS must also be reversed via GSTR-3B in the period the return credit appears.

The three standard variance types in Flipkart reconciliation are: FEE_DEDUCTION (marketplace commission and shipping charges that differ from the fee schedule), TAX_DEDUCTION (TCS amount that does not match gross taxable value at 1%), and ROUNDING (sub-rupee differences created by per-order rounding in Flipkart's payout calculation). Each type requires a different resolution path — fee disputes go to Seller Hub, tax mismatches go to GSTR-8 correction, and rounding is written off below a materiality threshold.

Industry analysis indicates sellers lose 2-3% of gross payment volume to fee-related errors. For a seller with ₹5 crore monthly GMV, this translates to ₹10-15 lakh annually. The most common sources are commission category misclassification, volumetric weight overcharges, and incomplete fee reversals on returned orders.

SAFE-T claims must be filed within 90 days of the disputed transaction through Seller Central. Amazon sends information requests with a 3-day response window. If the claim is denied, sellers have one appeal within 7 days. Note that an active A-to-Z guarantee claim on the same order blocks SAFE-T filing until the A-to-Z claim is resolved.

Flipkart settlement cycles depend on the seller tier: Platinum sellers receive settlements at T+5, Gold at T+7, Silver at T+10, and Bronze at T+15 business days. Following the 2025 pricing update, Flipkart determines the final selling price in certain categories, which means the commission structure is applied to a marketplace-determined base rather than the seller's listed MRP.

TCS under Section 52 of the CGST Act must be computed on the net value of taxable supplies, excluding GST. Sellers should verify that TCS is not being computed on the gross settlement amount including GST. Additionally, the intra-state and inter-state split must match actual delivery addresses, not the seller's registered address. Cross-reference TCS credits in Form 26AS against the marketplace TCS certificate quarterly.

Manual VLOOKUP matching against settlement reports achieves approximately 51% match rate because marketplace settlements arrive as lump-sum bank credits covering thousands of orders, with deductions for commission, shipping, TCS, and returns netted at the line-item level. Order-level matching requires unpacking each settlement row into its constituent fee components and matching against the original order, which VLOOKUP cannot do without extensive preprocessing.

MDR (Merchant Discount Rate) is the fee charged by the payment gateway for processing each transaction. It is calculated as a percentage of the transaction value for card transactions (typically 1.5%–2.5% for credit cards, varying for debit cards) or as a flat fee for net banking (typically ₹10–₹25 per transaction). The MDR is deducted from the settlement amount before the net proceeds are credited to the merchant.

Yes. GST at 18% is charged on MDR, making the effective cost MDR × 1.18. For example, a 2% MDR on a transaction becomes an effective charge of 2.36% including GST. Merchants registered under GST can claim the 18% GST component as Input Tax Credit (ITC) on their GSTR-3B, provided the gateway issues a valid GST invoice or tax deduction statement.

As per RBI guidelines, UPI P2M (person-to-merchant) transactions up to ₹2,000 attract 0% MDR. For higher UPI transaction amounts, MDR may apply depending on the gateway and the merchant's plan. Merchants should verify their specific MDR schedule for UPI in their gateway contract, as rates above the zero-MDR threshold vary by provider.

FEE_DEDUCTION is the exception type raised when the actual MDR deducted in the settlement does not match the expected MDR calculated from the contracted rate and transaction type. The most common cause is a transaction being billed at the credit card rate (1.5%–2.5%) when it was processed using a debit card (which may have a different contracted rate). FEE_DEDUCTION exceptions require verification with the gateway and, if confirmed, a fee adjustment credit.

International card transactions are billed at a higher MDR than domestic cards — typically 2.5%–3.5% depending on the gateway and card type. The reconciliation must identify each international card transaction in the settlement report (usually flagged by card country code or network identifier) and verify that the MDR applied matches the international rate in the merchant's gateway agreement, not the domestic card rate.

Meesho's advertised commission rate is 0%, but sellers incur logistics charges (typically ₹30–80 per shipment depending on weight and zone), return shipping charges, and TCS at 1% under GST Section 52. In high-return-rate categories, return logistics charges can exceed forward logistics charges in a given week, resulting in a net negative settlement that Meesho carries forward as a debit against the next week's payout.

TCS is deducted on the original forward sale at the time of settlement, not on the net amount after returns. If a seller sells ₹50,000 worth of goods in a week and ₹20,000 worth are returned, TCS of ₹500 (1% on ₹50,000) was already deducted and appears in GSTR-2B. Meesho issues a TCS reversal for the returned ₹20,000 in a subsequent settlement cycle and files a revised GSTR-8, which then generates a correcting entry in GSTR-2B.

A negative Meesho settlement occurs when return deductions, return logistics charges, and penalties in a given week exceed forward sales for that same period. The negative balance does not result in a debit to the seller's bank account — Meesho carries it forward and deducts it from the next positive settlement. The seller must record this as a receivable reduction in their books and not recognise the deferred deduction as current-period expense until it is actually netted in the subsequent settlement.

Meesho files GSTR-8 by the 10th of the following month, which auto-populates the seller's GSTR-2B with the TCS credit under Meesho's operator GSTIN. The seller claims the credit in GSTR-3B by adjusting it against output tax liability for the period. For intra-state supplies, the credit splits as 0.5% CGST + 0.5% SGST; for inter-state, it is 1% IGST. The credit also appears in Form 26AS Part F.

The three variance types that recur in Meesho reconciliation are: FEE_DEDUCTION (logistics charges that differ from Meesho's published rate card — typically due to weight discrepancy disputes), TAX_DEDUCTION (TCS amount in GSTR-2B that does not match calculated TCS on gross forward sales net of accepted returns), and ROUNDING (sub-rupee differences in per-order payout calculations). Each variance type is resolved through a different process: rate disputes via Meesho seller support, TCS discrepancies via GSTR-8 revision request, and rounding via materiality write-off.

Because the change is dated. An MDR renegotiation that takes effect on 15 July 2026 applies only to transactions captured on or after 15 July. Transactions from 1–14 July continue to settle at the old rate — they were captured under the prior commercial terms, and the payment gateway honours the effective-date rule when computing the deduction. The July settlement file therefore contains two contractually correct MDR rates, and a reconciliation that expects a single monthly rate will show a variance that does not exist.

The rate-schedule table stores the effective-from date for each MDR rate. For every transaction on the settlement file, the reconciliation compares the transaction capture timestamp to the schedule and selects the rate whose effective-from date is on or before the capture date. On the day of the change, transactions captured at 00:00:00 to 23:59:59 IST on 15 July fall under the new rate; transactions captured up to 23:59:59 IST on 14 July fall under the old rate. Gateways typically apply the change in the settlement cycle following the effective date.

No. Section 194-O TDS at 0.1% and Section 52 CGST TCS at 0.5% are computed on the gross transaction value or net value of taxable supplies respectively, not on the MDR. The MDR is a deduction between the payment aggregator and the merchant; it does not change the value of the underlying supply. A renegotiation from 2.4% to 2.0% has zero effect on the merchant's income tax or GST TCS liability, but it does change the net settlement credited to the merchant's bank.

The old rate applies. MDR is computed at capture, not at settlement, because the contractual rate at capture is what the gateway has committed to. A transaction captured at 23:59:00 on 14 July that settles on 16 July still deducts MDR at the old 2.4% rate. This is the most common source of reconciliation variance during a rate change — the settlement date is inside the new-rate window but the capture date is in the old-rate window.

MDR is a payment processing charge, typically booked as a finance/banking cost. During a rate change month, the total MDR expense for the month is the sum of two components: (old rate x volume captured before change) + (new rate x volume captured on or after change). The GST treatment of MDR (Section 194H at 5% is not applicable to MDR — 194H is commission/brokerage; MDR is not commission in the tax sense) and the input GST charged by the aggregator on MDR both continue as before the change.

PayU India's standard settlement cycle is T+2 working days from the payment capture date. Settlement timelines may vary by merchant category and risk profile. For HDFC SmartGateway and other bank-powered checkout solutions that use PayU's underlying infrastructure, the settlement timeline is governed by the bank's agreement with the merchant, which typically mirrors T+2.

The PayU Dashboard (PayU Biz portal) includes a Settlements section where you can download settlement reports by date range. Each report includes a settlement_id field, the settlement date, the net amount credited, and transaction-level details including Payment ID, Order ID, gross amount, MDR, and GST on MDR. The settlement_id is the key for matching the downloaded report to the NEFT credit in the bank statement.

PayU MDR rates vary by instrument: UPI transactions carry 0% MDR (government mandate for person-to-merchant UPI); domestic debit cards are typically 0.4–0.9% depending on the merchant's plan; domestic credit cards range from 1.5–2.5%; and international cards may attract up to 3.5%. Each instrument's MDR is applied separately, and GST at 18% is charged on each MDR amount.

LazyPay, PayU's BNPL product, processes transactions where the customer's obligation is deferred. From a merchant settlement perspective, the PayU settlement credit arrives on the same T+2 cycle as card payments — LazyPay absorbs the deferred risk, not the merchant. In the settlement report, LazyPay transactions are identifiable by instrument type. Reconciliation logic should classify these separately to correctly attribute fee structures.

Common mismatches in PayU settlement reconciliation include: MDR rate applied differing from the contracted rate (FEE_DEDUCTION), GST on MDR variance between settlement file and PayU's tax invoice (TAX_DEDUCTION), refund deductions where the original Order ID is not in the current system scope (PARTIAL_PAYMENT), and sub-rupee fee rounding (ROUNDING). A PayU settlement credit appearing in the bank with no matching settlement_id in the report typically indicates a date boundary issue in the report export range.

Yes for genuine UPI transactions and for RuPay Debit. The 30 December 2019 notification (effective 1 January 2020) prescribes Zero MDR on both rails. But if a checkout tile labelled 'Pay via UPI' is used with a premium credit card that has been linked to the UPI app under NPCI's UPI-on-cards circular, the transaction is a credit card transaction routed through UPI. The MDR schedule of the underlying card applies — typically 1.5% to 2.4% for premium credit cards on standard MCC codes. The tile label is not what determines the fee. The network, card type, and often the BIN do.

The customer links a credit card — usually RuPay Credit today, with selective extension to other premium cards in permitted merchant categories — to a UPI app such as BHIM, PhonePe, or Google Pay. On the OTT checkout, the customer selects a UPI tile and pays via a VPA. Behind the tile, the transaction is authorised on the credit card network. The gateway settlement file will identify the transaction as CC (credit card) with a specific network (RuPay Credit, and where permitted others), not as UPI. The fee extraction must read the network field, not infer from tile label.

Because the gateway charges MDR based on the actual rail the transaction settled on, not on the label the customer clicked. A subscription checkout can show 'UPI' as the tile, but if the underlying card is a premium credit card linked to the UPI app, the settlement line will carry a credit card MDR of 1.5% to 2.4% plus 18% GST. Reconciliation that groups settlement lines by tile label under-books gateway cost against 'UPI = zero' assumptions and produces MDR schedule mismatches at auditor review.

Three fields. Network — RuPay Credit, Visa, Mastercard, American Express, Diners — separates zero-MDR rails (UPI, RuPay Debit) from priced rails. Card type — CR (credit) versus DR (debit) — separates zero-MDR RuPay Debit from priced RuPay Credit. BIN — the first 6 digits of the card number, redacted in most files but sometimes exposed as bank/network identifier — pins the specific card program and its fee band, since HDFC Infinia, American Express Platinum Reserve, and Amazon Pay ICICI each carry different MDR schedules within the same MCC.

Yes on both counts. Payment gateway service fees including MDR are taxable at 18% GST, and the gateway invoices the merchant for the fee plus GST. Where the fee is attributable to taxable outward supplies — subscription revenue is a taxable supply — the merchant claims the GST as input tax credit in GSTR-3B. Reconciliation must match the MDR line in the settlement file to the tax invoice line in the gateway's GSTR-1 that appears in the merchant's GSTR-2B, so the ITC on that GST is claimed correctly and not lost to timing mismatches.

Razorpay's standard settlement cycle is T+2 working days from the payment capture date. Merchants with a strong transaction history and low chargeback rates may request T+1 settlement. Settlements are initiated at a fixed cut-off time each business day; payments captured after the cut-off are included in the next day's batch.

The settlement_id is a unique identifier Razorpay assigns to each settlement batch. It appears in the Razorpay Dashboard settlement report and is the primary match key for linking individual transaction rows in the report to the corresponding NEFT credit in the bank statement. Without matching on settlement_id, a finance team cannot reliably link a bank credit to its component orders.

Razorpay charges MDR — typically 2% for standard card transactions — and applies 18% GST on that MDR amount. On a ₹10,000 transaction: MDR = ₹200, GST on MDR = ₹36, net settlement = ₹9,764. Razorpay issues a monthly GST invoice for the MDR charged. GST-registered merchants can claim ITC on the GST on MDR component.

Common exceptions in Razorpay settlement reconciliation include: FEE_DEDUCTION (MDR difference between expected rate and actual rate charged), TAX_DEDUCTION (GST on MDR variance), ROUNDING (sub-rupee rounding in fee calculation), PARTIAL_PAYMENT (refund adjustments reducing the gross-to-net bridge), and UNEXPLAINED (settlement reference present in the bank credit but not found in the order system).

Refunds processed through Razorpay are deducted from future settlement batches rather than paid out as a separate debit. In the settlement report, a refund appears as a negative amount against the original Order ID. The net settlement transferred to the bank account is the gross batch amount minus total MDR, GST on MDR, and refund deductions. Refund timing varies: the deduction from settlement typically occurs within 5–7 working days of the refund initiation.

The original settlement was already paid out by the payment gateway to the merchant bank account within the standard T+1 or T+2 window. Once that cycle is closed, any refund initiated afterwards cannot claw back the original transfer — it becomes a negative adjustment in the next available cycle. For a Day 15 refund on a Day 2 settlement, the deduction lands on Day 15 or Day 16 in a subsequent cycle net-off, not against the original settled amount.

Yes. The refund reduces the value of the original supply, so a credit note is mandatory under Section 34 of the CGST Act. The deadline is 30 November of the financial year following the year of the original supply, or the date of filing the annual return (GSTR-9), whichever is earlier. Missing this window means the ITC reversal cannot be formalised through the GST return, and the discrepancy surfaces in GSTR-9C.

The credit note is dated in the period the refund is issued, and the proportional GST reversal is reported in Table 4B(2) of GSTR-3B for that period. For a full refund of a monthly subscription, the entire 18% GST charged on the original invoice is reversed. For a partial refund — a pro-rated subscription cancellation — only the GST attributable to the unused portion is reversed.

Payment gateways settle in net terms, so a large refund day can produce a negative net cycle. In practice, the gateway will either debit the merchant's linked bank account for the shortfall or carry the negative balance to the next cycle. The reconciliation must flag negative-net days, confirm the direction of cash movement, and post the correct journal entry — a debit to the bank on cash outflow, or an offset receivable if carried forward.

It creates a cascade of errors. The original cycle's revenue and ITC positions were already booked correctly, and reopening them to net the refund double-counts the adjustment. The correct treatment is to leave the original cycle intact, book the refund as a negative revenue line in the cycle the credit note is dated, and reverse the proportional ITC in the same GSTR-3B period. This preserves the audit trail and keeps GSTR-1 and GSTR-3B internally consistent.

The standard refund timeline for Razorpay, PayU, and Cashfree is 5–7 business days from the date the merchant initiates the refund. The refund first appears as a deduction in the merchant's next settlement cycle, then reaches the customer's bank within the 5–7 day window. UPI refunds may process faster — typically 2–3 business days.

Yes, where the original supply was GST-inclusive. Section 34 of the CGST Act requires a credit note when a registered supplier reduces the value of a supply already invoiced. The credit note must be issued by 30 November of the financial year following the year of the original supply, or the date of filing the annual return (GSTR-9), whichever is earlier.

The ITC claimed on the inputs attributable to that supply must be reversed proportionally to the refund amount. For a full refund, the entire ITC on that transaction is reversed. For a partial refund — for example, a single item return from a multi-item order — only the ITC attributable to the returned items is reversed. The reversal is reported in Table 4B(2) of GSTR-3B.

Partial refunds appear in the settlement report as negative adjustments linked to the original payment_id or order_id, with the partial amount. The reconciliation must split the original order line: the refunded portion is matched to the credit note and ITC reversal, while the retained portion remains as revenue with the original ITC intact. Many ERP systems require a manual line split at this step.

Gateway-initiated refunds occur for failed transactions — where payment was captured but the order was not fulfilled due to a technical failure. These appear as automatic deductions in the settlement. The merchant must still issue a credit note for GST purposes if a tax invoice was raised, even if the refund was not merchant-initiated. GSTR-3B must reflect the ITC reversal in the same return period.

The PG holds funds in a nodal or escrow account and pushes settlement to the merchant's bank. When the total amount is large, or when it crosses the internal batching or rail thresholds of the sending bank, the disbursement is broken into two transfers — typically one via RTGS (for amounts of Rs 2 lakh and above, real-time) and one via NEFT (batched, half-hourly). Both credits reference the same PG settlement ID or utr_group but appear on the merchant's bank statement as separate lines with distinct UTRs, sometimes minutes apart.

No. A marketplace split settlement is an intentional configuration where the PG splits a single customer payment across multiple vendor accounts — for example, a hotel booking split between the aggregator and the property. Each split has its own settlement ID and its own tax obligation. The scenario in this article is the opposite: the merchant expects one settlement, receives one settlement confirmation from the PG, but the bank credits it as two lines due to rail-side split logic. The PG settlement file will show one row; the bank statement will show two.

The first credit should be booked as an on-account or suspense receipt against the PG settlement ID, not against a specific settlement line. The reconciliation engine should hold the settlement line as partially reconciled — matched by ID, unmatched by amount — until the second credit lands. Only if the second credit does not appear within the RBI-mandated T+1 window for that PG should it be escalated as a missing settlement.

TDS under Section 194O (0.1% on gross value facilitated by the e-commerce operator) and TCS under Section 52 of the CGST Act (0.5% on net taxable supplies) are deducted at the PG or aggregator layer and shown as line items in the settlement file — before the bank transfer occurs. A split at the bank level does not change the TDS or TCS position: the deductions belong to the single settlement, not to either bank credit line. The reconciliation continues to book the deductions against the PG settlement ID, not against the bank credits.

Some PGs use UPI for smaller settlement tranches (below the RTGS threshold and where the merchant bank supports high-value UPI credits) and RTGS for the larger portion. The bank statement then shows one UPI credit with a UPI transaction reference and one RTGS credit with a UTR. Both must be summed against the single PG settlement. UPI's zero MDR (Zero MDR notification dated 30 December 2019, applicable to UPI and RuPay Debit) means neither leg carries an MDR at the bank rail — the PG's own MDR on the underlying customer transactions is unchanged.

The primary match key is the Stripe payout_id, which appears in the Stripe dashboard payout detail and in the bank statement narration for SWIFT credits, typically in the payment reference or remittance information field. Standard settlement cycles from Stripe to Indian bank accounts are T+2 to T+7 depending on the payout schedule. For NEFT credits, the UTR number in the bank statement provides a secondary match key once the payout_id is located.

Indian businesses invoicing international customers in USD or EUR record the receivable at the exchange rate on the invoice date. Stripe settles the payout to the Indian bank account at Stripe's prevailing conversion rate on the settlement date, which differs from both the invoice date rate and the RBI reference rate. The difference between the booked receivable and the INR amount actually credited is a foreign exchange gain or loss that must be classified and accounted for — it is not a fee or error.

A Foreign Inward Remittance Certificate (FIRC) is issued by the receiving bank and serves as documentary proof of inward remittance under FEMA. Indian businesses that export services — SaaS subscriptions, consulting, software development — are required to repatriate export proceeds within the prescribed RBI timeline and maintain FIRC documentation. Without FIRC, the inward remittance from Stripe cannot be confirmed as export proceeds, which creates compliance risk during GST refund claims on zero-rated exports and FEMA scrutiny.

Section 195 applies to payments made to non-residents, not to payments received by Indian businesses. However, if an Indian business makes payments to Stripe — for example, for platform fees charged in USD — Section 195 may apply to those outward payments depending on the applicable DTAA rate between India and the country where Stripe's taxable presence is established. For inbound Stripe settlements to Indian accounts, TDS does not apply to the receipt itself; the Indian recipient's income is recognised in India and taxed under domestic rules.

Three variance types consistently arise in Stripe India reconciliation: FEE_DEDUCTION (Stripe's processing fee, typically 2–3% of the transaction value plus a fixed component, which is deducted before payout), TAX_DEDUCTION (any Stripe-collected taxes applicable in the originating jurisdiction), and ROUNDING — specifically the forex rate conversion difference between the invoice date rate and Stripe's settlement rate, which must be classified as a forex gain or loss in the books rather than a reconciling difference.

Because subscription revenue and advertising revenue are recognised under different paragraphs of Ind AS 115. A monthly subscription is an over-time performance obligation under Ind AS 115.35 — revenue is recognised rateably across the 30-day subscription period. An ad impression is a point-in-time obligation under Ind AS 115.32 — revenue is recognised the moment the impression is served. The payment gateway settles both on the same day, but the GL revenue lines follow completely different schedules. One reconciliation cannot cover both without splitting the settlement file by stream.

GSTR-1 requires supply values to be reported against the correct SAC. Subscription-based online content (streaming, OTT, OIDAR-classified services) sits under SAC 998431. Advertising services sit under SAC 998365. If the platform lumps both streams under one SAC in GSTR-1, the GST department cross-check against Form 27EQ (for ad networks acting as e-commerce operators) and against customer ITC claims (for B2B advertising) will fail. The 18% rate is identical, so there is no cash impact — but the SAC-wise turnover mismatch triggers scrutiny.

On subscription revenue, the streaming platform is the supplier of a B2C service — TDS is not deducted by individual customers. Where corporate subscriptions exist (a business buying enterprise plans for employees), Section 194J may apply if classified as professional/technical services. On ad revenue, the advertiser typically deducts TDS at 2% under Section 194C (contract) or 10% under Section 194J (technical service) when the platform bills the advertiser directly; where an ad network intermediates, the network deducts under Section 194H at 2% (payment code 1015, Sl. 18) on the commission it withholds before paying the publisher. Two revenue streams therefore produce two entirely different TDS reconciliation flows on the receivable side.

The split does not happen inside the settlement file. The gateway sees a card charge or UPI collect, not the underlying accounting classification. The split is driven by the order metadata the platform tags at capture: subscription_id links the transaction to the subscription ledger and drives the over-time deferral schedule; campaign_id or impression_batch_id links the transaction to the ad revenue ledger where recognition already happened at impression. Reconciliation joins the PG file to this metadata via payment_id, then routes each line to the correct GL sub-ledger.

When a customer pays ₹149 on the 15th of the month for a 30-day plan, the entire ₹149 is a customer receipt in cash but only 16 days of service have been delivered by month-end. Under Ind AS 115.35, revenue is recognised over the 30-day performance period — approximately ₹79 in the first month and ₹70 in the following month. The ₹70 sits as a contract liability (deferred revenue) at the balance sheet date. Reconciliation must tie the PG settlement (₹149 gross) to the two-month revenue schedule, the deferred revenue balance movement, and the corresponding GST liability (which arises at time of supply under Section 13 of CGST Act — typically the earlier of invoice or payment).

The TCS rate under Section 52 of the CGST Act is 1% of the net value of taxable supplies made through the e-commerce operator. For intra-state transactions, this is split as 0.5% CGST and 0.5% SGST. For inter-state transactions, it is 1% IGST. The rate applies to the net taxable value — after returns but before GST — of supplies facilitated by the operator.

GSTR-8 must be filed by the e-commerce operator by the 10th of the month following the calendar month in which TCS was collected. For example, TCS collected in January must be reflected in GSTR-8 filed by 10 February. Sellers should check GSTR-2B after the 14th of the following month, when auto-population from operator GSTR-8 filings is typically complete.

A mismatch between the settlement TCS and the GSTR-2B credit means the operator has either filed GSTR-8 with a different value or has not yet filed. The seller cannot claim the unmatched TCS in GSTR-3B — claiming more than what appears in GSTR-2B creates a discrepancy that will be flagged in GST scrutiny. The seller must contact the operator's seller support to request a GSTR-8 correction or confirmation of the correct value.

TCS deducted by e-commerce operators under Section 52 of the CGST Act appears in Part F of Form 26AS (Tax Collected at Source), which is the income tax Annual Information Statement. This is separate from the GST TCS credit that appears in GSTR-2B. Sellers should reconcile both: the GSTR-2B credit for GST purposes and the Form 26AS entry for income tax purposes.

Yes. TCS credit appearing in GSTR-2B — auto-populated from the operator's GSTR-8 — can be claimed by the seller in GSTR-3B to offset their output GST liability for that month. There is no separate application; the credit is applied directly in the GSTR-3B return. The seller's obligation is to ensure the GSTR-2B credit matches the settlement deduction before claiming, and to carry forward any unmatched credit to the month when the GSTR-8 correction is filed.

A test transaction ghost is a small-value transaction — commonly ₹1 or ₹2 — executed against production payment gateway credentials during engineering testing, load testing, or misconfigured environment switching. The gross amount is captured and later refunded, but MDR, gateway fee, or GST-on-fee is retained by the gateway. The net effect is a residual paise-level credit or debit in the settlement file that has no matching invoice, no customer record, and no subscription reference. Over months these accumulate into an unexplained variance that appears random until traced back to the credential misuse.

The ₹1 gross is captured. The merchant refund is initiated, but the refund flows through the gross-refund path — the MDR, plus GST at 18% on that MDR, is not refunded because the gateway has already recorded the fee as earned. On a domestic card path with MDR around 2%, the fee is 2 paise, GST on fee is roughly 0 paise at that scale (rounded), so the net residue is about 98 paise sitting in settlement with no source transaction on the merchant side. UPI ghosts show a slightly different residue pattern because MDR is zero on UPI, but a failed-refund path or a partial-capture path can still leave paise-level ghosts.

Absorbing ghost transactions into month-end variance breaks the audit trail. Under RBI's Payment Aggregator framework and the GSTR-3B / GSTR-1 reconciliation regime, every credit in the settlement file must be traceable to an invoice, an ITC obligation, and a customer. Absorbing 98 paise per ghost, over hundreds of ghosts, means the merchant is booking revenue against no invoice — which triggers a GST department query at audit and cannot be reconciled to GSTR-1 outward supplies. Quarantine preserves the audit trail: the ghost is isolated, its origin traced (usually an engineering environment misconfiguration), and either reversed at source or written to a specific 'test-transaction ghost' P&L line with documentation.

A three-signal filter catches most ghosts: (1) amount-range filter — settlement lines with net amount below ₹5 or gross amount below ₹10 are candidates; (2) no-corresponding-invoice check — the payment_id or order_id from the settlement file has no matching invoice or order record in the ERP or subscription database; (3) no-customer-record check — the customer email, phone, or subscription ID on the transaction (if available from the gateway) does not exist in the CRM or subscription master. A transaction that clears all three signals is a ghost. Some platforms add a fourth signal — repeated same-amount transactions from the same IP or device fingerprint within a short window — to identify load-test bursts.

Yes, but with a different residue profile. UPI has zero MDR per the December 2019 notification, so an idealised ₹1 UPI capture followed by full refund should net to zero. Ghosts on UPI paths typically arise from: (a) failed refund attempts that leave the ₹1 permanently in settlement with no matched credit note, (b) UPI reversals that partially process, leaving small paise-level breaks, or (c) collect-request tests that succeed but with a mandate that was never intended for production. The detection logic — amount-range, no-invoice, no-customer — catches these regardless of the card-vs-UPI residue pattern.

The UPI Reference ID is a 12-digit numeric identifier generated by the NPCI for each UPI transaction. It is distinct from the UTR (Unique Transaction Reference), which is a bank-generated identifier for NEFT, RTGS, and IMPS transactions. For UPI P2M transactions, the UPI Reference ID is the correct match key. The bank narration for a UPI credit typically reads: UPI/P2M/[12-digit UPI Ref ID]/[VPA or merchant name]. Using UTR to match UPI credits does not work because UTR is not generated for all UPI transaction types.

UPI P2M (Person to Merchant) transactions settle on a T+0 basis — the merchant's account is credited on the same day the transaction is authorised. This is different from card transactions, which typically settle T+1 or later. For merchants using payment aggregators like Razorpay or PayU, UPI transactions are first collected into the aggregator's nodal account and then settled to the merchant in batches — usually T+1 — based on the aggregator's settlement schedule. The T+0 settlement refers to the NPCI-to-nodal bank leg, not necessarily the aggregator-to-merchant leg.

For UPI P2M (Person to Merchant) transactions below ₹2,000, MDR is 0% per the RBI circular that waived MDR on small-value UPI payments. For transactions above ₹2,000 and for certain merchant categories, MDR may apply at rates set by the acquiring bank or payment aggregator. Merchants should verify the applicable MDR tier in their payment aggregator agreement. For reconciliation purposes, a zero-MDR transaction means the bank credit equals the gross transaction amount — there is no fee deduction to account for in the matching calculation.

When UPI is processed directly via a bank's merchant UPI integration, each transaction generates a separate bank credit with its UPI Reference ID. Reconciliation involves matching each bank credit to the corresponding order in the POS or e-commerce system using the UPI Reference ID. When UPI is processed through an aggregator like Razorpay or PayU, transactions are pooled in the aggregator's nodal account and settled to the merchant as a batch credit (typically daily). Reconciliation then requires a two-step process: match the aggregator settlement report to the batch bank credit, then reconcile individual UPI transactions within the aggregator report to order-level records using the UPI Reference ID.

Three variance types arise in UPI reconciliation: FEE_DEDUCTION (aggregator charges and MDR where applicable, which reduce the batch settlement amount from gross transaction total), TAX_DEDUCTION (18% GST on MDR where MDR applies — typically on transactions above ₹2,000 in categories where MDR is charged), and ROUNDING (sub-rupee differences in per-transaction fee calculations that accumulate in batch settlements). For direct UPI with 0% MDR transactions below ₹2,000, FEE_DEDUCTION and TAX_DEDUCTION variances are zero, and only ROUNDING applies.

Most Indian payment aggregators — Razorpay, PayU, Cashfree, Bill Desk, CCAvenue — settle merchants on T+1 or T+2 bank working days after successful capture. UPI transactions often settle on T+1; card transactions typically follow T+2. The RBI Payment Aggregator guidelines (17 March 2020) require settlement to the merchant's escrow-linked bank account within these timelines on working days only.

The settlement cycle counts bank working days, not calendar days. If Republic Day (26 January) falls on a Monday and the preceding Saturday-Sunday are non-working, a capture on Friday 23 January is settled T+2 working days later — which lands on 29 January (Thursday), not 25 or 27 January. Adding the RBI clearing house holiday and second-Saturday rules can stretch the calendar gap to four or five days.

A holiday-stretched settlement is not a failed settlement. The reconciliation must overlay the RBI clearing house holiday calendar on the expected-settlement-cycle table and recompute the expected arrival date before flagging any transaction as missing. Only when the settlement fails to arrive after the recomputed date — plus a reasonable buffer — should the item be classified as delayed or failed.

Yes. Each acquirer bank has a working-day definition that includes weekly-off patterns (some banks close on second and fourth Saturdays, others follow different rules) and regional holidays. When the payment gateway's escrow bank is different from the merchant's settlement bank, both calendars matter — the settlement leaves the acquirer on a working day of the escrow bank and reaches the merchant on a working day of the settlement bank.

UPI itself operates 24x7 for consumer transactions, but merchant settlement into a bank account follows the acquirer bank's working-day cycle. On an RBI clearing house holiday, the merchant credit is deferred to the next working day even though the underlying UPI transactions continued to be captured through the holiday. Reconciliation must expect a bulked-up settlement file on the first working day after a long stretch of holidays.

Axis Bank Corporate Internet Banking (CIB) offers three primary export formats: CSV (for spreadsheet use), PDF (for signed records), and MT940 (for ERP and reconciliation systems). MT940 is available to corporate clients enrolled in the CIB Premium or Liquidity Management tier. The CSV download retains the same narration text as CIB on-screen view, but truncates the description column at around 120 characters, which is the most common cause of UTR loss during NEFT and RTGS imports.

Axis Bank NEFT inward credits use 'NEFT-[UTR]-[remitter name]-[remitter bank]-[reference]' separated by hyphens, while RTGS inward credits use 'RTGS-[UTR]-[remitter name]-[remitter IFSC]-[reference]'. The 22-character UTR appears in position 6 to 27 of the narration. In MT940, the same data sits inside the :86: tag and is preceded by Axis's '/RFB/' structured-information marker. Reconciliation parsers must strip the '/RFB/' prefix before extracting the UTR.

Axis Bank runs end-of-day statement generation at 23:30 IST on banking days. On RBI-notified holidays, no end-of-day statement is generated; the next banking day's statement covers both calendar days under a single value date. NEFT and RTGS settlement cut-offs follow RBI's notified windows — RTGS operates Monday to Sunday 24x7 except during scheduled maintenance, while NEFT also runs 24x7 in half-hourly batches. Reconciliation teams should configure their date-bucket logic to roll up holiday postings into the next working day's statement.

Axis Bank auto-debits service fees under narrations such as 'AXIS CHG NEFT [MONTH]', 'AXIS CHG RTGS [MONTH]', 'AXIS CHG CMS [MONTH]', or 'AXIS CHG CASH HANDLING'. GST at 18% is added in the same debit line under 'IGST 18%' or 'CGST 9% + SGST 9%' depending on the registered state. Axis issues a consolidated monthly tax invoice that finance teams use to claim input tax credit. Section 194A TDS at 10% applies to interest credits above ₹40,000 per financial year on Axis fixed deposits and current account sweeps.

Axis CIB exposes both an MT942 intra-day statement (delivered every 30 to 60 minutes during banking hours) and an MT940 end-of-day statement (delivered after 23:30 IST). The intra-day MT942 is provisional — it includes credits that have entered the corporate account but may not have cleared inter-bank settlement. For audit-grade reconciliation, only the end-of-day MT940 closing balance in the :62F: tag is the book-of-record. Treasury dashboards and cash-position reports may consume MT942 for visibility, but the daily reconciliation should always close against the MT940 :62F: figure.

All bank service charges in India attract GST at 18% under SAC code 997119 (banking and related financial services). This applies to NEFT charges, RTGS charges, account maintenance fees, cheque book charges, IMPS charges, DD charges, and locker charges. Basic savings account services are exempt, but all current account services and transaction fees are taxable at 18%.

Yes. GST paid on bank charges is eligible for ITC under Section 16 of the CGST Act, provided the company is registered under GST and the charges relate to business use. The bank issues a tax invoice (or consolidated statement with GSTIN) at the end of each month. The ITC can be claimed in the same month's GSTR-3B after it appears in GSTR-2B, typically within 30–45 days of the charge being levied.

NEFT charges typically appear as 'NEFT CHG' or 'NEFT TRN CHG' followed by the transaction batch date and count — for example, 'NEFT CHG 15MAR26 12TXN 236.00 GST 42.48'. RTGS charges appear as 'RTGS CHG' with the individual transaction reference. The combined debit (charge plus 18% GST) is auto-debited without a prior debit note, making narration-based matching the only viable matching method.

Bank charges create exceptions because they arrive without prior invoice or purchase order, are batched across multiple transaction types in a single auto-debit, carry a GST component that must be split from the base charge for ITC purposes, and vary month to month based on transaction volume. A company processing 500 NEFT transactions in March and 800 in April will receive different charge amounts — making fixed-amount matching fail and requiring narration-pattern matching instead.

The recommended tolerance for bank charge matching is ±₹5 for charges below ₹500 and ±1% for charges above ₹500. This accommodates rounding differences in GST calculation (banks calculate GST on the total monthly charge before rounding, not per transaction) and minor fee schedule revisions. Charges outside tolerance should be flagged as FEE_VARIANCE for manual review rather than auto-matched.

RBI mandates the underlying payment systems (NEFT, RTGS, IMPS, UPI, NACH) and the data they carry, but does not prescribe the exact text format banks must use in customer statement narrations. Each bank decides how to render the payment system message in its core banking system. HDFC prefixes NEFT credits with 'NEFT CR:' and forward-slash delimited fields; SBI uses 'TRANSFER FROM' and dash separators; ICICI uses 'NEFT-' and pipe delimiters. The underlying UTR is identical, but the surrounding text varies. A narration classification library normalises across these bank-specific conventions.

An anchor token is a short, high-confidence string that uniquely identifies a transaction family in a narration. Examples: 'NEFT' anchors all NEFT transactions, 'UPI/' anchors UPI, 'CHRG' anchors bank service charges. Anchor tokens are matched first, then secondary regex extracts the UTR, counterparty, and reference. A well-tuned anchor library uses 20 to 25 tokens to cover above 95 percent of narrations across the major Indian banks.

Two cases recur. First, 'TRF' can mean inward transfer, outward transfer, or internal sweep depending on the bank — resolved by debit/credit direction plus the next token. Second, 'UPI/' covers P2P, P2M, and aggregator collection — resolved by checking the VPA suffix (bank handles for P2P, @razorpay or @paytm for aggregators) and the amount band. Ambiguity rules should be encoded as a priority-ordered list, with the most specific rule evaluated first.

No. Razorpay, PayU, Cashfree, and Stripe India settlements appear as bulk NEFT or IMPS credits with the aggregator's legal entity name in the counterparty field — for example, 'NEFT CR:[UTR]/RAZORPAY SOFTWARE PVT LTD/SETTLEMENT'. The narration does not list the underlying merchant transactions. Reconciliation requires the aggregator's settlement report (CSV or API) to explode the single credit into the underlying orders. The narration classification library should route aggregator settlements to a dedicated 'PG-Settlement' family rather than treating them as generic NEFT credits.

Banks change narration formats roughly once every 18 to 24 months, typically alongside core banking system upgrades. A practical cadence is a quarterly review of unmatched narrations: the top 20 unmatched narration patterns from the previous quarter become candidates for new rule additions. Major events — RBI mandate changes, ISO 20022 migration milestones, new payment products like RuPay Credit on UPI — trigger an out-of-cycle update.

A UTR (Unique Transaction Reference) is 22 characters long for NEFT, RTGS, and IMPS. It follows the format: 4-character bank code + 2-digit year + 3-digit day of year + 7-digit sequence number. For example, HDFC260801234567 in a NEFT narration uniquely identifies the transaction for matching.

The Reserve Bank of India mandates the UTR structure but does not standardise the full narration text. Each bank appends counterparty name, reference, and additional fields in its own format. HDFC uses 'NEFT CR:[UTR]/[name]/[ref]' while ICICI typically uses 'NEFT-[UTR]-[name]-[ref]', requiring separate parser configurations for each bank.

A single NACH credit line in the bank statement represents the total of all successful mandates in that batch — often 200 to 500 individual transactions. Reconciliation systems must explode the batch: they retrieve the NACH batch file from NPCI or the sponsor bank, match each mandate reference to the sub-ledger, and flag the net difference as unreconciled. Batch explosion requires the mandate ID, amount, and settlement date for each record.

Many Indian bank CSV exports limit the narration field to 50 or 100 characters. A NEFT narration carrying a 22-character UTR plus counterparty name may be cut mid-string, losing the last digits of the UTR. In this case, reconciliation systems fall back to amount-plus-date matching, which generates false positives when two transactions of the same value arrive on the same day. MT940 format avoids truncation by using a dedicated :86: field.

Cash deposits and over-the-counter deposits rarely carry a system-generated reference in bank narrations — they typically show only branch code and teller ID. Some older NEFT inward credits from cooperative banks may omit the UTR. Cheque credits show the cheque number but not a unique digital reference. These instruments require manual or rule-based matching rather than reference-key lookup.

OCR is necessary when the only available source is an image-only PDF, a scanned dot-matrix print, or a password-protected statement export from an older portal that does not also offer CSV or Excel. The most common cases are PSU branch statements collected manually at the branch, cooperative bank statements from portals that predate CSV exports, and archived statements from banks that have since changed their portal but where the old period is only available as a stored PDF. For these sources OCR is the only path to digitisation.

Typed PDFs generated digitally by the bank's portal yield character-level OCR accuracy in the 97-98 percent range, which translates to transaction-level capture of roughly 99 percent because most errors are non-material (an extra space in a narration, a comma misread as a period in a non-amount field). Scanned colour PDFs of similar layouts drop to roughly 85-92 percent transaction-level accuracy. Dot-matrix printer output, especially when the ribbon is faded or the scan is low-DPI, falls to 70-85 percent transaction-level accuracy, with most errors concentrated in amount columns where digit confusion (1 versus 7, 0 versus 8, 3 versus 8) is highest.

Yes, for any bank where both formats are available. The CSV is the primary source for posting and matching. The PDF is the backstop for two purposes: confirming opening and closing balances against the bank's signed statement of record, and recovering narration content that the CSV truncates. CSV exports from many Indian bank portals truncate narration at 100 to 150 characters; the PDF retains the full text. The hybrid pull also catches the rare case where a CSV row is missing or duplicated due to a portal export bug.

Several cooperative banks, district central cooperative banks, and small regional PSU branches still deliver only PDF statements through their portals, and a handful operate dot-matrix printers for over-the-counter statements. Among the major PSU banks, archived statements from the pre-2018 period are commonly only available as scanned PDFs. Among private banks, the OCR requirement is generally limited to client-provided statements during onboarding when the corporate has not yet enrolled in CMS or NetBanking corporate access.

Any transaction line where the OCR engine returns a character-level confidence below a defined threshold — commonly 90 percent — should be routed to a human review queue rather than auto-posted. The review queue shows the cropped image of the original line next to the OCR output so the reviewer can correct in seconds. Amount fields specifically should be re-validated against the row total and the running balance; if the row breaks the balance arithmetic by more than ₹1, the line is flagged regardless of OCR confidence. This catches the digit-confusion errors that OCR confidence scores often miss.

CARO 2020 applies to all companies except banking companies, insurance companies, Section 8 companies, one-person companies, and small companies as defined under Section 2(85) of the Companies Act, 2013. Clause 3(ii)(b) specifically applies where the aggregate working capital limit from banks or financial institutions exceeds ₹5 crore at any point during the year. Listed companies, NBFCs above threshold, and manufacturing companies with working capital facilities are the most commonly affected.

Auditors must disclose the nature and amount of discrepancies in their report under Clause 3(ii)(b). Persistent unexplained items older than 90 days typically trigger a material weakness observation under Section 143(3)(i). If the discrepancy is large relative to working capital, the auditor may issue a qualified opinion. Companies must then disclose the qualification in their annual return filed with the MCA.

The DBCP was launched in July 2025 by the Indian Banks' Association in collaboration with ICAI. It provides digitally signed bank balance confirmations directly to auditors, eliminating manual balance confirmation letters. Currently, Canara Bank, Punjab National Bank, Bank of Maharashtra, and UCO Bank are live on the portal. Auditors can request balance confirmations for specific dates, and the digitally signed response is admissible as audit evidence under SA 505.

GST authorities cross-reference declared turnover in GSTR-1 against total bank inflows received through data-sharing arrangements with banks. Unreconciled credits sitting in suspense accounts or unexplained bank deposits that exceed declared sales create a presumption of suppressed turnover. This triggers a demand notice under Section 73 or Section 74 of the CGST Act, with interest at 18% per annum and penalties ranging from 10% to 100% of the tax amount depending on whether fraud is established.

For a company with 3 to 5 bank accounts processing 500 to 2,000 transactions per month, manual reconciliation typically requires 3 to 7 staff days per month. Companies with payment gateway settlements and NACH collections face higher volumes and typically spend 10 to 15 staff days per month. The manual error rate ranges from 15% to 25%, primarily from narration mismatches and date-proximity errors across UPI, NEFT, and RTGS entries.

HDFC Bank NEFT inward credits follow the format 'NEFT CR:[UTR]/[counterparty name]/[reference]' in the narration field. The UTR is 22 characters: 4-digit bank code + 2-digit year + 3-digit day of year + 7-digit sequence (for example, HDFC2268012345678). Forward slashes delimit the fields. In MT940 :86: tag, this narration is prefixed with /INF/.

No. MT940 is available only for HDFC current account holders enrolled in the CMS (Cash Management Services) platform. Standard current accounts and savings accounts receive CSV or PDF downloads via NetBanking only. CMS enrollment generally requires a monthly average balance above ₹5 lakh and a formal onboarding with the HDFC relationship manager.

HDFC NetBanking provides a CSV download with narration as free text — fields are not standardised and narration may be truncated at 100 characters. HDFC CMS delivers MT940 via SFTP or a REST API endpoint at configurable intervals (end-of-day or intraday MT942). CMS also provides structured collection reports for NACH mandates, RTGS high-value credits, and bulk NEFT batches — data that NetBanking does not expose in machine-readable form.

HDFC Bank debits service charges as auto-debit entries. The narration follows the format 'HDFC CHRG [service type] [period]' — for example, 'HDFC CHRG NEFT FEB2026'. GST at 18% on service fees is added in the same debit or as a separate line. Reconciliation systems map these entries to the 'bank charges' GL code and match the GST component against HDFC's monthly tax invoice. Section 194A TDS at 10% applies to HDFC interest credits above ₹40,000 per year and appears as a separate debit in the statement.

The /INF/ prefix is HDFC Bank's internal marker indicating that structured narration information follows. It appears at the start of the :86: tag content — for example, ':86:/INF/NEFT CR:HDFC2268012345678 ABC CORP INV-2024-001'. Reconciliation parsers configured for HDFC must strip the /INF/ prefix before extracting the UTR and counterparty. Systems not configured for this prefix will fail to extract any match key from HDFC MT940 files.

ICICI Bank NEFT inward credits appear as 'NEFT-[UTR]-[counterparty name]-[reference]' in the narration field, using hyphens as delimiters — different from HDFC's forward-slash format. RTGS credits follow 'RTGS CR:[UTR] [counterparty] [reference]'. The UTR is 22 characters starting with ICIC for ICICI-originated transfers or the originating bank's 4-character code for inward credits.

ICICI uses /TXT/ as the prefix in the :86: narration field, while HDFC uses /INF/. A typical ICICI MT940 :86: line reads ':86:/TXT/NEFT-ICIC2268012345678-ABC CORP-INV-2026-001'. Reconciliation parsers must be configured with the correct prefix per bank. Using the HDFC /INF/ parser on ICICI files — a common misconfiguration — results in null extraction of all match keys and 100% manual fallback.

Yes. ICICI iCollect is a collections management service where each payer is assigned a unique virtual account number. Inward payments to a virtual account appear in the main current account statement with the virtual account number in the narration — for example, 'NEFT-[UTR]-ICICI iCollect-[VA number]-[payer name]'. Reconciliation systems must extract the virtual account number as the primary match key, not the UTR or payer name, to correctly attribute the payment to the right invoice or mandate.

ICICI auto-debits service fees with narrations in the format 'ICICI BANK CHARGES [service description] [month]'. GST at 18% on banking service fees is included in the same debit entry or posted as a separate line depending on the account type. ICICI issues a monthly GST invoice. Finance teams must match the charge debit to the ICICI invoice and claim the 18% GST as input tax credit. Section 194A TDS at 10% applies to ICICI fixed deposit interest above ₹40,000 per financial year.

For enterprise accounts on ICICI CIB, MT940 via SFTP is the recommended method — it delivers structured, field-tagged data daily (end-of-day) or intraday (configurable). For accounts not on CIB, CIB portal CSV export is the next best option. PDF statement via InstaAlert or NetBanking should be avoided for reconciliation at scale — it requires OCR and produces 3 to 5 times more manual intervention per 1,000 transactions compared to MT940.

Yes, but only for corporate clients enrolled in IDFC FIRST's connected banking or cash management programme. Standard current account holders receive Excel, CSV, and PDF downloads from the corporate portal. MT940 is delivered via SFTP at end-of-day, with intraday MT942 available on request. Onboarding to MT940 requires a formal request through the relationship manager, agreed delivery windows, and a test cycle to confirm UTR placement and tag mapping before production cutover.

IDFC FIRST NEFT inward credits use the narration format 'NEFT-[UTR]-[remitter name]-[remitter bank]-[reference]' separated by hyphens. The 22-character UTR appears in the second segment and is the most reliable match key. In MT940 the narration is carried inside the :86: tag with the same hyphen-delimited segments. Reconciliation parsers should split on hyphens, validate the second segment as a 22-character alphanumeric UTR, and treat the trailing reference as the customer invoice number candidate.

NACH credits appear as a single consolidated entry per batch with narration 'NACH-[sponsor bank code]-[batch reference]-[settlement date]'. The single line aggregates all successful mandates and does not list individual debtors. To reconcile at mandate level, finance teams must pull the NPCI NACH settlement report or the bank's NACH MIS file and explode the batch against the sub-ledger. The bank statement alone is insufficient for mandate-level reconciliation.

IDFC FIRST offers a corporate connected banking programme that supports host-to-host integration via SFTP and a partner API channel for balance, statement, and payment status retrieval. The exact integration surface is agreed during onboarding and depends on customer tier. Statement files are typically pushed end-of-day; intraday MT942 is available where required. The marketing posture here is general — finance teams should obtain the live specification from their IDFC FIRST relationship manager rather than relying on third-party blogs for endpoint details.

IDFC FIRST debits service charges as auto-debit entries with narration 'IDFC-CHRG-[service type]-[period]'. GST at 18% on bank service fees is included in the same debit or on a separate line, and IDFC FIRST issues a monthly GST tax invoice that supports input tax credit claims. Section 194A TDS at 10% applies to interest credited on fixed and recurring deposits where annual interest exceeds ₹40,000 (₹50,000 for senior citizens) and appears as a separate debit line that must be matched to Form 26AS.

Kotak FYN — the bank's corporate banking portal that replaced Kotak Net for most enterprise users — exposes statements in CSV, PDF, MT940, and a structured collections report. CSV is downloaded on demand; MT940 is delivered via SFTP at end-of-day to corporate clients enrolled in Kotak's cash management services. The collections report is a separate file containing NACH mandate-level settlement detail that is not present in the main statement.

Kotak Mahindra NEFT inward narrations follow 'NEFT IN [UTR] [remitter name] [remitter IFSC] [reference]' with single-space delimiters. RTGS narrations follow the same shape with 'RTGS IN' as the prefix. The UTR is the 22-character standard format and appears at position 9 to 30 in the narration text. In MT940, this content sits inside the :86: tag with Kotak's '/PRI/' structured-information marker at the start, which reconciliation parsers must strip before extracting fields.

When corporates upload bulk NEFT, RTGS, or NACH payment files to Kotak FYN, the bank assigns a Batch Payment ID — a Kotak-internal reference of the form 'KOTBP[YY][NNNNNN]' that appears on the consolidated debit line. The individual beneficiary credits are not in the main statement; they sit in a separate batch-status file downloaded from FYN after settlement. Reconciliation uses the Batch Payment ID to join the consolidated debit to the beneficiary-level credits in the payroll, vendor payment, or NACH collections register.

Kotak Mahindra auto-debits service fees with narrations such as 'KOTAK CHG NEFT [MONTH]', 'KOTAK CHG RTGS [MONTH]', 'KOTAK CHG CASH MGMT [MONTH]', or 'KOTAK CHG CMS UPLOAD [BATCH]'. GST at 18% is added in the same debit line as 'IGST 18%' or as a split 'CGST 9% + SGST 9%' depending on the registered state. Kotak issues a consolidated monthly tax invoice that finance teams use to claim input tax credit. Section 194A TDS at 10% applies to Kotak interest credits above ₹40,000 per financial year on current account sweeps and fixed deposits.

Yes. Kotak FYN supports an MT942 intra-day feed for corporate clients enrolled in its Liquidity Management module. The MT942 file is delivered at configurable intervals during banking hours and reflects provisional postings — credits that have hit the account but may not have cleared inter-bank settlement. For audit-grade reconciliation, the end-of-day MT940 :62F: closing balance remains the book-of-record; MT942 is consumed only for treasury cash visibility and is flagged as provisional in operating reports.

As of 2026, MT940 export is supported by HDFC Bank (via CMS), ICICI Bank (via CIB), Axis Bank (via CMS), Kotak Mahindra Bank (via Kotak CMS), and SBI (for select current account products under the Corporate Banking platform). MT940 is generally available only for current accounts with a CMS or corporate banking relationship — savings accounts and basic current accounts are not eligible.

The :86: tag is the information-to-account owner field in MT940. It contains the narration text for each transaction — including the UTR, counterparty name, and payment reference. HDFC uses a /INF/ prefix inside :86:, while ICICI uses /TXT/. This prefix tells the parser where the structured narration begins. Without correct :86: parsing, a reconciliation system extracts no match keys and every transaction falls to manual review.

CSV exports from NetBanking are unstructured — narration, amount, date, and balance appear as free-text columns with no guaranteed field positions. PDFs require OCR. MT940 uses fixed SWIFT tags: :60F: for opening balance, :61: for each transaction line (date, amount, reference), and :86: for narration. A reconciliation system can reliably extract UTR, value date, and credit/debit indicator from :61: without any text parsing — reducing mismatch errors by 30 to 50 percent compared to CSV import.

No. SBI MT940 is available selectively under the Corporate Banking and Large Corporate segments. Standard current account holders using SBI OnlineSBI or YONO Business receive CSV or PDF downloads only. Enterprises requiring MT940 from SBI must apply through their relationship manager and may need to maintain a minimum average balance of ₹10 lakh or more in the corporate tier.

MT940 files are typically generated once per business day — usually by 8:00–9:00 AM IST covering transactions up to the prior day's bank cut-off. For HDFC and ICICI CMS clients, intraday MT940 (MT942) is available at configurable intervals of 2 to 4 hours. RTGS and NEFT credits posted after the bank's day-end cut-off (generally 6:00 PM IST) appear in the next business day's MT940 file.

MT940 is the legacy SWIFT MT (Message Type) end-of-day statement format that has been in use since the 1990s. CAMT.053 is the ISO 20022 XML equivalent introduced for cross-border payments under CBPR+ migration. The data is broadly equivalent but the structure differs: MT940 uses fixed tags such as :60F:, :61:, :86:, and :62F: with semi-structured free-text content; CAMT.053 uses an XML schema with named elements like statement entry, amount, value date, and structured remittance information. CAMT.053 carries materially more structured data — particularly in remittance information — making downstream reconciliation parsing more reliable.

The SWIFT CBPR+ programme reached its full cutover for cross-border payments on 22 November 2025, ending the coexistence window that began in March 2023. From that date, SWIFT cross-border payments use ISO 20022 messages natively. Statement delivery to corporate customers in India is governed separately — each bank decides when to switch from MT940 to CAMT.053 for its corporate clients. Most large Indian banks offer CAMT.053 alongside MT940 today, with corporates choosing the format their ERP supports.

MT942 is the intraday statement — sent multiple times during the day to report partial activity since the last MT940 or MT942. Use MT942 when treasury needs same-day visibility into customer collections, large outbound payments, or position monitoring before market close. Typical cadences are hourly, every two hours, or on-demand triggered by threshold events. MT940 remains the end-of-day statement of record and is what reconciliation runs against. MT942 supports near-real-time decisioning but does not replace MT940 for end-of-day reconciliation closure.

Yes. ISO 20022 CAMT.053 carries the UTR (or equivalent end-to-end reference) in a structured remittance information element rather than embedded in free text. The schema also supports separate fields for the original ordering customer, intermediary banks, and structured creditor reference. This is a material improvement over MT940, where the UTR and counterparty often live inside the :86: free-text field and need narration-pattern parsing to extract. Reconciliation engines consuming CAMT.053 from Indian banks should map the structured fields directly rather than reapplying MT940-era regex extraction.

No. MT942 is generally available only to corporate customers enrolled in CMS (Cash Management Services) or equivalent treasury platforms at HDFC, ICICI, Axis, Kotak, and a few others. Standard current account holders receive MT940 end-of-day only. PSU banks have variable MT942 support — most large PSU banks support it for top-tier corporate customers but with less mature SFTP delivery infrastructure. Confirm MT942 availability and cadence with the relationship manager before designing intraday reconciliation workflows.

For most mid-market Indian companies, the minimum is twice daily: an opening position pulled by 10:30 AM after the previous night's NEFT/RTGS settlement window closes, and a pre-cut-off position pulled by 4:30 PM ahead of the 6:00 PM RTGS cut-off. Enterprises running active intraday liquidity management refresh on an hourly cadence using MT942 intraday statements from banks that support the format. Banks without MT942 (most PSU banks and several cooperative banks) require a portal pull or CMS report at the same interval.

A target balance sweep leaves a pre-agreed minimum balance in the operating account at end-of-day and moves the rest to a concentration account. A zero-balance account sweeps the entire closing balance to zero each night; any debits the next morning are funded by an automatic reverse-sweep from the concentration account. Zero-balance accounts maximise interest earnings on the concentration pool but require disciplined cash forecasting because morning debits will fail if the concentration account is itself underfunded. Most Indian treasury teams use target balance for operating accounts and zero-balance for collection-only accounts.

Virtual accounts are reference numbers issued by the bank that map to a single real current account. The credit lands in the real account, but the bank's CMS report breaks down the credit by virtual account, customer reference, or invoice tag. The deposit view (NetBanking transaction list) shows only the consolidated credit line, often with a narration like 'VAN CR consolidated'. Treasury teams that reconcile only against the deposit view will not see the customer-level breakdown. The CMS collection report is the authoritative source for virtual account reconciliation.

MT940 is the end-of-day SWIFT statement with confirmed opening balance, all booked transactions, and a confirmed closing balance. MT942 is the intraday transaction report — it carries provisional movements since a defined start time but does not certify a closing balance. Cash position reconciliation uses MT942 to project the live position throughout the day and switches to MT940 after end-of-day for the audit-grade closing position. MT942 is typically delivered every 60 to 120 minutes through SFTP for banks enrolled in intraday reporting.

Idle balance is any positive balance above the agreed target balance that is not earmarked for a known outflow in the next 24 hours. For operating accounts, the target balance is usually one to three days of average outflows. For collection-only accounts, the target is typically zero. Treasury teams flag any account where the closing balance exceeded target by more than 25 percent for three consecutive days, since that pattern indicates either a sweep failure or a forecasting gap. Idle balance over a quarter is recovered as either short-term FD placement or sweep parameter tuning.

The most common cause is a NACH or ECS credit received on the last working day of the month that the bank posts on that date but the company's ERP records in the following period — a 1-day timing difference that creates an opening balance variance of exactly the credit amount. For companies processing 200 or more NACH mandates monthly, this timing mismatch can affect 5–12 transactions in any given month-end cycle.

The correction requires a journal entry reversing the prior-period TDS receivable debit and re-posting it in the correct period. The TDS certificate (Form 16A or 16B) carries the quarter and financial year of deduction, which determines the correct period. If the TDS deduction was under Section 194C or 194J and was booked in Q3 but the certificate covers Q2, the correction must be made before filing the ITR for that financial year to avoid mismatch in Form 26AS.

For a company with 5 bank accounts running monthly reconciliation, opening balance verification should take 30–60 minutes if the prior period was clean and signed off. If prior-period items were left unresolved, the investigation extends to 2–4 hours per account. Companies that automate opening balance carry-forward and flag unresolved prior-period items reduce this to under 15 minutes per account in 90% of months.

A GSTR-2B mismatch does not directly affect the bank opening balance, but it can affect the ITC ledger opening balance. If a GST credit note was received from a supplier in March but not reflected in GSTR-2B until April, and the company booked the ITC in March, the ITC ledger opening balance for April will show a higher credit than what GSTR-2B supports — creating a GST reconciliation exception that must be resolved separately from the bank reconciliation.

The standard approach is a prior-period adjustment entry: debit or credit the relevant account (bank, TDS receivable, GST ITC) with a corresponding credit or debit to a Prior Period Adjustments account (under Other Income or Other Expenses per Schedule III of the Companies Act 2013). If the amount is material (typically above ₹5 lakh for mid-size companies or as defined in the accounting policy), it must be disclosed separately in the notes to financial statements.

A bulk salary NEFT batch appears as a single debit line with a narration such as 'NEFT DR BULK SALARY MAR26 412 EMP' or 'BULK SAL NEFT 412EMPS REF2600312'. The total debit equals the sum of all net salary credits to individual employee accounts. The bank's bulk payment acknowledgement file (CSV or PDF) carries the individual employee-level UTR references — which are the match keys against the payroll register's employee-wise net pay column.

Salary TDS falls under Section 192 of the Income Tax Act. It is deducted at source based on the estimated annual income of each employee and the applicable slab rate. The deducted TDS must be deposited via Challan ITNS 281 by the 7th of the following month — except for the month of March, where the deadline is 30 April. The CIN (BSR code + date + serial number) from the challan is the match key against TRACES records.

PF contribution debits should be matched using the TRRN (Transaction Reference Number from EPFO's ECR portal) as the primary match key. The debit appears as 'PF CONTRIBUTION MMYY TRRN XXXXXXXXXX' and covers both the employee share (12% of basic) and the employer share (3.67% EPF + 8.33% EPS + 0.5% EDLI + 0.5% admin). The total PF debit should equal the sum of the employer and employee PF amounts from the payroll register for all employees earning above ₹15,000 basic.

The most common mid-month failure is an off-cycle salary run — arrear payments, salary revisions, or joining bonuses paid outside the regular payroll date — that creates an additional bank debit not captured in the main payroll register. A revision in July for April through June arrears generates a debit that the reconciliation engine cannot match to the standard payroll file. Off-cycle payments must be tagged in both the payroll system and the bank transfer narration with a distinct reference code.

ESI contributions are debited separately from the salary NEFT — typically 3–7 days before or after the salary date — as 'ESI CONTRIBUTION MMYY REGNO XXXXXXXXXX'. The total debit covers the employer share (3.25%) and employee share (0.75%) for all employees earning ₹21,000 per month or below. The match key against the ESIC portal (esic.gov.in) is the ESI employer registration number and the challan reference. ESI challan deadline is the 15th of the following month.

SBI YONO Business supports CSV download for most current accounts. Select CMP (Cash Management Product) and corporate CMS accounts additionally support MT940 format, which is required for direct integration with SAP and Oracle Financials. Standard CSV from YONO Business is the default for accounts without CMP enrollment.

PFMS credits appear with the narration prefix 'PFMS' followed by the scheme code and beneficiary reference — for example, 'PFMS/MNREGS/2024-25/REF12345678'. The UTR number occupies characters 1–22 and is the primary match key. Finance teams must parse PFMS narrations separately from standard NEFT credits because the structure differs.

MT940 export is available only for accounts enrolled in SBI's CMP (Cash Management Product) or select CMS (Cash Management Services) arrangements, typically accounts with a monthly transaction volume above ₹5 crore. Standard current accounts on YONO Business receive CSV statements only. MT940 enablement requires a separate application to SBI's corporate banking team.

GST refund credits appear with the narration 'GSTN REFUND' followed by the GSTIN, refund application reference number (ARN), and the tax period — for example, 'GSTN REFUND 29ABCDE1234F1Z5/ARN-AB-2024-1234567/032024'. The credit typically arrives 7–10 working days after GSTN processes the refund order and is routed via SBI's government payments gateway.

Companies running SBI alongside HDFC or ICICI should configure separate statement parsers for each bank because narration formats, UTR placement, and date formats differ significantly. SBI narrations are longer (up to 50 characters) and UTR position varies by payment type, whereas HDFC and ICICI follow a more consistent 22-character UTR prefix structure. A multi-pass matching engine that normalises narration formats across banks before attempting UTR extraction reduces the exception rate from approximately 18% to below 4%.

YES Online is the corporate portal where authorised users log in to view balances, download CSV and Excel statements, initiate payments, and pull reports. YES Connect is the host-to-host integration that pushes statement files, payment acknowledgements, and balance reports to the corporate's SFTP endpoint on agreed schedules. For high-volume reconciliation, YES Connect is preferred because it removes the manual download step from YES Online and delivers structured files that ERP statement importers can consume without portal scraping.

Yes. MT940 is available to corporate customers enrolled in the YES Connect host-to-host programme. The file is delivered via SFTP at end-of-day, with intraday MT942 available on request for treasury operations. Onboarding to MT940 requires a formal request through the corporate relationship manager and a test cycle to validate UTR placement inside the :86: tag, account number formatting, and value-date handling before production cutover. Standard YES Online portal users continue to receive CSV, Excel, and PDF formats only.

Yes Bank NEFT inward credits use the narration pattern 'NEFT/[UTR]/[remitter name]/[remitter bank]/[reference]' separated by forward slashes. The 22-character UTR is the second segment after splitting on the slash and is the primary match key. In MT940 the same narration appears inside the :86: tag without a vendor prefix. Reconciliation parsers configured for HDFC's /INF/ prefix should not apply that strip to Yes Bank — doing so corrupts the leading 'NEFT' marker.

Yes Bank underwent a Reserve Bank of India-led reconstruction in March 2020 that brought a consortium of investors into the bank. Operationally, account numbers and IFSC codes remained unchanged for the vast majority of corporate customers and historical reconciliation continues without remap. A small number of legacy customers received account-number changes during subsequent branch consolidation; where historical statements pre-2020 are being matched against current balances, the relationship manager can confirm whether a remap file is needed. For current operations from 2021 onwards, no special handling applies.

Yes Bank debits service fees with GST at 18% included, with narration following 'YESB-CHRG-[service]-[period]' on portal exports. A consolidated monthly GST tax invoice is issued and supports input tax credit claims on the GST component. Section 194A TDS at 10% applies to interest credited on fixed and recurring deposits where annual interest exceeds ₹40,000 (₹50,000 for senior citizens) and appears as a separate debit line tagged 'TDS-194A' that must be matched against Form 26AS.

Indian companies must pay advance tax in four instalments: 15% of estimated tax liability by 15 June, 45% by 15 September, 75% by 15 December, and 100% by 15 March. These percentages are cumulative — by 15 September, the total advance tax paid should be at least 45% of the full-year liability, not 45% of the remaining amount. If any instalment date falls on a bank holiday, payment is due on the next working day. The assessment year for FY 2025-26 is AY 2026-27, and all Challan 280 payments must specify AY 2026-27 correctly.

The CIN (Challan Identification Number) is the three-part identifier printed on the counterfoil of Challan 280 after payment: BSR code of the bank branch (7 digits) + date of deposit (DDMMYYYY) + challan serial number (5 digits). The CIN is the match key that links the Challan 280 payment to the advance tax credit in Form 26AS. During reconciliation, the CIN from the bank challan counterfoil or bank statement must match the CIN appearing in Form 26AS Part F (Details of Tax Deducted at Source / Tax Collected at Source / Advance Tax). If the CIN does not appear in Form 26AS, the payment has not been credited to the PAN.

After a Challan 280 payment is made online or at a bank branch, the credit typically appears in Form 26AS within 3 to 7 working days. For NEFT-based payments through netbanking, the update is usually faster (3–4 days). For physical challan payments at bank branches, the branch must upload the data, which can take 5–7 working days. Reconciliation run immediately after payment will show the bank debit but not the Form 26AS credit — this is a timing difference that should be tagged and reviewed 7 days after payment.

Section 234C interest applies when the cumulative advance tax paid by any instalment date is less than the prescribed percentage. The interest rate is 1% per month (12% per annum) on the shortfall amount, calculated for a period of 3 months (for June and September instalments) or 1 month (for December and March instalments). For example, if the September instalment requires 45% of ₹10,00,000 tax = ₹4,50,000, and only ₹3,00,000 was paid, Section 234C interest applies on ₹1,50,000 at 1% per month for 3 months = ₹4,500.

If Challan 280 is paid under the wrong PAN, the credit will appear in Form 26AS of the wrong taxpayer, not in the company's Form 26AS. The company will show a shortfall, and Section 234B/234C interest will accrue. Correction requires submitting a challan correction request through the bank that accepted the payment, or through the Assessing Officer's office, which can take 30–90 days. If paid under the correct PAN but wrong assessment year, the credit appears under the wrong year and the same correction process applies. Both errors must be corrected before the return filing date to avoid demand notices.

APS-04 is a NACH variant that introduces a pre-booking step before the actual debit presentation. The originator submits an APS-04 request to reserve a debit on the customer's account, the customer's bank confirms the pre-booking, and the actual debit is then presented and settled on the scheduled date. Standard NACH-Debit has no pre-booking step — the debit is presented directly, with the result coming back on settlement day. APS-04 trades a longer cycle for higher confirmation certainty, which is useful for higher-ticket recurring debits.

The reconciliation engine must hold each APS-04 instruction in a pre-booked state until either a presentment confirmation arrives, a presentment failure arrives, or a timeout elapses. A pre-booked instruction that does not progress to a presentment within the expected window indicates an originator-side or bank-side failure that needs investigation — not a customer-side failure. The instruction reference is the join key across all three states (pre-booked, presented, settled or returned).

The settlement cycle depends on when the APS-04 request was pre-booked and when the presentment was scheduled. A typical pattern is pre-booking on D-3, presentment on D-day, and settlement on D-day or D+1. The exact timing is set by the originator's batch policy and the presenting bank's processing windows. The reconciliation engine should treat the pre-booking date and the presentment date as distinct event dates, both stored on the instruction record.

Return codes at the presentment stage are the same NPCI library used by standard NACH-Debit — codes 01 through 99 for insufficient funds, account closed, mandate not registered, and the rest. The difference is that APS-04 can also fail at the pre-booking stage, with a separate set of pre-booking rejection reasons. Reconciliation engines should track both failure modes on the same instruction record so the operations team can see whether the instruction died at pre-booking or at presentment.

APS-04 is preferred when the originator wants advance confirmation that the customer's account will support the debit — typical for higher-ticket recurring obligations like insurance premiums, education fees, and corporate subscription billing where a failed debit creates downstream service-disruption risk. For low-ticket consumer subscription billing where retries are cheap and customer notification can absorb a failed debit, standard NACH-Debit is usually sufficient.

The primary reconciliation difference is the match key. Legacy ECS used the MICR code and bank account number as the mandate identifier — a combination that was not unique across banks and did not support end-to-end tracking from originator to destination bank. NACH replaced this with the UMRN (Unique Mandate Reference Number), a 20-character alphanumeric identifier assigned by NPCI at mandate registration. The UMRN appears in every NACH file — the batch submission, the settlement confirmation, and the return file — making mandate-level traceability possible in a way that ECS never supported.

Legacy ECS mandates were identified using the MICR code of the destination bank branch plus the account number. This combination was not globally unique — two accounts at different banks could share the same MICR+account pattern in edge cases — and the MICR code changed when a bank branch relocated or was absorbed in a merger. NACH's UMRN is a 20-character alphanumeric code assigned by NPCI centrally at mandate registration. The UMRN never changes for the life of the mandate and is unique across all banks, making it a reliable primary key for reconciliation.

Double debit occurs when an ECS mandate and a NACH mandate for the same borrower and the same EMI due date are both active and both presented in the same billing cycle. Since ECS and NACH run on separate rails and separate bank processing queues, the destination bank processes both independently and may honour both — debiting the borrower's account twice for the same EMI. The lender receives two credits for the same loan account. Preventing this requires maintaining a deduplication flag in the mandate register: once a NACH mandate is registered and active for a borrower, the corresponding ECS mandate must be cancelled before the next ECS batch submission.

During the dual-running period, the reconciliation system must maintain two parallel mandate registers: one for active ECS mandates with MICR+account as match key, and one for active NACH mandates with UMRN as match key. Each bank credit must be tagged to its originating channel — ECS or NACH — based on the transaction reference format. Once tagged, the credit is matched to the borrower's loan record using the appropriate match key. A deduplication check must run before each batch submission to ensure no borrower has both an ECS and a NACH mandate active for the same due date.

RBI mandated the migration from ECS to NACH and directed banks to transition mandate volumes to the NACH platform. NACH is now the active platform managed by NPCI for bulk debit and credit mandates. Legacy ECS infrastructure has been wound down at most major banks. However, some organisations that completed the technical migration early still carry residual ECS references in their internal systems for historical mandate records predating the migration. For active mandate books, NACH is the only operating channel.

The employer ESI contribution rate is 3.25% of gross salary. The employee ESI contribution rate is 0.75% of gross salary. Both contributions are calculated on gross salary (including basic, DA, HRA, and all allowances except overtime wages and certain excluded payments). The combined ESI contribution rate is 4% of gross salary for covered employees. For employees earning up to ₹137 per day, the employee contribution is waived — the employer still contributes 3.25%.

ESI coverage applies to employees earning ₹21,000 per month or less in gross salary (₹25,000 per month for persons with disability). Coverage is determined at the start of each contribution period — April 1 or October 1 — based on wages in the preceding period. An employee who earns ₹18,000 per month in October gets covered from October 1 regardless of whether their salary rises above ₹21,000 during the six-month period ending March 31. Coverage ends only at the next contribution period boundary.

An IP (Insurance Policy) number is the unique identifier assigned to each covered employee by ESIC when they are registered on the ESIC portal. The IP number is used to match contribution data at the employee level: the employer's monthly return lists contributions by IP number, and ESIC's records are maintained at the IP number level. During ESI reconciliation, the count of active IP numbers in the ESIC portal for the wage month should match the count of covered employees in the payroll register. IP number mismatches occur when new employees are not registered promptly or when exited employees remain active in the ESIC portal.

The monthly ESI challan must be paid by the 15th of the month following the wage month. For wages paid in January, the ESI challan payment deadline is 15 February. The employer must file the monthly contribution return on the ESIC portal and pay the challan within this deadline. Late payment attracts interest at 12% per annum under the ESI Act. If the 15th falls on a bank holiday, the payment is due on the next working day.

ESI contribution periods run April–September and October–March. Coverage for each period is determined by wages in the immediately preceding period. An employee earning ₹19,000 per month during April–September will be covered during October–March — even if their salary is revised to ₹24,000 in November. The ESI challan for November must include this employee at the new gross salary of ₹24,000 (contributions at 4% of ₹24,000), even though the employee is above the ₹21,000 ceiling. Companies with bi-annual salary revision cycles see systematic headcount and contribution mismatches at each contribution period boundary, requiring a reconciliation run specifically for the transition months of April and October.

Apply the 15-day rule as a conservative default. If no written agreement is documented in your records, Section 15 of the MSMED Act treats the relationship as having no agreed payment period, which triggers the 15-day window. Retroactively claiming that an informal understanding constitutes a written agreement is not accepted under the Act. The safer approach is to formalise all MSME vendor agreements in writing and retain the documents, which then permits the 45-day window.

Partial payment does not reset the clock on the remaining outstanding amount. If ₹5 lakh is due to an MSME and ₹2 lakh is paid within 15 days, the remaining ₹3 lakh continues to age from the original acceptance date. If the ₹3 lakh is not paid within the applicable window (15 or 45 days from acceptance), only that amount is disallowed under Section 43B(h). Track each invoice balance separately — do not aggregate across invoices from the same vendor.

For Section 43B purposes, the relevant date is when the payment leaves the buyer's account — that is, the bank debit date on the NEFT/RTGS transaction. NEFT settles in hourly batches and RTGS is real-time during business hours, so the credit at the MSME's end normally happens the same day. The UTR generated at the time of NEFT/RTGS initiation is the documentary evidence of payment date. Retain UTR records for all MSME vendor payments as part of the compliance trail.

Monthly at minimum, but for companies with high MSME vendor volumes, a weekly review is more protective. The 15-day window in particular requires near-real-time monitoring — by the time a monthly review catches a breach, it is already too late for that payment. Set system alerts when MSME payables reach 10 days outstanding (for the 15-day rule) and 35 days outstanding (for the 45-day rule), giving the AP team a working window to clear before breach.

Most corporate NACH-Credit batches settle T+0 or T+1 depending on the presenting bank and the batch cut-off. A batch submitted before the morning cut-off (typically 11:00 AM) usually settles same day; a batch submitted after cut-off settles next business day. The bank debits the corporate's account on the settlement date and credits the beneficiary accounts. Return files for failed credits typically arrive T+1 from settlement, occasionally T+2.

The bank debit alone is not a reconciliation. The correct reconciliation joins three sources: the credit instructions submitted to the bank (one row per beneficiary), the bank debit advice or settlement confirmation (gross amount), and the return file (per-beneficiary failures with reason codes). The gross debit minus the return value should equal the value actually credited to beneficiaries. If it does not, the difference is a reconciliation exception that must be cleared the same day.

Common NACH-Credit returns include code 02 (account closed), 03 (no such account), 04 (account inoperative), 05 (account frozen), 11 (mandate not registered, for mandated credit), and 25 (invalid beneficiary details). The corporate response is to repost the failed credits via NEFT or RTGS the same business day, update the beneficiary master if the bank account details have changed, and emit an exception MIS to the payroll or accounts payable team for follow-up with the beneficiary.

For TDS, the corporate's liability is discharged when the payment reaches the government's account via the income tax challan rail, not via NACH-Credit. For vendor payments, however, NACH-Credit failures matter for Section 43B(h) MSME-payment recognition and for TDS deposit timing on payments to suppliers. A failed NACH-Credit that is not reposted within the statutory window can push a payment outside the 45-day MSME window or delay TDS deposit, both of which carry disallowance and interest exposure.

NACH-Credit handles thousands of beneficiaries in a single file with one debit on the corporate's account, one settlement reference, and one return file. NEFT and RTGS require one transaction per beneficiary, generating one bank debit per payment and one credit confirmation per payment — at scale, that volume of bank events overwhelms reconciliation and increases per-transaction fees. NEFT and RTGS remain useful for one-off high-value payouts and for reposting NACH-Credit failures.

Return code 01 (Insufficient Funds) is retriable under the NPCI framework. Most NBFCs allow up to two retries per billing cycle, with each retry submitted 3 to 5 business days after the previous return. The retry uses the same UMRN and does not require fresh mandate registration. Critically, retries do not reset the DPD counter — DPD continues to accrue from the contractual due date regardless of how many retries succeed within the cycle.

Codes that indicate a structural problem with the mandate are non-retriable. These include account closed (10), no such account (11), payer deceased (08), mandate not registered (16), and account frozen (17). For these, the NBFC must stop further presentations on the UMRN, trigger a re-registration workflow with the borrower, and post the EMI as outstanding with DPD starting from the original due date. Continuing to present on a non-retriable code wastes presentation slots and accumulates bank charges.

A useful segmentation runs on rolling 90-day data and groups borrowers into four bands: clean (zero bounces), occasional (one bounce, recovered on retry), persistent (two or more bounces, eventually paid), and chronic (failed cycle with DPD greater than 30). Each band drives a different collection action — clean borrowers stay on auto-debit, persistent borrowers move to pre-debit reminders, and chronic borrowers shift to manual collections. The segmentation only works when the reconciliation engine posts return codes to the LMS within the same business day.

Yes, if the loan agreement explicitly provides for bounce charges and the charge is disclosed in the Key Fact Statement at origination. The recovery is added to the next billing cycle as a separate line item, and the reconciliation system must track which bounce charges have been billed, paid, or written off. RBI's October 2023 fair-lending circular requires that penal charges be reasonable, disclosed up-front, and not capitalised — so the recovery process must respect those limits.

Under the RBI co-lending model, the originating NBFC typically collects EMIs via NACH and remits the partner bank's share within a contractually defined window — usually T+1 or T+2 from settlement. Daily reconciliation produces the borrower-level success and return outcomes that drive the partner remittance file. A weekly cycle delays partner remittance and creates float on the NBFC's books that does not legally belong to it, which is a co-lending compliance concern.

UMRN stands for Unique Mandate Reference Number — a 20-character alphanumeric identifier assigned by NPCI when a NACH mandate is successfully registered. In mandate reconciliation, the UMRN is the primary key used to match the internal mandate register entry against NPCI's mandate database. If a UMRN appears in the internal register with status Active but NPCI shows it as Cancelled, the next NACH debit presentation using that UMRN will return with code 25 (Mandate Cancelled). Regular UMRN-level reconciliation against NPCI's portal prevents these avoidable returns.

When a borrower submits a cancellation request to their bank, the bank processes the cancellation through NPCI's NACH mandate management system. NPCI updates the mandate status to Cancelled and the UMRN becomes inactive. The originator (NBFC or lender) is not automatically notified — the cancellation appears only in the return file when the next debit presentation fails with return code 25. This notification gap is why proactive mandate register reconciliation matters: without a weekly check against NPCI's mandate status data, the lender discovers the cancellation only after a failed debit.

For NBFCs with active NACH debit batches, a weekly mandate register reconciliation is the minimum acceptable frequency. High-volume lenders (above 50,000 active mandates) should run reconciliation at least twice per month, with an additional check 48 hours before each major batch submission. The pre-batch check catches cancellations and expired mandates that would otherwise generate avoidable returns. Some lenders with API access to their bank's NACH portal run daily mandate status checks for mandates flagged as at-risk (previous code 01 returns or recent stop payment history).

A NACH mandate amendment for a bank account change requires the originator to submit a cancellation request for the existing UMRN and register a fresh NACH mandate on the new bank account. NACH does not support mid-mandate account number changes in place — the amendment is a cancel-and-reregister process. The new mandate registration typically takes 5–7 working days to be activated by NPCI. During this window, the EMI cannot be collected via NACH; the lender must arrange an alternative collection method (UPI AutoPay or post-dated cheques) to avoid a DPD gap.

A new NACH mandate registration submitted to NPCI through the presenting bank takes 5–7 working days to be processed and activated. The mandate becomes available for debit presentations only after NPCI assigns a UMRN and marks the mandate as Active. First-time debit presentations can be submitted only after this activation. If a batch is submitted with a UMRN that has not yet been activated, the presentation will return with an error code. Lenders typically build a 10-day buffer between mandate registration and the first EMI due date to account for processing delays.

RBI's prudential norms require that DPD counting begins from the contractual due date, not from the date the NBFC processes the return. In practice, this means the LMS must be updated within the same business day the return file is received — typically T+1 or T+2 from presentation date. An NBFC that processes returns only during weekly reconciliation runs will systematically understate DPD for 5–6 days on every failed debit, which affects NPA provisioning accuracy for the period.

Under RBI IRACP norms, a loan account becomes a Non-Performing Asset (NPA) when it remains overdue for more than 90 days. If the NACH return is posted to the LMS 5–7 days late in each billing cycle, the effective DPD count is understated by those days. Over three billing cycles, this can delay NPA classification by 15–21 days relative to the correct timeline — directly affecting provisioning requirements and regulatory reporting accuracy.

Partial NACH settlements are uncommon but occur when a bank applies a partial debit due to account-level restrictions. The reconciliation system receives a settlement amount lower than the presented amount. The correct LMS update is to post the actual amount collected as a partial payment, mark the balance as outstanding, and begin DPD counting on the unpaid portion from the original due date. For detailed handling, the partial payment reconciliation India process applies the same net-settled logic used in payment gateway contexts.

Yes. Return code 01 (Insufficient Funds) is a retriable return under NPCI's NACH framework. The originator can submit a fresh NACH presentation using the same UMRN. Most NBFCs allow a maximum of 2 retries per billing cycle. The retry window is typically 3–5 business days from the original return date. Each retry resets the presentation date but does not reset the DPD counter — the DPD counter runs from the original contractual due date regardless of retry attempts.

RBI does not publish a specific NACH return rate threshold in isolation, but NACH return rates feed directly into the NBFC's portfolio-at-risk (PAR) metrics, which form part of the Supervisory Return (NBS-7 and NBS-9) submitted to RBI. An NBFC with high unreconciled NACH return rates may show understated PAR figures in regulatory returns, which can attract scrutiny during inspections. Accurate NACH reconciliation is therefore both an operational and a compliance requirement.

NACH return code 01 means Insufficient Funds — the borrower's account did not have enough balance on the presentation date. This is a retriable return. Most lenders allow up to 2 retry attempts within the same billing cycle. The retry must be submitted as a new NACH batch with the same UMRN. Each retry attempt resets the presentation date for DPD calculation purposes, so lenders typically retry within 3–5 business days of the original return.

Code 20 (Account Closed) means the destination bank account no longer exists. Code 25 (Mandate Cancelled by Account Holder) means the account is active but the borrower has specifically withdrawn the NACH mandate authorization. Both are non-retriable returns, but the resolution differs: code 20 requires the borrower to register a new mandate on a different bank account, while code 25 requires mandate re-registration on the same or a different account — and may indicate intentional non-payment, which triggers a separate collections workflow.

Code 27 (Stop Payment) means the account holder has placed a specific instruction with their bank to stop the NACH debit. Unlike code 01 (Insufficient Funds), code 27 is a deliberate borrower action and is classified as a dispute return, not a liquidity failure. Retrying a code 27 return without resolving the underlying dispute will result in a repeated code 27. The correct workflow is to initiate a borrower contact and dispute resolution process — not a standard retry.

Under the NPCI NACH framework, the destination bank returns rejected mandates to NPCI, and the return file is made available to the presenting bank (and through it, to the originator) within T+1 or T+2 business days from the presentation date. In practice, most NBFCs configure their bank's API integration to receive the return file by T+1 morning. A 48-hour processing window is the maximum accepted delay before DPD reporting is considered understated.

UMRN stands for Unique Mandate Reference Number — a 20-character alphanumeric identifier assigned by NPCI at the time of mandate registration. Every NACH debit presentation carries the UMRN, and every return file entry includes the UMRN of the failed mandate. The reconciliation system uses the UMRN as the primary match key to link each return code back to the specific borrower, loan account, and scheduled EMI amount in the loan management system (LMS).

The ECR (Electronic Challan cum Return) is the single monthly filing submitted by employers on the EPFO portal that combines both the challan (payment instruction) and the return (employee-level contribution data). It contains each employee's UAN, wage month, gross wages, EPF wages, employer EPF contribution (3.67%), employer EPS contribution (8.33%, capped at ₹15,000 basic), employee EPF contribution (12%), and EDLI contribution (0.5%). Filing and payment must happen together — the ECR generates the TRRN once the challan amount is confirmed.

The TRRN (Transaction Reference Number) is a unique number generated by the EPFO portal when the employer raises a PF challan. It appears in the bank narration as 'EPFO TRRN [number] PF CONTRIBUTION [MONTH]' when the challan amount is debited. The TRRN is the primary match key linking the ECR filing on the EPFO portal, the bank debit on the bank statement, and the PF expense ledger entry in the books. Without the TRRN, PF bank reconciliation relies on amount matching alone, which fails when multiple challans of similar amounts are filed in the same period.

The ECR must be filed and the corresponding PF challan must be paid by the 15th of the month following the wage month. For wages paid in January, the ECR filing and challan payment deadline is 15 February. The deadline applies to all establishments covered under the EPF and MP Act, 1952. Late payment attracts interest under Section 7Q at the rate of 12% per annum from the due date to the actual date of payment.

For employees with basic salary above ₹15,000, the employer's EPS (Employees' Pension Scheme) contribution is capped at 8.33% of ₹15,000 = ₹1,250 per month. The employer's EPF contribution for such employees is 12% of actual basic minus ₹1,250. The employee's own EPF contribution remains 12% of actual basic with no cap. In the ECR, the 'EPF wages' column shows the actual basic; the EPS calculation is automatically capped by the portal. Misapplying the cap — either in payroll or during ECR reconciliation — is a common source of ECR-to-payroll mismatch.

Late PF challan payment attracts interest under Section 7Q of the EPF and MP Act at 12% per annum (1% per month). The interest accrues from the due date (15th of the following month) to the actual date of payment. If a company has 100 employees with an average monthly PF contribution of ₹3,000 per employee, a single month's delay on a ₹3,00,000 challan accrues ₹3,000 in interest. Interest payments must be separately accounted for and are not deductible as business expense.

The EPF contribution and the ESI contribution are both due by the 15th of the following month — wages for May are deposited by 15 June. A missed cut-off triggers automatic interest under Section 7Q at 12 percent per annum on the unpaid amount, calculated from the 16th to the date of deposit. In addition, EPFO may levy damages under Section 14B at rates ranging from 5 percent to 25 percent of the arrears depending on the period of default. Section 14B damages are discretionary in name but routinely applied during inspections.

The reconciliation runs across three artefacts. The payroll register reports each employee's gross wages, EPF wages (capped at ₹15,000 unless the voluntary higher contribution is in force), employer share, and employee share. The ECR file uploaded to the EPFO portal carries the same per-employee numbers in the prescribed format. The bank challan is the deposit receipt against the ECR. All three must match on totals and on per-employee detail; any mismatch must be resolved before the deposit cut-off.

EPF: employee contributes 12 percent of EPF wages, employer contributes 12 percent split between EPF (3.67 percent), EPS (8.33 percent capped at the wage ceiling), and EDLI plus administrative charges (0.5 percent plus 0.65 percent EDLI). ESI: employee contributes 0.75 percent of gross wages up to the ₹21,000 wage ceiling, employer contributes 3.25 percent of the same. The reconciliation engine must compute each share independently and validate that the totals in the ECR file align with the payroll register.

NACH-Credit handles the net-pay disbursement to employees on payroll day. The EPF and ESI deposits are separate transactions to the EPFO and ESIC challan accounts, typically settled by 15th of the following month. The two flows are reconciled independently — the payroll NACH-Credit reconciliation confirms net pay landed in employee accounts, and the statutory reconciliation confirms the employer and employee statutory shares landed at EPFO and ESIC. The link between them is the per-employee payroll register, which is the source of truth for both reconciliations.

If the ECR is uploaded but the bank challan deposit fails — for example, an insufficient-funds return on the NACH-Debit settlement — the EPFO portal will mark the ECR as unpaid, the late-fee interest meter starts on the 16th, and the employer is technically in default. The reconciliation MIS should flag any ECR with no matching successful bank challan within the cut-off window the same day, so the employer can re-initiate the deposit before the late-fee meter starts.

Professional tax is levied by states under Article 276 of the Constitution, capped at ₹2,500 per person per year. Major states levying PT include Karnataka, Maharashtra, Gujarat, West Bengal, Tamil Nadu, Andhra Pradesh, Telangana, Kerala, Madhya Pradesh, Assam, Odisha, and Jharkhand. Slab structures vary materially — Karnataka levies ₹200 per month above a threshold gross salary, Maharashtra runs a multi-slab schedule from ₹175 to ₹300 per month with a higher rate for February, Gujarat runs ₹200 monthly, and West Bengal runs ₹110 to ₹200 across slabs. Each state publishes its current schedule on the commercial taxes department portal.

The state-of-work field on the payroll register, captured at the salary-cycle level, is the controlling field. Most employers apply PT in the state where the employee is principally based for the month — usually the registered place of work for that month. Employees on temporary assignments or transfers mid-month follow the policy the employer has documented. The reconciliation engine should validate that every employee has a state-of-work value every month and that the value matches the PT registration the employer holds in that state.

Most states require monthly deduction and monthly deposit, typically by the 10th to the 20th of the following month — Karnataka by the 20th, Maharashtra by the end of the following month (with quarterly returns), Gujarat by the 15th. The cycle is similar to EPF and ESI in shape but the dates are state-specific. Reconciliation engines should encode each state's calendar and surface upcoming cut-offs from a shared event source so the payroll team does not miss a state-specific date.

All three are payroll-driven obligations computed from the same per-employee gross wages. The reconciliation engine reads the payroll register, applies PT slabs by state of work, applies EPF on EPF wages, and applies ESI on gross wages (capped at ₹21,000). Each obligation has its own deposit channel, its own portal, its own cut-off. The integrating discipline is per-employee per-month — every payroll row produces a PT amount, an EPF share, and an ESI share, and each must be reconciled against its respective deposit.

A useful PT MIS shows per-state per-month: number of employees liable, total PT computed, total PT deposited, cut-off date, deposit date, and any open variance. Variances are typically state-master mismatches (employee assigned to a state where the employer is not registered for PT) or computation errors (wrong slab applied). The MIS should also flag any state where PT computed is zero but the employer has employees assigned — which usually indicates a misconfigured state master.

No. Section 43B(h) covers only Micro and Small enterprises as defined under the MSMED Act 2006 (revised 2020). Micro enterprises have investment below ₹1 crore and turnover below ₹5 crore. Small enterprises have investment below ₹10 crore and turnover below ₹50 crore. Payments due to Medium enterprises (investment below ₹50 crore, turnover below ₹250 crore) are not subject to the 15/45-day disallowance rule.

If a supplier has not obtained Udyam Registration from the government portal (udyamregistration.gov.in), they cannot legally claim MSME status. Section 43B(h) applies only to registered Micro and Small enterprises. However, the tax department may scrutinise situations where payments are delayed to suppliers who later obtain Udyam registration retroactively. Best practice is to collect Udyam certificates at the time of onboarding every new vendor.

No. Section 15 of the MSMED Act sets a hard cap of 45 days regardless of the contract terms. A buyer and MSME supplier can agree to any timeline in writing, but the maximum enforceable period is 45 days from the date of delivery or acceptance. Any contractual clause exceeding 45 days is void in relation to the MSMED Act. The 15-day rule applies where no written agreement exists.

Yes. Beyond income tax disallowance, the MSMED Act provides for compound interest on overdue payments at three times the bank rate notified by RBI. This civil remedy is separate from the tax consequence. Additionally, CARO 2020 requires company auditors to specifically disclose amounts due to MSMEs outstanding for more than 45 days in the audit report, creating reputational and regulatory exposure beyond the tax risk alone.

The disallowed amount is deductible only in the financial year in which actual payment is made to the MSME supplier. If ₹10 lakh due to an MSME was not paid in FY 2024-25, it is disallowed in AY 2025-26. When the payment is made in FY 2025-26, the ₹10 lakh becomes deductible in AY 2026-27. There is no retrospective relief — the timing of actual payment determines the year of deduction.

Indian companies must track the following recurring statutory payment deadlines: TDS challan (Challan 281) — 7th of the following month (30 April for March); GST PMT-06 / monthly challan — 20th of the following month for GSTR-3B filers; PF ECR filing and challan payment — 15th of the following month; ESI challan — 15th of the following month; professional tax — varies by state, typically 15th–20th. Advance tax instalments are quarterly: 15 June, 15 September, 15 December, and 15 March. A single statutory payment register tracking all six obligation types with their due dates prevents deadline misses that arise when different teams manage different portals.

CPIN (Common Portal Identification Number) is the 14-digit number generated by the GST portal when a taxpayer creates a GST challan (PMT-06) for payment of CGST, SGST, IGST, or cess. The CPIN is valid for 15 days from generation. Once payment is made, the bank transmits the CPIN to the GST portal, which updates the electronic cash ledger. The CPIN is the primary match key in GST payment reconciliation — it links the GST challan in the GST portal to the bank debit. The bank narration for GST payments follows: 'NEFT CR GSTN CPIN [14-digit number] CGST SGST IGST'. Any GST portal challan without a CPIN confirmation is an open item in the statutory payment register.

This is a timing difference, not an error, in most cases. The standard resolution path is: (1) confirm the bank debit by locating the narration with the match key (TRRN, CPIN, CIN, or BSR+date+serial); (2) check the government portal status for the challan — most portals (TRACES, GST, EPFO, ESIC, OLTAS) have a challan status lookup by match key; (3) if the portal shows the challan as pending, allow 2–3 working days for confirmation; (4) if the portal shows no record after 5 working days, file an inquiry with the bank — the payment data may not have been transmitted. Tag the item in the statutory payment register as 'bank debit confirmed — portal pending' with the expected resolution date.

Interest for late TDS deposit is charged at 1.5% per month (18% per annum) under Section 201(1A) of the Income Tax Act for the period from the date on which TDS was deducted to the date of actual deposit. For TDS not deducted, the interest rate is 1% per month from the date on which TDS was deductible. Even a single day's delay triggers a full month's interest — a TDS challan due on 7 February and paid on 8 February incurs 1.5% interest for the full period. For a company with a monthly TDS liability of ₹5,00,000, a one-month delay costs ₹7,500 in interest.

An Indian company with a workforce and multiple tax registrations typically logs into 5–6 separate portals every month to verify statutory payment compliance: (1) TRACES / Income Tax portal — for TDS challan confirmation and Form 26AS; (2) GST portal — for CPIN confirmation and electronic cash ledger; (3) EPFO portal — for TRRN confirmation and ECR filing status; (4) ESIC portal — for ESI challan confirmation and IP number count; (5) OLTAS portal — for advance tax CIN status; (6) state professional tax portal (if applicable). Each portal uses a different match key, a different login credential, and provides confirmation in a different format — making manual monthly verification a significant time sink without a consolidated statutory payment register.

It must handle TDS net-of-gross receipt matching — where the invoice amount, TDS deducted at source, and net bank credit are three separate figures that all need to reconcile simultaneously. The software must match the TDS certificate reference, PAN of the deductor, the applicable section (194C, 194J, 194H, etc.), and deposit quarter to Form 26AS. Organisations on generic accounting platforms find that this three-way match requires manual adjustment outside the system — which reintroduces the same exception management overhead that automation is meant to eliminate.

GSTR-2B is a supplier-level, GSTIN-level document with locking behaviour — ITC appearing in GSTR-2B for a period is locked to that period and cannot be claimed in an earlier period even if the invoice was dated earlier. Generic GST reconciliation tools that compare invoices to GSTR-2A (the older, non-locking document) will produce a different exception set than GSTR-2B-based matching. The Rule 36(4) ITC cap is calculated on GSTR-2B data, not GSTR-2A. Any reconciliation software evaluated for Indian ITC claiming must demonstrate GSTR-2B-specific matching, not just GST reconciliation in general.

A purpose-built platform with India-specific presets configures and deploys in 2 to 4 weeks. Week 1 covers ERP field mapping and data source connection. Week 2 is integration testing with live transaction data. Week 3 is a parallel run alongside the existing manual process. Week 4 is production cutover and sign-off. Generic or custom-built tools without India presets typically require 3 to 6 months of configuration and development, since the TDS, GST, and NACH matching logic must be built from scratch.

A realistic contract target for a purpose-built reconciliation platform is 70–85% automated match rate across all transaction types. This means 70–85% of transactions are confirmed without human intervention. The remaining 15–30% form a structured exception queue classified by variance code — FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, or UNEXPLAINED — so exceptions are pre-sorted by resolution path rather than presented as an undifferentiated list of unmatched items.

India data residency means the reconciliation platform stores all financial transaction data — bank statements, ERP records, TDS certificates, GSTR-2B data — within India-based data centre infrastructure. For listed companies and regulated entities (NBFCs, payment aggregators), RBI and SEBI guidelines require financial data to be stored within India. AWS Mumbai (ap-south-1) satisfies this requirement. Platforms hosted on generic EU or US infrastructure may not satisfy domestic data localisation obligations, creating compliance risk separate from the reconciliation function itself.

Yes, provided the platform supports entity-level separation within a single instance — separate ledgers, separate TDS reconciliation runs, separate GSTR-2B matching per GSTIN, but a consolidated exception dashboard across entities. CAs working with spreadsheet-based multi-entity clients flag that cross-entity reconciliation requires manual export-and-merge workflows across separate files, which introduces reconciliation errors and makes consolidated audit trails impossible. A multi-entity reconciliation platform eliminates the merge step and maintains entity-level audit integrity.

For most Indian enterprises, TDS compliance coverage is the highest-stakes criterion because errors in Form 26AS matching carry 18% per annum interest under Section 201 of the Income Tax Act, plus potential disallowance of expenses. Specifically, verify that the platform handles TDS net-of-gross matching — where TDS is deducted from gross invoice value but the bank credit arrives net — and supports all relevant sections (194C, 194J, 194H, 194I, 194Q) rather than a generic TDS flag.

A platform with pre-built India-specific presets and config-only deployment should be live in 2 to 4 weeks. Week 1 covers ERP field mapping and connector setup; Week 2 covers matching rule configuration and tolerance band calibration; Week 3 is a parallel run against the existing manual process; Week 4 is production cutover and sign-off. Any vendor quoting more than 8 weeks for standard deployment is likely building custom code — which extends timelines, increases cost, and creates maintenance dependency.

At minimum, require ISO 27001:2022 certification and AWS Mumbai (ap-south-1) data residency for most Indian enterprises. Regulated entities — NBFCs, payment aggregators, banks, and insurance companies — should additionally verify alignment with RBI's IT and cyber security frameworks, and SEBI's cloud framework for market intermediaries. DPDP Act 2023 compliance documentation should be requested from any vendor handling personal financial data of Indian customers.

A config-only platform deploys in 2 to 4 weeks by setting parameters — ERP field mappings, matching rules, tolerance bands, industry presets — without writing code. A custom-development platform requires developers to build or extend matching logic for each client, typically taking 3 to 6 months and creating ongoing maintenance dependency on the vendor. For Indian enterprises, config-only is preferable because regulatory changes (new GST rules, new TDS sections, revised NACH codes) are absorbed by the vendor through rule updates rather than requiring a new development engagement.

Ask the vendor to run your own sample data — a month of bank statements and ERP exports — through their matching engine before you sign. A credible engine should achieve at minimum 70% match rate on your first pass, with exceptions classified by variance code (not just flagged as unmatched). Request to see the signal hierarchy applied: UTR should carry the highest priority because it is the most deterministic Indian payment identifier. If the vendor cannot demonstrate match rate improvement across multiple passes on your own data, their published benchmark numbers apply to a different dataset.

The practical threshold is 2,000 transactions per month. Below 500 transactions with simple matching rules, Excel is workable. Between 500 and 2,000, error rates climb and audit trail gaps become a risk. Above 2,000, manual reconciliation in Excel typically consumes 40–60 staff hours per month and produces reconciliation sign-off delays that affect the monthly close cycle.

Python can handle TDS matching for stable, structured data, but it breaks when deduction rules change across sections (194C, 194J, 194H) or when gross receipt amounts vary by counterparty. India-specific scenarios — particularly TDS matched to Form 26AS entries with different PAN-TAN combinations — require logic that must be rebuilt every quarter if maintained in scripts.

GSTR-2B reconciliation can be started in Excel, but ITC eligibility under Rule 36(4) changes with each GST council notification, and GSTIN validation requires a live check against the GST portal. Excel has no mechanism for portal-integrated validation, which means eligibility decisions must be made manually. For businesses claiming more than ₹5 lakh per month in ITC, manual eligibility decisions create material audit exposure.

A purpose-built reconciliation platform logs every match decision, every manual override, the user identity who made each change, and the timestamp. This produces a structured, queryable audit trail that satisfies statutory auditors under the Companies Act and income tax proceedings. Excel workbooks log nothing by default, and even with manual change tracking, the audit trail is neither tamper-evident nor machine-queryable.

A configuration-based reconciliation platform typically deploys in 2–4 weeks from initial discovery to go-live. An in-house Python solution requires a developer, a testing cycle, and ongoing maintenance each time a bank statement format, GST rule, or ERP export format changes. The maintenance burden alone — typically 8–15 developer hours per quarter just to keep up with Indian regulatory format changes — often makes the build-vs-buy calculation straightforward.

A mid-size Indian enterprise running manual reconciliation across bank, TDS, and GSTR-2B streams typically spends 40–80 staff hours per month on reconciliation tasks. At a loaded cost of ₹600–₹1,200 per hour for qualified finance staff, the annual staff cost ranges from ₹2.9 lakh to ₹11.5 lakh — before accounting for the CA time required for sign-off review.

The amount varies by industry, but companies processing more than ₹2 crore in TDS deductions annually and reconciling manually commonly write off 1–3% of TDS receivable due to unmatched Form 26AS entries. At ₹2 crore in annual TDS deductions, a 2% write-off rate is a ₹4 lakh direct P&L loss that disappears with correct reconciliation — this is the most concrete number in any board business case.

ITC claimed in excess of the Rule 36(4) provisional limit, or ITC not reversed when a supplier fails to file, attracts 18% annual interest under Section 50 of the CGST Act, plus potential penalty of up to 100% of the excess credit under Section 74. For enterprises claiming ₹50 lakh per month in ITC, a 5% eligibility error rate produces a ₹2.5 lakh monthly exposure — ₹30 lakh annualised at 18% interest.

Each additional day in the monthly close cycle delays invoice approval, payment authorisation, and bank drawdown decisions. For a company with ₹10 crore in monthly operating payments, each day of close delay at 10% cost of capital is approximately ₹27,400 in working capital cost. A reconciliation-driven 3-day close delay costs roughly ₹82,000 per month — ₹9.8 lakh per year — in working capital friction alone.

Unlike project implementations, a configuration-based reconciliation platform can be scoped to your specific use case in an initial discovery conversation. This means the business case presented to the board can include a specific deployment timeline, a projected match rate improvement based on a sample data review, and a defined go-live milestone — all before the approval is granted. The 2–4 week deployment window means the board can approve in one cycle and expect live results before the next quarterly close.

A configuration-based reconciliation platform typically deploys in 2–4 weeks from the initial discovery conversation to go-live for a single-use case (for example, bank reconciliation or TDS reconciliation). A multi-stream deployment covering bank, TDS, GSTR-2B, and payment gateway reconciliation typically completes within 6–8 weeks. The 30-60-90 day framework applies to deployments where multiple reconciliation streams are configured, tested in parallel, and signed off sequentially.

The minimum data requirement for an implementation kick-off is: 3 months of historical transaction data in the source formats used (MT940 or CSV bank statements, ERP export in the standard format, TDS challan CSVs, GSTR-2B JSON or Excel exports), a list of all counterparties and their PAN/GSTIN details, and sample exception cases from the current manual process. Data quality issues — inconsistent narrations, missing UTRs, duplicate entries — are better discovered during the review phase than after configuration begins.

A configuration-based implementation adjusts matching rules, tolerance thresholds, variance codes, and workflow routing within the platform's existing architecture — no code is written. A custom development implementation builds or modifies the software itself for the client's specific requirements. Configuration implementations are faster (2–4 weeks vs. 3–6 months), more predictable in timeline, and less expensive to maintain. For Indian enterprises, the key advantage is that configuration changes can be made in hours when matching rules need to be updated for a regulatory change — a code change requires a development cycle.

The three most common causes of implementation delays for Indian enterprises are: (1) ERP export formats that are non-standard and require transformation before the matching engine can ingest them — this is the most common cause; (2) bank statement narration inconsistencies across HDFC, ICICI, and SBI formats that require custom normalisation rules; and (3) incomplete counterparty master data that prevents PAN/GSTIN-level matching for TDS and GST streams. All three can be identified and mitigated during the data quality review in days 1–30.

During the parallel run phase (typically days 31–60), the reconciliation engine runs against live transaction data at the same time the existing manual process continues. The parallel run produces side-by-side match outputs for comparison. Sign-off criteria should include: match rate on the configured streams meets the contractual target (70–85%), exception volumes are stable and reviewable within the exception workflow, and the team operating the dashboard can process the daily exception queue without vendor support. The parallel run should run for at least two complete monthly close cycles before go-live sign-off.

Identify the number of finance team members involved in reconciliation across all types — bank, TDS, GSTR-2B, NACH, platform settlements. Estimate the hours per month each spends on reconciliation tasks: data downloads, VLOOKUP/formula work, exception investigation, follow-up with vendors or banks. Multiply hours by fully-loaded cost per hour (salary plus overhead, typically 1.4–1.6x gross salary). For a mid-size Indian enterprise with 3 finance staff spending 40% of their time on reconciliation, the annual staff cost of reconciliation often ranges from ₹18 to ₹36 lakh, depending on seniority and location.

Reconciliation debt is the accumulation of financial mismatches that have not been resolved and represent either recoverable value or compliance liability. In India, the two largest categories are TDS receivable not reflected in Form 26AS (value: tax credit that cannot be claimed in the income tax return, attracting interest at 18% p.a. if a demand results) and ITC not claimed because a vendor invoice did not appear in GSTR-2B (value: the GST amount, which must either be forgone or pursued through a vendor correction). For a company with ₹50 crore annual vendor spend, even 0.5% unreconciled ITC represents ₹25 lakh of potential leakage per year.

Reconciliation exceptions outstanding at month-end prevent closure of the bank ledger, the TDS receivable ledger, and the ITC ledger. Each open exception must be investigated, resolved, or provisioned before the trial balance is reliable. A finance team processing 10,000 monthly transactions manually typically spends 8–12 days resolving exceptions before the close can proceed. Automated reconciliation that reduces exceptions to a classified queue — where ROUNDING exceptions are bulk-approved, TAX_DEDUCTION exceptions are pre-understood, and UNEXPLAINED exceptions are the genuine investigation cases — compresses this to 1–2 days of targeted exception review.

Under Section 201 of the Income Tax Act, an entity assessed as an assessee-in-default for TDS non-deduction or short-deduction faces interest at 1% per month from the due date of deduction, plus interest at 1.5% per month from the date of deduction to the date of actual deposit. A penalty equal to the TDS amount can also be levied under Section 271C. For ITC, Section 73 of the CGST Act imposes a 10% penalty on the disputed ITC amount, or 100% if fraud is established. Organisations that reconcile TDS and ITC positions quarterly rather than monthly face a compounding exposure that grows with each missed period.

For cloud-deployed reconciliation software, no significant IT infrastructure investment is required — the platform runs on the vendor's infrastructure (AWS Mumbai in the case of ISO 27001:2022-certified Indian platforms) and is accessed via web interface. The implementation cost is configuration time (typically 2–4 weeks at the vendor's standard professional services rate) plus internal effort for data mapping and parallel run validation. The ROI model should include these implementation costs in the investment figure and offset them against the first year's savings in staff time, reconciliation debt recovery, and penalty risk reduction.

The business case is typically self-evident above three thresholds: 10,000 monthly transactions across all reconciliation types, more than one compliance reconciliation obligation (e.g., both TDS and GSTR-2B), and a quarterly filing deadline where exception backlogs are visible. Below these thresholds, the staff cost savings may not justify a dedicated platform. Above them, the combination of staff cost reduction, TDS and ITC debt recovery, audit penalty risk reduction, and close cycle compression typically yields payback in 6 to 18 months — before accounting for the risk mitigation value of having an immutable audit trail.

SAP and Oracle both include bank reconciliation modules that handle statement import and basic ledger matching. However, producing a reconciled view across bank statements, TDS receivables from Form 26AS, GST ITC from GSTR-2B, and NACH batch returns requires manual steps outside the standard SAP FICO or Oracle Financials workflows. India-specific exception types — TDS net-of-gross, NACH bounce disaggregation, GST TCS under Section 52 — are not natively classified by the standard ERP matching logic, requiring manual adjustment for each occurrence.

Reconciliation software ingests data from external sources — bank MT940 files, GSTN JSON, NPCI NACH return files, payment gateway settlement CSVs, TRACES Form 26AS — normalises them into a common schema, and applies multi-signal matching against ERP ledger entries. It produces a variance code for each unmatched item (FEE_DEDUCTION, TAX_DEDUCTION, ROUNDING, PARTIAL_PAYMENT, PENALTY_OR_INTEREST, UNEXPLAINED), routes exceptions to the correct reviewer, and writes cleared items back to the ERP. These are not capabilities built into standard ERP modules — they operate as a matching layer on top of the ERP's recorded data.

Once the reconciliation engine confirms a match — either through exact matching, composite-signal matching with confidence above threshold, or human approval of a classified exception — the cleared entry is posted back to the ERP via the configured integration. For SAP, this uses an RFC or BAPI call to post a clearing document in the relevant FI module. For Tally, the cleared journal entry is written as an import file. This writeback step closes the loop: the ERP's open items are cleared, and the reconciliation audit trail records the match reference.

No. Reconciliation software does not replace the ERP general ledger — it operates on top of it. The ERP remains the system of record for all ledger entries, vouchers, and financial statements. Reconciliation software's role is to verify that what the ERP recorded matches what external sources (banks, tax portals, payment gateways) confirm actually happened, and to classify and route the differences. The two systems have complementary functions; removing either creates a gap in the financial control chain.

Yes, particularly for TDS and GSTR-2B reconciliation. A company with 500 or more transactions per month on Tally faces the same India-specific compliance challenges as a large enterprise on SAP: TDS deducted by customers must be traced to Form 26AS each quarter; ITC claimed in GSTR-3B must be verified against GSTR-2B; NACH debits must be reconciled against bank credits. Tally does not have native connectors to TRACES or the GST portal. Reconciliation software handles the ingestion, matching, and exception classification — Tally remains the accounting system of record.

The most diagnostic question is: 'How does your platform handle TDS net-of-gross receipt matching when the same counterparty deducts under multiple sections in the same month?' A vendor with genuine TDS matching capability will explain how section-level deduction rates (194C at 1–2%, 194J at 10%, 194H at 5%) are applied separately before the net receipt is matched to the bank credit. A vendor without India-specific TDS logic will describe a generic tolerance match that treats TDS as a rounding difference — which produces mismatch on multi-section deductions.

Yes. A vendor with a patented matching engine and a defined pipeline architecture should be able to commit to a match rate target range — typically 70–85% — based on a review of a sample of the client's actual transaction data. This commitment should appear in the contract as a measurable service level. A vendor who declines to commit to a match rate, or who only expresses the commitment as a best-efforts statement, is signalling uncertainty about the engine's performance on Indian transaction data.

A vendor who conducts a structured discovery conversation to map the client's transaction types, matching rule requirements, and India compliance scope before configuring the engine will achieve higher match rates than one who delivers a generic setup. When evaluating the answer, listen for whether the vendor distinguishes between different matching streams (bank vs. TDS vs. GSTR-2B), asks about counterparty volume and PAN/GSTIN completeness, and sets a match rate expectation based on the specific data — not a generic claim. Generic answers to the scoping question are a proxy for generic configuration.

The four ERP systems with the highest penetration among mid-size Indian enterprises are SAP Business One / S/4HANA, Oracle NetSuite, Tally Prime, and Busy Accounting. A vendor with native connectors for all four avoids the custom transformation step that most commonly delays implementations. Beyond ERP connectors, Indian enterprises should verify native support for bank statement ingestion (MT940 from HDFC, ICICI, SBI, Axis, Kotak), GST portal export (GSTR-2B JSON), TRACES challan CSV, and payment gateway settlement files from Razorpay, Cashfree, and PayU.

A rule-based matching engine matches transactions when they satisfy a defined rule exactly — same amount, same reference, same date. It fails when Indian transaction data introduces partial references, truncated UTRs, or TDS net-of-gross differences that prevent exact matches. A composite-signal engine assigns confidence scores to multiple matching signals, with UTR as the strongest signal, followed by partial payment reference, counterparty name, and date, and matches transactions that exceed a confidence threshold even when no single signal is an exact match. For Indian enterprises where UTR-present-but-narration-inconsistent is a common pattern, a composite-signal engine is required to achieve match rates above 70%.

For most Indian enterprises, yes. RBI's 2018 circular on storage of payment system data mandates that data be stored only in systems located in India. AWS Mumbai (ap-south-1) is a data centre region physically located in India. A SaaS platform configured to store and process data exclusively in ap-south-1 — with no data transfer to non-India regions — satisfies this requirement. Payment system operators and payment aggregators regulated under the Payment Aggregator guidelines should verify the vendor's region configuration documentation before deployment.

The primary categories are: scheduled banks regulated by RBI under the IT and Cyber Security Framework, insurance companies regulated by IRDAI with specific data residency mandates, PSUs operating under government data sovereignty policies, and stock brokers or market intermediaries subject to SEBI's cloud framework. Entities in these categories typically need dedicated, isolated infrastructure — a private cloud (dedicated VPC within AWS Mumbai) satisfies this for the large majority of them; a small residual segment with a binding on-own-infrastructure mandate needs true on-premise, which is outside what most reconciliation vendors, including TransactIG, offer. For all other Indian enterprises — NBFCs, mid-market manufacturers, IT services firms, e-commerce companies — SaaS on AWS Mumbai is both compliant and operationally preferable.

On-premise deployment requires: server hardware (typically ₹15–30 lakh for an enterprise setup), annual maintenance contracts, internal IT staff time for patching and updates, database administration, and disaster recovery infrastructure. SaaS deployment eliminates all of these in exchange for a subscription fee. Over a 3-year period, on-premise TCO is typically 2 to 4 times higher than SaaS TCO for mid-market organisations processing under 5 million transactions per month, because hardware and IT staff costs do not scale proportionally with usage.

The Digital Personal Data Protection Act 2023 applies to entities processing personal digital data of Indian residents. Financial transaction data containing PAN numbers, Aadhaar references, or bank account details falls within its scope. Under the Act, data fiduciaries must implement reasonable security safeguards. For SaaS vendors, ISO 27001:2022 certification and AWS Mumbai residency are evidence of such safeguards. For on-premise deployments, the enterprise itself assumes full responsibility for implementing equivalent controls — without the vendor's certification coverage.

SaaS deployment on a config-only platform with India presets typically takes 2 to 4 weeks: connector setup and data source mapping in Week 1, matching rule and tolerance configuration in Week 2, parallel run validation in Week 3, production cutover in Week 4. On-premise deployment adds infrastructure provisioning (2 to 4 weeks for server procurement and setup) and network security configuration before any application deployment begins. Private cloud (dedicated VPC) deployment falls between the two: infrastructure is vendor-managed but provisioning takes 1 to 2 additional weeks compared to shared SaaS.

ISO 27001:2022 certification confirms that the vendor has an audited information security management system covering the scoped environment, but the scope matters. A certification that covers only the vendor's corporate office, and not the reconciliation application and its data hosting environment, provides no assurance about the application itself. Always verify that the certification scope explicitly includes the reconciliation platform and the infrastructure on which it runs.

Data residency means that financial data — bank statements, TDS certificates, settlement reports — is stored and processed on servers physically located in India. RBI's Master Direction on IT Governance requires regulated entities to ensure data localisation for critical financial data. For non-RBI-regulated enterprises, the DPDP Act 2023 creates additional obligations around cross-border data transfers. An India-hosted deployment on AWS Mumbai, for example, satisfies both requirements and avoids cross-border transfer complexity.

The Income Tax Act and the Companies Act both require that books of account and supporting records be maintained in a form that can be produced during an audit or assessment proceeding. For reconciliation records, this means the audit trail must be user-attributed (who matched or overrode each entry), timestamped (when each action occurred), tamper-evident (the trail cannot be modified retroactively), and queryable (an auditor can search by date range, user, or transaction reference). Platforms that log actions only in application logs, without a structured queryable interface, typically do not satisfy the evidentiary standard.

The Digital Personal Data Protection Act 2023 classifies individuals' financial data as personal data. When reconciliation software processes bank statements or TDS certificates containing individual account holder or deductee details, the enterprise deploying the software is a data fiduciary, and the software vendor is a data processor. The enterprise must ensure the vendor operates under a lawful data processing agreement, implements adequate security safeguards, and does not transfer personal data outside India without meeting the DPDP Act's cross-border transfer conditions.

Enterprise-grade security practice for financial applications requires at minimum annual penetration testing by an independent CERT-In empanelled auditor, with results disclosed to prospective customers under NDA. Vendors processing significant financial data volumes should conduct testing twice yearly. Ask specifically for the date of the most recent penetration test, the scope of the test (black box, white box, or grey box), and whether critical or high findings from the last test have been remediated before deployment.

PM-JAY covers 1,929 treatment packages across 27 specialities. Package rates are set by the National Health Authority (NHA) at the central level, but states can modify rates within a band — some states like Rajasthan and Tamil Nadu have state-specific rate cards that differ from the central package rates. Hospitals must reconcile settlements against the applicable state rate, not the central rate, which creates a reconciliation challenge for multi-state hospital chains.

TMS (Transaction Management System) is the digital platform through which all PM-JAY claims are submitted, tracked, and settled. Hospitals submit claims through TMS with treatment details, package codes, and supporting documents. The claim moves through stages — submitted, under review, approved, settled — and each stage is timestamped in TMS. Reconciliation requires matching the TMS-approved claim amount against the actual bank credit received, as the settlement is processed through the State Health Agency (SHA).

Settlement amounts may differ from approved package rates for several reasons: the state applies a different rate than the central package rate, the SHA deducts TDS under Section 194J at 10% on the gross settlement, the claim was partially approved due to incomplete documentation, or the hospital is classified under a different tier (public vs private, NABH-accredited vs non-accredited) with different rate multipliers. Each of these variances must be identified and categorised separately during reconciliation.

The NHA target is 15 days from claim approval to settlement. In practice, settlement timelines vary by state — some states like Kerala settle within 20–30 days, while others take 60–90 days. The full cycle from patient discharge to bank credit includes claim submission (1–3 days), claim review and approval (7–15 days), and settlement processing by the SHA (15–60 days). Total end-to-end timelines of 30 to 90 days are common across most states.

Claims approved in TMS but not yet reflected as bank credits should be tracked as receivables with ageing analysis. Under Indian Accounting Standards (Ind AS 115), revenue can be recognised at the point of claim approval if collection is probable. However, the bank reconciliation must separately track the approved-but-unsettled bucket. If a claim remains unsettled beyond 90 days, it should be escalated to the SHA and provisioned as a doubtful receivable per the hospital's provisioning policy.

Under IRDAI guidelines, insurers and TPAs must provide initial preauthorisation for cashless claims within 1 hour of the hospital's request for planned admissions. For emergency admissions, the initial response must come within 1 hour of intimation. If additional information is needed, the TPA must communicate this within the same 1-hour window. Final preauth approval or rejection must be communicated within 24 hours. Non-compliance exposes the insurer to regulatory action by IRDAI.

The preauth amount is an initial approval based on the expected treatment plan. The final settlement is based on the actual treatment delivered. For example, a knee replacement may receive a preauth of ₹2.5 lakh, but the final bill may be ₹3.2 lakh due to extended ICU stay or additional procedures. The TPA reviews the final bill and may approve the full amount, apply sub-limits (e.g., ICU charges capped at ₹5,000/day), or disallow certain items. The difference between preauth and final settlement creates the reconciliation variance that must be tracked.

Split-payer reconciliation occurs when a patient's hospital bill is paid by two or more parties. In a typical cashless claim, the insurer pays the approved amount through TPA settlement, and the patient pays the co-pay or non-covered charges directly. For a ₹5 lakh bill where the insurer approves ₹4.5 lakh, the patient must pay ₹50,000 as co-pay. Both amounts must reconcile against the same patient episode — the TPA settlement arrives as part of a batch credit weeks later, while the patient co-pay may be collected at discharge via cash or UPI.

IRDAI mandates that final claim settlement must occur within 30 days of the hospital submitting the final bill and all supporting documents to the TPA. In practice, the hospital submits the final bill within 3–5 days of discharge, and the TPA processes it within 15–30 days. Bank credit for the batch settlement may take an additional 5–10 days. The total cycle from discharge to bank credit typically ranges from 25 to 45 days, though disputed claims can extend beyond 60 days.

Enhancement requests occur when the treatment cost exceeds the original preauth. The hospital submits an enhancement request through the TPA portal with clinical justification. The TPA has 4 hours to respond to enhancement requests under IRDAI norms. If approved, the new preauth amount replaces the original. If denied, the excess becomes patient liability. Each enhancement creates a new preauth entry that must be linked to the original claim for reconciliation. Some claims have 2–3 enhancements, each changing the expected settlement amount.

CGHS covers approximately 38 lakh beneficiaries across India, including serving central government employees, pensioners, Members of Parliament, judges, and freedom fighters. The scheme operates through CGHS wellness centres in 80+ cities, with empanelled hospitals providing cashless or reimbursement-based treatment. Settlements are processed by city-wise CGHS offices, each with its own processing cadence.

CGHS rates are fixed by the Ministry of Health and Family Welfare and are typically 30-50% lower than NABH-accredited private hospital rates. For example, a knee replacement surgery that a hospital bills at ₹3.5 lakh under private insurance may carry a CGHS package rate of ₹1.8-2.2 lakh. Empanelled hospitals agree to accept CGHS rates as full payment for listed procedures, making rate-difference reconciliation a structural part of every settlement cycle.

Every CGHS claim requires a valid referral from a CGHS wellness centre to the empanelled hospital. The referral letter specifies the approved procedure or treatment category. Claims submitted without a valid referral — or where the treatment performed differs from the referral scope — are rejected during CGHS audit. Hospitals must match each claim against the referral letter number and validate that the procedure code falls within the referral scope before submission.

CGHS settlement timelines vary by city office and claim type. Routine outpatient claims settle in 30-45 days. Inpatient package claims take 45-90 days on average, with some city offices reporting backlogs extending to 120 days. Emergency claims without prior referral take longer due to additional documentation requirements. Hospitals should track ageing by city office and claim type separately to identify systemic delays.

CGHS claims require: (1) valid CGHS beneficiary card or e-card details, (2) referral letter from the CGHS wellness centre with permission number, (3) discharge summary with procedure codes, (4) itemised bill matching CGHS rate schedule, (5) pre-authorisation approval for listed procedures, and (6) investigation reports supporting the treatment. Missing any document results in claim return, and resubmission resets the settlement clock.

Diagnostic and pathology services provided by a clinical establishment are exempt from GST under Notification 12/2017 — Central Tax (Rate), entry covering health-care services by a clinical establishment, an authorised medical practitioner, or paramedics. The exemption applies to clinical tests, radiology, and sample collection that is integral to a diagnostic test. However, wellness packages marketed as preventive lifestyle programmes, courier charges billed separately, and home-collection convenience fees are not automatically exempt — labs must evaluate each non-test line against the exemption boundary and charge GST at 18% on items that fall outside the health-care services definition.

When a hospital or corporate empanels a diagnostic lab and pays for tests in arrears, the payer typically deducts TDS under Section 194J for professional or technical services at 10%. Under the TDS 2026 framework, the corresponding payment code is 1002 (professional services). The lab must reconcile the 26AS credits against its own revenue ledger by deductor, and follow up on any deductor who has remitted TDS but not yet issued a Form 16A. Aggregator commissions, where the aggregator deducts TDS on its commission income paid back by the lab, follow a different section and are tracked separately.

Online test aggregators — including platforms such as PharmEasy, 1mg Labs, and Tata 1mg, alongside in-house aggregator arms of large lab chains — typically work on a discounted MRP model. The customer pays the MRP listed on the aggregator app. The aggregator retains a discount or commission spread, a collection fee, and any platform-charged convenience fee. The lab receives a net lab share that is the contractual per-test rate, often 35–55% of MRP for high-volume tests. Monthly settlement files list each booking, the MRP, the deductions, and the net payable. Reconciling these files against the lab's own LIMS booking register is what surfaces silent leakage.

The bank credit ties to the aggregator's settlement file, but the settlement file itself is the source of leakage. Common patterns: a package test booked on the aggregator gets settled at the individual-test lab share instead of the package rate; a home-collection convenience fee that was meant to be split with the lab is fully retained by the aggregator; courier charges for sample transport are not invoiced back; and rate-card revisions take effect retroactively without being reflected in the lab's billing system. Without a per-test rate-card match against the settlement file, the lab confirms only that money arrived — not that the right amount arrived.

When a diagnostic lab collects payment for a radiology test that is performed by a sub-contracted imaging centre, the lab may treat the radiology portion as a pure-agent reimbursement under Rule 33 of the CGST Rules, provided the sub-contractor's invoice is in the patient's name, the lab does not mark up the reimbursed amount, and the arrangement is documented. The pure-agent component is excluded from the lab's value of supply for GST. If the lab marks up the radiology fee or bills the patient in its own name without disclosing the sub-contractor, the full amount becomes part of the lab's supply and the GST exemption boundary is evaluated on the bundled service.

ECHS covers approximately 55 lakh beneficiaries, including ex-servicemen, their dependants, and war widows. The scheme operates through 427 ECHS polyclinics across India and empanels private hospitals for secondary and tertiary care. Each beneficiary holds a smart card that must be validated at the point of admission for cashless treatment.

ECHS settlements take 60 to 120 days from claim submission. The claim flows from the empanelled hospital to the Station HQ, then to the Regional Centre for audit and approval, and finally to the payment authority. Claims requiring additional documentation or those flagged during audit can extend to 150+ days. Hospitals should maintain separate ageing buckets for ECHS claims given this extended cycle.

ECHS package rates are independently set and differ from both CGHS and PM-JAY schedules. For a standard cataract surgery, ECHS may reimburse ₹15,000-20,000, CGHS ₹18,000-25,000, and PM-JAY ₹12,000 under Health Benefit Package 2.2. Hospitals empanelled under multiple government schemes must maintain separate rate cards and ensure the correct rate schedule is applied during billing.

Every ECHS claim requires a referral from an ECHS polyclinic. The referral specifies the condition, approved specialty, and the empanelled hospital. Emergency admissions can bypass polyclinic referral but require post-facto intimation within 24 hours and subsequent validation by the polyclinic medical officer. Claims submitted without referral or with expired referrals are rejected at Station HQ audit.

Common ECHS rejection reasons include: referral letter expired or not matching the treatment performed, smart card not validated at admission, procedure not listed in the ECHS package directory, billing above ECHS package rate, incomplete discharge summary, and missing investigation reports. The Station HQ medical audit team reviews every claim before forwarding to the Regional Centre for payment, and any documentation gap results in claim return with a 30-45 day resubmission delay.

Since the July 2022 GST amendment, hospital room rent above ₹5,000 per day attracts 5% GST without input tax credit. Room rent at or below ₹5,000 per day remains exempt. For multi-speciality hospitals with rooms at different price points, the billing system must split GST and non-GST components on the same patient invoice. The reconciliation system must verify that GST collected matches GST reported in GSTR-1 and that exempt room revenue is correctly excluded.

Patient deposits follow a lifecycle: initial deposit at admission, partial consumption during treatment, possible top-ups, and final settlement or refund at discharge. A patient admitted with a ₹1 lakh deposit may consume ₹60,000 during a 5-day stay, receive a ₹40,000 refund at discharge, and then have an insurance claim settle ₹3.5 lakh separately. The deposit, consumption, refund, and insurance settlement are four separate entries that must all reconcile against the same patient episode in the HIS.

UPI collections from OPD counters and pharmacy terminals are settled by the payment gateway (Razorpay, Pine Labs, etc.) as a netted daily credit — total UPI collections minus MDR and GST on MDR. A hospital collecting ₹4.2 lakh in UPI payments across 180 transactions receives a single bank credit of approximately ₹4.12 lakh after MDR deduction. The 180 individual transaction details are available only in the payment gateway settlement report, not in the bank narration.

Cash collected at OPD counters is deposited into the bank account, typically at end of day. A hospital with 5 OPD counters may make 2–3 cash deposits daily, each covering collections from multiple counters. The bank statement shows the deposit amount and a deposit slip reference — not the counter-level breakdown. Reconciliation requires matching the bank deposit entry to the cash register totals from each counter in the HIS, accounting for any denomination differences or cash handling discrepancies.

When hospitals invoice corporates for employee health checkups, the corporate deducts TDS under Section 194J at 10% before payment. A hospital billing ₹10 lakh for a bulk health checkup receives ₹9 lakh in the bank. The ₹1 lakh TDS must be tracked as a receivable and verified against Form 26AS. If the corporate files the TDS return late or with incorrect details, the hospital cannot claim the TDS credit in its income tax return until the mismatch is resolved through TRACES.

Central billing aggregates patient bills into a single corporate billing entity, typically used for corporate clients, TPA settlements, and group health policies where the contract sits with the parent company. Unit billing keeps revenue at the originating hospital unit and is used for cash patients, walk-ins, and most OPD/pharmacy transactions. Most Indian hospital chains run a hybrid: TPA and corporate revenue flows through central billing while cash, OPD, and pharmacy revenue stays at the unit. The reconciliation challenge is that the HIS records the service at the unit, the GL books the revenue at central, and the bank credit lands in either a central pooled account or a unit-level current account depending on the payment mode.

Pharmacy revenue carries a different GST treatment than core healthcare services. Healthcare services by a clinical establishment are exempt under Notification 12/2017, but standalone pharmacy sales are taxable at 5%, 12%, or 18% depending on the drug schedule. Hospital pharmacies that dispense to in-patients can claim the exemption for medicines forming part of inpatient care, but OTC sales to outpatients and walk-ins are taxable. The carve-out is needed because the HIS often bundles pharmacy into the IPD bill while the GST return needs the taxable pharmacy slice extracted separately, with input tax credit reversed on the exempt portion.

Doctor consultation payments made by hospitals to visiting consultants and revenue-share doctors fall under the professional services category. From the 2026 TDS migration, these payments are reported under payment code 1027 (professional fees, Sl. 6(iii).D(b)) within the 1001-1092 series, replacing the legacy Section 194J reporting where applicable for the new tax year. The deduction is on the doctor's share of consultation revenue net of the hospital's facility fee, and the hospital must issue Form 16A reflecting the new payment code. Hospital chains running revenue-share arrangements with hundreds of consultants across multiple units need the HIS-to-GL reconciliation to disaggregate consultation revenue by doctor, by unit, and by payment code before the quarterly TDS return.

Inter-unit transfer variance arises when a patient is admitted at one unit, transferred to another for specialised care, and discharged from a third — but the HIS books the revenue at the originating unit while the GL needs it split by service location. The same pattern shows up with shared doctors who consult across units, with diagnostics samples sent to a central lab, and with pharmacy stock transfers between units. If the HIS and GL use different unit-mapping logic, the consolidated revenue ties at the chain level but every individual unit P&L is off. Reconciliation has to match the inter-unit transfer entries, net them out at the chain level, and reattribute revenue to the correct unit for management reporting.

The consolidation process pulls HIS revenue feeds from each unit, normalises them into a common service-line taxonomy (IPD, OPD, pharmacy, diagnostics, consultation), maps them to GL accounts, and compares unit-level totals against the unit's bank deposits and TPA settlements. Variance is isolated by drilling down from the chain total to the unit total to the service-line total to the collection-mode total. When a variance shows up, it is almost always either a missed bank credit, a partial TPA settlement that was booked in full, a cash collection that did not reach the bank, or a pharmacy module that booked sales without recording the corresponding cash or card receipt. The reconciliation system needs to expose all four collapsed views so the central team can localise the variance to the source unit in hours, not days.

A mid-size Indian hospital (100-300 beds) typically manages empanelments with 5 to 15 insurance companies simultaneously. Each insurer operates through one or more TPAs, and each TPA has its own claim submission portal, file format, rate negotiation, and settlement cycle. A 500-bed multi-specialty hospital may deal with 20+ insurer-TPA combinations, each requiring separate reconciliation tracking.

Under IRDAI Health Insurance Regulations 2024, insurers must process preauthorisation requests within 1 hour for cashless claims. Final claim settlement must be completed within 30 days of receiving the last necessary document from the hospital. Delays beyond 30 days entitle the hospital to interest on the outstanding amount. Hospitals should track the 'last document submitted' date per claim to enforce this timeline during reconciliation.

The five primary revenue leakage sources are: (1) underpaid claims where the insurer settles below the agreed tariff without documented disallowance, (2) rejected claims not resubmitted within the appeal window, (3) co-pay amounts billed to patients but not collected, (4) TDS deducted by insurers under Section 194J but not reflected in Form 26AS, and (5) rate differences between the hospital's billed amount and the TPA-negotiated tariff that are written off without review.

TPAs batch multiple claim settlements into a single bank transfer. One NEFT credit of ₹12 lakh may cover 40-80 individual claims, with partial payments, disallowances, and deductions netted into the total. The hospital receives a settlement file (CSV or Excel) listing individual claim amounts, but the sum of individual amounts often differs from the bank credit by ₹500-5,000 due to TDS deductions, processing fees, or rounding. Unpacking each batch requires line-by-line matching against the hospital billing system.

TDS under Section 194J at 10% applies when insurance companies or TPAs make payments to hospitals for corporate health checkup packages or retainer-based wellness programmes. Regular cashless claim settlements are generally treated as reimbursement of medical expenses and not subject to TDS. However, some insurers deduct TDS on bulk settlements, creating a TDS receivable that must be reconciled against Form 26AS quarterly.

Under IRDAI Health Insurance Regulations 2024, insurers must settle claims within 30 days of receiving the last necessary document. For cashless claims, initial preauthorisation must be processed within 1 hour. If the insurer requires additional documents, the request must be made within 15 days of claim receipt. Failure to settle within the mandated timeline entitles the claimant to interest at the bank rate on the outstanding amount from the date of claim to the date of payment.

IGMS (Integrated Grievance Management System) is IRDAI's centralised portal for insurance grievances. When a hospital or patient files a complaint regarding claim settlement delays, partial payments, or wrongful rejections, IGMS generates a unique grievance number. Insurers must respond within 15 days. Hospitals should track IGMS grievance numbers alongside claim IDs in their reconciliation system to monitor which disputed claims have active regulatory complaints.

Hospitals must maintain: (1) preauthorisation requests and approvals with timestamps, (2) claim submission records with document checklists, (3) settlement files from TPAs with line-by-line reconciliation, (4) disallowance communications with insurer responses, (5) IGMS grievance records for disputed claims, (6) rate agreements with each TPA/insurer, and (7) patient consent forms for cashless treatment. These records must be retained for a minimum of 8 years as per IRDAI guidelines.

IRDAI registers and regulates all Third Party Administrators under the IRDAI (TPA - Health Services) Regulations. TPAs must maintain a minimum net worth of ₹1 crore, employ qualified medical professionals for claim adjudication, and submit quarterly reports to IRDAI on claim processing volumes, settlement ratios, and turnaround times. Hospitals empanelled with TPAs can verify TPA registration status on the IRDAI website and escalate through IRDAI if a TPA violates settlement timelines.

IRDAI can impose penalties up to ₹1 crore per violation under Section 102 of the Insurance Act, 1938 (as amended). For repeated delays in claim settlement, IRDAI can issue directions to the insurer, suspend the insurer's licence for specific product lines, or initiate action against the TPA's registration. Hospitals can use these regulatory provisions as leverage when following up on systematically delayed settlements by filing complaints through IGMS.

The IRDAI Master Circular on Health Insurance Business consolidates the list of items that an insurer or TPA may not pay for under a hospitalisation claim — typically grouped as List I (non-medical consumables like gloves, masks, administrative charges), List II (items payable when consumed during procedure), and List III (items payable when used for specific patients). Hospitals must map each line in the final bill to one of these three lists, because non-payable deductions under List I are valid by regulation and cannot be grieved on merit — only on misclassification. The legitimate dispute surface is when a List II or List III item is wrongly classified as List I by the TPA's medical officer.

When a policyholder occupies a room category higher than the policy's eligible room-rent limit, the TPA applies a proportionate deduction to associated charges — typically nursing, doctor visit fees, operation theatre charges, investigations, and consumables. The standard formula is: payable amount = billed amount × (eligible room rent ÷ actual room rent). If a policy allows ₹4,000 per day room rent and the patient occupied a ₹6,000 per day room, every linked charge is paid at the ratio 4,000 / 6,000 = 66.7%. Pharmacy, implants, and pre-fixed package components are usually excluded from the proportionate cut, but TPAs vary in which line items they include — this is the single largest dispute category.

The escalation runs in three tiers. Tier one: lodge a written complaint with the insurer's Grievance Redressal Officer (GRO), who must respond within 14 days under IRDAI norms. Tier two: if unresolved or unsatisfactory, escalate through the Integrated Grievance Management System (IGMS) portal at igms.irdai.gov.in, which routes the complaint to IRDAI's consumer affairs department and tracks the insurer's response timeline. Tier three: approach the Insurance Ombudsman under the Insurance Ombudsman Rules 2017 for claims below the prescribed monetary limit. Hospitals typically lodge grievances on behalf of the insured under a signed authorisation, and the per-deduction-code audit trail from reconciliation is what makes the grievance substantive rather than generic.

Empanelment MoUs between hospitals and TPAs or direct insurers carry five commercial levers that shape every subsequent payout. First, the rate-card discount against published tariff — typically 10% to 35% depending on insurer leverage. Second, the package rate list, which fixes a ceiling for named procedures regardless of actual billing. Third, the MoU validity period and the auto-renewal clause. Fourth, the rate-revision clause, which defines when and how tariffs can be raised — usually annually with mutual consent. Fifth, the exclusivity or volume-commitment terms. Hospitals that approach rate revision negotiations with a per-deduction-class history from reconciliation can argue for narrower NPI lists, higher package caps, or removal of specific sub-limits.

Healthcare services provided by a clinical establishment, an authorised medical practitioner, or paramedics are exempt under Notification 12/2017-Central Tax (Rate), so the core hospital service line does not attract GST. The TPA's administrative service to the insurer is a separate taxable supply but is not on the hospital's payout side. On the TDS side, corporate clients booking employee health checkups or wellness packages typically deduct TDS under Section 393(1) Sl. 6(iii).D(b) of the Income Tax Act 2025 (the successor to Section 194J for fees for professional services, payment code 1027 under the 2026 TDS code framework). The hospital must reconcile this TDS receivable against Form 26AS each quarter and ensure the corresponding payment code appears correctly in the deductor's TDS return.

Consignment stock is the commercial model where the medical device supplier places physical inventory — typically stents, orthopaedic implants, spinal cages, or trauma plates — at the hospital's sterile store, but retains ownership and balance-sheet recognition of that stock. The hospital draws units only when a surgeon opens them in theatre. The supplier raises a tax invoice at the point of consumption, not the point of physical delivery. The model is standard for high-value implants because no hospital wants to lock working capital into a wide size range of every SKU, and no surgeon wants to be told mid-procedure that the correct size is not available.

Payments to medical device suppliers for goods consumed under a consignment arrangement are generally treated as payment for goods, and TDS under Section 393(1) Sl. 8(ii) payment code 1031 (which replaced legacy Section 194Q) at 0.1 percent applies once aggregate purchases from a supplier exceed ₹50 lakh in a financial year. Where the contract bundles supply with a technical service element — for example, a clinical applications specialist who scrubs in to assist with calibration of a cath-lab device — that service component is liable to TDS under Section 393(1) Sl. 6(iii).D(a) at payment code 1026, the technical fees code under the 2026 regime (2 percent). The hospital's finance team must split the invoice value between the goods leg and the service leg before deducting at the correct rate, and the supplier's e-invoice line items must support that split.

Medical devices in India fall across three GST slabs. A notified list of life-saving devices and specified diagnostic kits attracts 5 percent. Most surgical instruments, orthopaedic implants, cardiac stents, and standard medical equipment attract 12 percent. Certain electronic medical devices — particularly imaging consumables and some monitoring equipment categories — attract 18 percent. The reconciliation impact is direct: each supplier invoice must be classified at the SKU level to the correct slab, and the hospital's GSTR-2B credit will only flow through at the rate the supplier has actually charged. Slab mismatches between the supplier's e-invoice and the hospital's purchase order are a routine source of credit-block exceptions during the GSTR-2B match.

Schedule I of the CGST Act treats the supply of goods between distinct persons, or to an agent who undertakes to supply on behalf of the principal, as a supply even without consideration. Tax authorities have taken the position that consignment stock left at a hospital beyond a reasonable period — typically defined in field assessments as six months without consumption — risks being reclassified as a deemed supply at the point of original physical delivery. The practical exposure sits with the supplier, not the hospital, but the hospital is drawn in when assessments examine the stock-ageing report. A reconciliation routine that produces a clean monthly ageing of unconsumed consignment stock by SKU, batch, and hospital location is the document trail that defends against the reclassification.

The right match is supplier stock register versus hospital theatre log versus hospital purchase invoice. The supplier's register shows units physically placed, units consumed per the supplier's reading of theatre returns, and the resulting closing stock. The hospital's theatre log shows units actually opened by SKU, batch number, and patient procedure. The hospital's purchase invoice shows units the supplier has billed and the hospital has accepted into its purchase ledger. All three should agree at the SKU-batch level. Best practice is a monthly close cycle aligned to the GSTR-1 filing date of the supplier, with a weekly informal check for the highest-value SKUs — coronary stents and spinal cages in particular — where a single missing unit is a material exception.

No, GST is not applicable on healthcare services provided by a clinical establishment to foreign patients. The exemption under Notification 12/2017 (Central Tax — Rate), entry 74, covers healthcare services provided by a clinical establishment, an authorised medical practitioner, or paramedics — and the exemption applies regardless of the patient's nationality or place of residence. The qualifying condition is the nature of the service and the status of the provider, not the patient. However, ancillary services billed by the hospital — attendant accommodation, airport transfers, visa-extension paperwork, hotel arrangements, non-medical concierge — are taxable at standard GST rates unless billed on a pure-agent basis with proper documentation.

An FIRC — Foreign Inward Remittance Certificate, now mostly issued in electronic form as e-FIRC by AD-Category-I banks — is the document that certifies a foreign currency receipt has been credited to an Indian beneficiary, with the purpose of remittance recorded against a specific RBI purpose code. For medical treatment receipts, the correct purpose code is P0301 (medical treatment, including ancillary expenses). The FIRC is the FEMA documentation trail that proves the inward remittance was received against medical services — which in turn supports the GST exemption claim, qualifies the receipt under the healthcare services entry, and demonstrates the receipt was not received as a donation, capital flow, or unrelated commercial transaction.

Hospitals typically raise invoices in INR for transparency with the patient and for HIS billing consistency. The receipt arrives in foreign currency three to seven days later, converted by the bank at the date-of-credit exchange rate, with SWIFT correspondent-bank charges deducted along the way. The recommended treatment under Ind AS 21 and Income-Tax Rule 115 is to record the receivable at the transaction-date rate, recognise an FX gain or loss on the date of receipt for the difference, and treat SWIFT charges as a separate expense or as a receivable adjustment depending on which party is contractually liable. The recon system must capture three values per patient — INR billed, foreign currency received, and INR credited — and classify any residual variance as FX gain/loss, SWIFT charge reimbursement, or a genuine receipt shortfall.

No, the Foreign Contribution Regulation Act 2010 does not apply to foreign patient receipts. FCRA governs foreign contributions — donations, grants, gifts received for definite cultural, economic, educational, religious, or social programmes — and explicitly excludes payments received in the ordinary course of business. A foreign patient paying for medical services is making a commercial payment for service rendered, governed by FEMA inward remittance rules and the GST healthcare exemption, not FCRA. Hospitals do not need an FCRA registration to receive foreign patient payments. The applicable framework is the FEMA Master Direction on Reporting under FEMA, 1999 and the RBI purpose code P0301.

Missing FIRCs create three downstream problems. First, the FEMA documentation trail for the inward remittance is incomplete, which the authorised dealer bank can flag at year-end reconciliation. Second, the GST exemption documentation becomes weaker — while the exemption itself does not legally depend on the FIRC, the absence of an FIRC makes it harder to demonstrate the receipt was against the medical-services invoice during a GST audit or scrutiny. Third, statutory auditors will typically raise an observation in the FY-end audit report on foreign exchange receipts lacking certification, which carries through to internal financial controls reporting. Hospitals should run an FIRC-pending register monthly and chase the AD bank for any receipt older than 30 days without an issued e-FIRC.

MRP is the Maximum Retail Price printed on the strip — the ceiling at which a retailer can sell to a patient. PTR (Price To Retailer) is what the stockist invoices to the chemist, and PTS (Price To Stockist) is what the manufacturer or CFA invoices to the stockist. The reconciliation problem is that all three move independently: the manufacturer can revise PTS mid-quarter through a trade scheme, the stockist may pass on only part of that revision through PTR, and MRP changes require label re-stickering. When a batch sold at the old PTR receives a new credit note keyed to the revised PTS, margin per strip slips by 1.5 to 4 percent and shows up only when batch-level closing stock is reconciled against the credit note ledger.

Most Indian pharma manufacturers accept near-expiry returns from stockists under a 3-month-prior or 6-month-prior window depending on the molecule, the channel, and the scheme. Hospital channel is typically 3 months; retail chain channel is often 6 months. The stockist raises an expiry-return claim with batch number, quantity, and the PTS at which the original purchase happened. The manufacturer issues a credit note net of a breakage allowance — usually 0.5 to 2 percent. Reconciliation fails when the claim is raised at current PTS but the original purchase happened at an older PTS, or when the manufacturer applies a scheme-period PTS that the stockist did not track. Batch-level cost-flow accounting is mandatory.

Under Section 9(5) of the CGST Act read with the notified categories, certain ecommerce operators are liable to collect and pay GST on supplies made through them. For pharma marketplaces, the practical split is: where the order is fulfilled by the marketplace's own licensed pharmacy entity, the marketplace acts as the supplier and discharges GST. Where the order is routed to a partner stockist or chemist, the supplier-of-record remains the stockist, and the marketplace deducts TCS under Section 52 instead. Reconciliation requires keying each order to the fulfilment entity and matching the GST and TCS legs to the marketplace MIS, the stockist GSTR-1, and the marketplace GSTR-8.

Under the new TDS architecture, commission and brokerage payments fall under Section 393 of the consolidated TDS provisions and carry payment code 1001. This replaces the older Section 194H reference for filings from the migration cut-off onward. The rate continues to be 2 percent on commission with the threshold preserved. The reconciliation issue is that stockist payouts often combine trade discount (no TDS), turnover-linked rebate (no TDS where structured as a discount through credit note), and commission (TDS applies). Misclassification triggers 26AS mismatches and downstream notices.

Rule 86B caps the use of input tax credit at 99 percent of output tax liability for taxpayers whose monthly taxable supplies exceed ₹50 lakh, with carve-outs for exporters, refund applicants, and certain other categories. A pharma stockist with monthly secondary sales of ₹7 crore comfortably crosses the threshold and must discharge at least 1 percent of output GST in cash even when ITC is fully available. On a typical month's output GST of ₹84 lakh that means roughly ₹84,000 in cash discharge, and any ITC blocked due to GSTR-2B mismatch on supplier invoices stacks on top. Reconciliation must surface both the Rule 86B floor and the 2B-blocked ITC on the same dashboard.

There are 19+ licensed TPAs in India, including Star Health TPA, Medi Assist, Paramount Health Services, and MD India. Each TPA uses a different settlement file format — some send CSV, others send Excel with varying column structures. There is no IRDAI-mandated standard file format for settlement sidecar files, which means hospitals must maintain a separate parsing configuration for each TPA they work with.

TPA settlement cycles in India range from 15 to 90 days depending on the insurer and claim type. Cashless claims under IRDAI guidelines must receive initial preauthorisation within 1 hour and final settlement within 30 days of discharge. In practice, reimbursement claims take 45 to 90 days. Partial settlements and disputed amounts extend the effective cycle further, with some claims remaining open for 120+ days.

A TPA settlement sidecar file is the claim-level detail file that accompanies a batch bank credit. When a TPA settles 200 claims in one payment, the bank statement shows a single credit entry. The sidecar file lists each individual claim number, patient name, approved amount, deducted amount, and net payable. Without this file, the hospital cannot determine which specific claims were settled, partially paid, or rejected within that batch.

TPA clawbacks appear as negative settlement amounts — a debit entry in the bank statement referencing a previous batch. This happens when the TPA reverses a previously settled claim due to audit findings, duplicate claims, or policy disputes. Clawback amounts are netted against the current batch settlement, so the bank credit may be lower than the sum of approved claims. Some TPAs send a separate clawback file; others include negative line items within the regular settlement sidecar.

A partial settlement occurs when the TPA approves less than the hospital's billed amount — typically due to rate differences between the hospital's tariff and the insurer's approved package rate. For example, a hospital bills ₹2.5 lakh for a procedure but the TPA approves ₹1.8 lakh based on the insurance policy's sub-limits. The ₹70,000 difference must be tracked separately as either patient liability (co-pay) or a write-off. The reconciliation system must match the partial settlement to the original claim and flag the variance for billing follow-up.

Deferred revenue is the portion of cash received for a service that has not yet been delivered. Under Ind AS 115, a SaaS company that receives ₹12 lakh for a 12-month subscription must recognize only ₹1 lakh per month as revenue and carry ₹11 lakh as a current liability on day one. Reconciliation confirms that the deferred revenue balance on the balance sheet matches the sum of undelivered performance obligations across all active contracts. Errors here directly affect reported profit and Schedule III disclosures filed with the MCA.

SaaS services are classified as OIDAR (Online Information and Database Access or Retrieval) under GST and attract 18% GST under SAC 998314. For domestic customers, the SaaS company charges 18% GST on each invoice. For export customers, the company can either file a Letter of Undertaking (LUT) for zero-rated supply or pay IGST and claim a refund. The reconciliation must separate the GST component from the deferred revenue schedule — GST liability arises on invoice date, not on revenue recognition date.

A multi-element SaaS contract — subscription plus implementation plus annual support — contains three separate performance obligations under Ind AS 115. Each must be allocated a portion of the total transaction price based on standalone selling price. Implementation revenue is recognized on completion (point in time), subscription revenue over the contract period (over time), and support revenue over the support period. The deferred revenue schedule must track each element separately.

Monthly reconciliation is the minimum standard for SaaS companies with more than 100 active subscriptions. The process matches the deferred revenue waterfall schedule against three data sources: (1) cash received per bank statement, (2) invoices raised per the billing system, and (3) revenue recognized in the general ledger. Quarterly reconciliation is required at minimum for Ind AS-compliant companies to support the financial statement disclosures mandated under Schedule III — specifically the contract liability balance and revenue recognized from opening deferred revenue.

Under Ind AS 115, a contract liability exists when the company has received payment before satisfying the performance obligation. Deferred revenue is the common accounting term for the same concept. For Indian SaaS companies, the Schedule III balance sheet reports this as 'Contract Liabilities' under current liabilities. The reconciliation must ensure that the contract liability balance equals total cash received minus total revenue recognized across all active contracts, with separate tracking for each performance obligation in multi-element arrangements.

Under Ind AS 102 Share-Based Payment, equity-settled share-based payment transactions are measured at the fair value of the equity instruments granted at the grant date. The fair value is determined using an option-pricing model — typically Black-Scholes for plain-vanilla options and a binomial or Monte Carlo model where the awards have market-based vesting conditions. Once measured at grant date, the fair value is not remeasured for service-condition or non-market performance condition vesting, even if the actual outcome differs from the original estimate. The expense is recognised over the vesting period on a straight-line basis where vesting is graded only by service, or on an accelerated basis (each tranche treated as a separate award) where vesting is in tranches. Cash-settled awards (such as stock appreciation rights settled in cash) are measured at fair value at each reporting date through the settlement date.

Graded vesting — for example, a four-year RSU with 25 per cent vesting on each anniversary — is treated under Ind AS 102 as each tranche being a separate award. Tranche 1 vests over one year and the expense is recognised over twelve months. Tranche 2 vests over two years and its expense is recognised over twenty-four months. Tranche 3 over three years, tranche 4 over four years. The aggregate expense in year 1 is the sum of one full tranche plus partial recognition of the other three — front-loading the P&L cost relative to a straight-line interpretation. This is materially different from US GAAP where the same award is often recognised straight-line in aggregate. The Ind AS approach produces a higher year-1 charge and a tapering profile across the vesting period.

Under Section 17(2)(vi) of the Income Tax Act, the difference between the fair market value of the share on the date of exercise and the exercise price paid by the employee is taxable as a perquisite in the hands of the employee in the year of exercise. The employer is required to deduct TDS on this perquisite under the salary TDS framework — historically Section 192, now restructured under the new payment-code era as Section 393 with the salary payment code. The TDS is computed on the perquisite value (FMV minus exercise price) at the employee's applicable slab rate. For employees of eligible start-ups, Section 192(1C) defers the TDS to the earliest of fourteen days from the end of forty-eight months from the end of the relevant financial year, the date of sale of the shares, or the date the employee ceases to be an employee. The perquisite value is reported in Form 16 and in the employee's salary income.

An RSU is a right to receive shares (or cash equivalent) at vesting, typically at no exercise price. The fair value at grant for an equity-settled RSU is the grant-date share price minus the present value of dividends expected during the vesting period that the employee is not entitled to receive. For a listed company, the grant-date share price is the closing market price on the grant date. For an unlisted company, the fair value is determined by an independent valuation — typically a Discounted Cash Flow or a recent equity transaction price as a base, adjusted for the minority discount and the marketability discount. The valuation must be supportable for audit and must align with the Rule 11UA valuation used for perquisite TDS on exercise.

Modification accounting under Ind AS 102 applies when the terms of a share-based payment award are changed after grant. The classic IT services trigger is IPO-accelerated vesting — the company changes the vesting schedule so that unvested awards vest on listing, or vest faster. The modification accounting principle is that the modification must not reduce the total fair value recognised below the original grant-date fair value. If the modification is beneficial to the employee (accelerated vesting, lower exercise price, longer exercise window), the incremental fair value at the modification date is recognised as an additional expense over the modified vesting period. If the original award had not yet been fully expensed, the unrecognised portion of the original fair value is accelerated to the modified vesting period. IPO-accelerated vesting therefore typically produces a one-time catch-up expense in the period of listing, which must be disclosed separately.

Section 2(6) of the IGST Act, 2017 defines export of services as a supply where all five conditions are satisfied. First, the supplier of service is located in India. Second, the recipient of service is located outside India. Third, the place of supply of service is outside India, determined under Section 13 of the IGST Act. Fourth, the payment for service is received in convertible foreign exchange or in Indian rupees wherever permitted by the RBI. Fifth, the supplier and recipient are not merely establishments of a distinct person under Explanation 1 of Section 8. Failure on any single limb collapses the export classification — the supply becomes a normal taxable supply liable to IGST at 18%.

The Letter of Undertaking filed in Form GST RFD-11 allows an exporter to make zero-rated supplies without paying IGST upfront. The alternative — paying IGST at 18% on each export invoice and then claiming refund under Section 54 — locks up cash for 60-90 days per cycle. For a SaaS company invoicing ₹15 crore quarterly to overseas customers, that is ₹2.7 crore of IGST stuck in refund pipelines at any given time. The LUT removes this cash drag. It is filed once at the start of each financial year on the GST portal, valid for the full year, and can be furnished by any registered exporter who has not been prosecuted for tax evasion exceeding ₹2.5 crore in the preceding two years.

Under FEMA and the Master Direction on Export of Goods and Services, the full value of export proceeds must be realised and repatriated to India within nine months from the date of export. For SaaS exporters, the date of export is typically the date of issue of the export invoice. If proceeds are not realised within nine months, the supply ceases to qualify as a zero-rated export under Section 16 of the IGST Act read with the GST refund rules. The exporter must then either repay the refund already claimed with interest, or pay IGST on the unrealised portion. AD Category-I banks track each export invoice against FIRCs and report defaults to the RBI under the EDPMS (Export Data Processing and Monitoring System) for goods and the equivalent monitoring framework for services.

Yes. Under Rule 48(4) of the CGST Rules, any registered person whose aggregate turnover in any preceding financial year from 2017-18 onwards exceeds the prescribed threshold must issue e-invoices for all B2B supplies, including exports and SEZ supplies. The threshold has been progressively lowered and now stands at ₹5 crore. The export invoice must be reported to the Invoice Registration Portal (IRP), which returns an IRN (Invoice Reference Number) and a signed QR code. The export invoice is also auto-populated into the exporter's GSTR-1 under Table 6A (Exports). Failing to e-invoice an export invoice attracts a penalty under Section 122 of the CGST Act and may delay refund processing.

The FIRC (Foreign Inward Remittance Certificate), now largely replaced by the electronic BRC (Bank Realisation Certificate) issued through EDPMS for services, is the documentary proof that the export proceeds have been received in convertible foreign exchange. For a GST refund claim under Section 54, the exporter must furnish a statement linking each export invoice (with invoice number, date, and IGST value) to the corresponding BRC or FIRC reference, the realisation date, the foreign currency amount, and the INR equivalent at the conversion rate applied by the AD bank. Where a single FIRC covers multiple invoices or a single invoice is realised across multiple FIRCs, the reconciliation table must show the split. Mismatches between invoice values and FIRC amounts (typically caused by bank charges deducted by the remitting bank) must be explained in the refund application.

Section 16 of the CGST Act prescribes four cumulative conditions for claiming ITC on an inward supply. First, the recipient must be in possession of a tax invoice, debit note, or other prescribed document. Second, the recipient must have received the goods or services. Third, the supplier must have actually paid the tax to the Government, and the invoice must be reflected in the recipient's GSTR-2B. Fourth, the recipient must have furnished the return under Section 39 (GSTR-3B). All four conditions must be satisfied in the same tax period to claim the credit. The 180-day rule additionally requires that the recipient pay the supplier within 180 days of the invoice date, failing which the ITC must be reversed and re-availed only when payment is made.

Rule 42 of the CGST Rules applies when a registered person uses inputs and input services partly for business purposes and partly for non-business purposes, or partly for taxable supplies (including zero-rated supplies) and partly for exempt supplies. For most pure-play SaaS firms with only taxable revenue (domestic at 18 per cent and exports zero-rated under LUT), Rule 42 does not bite because there is no exempt revenue. But for IT services firms or SaaS firms that also have exempt revenue — interest income, sale of securities, certain financial services, or specific exempt notifications — Rule 42 requires the common ITC pool to be apportioned. The reversal is computed using the formula in Rule 42: the common credit is multiplied by the ratio of exempt turnover to total turnover, and the resulting amount is reversed in the relevant tax period.

Rule 43 applies the same mixed-use principle to capital goods. Where capital goods are used partly for business and non-business purposes, or partly for taxable and exempt supplies, the ITC on the capital goods is apportioned over the useful life — deemed to be 60 months under Rule 43. The ITC is allocated monthly: the total ITC is divided by 60, and each month's allocation is split between taxable and exempt use in the ratio of taxable to total turnover for that month. The portion attributable to exempt or non-business use is reversed in that month. For SaaS firms, capital goods of GST relevance are typically limited because most infrastructure is consumed as services from cloud providers — but laptops, servers held on-premise, office equipment, and capitalised software licences fall in scope.

Section 17(5) of the CGST Act lists the categories of inward supplies on which ITC is blocked irrespective of business use. The categories most relevant to SaaS and IT services firms are: motor vehicles for passenger transport with seating capacity of thirteen or fewer (with exceptions for further supply, transport of passengers, and driver training); food and beverages, outdoor catering, club memberships, health services, life and health insurance (except where mandated by law or used for the same category of supply); construction of immovable property other than plant and machinery; goods or services received by a non-resident taxable person except on imported goods; goods or services used for personal consumption; goods lost, stolen, destroyed, written off, or disposed by way of gift or free samples; tax paid under Section 74 (suppression of facts), Section 129 (detention), or Section 130 (confiscation). Office canteens, employee insurance beyond statutory minima, and team off-site dinners are the most common blocked credits in SaaS finance teams.

The ITC reconciliation runs in three layers. The first layer matches the books purchase register against the supplier invoices auto-populated into GSTR-2B by the GSTN. Mismatches arise where the supplier has not filed GSTR-1, has filed late, has filed under the wrong GSTIN, or has the wrong invoice number or value. The second layer matches the eligible ITC computed by the books against the ITC claimed in GSTR-3B Table 4(A). The third layer applies Rule 42 / Rule 43 reversals (Table 4(B)(1)) and ineligible credits under Section 17(5) (Table 4(D)(1)) before deriving the net ITC. The reconciliation must close monthly because the GSTN ledger and the books must agree before the GSTR-9 annual return is filed.

Ind AS 115 (Revenue from Contracts with Customers) became effective for all Indian companies following Ind AS from 1 April 2018, replacing Ind AS 18 (Revenue) and Ind AS 11 (Construction Contracts). The MCA notification required retrospective application with a cumulative catch-up adjustment on the transition date. Companies that did not adjust their revenue recognition processes in 2018 may still carry legacy recognition patterns that do not comply with the five-step model.

The five steps are: (1) Identify the contract with the customer, (2) Identify the performance obligations in the contract, (3) Determine the transaction price, (4) Allocate the transaction price to each performance obligation, and (5) Recognize revenue as each performance obligation is satisfied. For an IT services company, a single master service agreement may contain multiple performance obligations — development (milestone-based), maintenance (over time), and licences (point in time) — each requiring separate tracking.

Contract modifications — scope changes, rate revisions, additional work orders — must be assessed as either a separate contract (if the additional goods/services are distinct and priced at standalone selling price) or a modification of the existing contract. If treated as a modification, the company must choose between prospective treatment (allocate remaining price to remaining obligations) or cumulative catch-up (recalculate from inception). Indian IT companies with change requests on fixed-price projects must document the modification type and adjust the revenue schedule accordingly.

Ind AS 115 requires disclosure of: (1) disaggregation of revenue by type (licence, subscription, services), geography, and timing (point in time vs over time); (2) contract balances — receivables, contract assets, and contract liabilities with opening and closing movements; (3) remaining performance obligations and expected timing of recognition; and (4) significant judgments — methods used to determine standalone selling prices and timing of satisfaction. These disclosures are mandatory in the notes to financial statements filed with the MCA under Schedule III.

Variable consideration includes milestone bonuses, performance penalties, volume discounts, and SLA credits that make the transaction price uncertain at contract inception. Under Ind AS 115, the company must estimate variable consideration using either the expected value method (probability-weighted) or the most likely amount method, and include it in the transaction price only to the extent that a significant revenue reversal is not probable. For an IT company with a ₹50 lakh project and a 10% milestone bonus, the bonus is included in revenue only when achievement is highly probable — typically when the milestone is near completion.

The classification depends on the nature of the contract. Section 194J (10% TDS) applies to fees for professional or technical services — this covers software development, consulting, and technical advisory work. Section 194C (1% for individuals, 2% for companies) applies to contracts for carrying out work, which covers staff augmentation and outsourced process execution. Many IT services contracts involve both elements, and clients often classify the entire contract under one section. The reconciliation process must match the TDS rate applied by the client in Form 26AS against the rate the company expects based on the contract classification. Disputes are common and require correction returns by the deductor.

Under Ind AS 115, revenue for a milestone-based IT contract is recognised when (or as) each performance obligation is satisfied. For fixed-price contracts with defined deliverables, each milestone typically represents a distinct performance obligation if the client can benefit from each deliverable on its own. Revenue is recognised at the point when the client formally accepts the deliverable (sign-off). If the milestones are interdependent and the client only benefits from the completed whole, revenue is recognised over time using the input method (cost-to-cost) or output method (milestones completed as a percentage of total). The transaction price must be allocated to each milestone based on standalone selling prices.

Many IT services contracts include retention clauses where 10-20% of each milestone payment is withheld until final delivery and acceptance. This retention creates a receivable that does not convert to cash until the project is complete, which may be 6-12 months after the milestone invoice was raised. The retention amount must be tracked as a separate receivable line item, not clubbed with the current milestone receivable. Under Ind AS 115, revenue is still recognised on milestone acceptance, but the retention receivable should be assessed for impairment if there is a significant delay in final acceptance.

Each milestone invoice triggers a TDS deduction by the client at 194J (10%) or 194C (1-2%). The deducted amount should appear in Form 26AS within the quarter it was deducted. The reconciliation matches: invoice number and amount in the billing system → TDS certificate (Form 16A) from the client → Form 26AS entry showing the certificate number, amount, and section. Common mismatches include: wrong section code (194C instead of 194J), wrong quarter of deposit by the deductor, amount mismatch due to GST inclusion in the TDS base, and TDS deducted but not deposited by the client within the due date (7th of the following month).

A standard milestone billing cycle for Indian IT services runs: deliverable completion by the project team (day 0) → internal quality review (day 1-3) → client submission and sign-off (day 3-10, contractual acceptance period is usually 7-15 working days) → invoice generation on acceptance (day 10-15) → client payment terms (30-60 days from invoice date) → TDS deduction by client at payment → net amount credited to bank. From deliverable completion to cash receipt, the typical cycle is 45-75 days. The reconciliation must track each milestone through every stage, because delays at any point — particularly client sign-off — cascade through the entire chain.

Under Ind AS 115, T&M contracts are typically structured so that the customer receives and consumes the benefits of the services as the entity performs — meaning the performance obligation is satisfied over time. Revenue is recognised based on hours billed at the contracted rate, which is the contractual measure of progress toward complete satisfaction of the performance obligation. The transaction price for each billing period is the hours-times-rate amount, the revenue recognised equals the transaction price, and there is no significant work-in-progress accounting because each unit of service is invoiced as it is delivered. The reconciliation is between the timesheet system (hours), the billing system (invoice value), and the revenue ledger.

A fixed-bid contract commits the IT services firm to deliver a defined scope for a fixed price. Under Ind AS 115, the performance obligation is still typically satisfied over time because the customer controls the work-in-progress, but the measure of progress is no longer hours-billed-at-rate. The firm must choose an input method (typically costs incurred to date over total estimated costs — the cost-to-cost method) or an output method (milestones reached, deliverables accepted, surveys of work performed). Revenue is recognised based on the measure of progress applied to the total transaction price. This creates an unbilled receivable when revenue recognition outpaces billing, or a deferred revenue (contract liability) when billing outpaces recognition. The estimate of total costs must be revisited at each reporting date, with cumulative catch-up adjustments where the estimate changes materially.

Under Ind AS 21, foreign currency revenue is translated to the functional currency (INR for an Indian IT services firm) at the spot rate on the date of the transaction — typically the invoice date for a billing event. The receivable booked is in the functional currency at that translated amount. At each reporting date, the outstanding receivable in foreign currency is revalued at the closing spot rate, with the difference taken to P&L as an unrealised forex gain or loss. When the receivable is settled, the difference between the booking rate and the realisation rate is a realised forex gain or loss. Both unrealised and realised forex movements are presented separately from operating revenue — they sit in other income or other expenses, not in revenue from operations.

Ind AS 109 permits hedge accounting where the firm hedges its foreign currency exposure through derivatives — typically forward contracts or options on USD, EUR, or GBP. Hedge accounting requires formal designation of the hedging relationship at inception, documentation of the risk management objective, identification of the hedged item and hedging instrument, and demonstration that the hedge is expected to be highly effective in offsetting changes in fair value or cash flows attributable to the hedged risk. Cash flow hedges of forecast foreign currency revenue defer the effective portion of the hedge gain or loss in Other Comprehensive Income and recycle it to P&L when the forecast revenue is recognised. Without hedge accounting, the derivative is fair-valued through P&L while the underlying revenue may be recognised in a later period, producing an accounting mismatch and earnings volatility.

The FIRC (Foreign Inward Remittance Certificate, increasingly electronic) is issued by the AD Category-I bank on receipt of foreign currency proceeds and is the proof of inward remittance for FEMA and GST refund purposes. The realisation date is typically days or weeks after the invoice date, especially for customers on NET-30 or NET-60 terms. The FIRC reconciliation links three values per transaction: the invoice value in foreign currency, the gross remittance per the SWIFT MT103, and the INR credit posted to the EEFC or domestic account. The reconciliation is independent of the revenue recognition under Ind AS 115 — revenue may be recognised in month 1, the invoice raised in month 1, and the FIRC realised in month 2 or month 3. The four-ledger reconciliation at month-end matches revenue ledger, billing ledger, AR ledger, and FIRC log.

A Foreign Inward Remittance Certificate (FIRC) is issued by the Authorized Dealer (AD) bank as proof that foreign currency was received into India. Under RBI FEMA guidelines, every software export receipt must have a corresponding FIRC. During reconciliation, each FIRC must be matched to the invoice it relates to, the bank credit in INR, and the SOFTEX declaration — a four-way match. Missing FIRCs can trigger FEMA compliance queries during RBI audits.

An Indian IT company invoices USD 50,000 at ₹83.50 (booking value ₹41,75,000). The client pays 30 days later when the bank applies a rate of ₹84.20, crediting ₹42,10,000. The ₹35,000 difference is a foreign exchange gain that must be recognized in the P&L under Ind AS 21. If the rate had moved to ₹82.80, the ₹35,000 shortfall is a forex loss. Both must be classified separately from trade receivable adjustments.

SOFTEX is a statutory declaration filed with the Software Technology Parks of India (STPI) or SEZ authority for every software export. Each SOFTEX entry must match the corresponding invoice, FIRC, and bank credit. STPI units must file SOFTEX within 30 days of the invoice date. Reconciliation must verify that every export invoice has a filed SOFTEX and that the SOFTEX amount matches the FIRC amount after accounting for exchange rate differences.

AD banks submit monthly returns to the RBI covering all foreign exchange transactions including software export receipts. Companies must provide supporting documents — FIRCs, invoices, and SOFTEX declarations — to the AD bank. For STPI/SEZ units, an annual performance report reconciling total exports against SOFTEX filings is also required. Any mismatch between reported receipts and actual bank credits can trigger an RBI inquiry under FEMA Section 13.

Section 195 applies when an Indian company makes payments to a non-resident, not when it receives payments from abroad. However, if an Indian IT company subcontracts work to a foreign vendor and pays in foreign currency, TDS under Section 195 must be deducted at the applicable rate (typically 10-40% depending on the nature of payment and DTAA provisions). The reconciliation must track the gross payment, TDS deducted, net remittance, and Form 15CA/15CB filing status for each outward payment.

Deferred revenue is the portion of a subscription payment received upfront that has not yet been earned through service delivery. For example, if a customer pays ₹12,00,000 for a 12-month annual subscription on 1 July, only ₹1,00,000 is recognised as revenue in July. The remaining ₹11,00,000 sits as a current liability (deferred revenue) on the balance sheet. Under Ind AS 115, revenue is recognised over the subscription period as the performance obligation — providing access to the SaaS platform — is satisfied over time. The deferred revenue schedule must reconcile monthly against the revenue recognition schedule and the cash receipt ledger.

SaaS subscriptions sold to Indian customers attract GST at 18% under SAC code 998314 (licensing services for the right to use computer software). The SaaS company must charge CGST + SGST for intra-state sales or IGST for inter-state sales. For annual subscriptions billed upfront, GST is payable on the full invoice value in the month of billing, even though revenue recognition is spread over 12 months. This creates a timing difference between GST liability (immediate) and revenue recognition (deferred) that must be tracked in the reconciliation process.

Yes. Indian SaaS companies exporting services must file Form GST RFD-11 (Letter of Undertaking) with their jurisdictional GST officer before the start of each financial year. The LUT allows zero-rated export of services without payment of IGST. If the LUT is not filed or lapses, the company must charge IGST at 18% on export invoices and then claim a refund — a process that typically takes 60-90 days and creates a cash flow gap. The LUT filing deadline is before the first export invoice of the new financial year, and the company must not have been prosecuted for tax evasion exceeding ₹2.5 crore in the preceding two years.

When an Indian SaaS company invoices in USD and receives payment in INR, three exchange rates are involved: the invoice date rate (for booking the receivable), the receipt date rate (for recording the bank credit), and the reporting date rate (for revaluing outstanding receivables under Ind AS 21). The difference between invoice date and receipt date rates creates a realised forex gain or loss. The difference between invoice date and reporting date rates creates an unrealised gain or loss. Both must be tracked per invoice and reconciled against the FIRC (Foreign Inward Remittance Certificate) issued by the bank. For a SaaS company with 200 USD-billed customers, this produces 600+ forex entries per quarter.

Under Ind AS 115 (Revenue from Contracts with Customers), a SaaS subscription typically constitutes a single performance obligation: providing continuous access to the software platform over the subscription period. Revenue is recognised over time because the customer simultaneously receives and consumes the benefit. The transaction price is the total subscription fee, allocated evenly across the subscription period (straight-line basis). If the subscription includes distinct deliverables — such as implementation services, training, or a separate data migration module — each must be identified as a separate performance obligation and allocated a portion of the transaction price based on standalone selling price. ICAI's guidance note on Ind AS 115 provides detailed examples for technology companies.

Not entirely. The Supreme Court in Engineering Analysis Centre of Excellence Pvt. Ltd. v. CIT (2021) held that the consideration paid by Indian end-users or distributors to non-resident software manufacturers for the resale or use of computer software through end-user licence agreements does not amount to royalty under the relevant DTAA where the agreement does not transfer copyright. As a result, such payments are not chargeable to tax in India and Section 195 (now restructured under Section 393(2) in the new payment-code era) TDS does not apply where the income is not chargeable. However, the ruling is fact-specific to standard shrink-wrap and EULA-based software distribution. Customised software, source-code licences, software bundled with hardware that grants copyright rights, and licences that confer the right to commercially exploit the software remain royalty. The buyer must apply the test on a contract-by-contract basis.

Section 393(2) of the Income Tax Act, 1961, under the restructured payment-code regime, captures TDS on payments to non-residents covering royalty, fees for technical services, interest, and other specified categories. The applicable payment code under the 1001 to 1092 series for royalty and fees for technical services is 1062. The buyer must obtain a TAN, deduct tax at the rate prescribed under the Act read with the applicable DTAA (whichever is lower, where the non-resident furnishes a Tax Residency Certificate and Form 10F), deposit the tax to the credit of the Central Government, file the TDS return, and issue Form 16A to the non-resident. The reconciliation between the books, the TDS challans, and the TDS return is the operational backbone of the compliance.

The equalisation levy was introduced as a separate charge — distinct from income tax — on specified services provided by non-resident e-commerce operators and on specified digital services. The 2 per cent equalisation levy on e-commerce supply or services applies to consideration received by a non-resident e-commerce operator from supply or services to specified persons in India, where the non-resident does not have a permanent establishment. The levy and income tax under Section 393(2) are mutually exclusive — if a payment attracts equalisation levy, it is exempt from income tax under Section 10(50). The buyer must classify each foreign vendor at onboarding to determine which regime applies, because the deduction and deposit mechanics differ. Equalisation levy is paid by the Indian payer to the Central Government, but it is not a withholding from the non-resident's invoice — it is an additional liability on the payer.

Three documents are essential to claim the lower DTAA rate over the domestic rate. First, a Tax Residency Certificate (TRC) issued by the non-resident's home tax authority for the relevant period. Second, Form 10F containing the non-resident's name, status, PAN if any, address, period of residency status, and TIN in the home jurisdiction — Form 10F must now be filed electronically on the income tax portal where the non-resident does not have a PAN, through a registered representative. Third, a self-declaration that the non-resident has no permanent establishment in India and that the payment is not effectively connected with any business carried on in India. Without this trio, the buyer must deduct at the domestic rate, which for royalty and fees for technical services is significantly higher than most DTAA rates.

Before any foreign remittance covered by Section 195 / Section 393(2), the remitter must file Form 15CA on the income tax portal. Part A applies to remittances up to ₹5 lakh in a year. Part B applies where the AO has issued an order or certificate. Part C applies to remittances above ₹5 lakh in a year that are chargeable to tax — and Part C requires a CA-certified Form 15CB stating the nature of the remittance, the chargeability, the applicable rate, and the TDS deducted. Part D applies to remittances not chargeable to tax. The AD bank will not process the outward remittance without the Form 15CA acknowledgement number and, where required, the Form 15CB. Errors in the form attract penalties under Section 271-I.

Clients deduct TDS on T&M invoices under Section 194J at 10% for professional and technical services. The TDS is calculated on the invoice value excluding GST (per CBDT Circular 1/2014, TDS is deducted on the base amount when GST is shown separately on the invoice). For a monthly T&M invoice of ₹15,00,000 plus GST of ₹2,70,000 (18%), the client deducts TDS of ₹1,50,000 (10% of ₹15,00,000) and pays ₹16,20,000 (₹15,00,000 + ₹2,70,000 GST - ₹1,50,000 TDS). The TDS must be deposited by the client by the 7th of the following month and should appear in the IT company's Form 26AS within the same quarter.

A mismatch between approved timesheet hours and invoiced hours is one of the most common T&M reconciliation exceptions. Causes include: timesheets approved after the billing cut-off date (hours appear in the next month's invoice), client-rejected hours that were included in the invoice, rate card changes effective mid-month that were not applied to all line items, and leave or bench days incorrectly marked as billable. The resolution requires a three-way check: timesheet system (approved hours per consultant per client) vs. billing system (invoiced hours and rates) vs. client purchase order (contracted rate and maximum hours). Any variance above the contractual tolerance (typically 0.5-1% of monthly billing) must be investigated before invoice finalization.

Indian IT companies billing T&M clients in USD must reconcile at three exchange rate points: the invoice date rate (used to book the INR receivable), the FIRC (Foreign Inward Remittance Certificate) rate at which the bank converts the USD wire to INR, and the RBI reference rate on the reporting date for revaluing outstanding receivables. For a $50,000 monthly invoice booked at ₹84.20/USD (receivable = ₹42,10,000) and received at ₹84.50/USD (bank credit = ₹42,25,000), the realised forex gain of ₹15,000 must be recorded. Under Ind AS 21, unrealised gains on open receivables at quarter-end are recognised in profit and loss. The FIRC from the bank is the authoritative document for the actual conversion rate.

For an Indian IT company with 15 clients on T&M billing, the month-end close for billing reconciliation typically follows: timesheet submission deadline (1st-2nd of the following month) → manager approval of timesheets (2nd-3rd) → billing team generates invoices from approved timesheets (3rd-5th) → invoices reviewed against rate cards and POs (5th-6th) → invoices dispatched to clients (6th-7th) → revenue recognised in the GL (7th-8th). The reconciliation of the previous month's receipts — matching bank credits to invoices, recording TDS receivables, and booking forex gains/losses — runs in parallel during days 1-5. For companies with 200+ consultants, this process extends to day 10-12 without automation.

Yes, and this is a frequent source of reconciliation mismatches. Section 194C (1% for individuals, 2% for companies) applies to contracts for carrying out work, while Section 194J (10%) applies to professional or technical services. Some clients classify T&M staff augmentation contracts under 194C, arguing that the IT company is providing manpower rather than professional services. The IT company may disagree and expect 194J treatment. When the TDS rate in Form 26AS does not match the company's expectation, the finance team must either accept the lower credit and file the return accordingly, or request the client to file a TDS correction return (Form 26Q) changing the section code. The correction return process takes 30-60 days.

Under Section 92CA of the Income Tax Act, 1961, the Assessing Officer must refer an international transaction or a specified domestic transaction to the Transfer Pricing Officer (TPO) where the aggregate value crosses the prescribed threshold under CBDT Instruction 3/2016, currently ₹15 crore for international transactions. Once referred, the TPO determines the arm's length price (ALP) and the AO is bound by that determination subject to the appellate process. For an IT services captive earning a cost-plus markup from its overseas parent, the international transaction value is typically the entire service revenue line, which for any meaningful captive exceeds the threshold and makes the TPO reference automatic.

Rule 10TD of the Income Tax Rules prescribes safe harbour margins by activity category. For software development services and IT-enabled services rendered by an eligible assessee to a non-resident associated enterprise, the operating margin must be at or above the prescribed band — historically around 17 to 18 per cent on operating cost — with the exact rate depending on the value of international transactions. The safe harbour is available for transactions up to a notified ceiling (most recently ₹200 crore). Opting into safe harbour gives certainty for five years, removes the TPO reference for that period, and avoids the dispute cycle — but the cost is locking in a margin that may be higher than the assessee's economic margin.

Form 3CEB is the report of an accountant under Section 92E of the Income Tax Act in respect of international transactions and specified domestic transactions. Every person who has entered into an international transaction or a specified domestic transaction during the previous year must obtain a report from a chartered accountant in Form 3CEB and furnish it on or before the specified date — currently 31 October of the assessment year for assessees subject to transfer pricing audit. The form lists each international transaction, the associated enterprise, the method applied to determine ALP, and the comparables used. Non-filing or delayed filing attracts a penalty of ₹1,00,000 under Section 271BA, and an incorrect report can attract Section 271AA penalties.

An APA under Sections 92CC and 92CD is a prospective agreement between the taxpayer and the CBDT (with the competent authority of the other country in bilateral and multilateral APAs) that determines the ALP or specifies the manner of determination for international transactions for up to five future years, with a roll-back of up to four prior years. Once signed, the APA insulates the captive from TPO adjustments and from MAP disputes for the covered years on the covered transactions. For a steady-state IT services captive, the APA replaces annual TP litigation risk with a single negotiation cycle plus an annual compliance audit report. Bilateral and multilateral APAs additionally protect against double taxation in the country of the parent.

A unilateral APA is signed between the taxpayer and the Indian CBDT alone. It gives certainty against TPO adjustments in India but does not protect against the foreign tax administration taking a different view on the same transaction, which can produce double taxation. A bilateral APA is negotiated with both the Indian CBDT and the foreign competent authority (typically under the MAP article of the relevant DTAA) and binds both jurisdictions on the agreed ALP. A multilateral APA extends the same protection across three or more jurisdictions. Bilateral and multilateral APAs are the preferred route for captives with material related-party transactions, particularly with US, UK, German, Japanese, and Australian parents, where the foreign tax administration is active on intra-group services.

No. The substantive rate stays at 0.1% across the 1961 Act → 2025 Act transition. Section 194O carried 0.1% from October 1, 2024 onward (reduced from the original 1% by the Finance Act 2024). The Income-tax Act 2025, effective from FY 2026-27, absorbs the same rate into §393(1) Sl. 8(v) under payment code 1035. The base also stays the same — gross transaction value, inclusive of GST. What changes is the statute reference, the form on which the credit surfaces (Form 26AS for FY 2025-26 deductions vs Form 168 for FY 2026-27 deductions), and the payment-code field on the challan.

Because the cutover is by date of deduction, not by date of filing. Any sale settled on or before March 31, 2026 is deducted under Section 194O of the 1961 Act and credits in Form 26AS. Any sale settled on or after April 1, 2026 is deducted under §393(1) Sl. 8(v) code 1035 and credits in Form 168. Q4 FY 2025-26 returns (Form 26Q) are filed in May 2026, so 194O credits surface in Form 26AS in May 2026. Q1 FY 2026-27 returns (Form 26Q under the new schema) are filed in July-August 2026, so code 1035 credits surface in Form 168 in August 2026. For roughly 12 months — April 2026 through March 2027 — an active seller will receive credits on both forms in parallel.

Yes. The 2025 Act preserves the individual / HUF participant exemption: no TDS if annual platform sales remain at or below ₹5,00,000 AND the participant has furnished PAN or Aadhaar. The exemption applies only to resident individuals and HUFs; companies, firms, and LLPs continue to face TDS on every transaction with no threshold. The exemption is annual and tracked cumulatively across the FY; once a seller crosses ₹5,00,000 of gross sales, all subsequent transactions in the year attract 0.1%. Most active sellers cross the threshold within the first month of the FY.

It depends on the deduction trigger. Under both the 1961 Act and 2025 Act, the deduction occurs at the earlier of credit to the participant's account or actual payment. If the marketplace credits the seller's account on April 2, 2026, the deduction is on April 2 under the 2025 Act and surfaces as code 1035 in Form 168. The underlying sale date (March 31) does not determine the regime — the credit / payment date does. This is the single largest source of cross-era confusion: sellers expecting March sales to appear in Form 26AS will find them in Form 168 instead because settlement crossed the FY boundary. Pre-tagging every settlement batch with the deduction date at ingestion is the only reliable defence.

The income-tax return form for AY 2027-28 (FY 2026-27) is expected to carry separate schedules for Form 26AS and Form 168 credits, with the Form 26AS schedule covering pre-April-2026 deductions (under the 1961 Act) and Form 168 covering post-April-2026 deductions (under the 2025 Act). Total claimable TDS is the sum of both forms. The reconciliation discipline: extract each settlement batch from the marketplace report, tag the deduction date, classify into the 194O / Form 26AS bucket or the 1035 / Form 168 bucket, sum within each bucket, and tie each bucket to the corresponding form line in the ITR. Mismatches will trigger CPC notices under the new Faceless Assessment regime; pre-tagging avoids the rework cycle.

American Express is a three-party closed-loop network — the network is also the issuer and the acquirer — so the interchange that Visa and Mastercard split between issuer banks and acquirer banks is consolidated into a single higher merchant fee. There is no regulatory cap on credit-card MDR in India; the only RBI cap is the 2017 circular on non-RuPay debit at 0.40% for small merchants and 0.90% for larger ones. Razorpay, PayU, and Cashfree all publish Amex on the 3% premium slab in their rate cards. Cashfree's rate card specifically lists American Express at 2.95% domestic. The roughly 100 basis-point spread above Visa and Mastercard is structural network economics, not a gateway markup.

The headline rate is close — Razorpay and PayU publish 3% plus GST on Amex; Cashfree publishes 2.95% domestic. PhonePe does not publish a per-instrument rate card and routes Amex through its custom enterprise quote, but its blended 1.95% standard plan carves out premium networks, which in practice means Amex falls into the gateway's premium tier with a quote pulled separately. The Cashfree 1.6% promotional rate that ran from September 2025 to April 2026 explicitly excluded American Express cards issued abroad, returning that volume to the international Amex slab of 2.95% to 3.5% plus forex. The differences between gateways on Amex are second-order; the first-order question for any merchant is whether Amex appears as a separate line on the settlement file or is absorbed into a blended deduction.

Cashfree's anniversary promotional rate of 1.6% flat, available to new merchants signing up between 18 September 2025 and 30 April 2026 and locked for twelve months up to ₹1 crore monthly GTV, explicitly excludes American Express cards issued outside India. An Amex card issued by an Indian bank is billed at the domestic Amex slab of 2.95%; an Amex card issued by an overseas bank is billed at the international Amex slab of 2.95% to 3.5% plus forex conversion, with chargeback-protection layers optional on top. The distinction is by issuer BIN, not by transaction geography, and is invisible from the buyer's checkout flow. A travel OTA, an export-led D2C merchant, or any business serving NRI customers must track the issuer-country split of its Amex volume separately to avoid silent international-slab billing on what it assumed was a domestic promo rate.

The detection technique is a per-network effective-rate audit. From the gateway settlement file, isolate transactions where the network is American Express (BIN starts with 34 or 37), sum the gross transacted volume and the total fee deducted on that bucket, and compute fee divided by volume to get the effective Amex rate in percentage terms. Compare that effective rate against the contracted Amex slab in the rate card — for most Indian merchants that is 2.95% to 3% domestic plus GST 18% on the fee. A second check splits the Amex bucket by issuer country using the BIN: Amex-India BINs should reconcile to the domestic slab; Amex-issued-abroad BINs should reconcile to the international slab. If the Amex effective rate equals the merchant's Visa or Mastercard effective rate to within 10 basis points, the gateway is not separately pricing Amex — that is the highest-confidence leakage flag in the merchant-fee dataset.

GST is 18% on the MDR or platform fee value regardless of which network the transaction was on. The GST is computed on the fee, not on the transaction value, and must always appear as a separate line item on the gateway tax invoice and on the merchant's reconciliation. For a ₹10,000 Amex transaction at 3% MDR, the fee is ₹300 and the GST is ₹54 — total deduction ₹354 — and the ₹54 is fully ITC-recoverable for a GST-registered merchant against the gateway's tax invoice for that period. The reconciliation rule is identical to every other network: separate the MDR line from the GST line, match both back to the gateway invoice, and never fold GST into the MDR percentage when computing per-network effective rates.

Amex and Diners are three-party (closed-loop) networks — the network is also the issuer and the acquirer, so the interchange that Visa and Mastercard split between issuer and acquirer banks is consolidated into a single higher merchant fee. Gateway rate cards reflect this structurally — Razorpay, PayU, and Cashfree all publish a 3% slab for Amex and Diners against a 2% slab for Visa/Mastercard consumer credit. Cashfree's rate card specifically lists Diners at 2.95%. The 1 percentage-point spread is not a markup the gateway is hiding — it is the underlying network economics — but it does mean a flat blended quote that does not separately price Amex and Diners is an averaging exercise the merchant cannot verify.

A blended rate is a single percentage applied to all qualifying transactions regardless of network, usually with a published carve-out list (Amex / Diners / international / commercial / EMI all at a higher slab). When the gateway offers a true blended rate with no carve-out, the gateway is taking the network-mix risk — it expects, say, 5% Amex and Diners share at 3% cost and 95% Visa/Mastercard/UPI at ~1.5% blended cost, averaging out to its quoted ~2%. If the merchant's actual Amex/Diners share is higher, the gateway is under-recovering; if lower, the gateway is over-recovering. Either way, the merchant has no per-network visibility unless it computes effective rates itself.

The per-network effective rate is total fees deducted on a network's volume divided by the gross transacted volume on that network, for a defined reconciliation period. From the gateway settlement file, group transactions by network (UPI, RuPay debit, Visa debit, Mastercard debit, Visa credit, Mastercard credit, Amex, Diners, international), sum gross volume and total fee deducted per group, and compute fee divided by volume. Compare each group's effective rate against (a) the gateway's published per-network rate, and (b) the blended rate. A network whose effective rate equals the blended rate has been priced flat — which is correct for some networks and wrong for Amex and Diners.

Once the gateway sees that its Amex and Diners volume is materially higher than the network mix it priced the blended rate against, it has three contractual levers. First, retrospective reclassification — re-categorising a tranche of transactions in a later cycle as 'premium / non-standard' and re-billing the differential. Second, a notice-period rate revision invoking the carve-out clause that exists in nearly every gateway agreement. Third, an opaque true-up at the next contract renewal. The merchant sees the second and third as a sudden rate change; the first appears as a settlement adjustment line that often goes unreconciled because the per-transaction itemisation is not visible.

No — GST is 18% on the MDR or platform fee value regardless of how the fee is computed. The GST is always a separate line item on the gateway tax invoice and is fully ITC-recoverable for a GST-registered merchant. The reconciliation rule is identical to per-network MDR: GST is computed on the fee, not on the transaction value, and the fee plus GST must reconcile back to the gateway tax invoice for the period. A blended rate does not change the GST mechanics — it only collapses the per-network audit trail that would let the merchant verify the fee itself.

BillDesk operates as a bill payment aggregator and a Bharat Bill Payment Operating Unit, not as a horizontal payment aggregator that sells flat-rate checkout to any D2C merchant. The customer base is anchored on institutional billers — DTH operators, telecom, state electricity boards, gas distributors, insurance companies, mutual funds and recurring-collection institutional merchants — and the pricing logic is segmented by biller category rather than priced as a flat blended rate. The settlement file therefore carries a biller-share column that does not exist on a Razorpay or PayU file, and the MDR slab depends on whether the biller is a regulated utility under a BBPS fee structure, a government department, an insurance company or a private institutional merchant. The reconciliation discipline that fits BillDesk is bill-cycle level rather than transaction-batch level.

A BillDesk settlement file exported from the biller portal contains, for each bill payment, the gross collection amount, the customer reference and biller reference, the payment instrument used (NetBanking with the partner bank code, Credit Card with the BIN, Debit Card with the BIN, UPI with the handle, Wallet or BBPS-channel attribution), the applicable MDR amount split between the biller-share and the gateway-share, the GST on the MDR, and the net amount due to the biller. The settlement is batched on a settlement cycle agreed in the biller contract — daily, T+1 or weekly depending on the biller — and reconciles against the bank credit at the cycle level. The reconciliation join is the settlement_batch_id against the bank credit on UTR and net amount, drilled to the per-transaction record by customer reference and bill number.

Under the Bharat BillPay framework operated by NPCI, the customer convenience fee or biller-borne charges are regulated and apportioned among the participating entities — the Bharat Bill Payment Operating Unit on the agent side, the Bharat Bill Payment Operating Unit on the biller side, and NPCI as the central network. For a BBPS bill payment routed through BillDesk acting as the biller-side BBPOU, the settlement file shows a biller-share line that is the portion BillDesk retains from the regulated fee structure, distinct from the standard MDR a private institutional merchant on BillDesk would see. Utility billers operating under the BBPS framework see a capped or zero customer-borne MDR depending on bill type and biller category, with the network economics flowing through the BBPS settlement at the biller-share level — this is the column that does not exist on a non-BBPS gateway file.

Three leakage cells recur. The first is net banking flat-fee versus percentage at high ticket sizes — a partner bank net banking line billed at approximately Rs 7 per transaction is materially cheaper than a 1.8 percent line on a Rs 5,000 electricity bill, and the leakage arises when the biller has not contractually established whether net banking is flat-fee or percentage and the settlement file silently applies one over the other. The second is BBPS biller-share calculation drift — the regulated apportionment on a BBPS bill changes by bill type and biller category, and a reconciliation that does not bind the expected biller-share per bill type to the contracted schedule will absorb drift quietly. The third is per-bill-type slab differentiation — an insurance premium collection and a DTH recharge sitting on the same BillDesk merchant account may legitimately bill at different slabs, and a single blended expected-rate model will misclassify variance as exception.

Where BillDesk operates as an e-commerce operator and the biller is the e-commerce participant — the standard pattern for institutional billers using BillDesk to collect bill payments from customers — Section 393(1) Sl. 8(v) of the Income-tax Act 2025 (payment code 1035) applies at 0.1% on the gross amount credited or paid to the biller, whichever is earlier. This rate has been 0.1% since 1 October 2024, replacing the original 1% rate of the legacy Section 194O regime. The deduction reconciles to the biller's Form 26AS. GST at 18% on the MDR fee plus the biller-share retained by BillDesk (not on the bill amount itself) is a separate line and is recoverable as input tax credit for registered billers, subject to GSTR-2B reconciliation against the BillDesk tax invoice. Keep MDR, biller-share, GST on the BillDesk fee, and TDS deducted by the operator as four distinct reconciliation columns. For regulated utilities operating under BBPS-mandated zero customer-borne fee structures, verify the operator's deduction logic against the actual amount credited, not the gross customer payment.

Cashfree's published standard rate is 1.95% on UPI, domestic cards, NetBanking, wallets, and domestic prepaid cards. The 10-year-anniversary limited offer drops that to a flat 1.6% for new merchants who sign up between 18 September 2025 and 30 April 2026. The promo is locked for 12 months from sign-up, applies up to ₹1 crore per month of GTV (volume above the cap reverts to standard pricing for that month), and requires UPI to be at least 40 percent of the merchant's monthly GTV. If the UPI mix falls below 40 percent in any qualifying month, Cashfree rescinds the promo and the rate reverts to 1.95 percent for the remaining months of the 12-month lock. The international card rate card and EMI rate card are separate and do not get the 1.6 percent treatment.

Three carve-outs matter for reconciliation. First, international Visa and Mastercard transactions get a 2.69 percent promotional rate up to ₹10 lakh of international GTV per month, then revert to 2.99 percent for that month's overflow. Second, American Express transactions on Indian-issued cards are billed at 2.95 percent; Amex cards issued abroad are excluded from the international promo and carry the standard international Amex rate plus forex. Third, the EMI rate card is independent: debit-card EMI at 1.5 percent, credit-card EMI at platform fee plus 0.25 percent, cardless EMI at 1.9 percent, and Pay Later at 2.2 percent. None of these instrument categories benefit from the 1.6 percent blended promo even when the merchant otherwise qualifies.

The UPI mix is calculated as the merchant's UPI GTV divided by total monthly GTV settled through Cashfree, including cards, NetBanking, wallets, EMI, and Pay Later. The published terms describe the check as a monthly qualification — Cashfree reserves the right to rescind the 1.6 percent rate if UPI falls below the 40 percent threshold during the promo period. Finance teams should treat the threshold as a hard line, not a band. A merchant running at 41 percent, 39 percent, 41 percent across three months has already triggered the carve-out in month two. The practical reconciliation discipline is to compute the rolling UPI mix in real time against the gross volume reported in the Cashfree dashboard, not against month-end exports that arrive after the breach has happened.

GST at 18 percent is charged on the MDR fee, not on the transaction value. A ₹10,000 transaction at 1.6 percent attracts ₹160 of MDR plus ₹28.80 of GST on that MDR, for a total deduction of ₹188.80. Cashfree issues a monthly GST invoice for the registered GSTIN; the GST-on-MDR amounts shown in the settlement report must reconcile to that invoice line for the corresponding period. GST-registered merchants can claim input tax credit on this amount after matching the Cashfree invoice in GSTR-2B. Reconciliation discipline keeps gross transaction value, MDR, GST on MDR, refund value, and reversal entries as separate columns — collapsing any of them into a single deduction figure breaks the GSTR-2B claim trail and the audit trail for the controller.

Cashfree publishes settlement reports through the merchant dashboard in CSV format, filterable by date range. The fields finance teams join against are: settlement_id and settlement_date for the batch level; gross_amount, mdr_amount, gst_on_mdr, and net_settlement_amount for the financial breakdown; order_id and payment_id for the OMS join. The default T+1 settlement cycle means daily reconciliation reads Day N capture data against Day N+1 settlement credits. The bank narration on the NEFT credit typically references a Cashfree nodal account and a UTR; matching the settlement_id and net amount to the bank credit is the first pass. Refund reversals appearing in a later settlement window are the most common source of variance between the batch total and the bank credit on Day N+1.

A commercial card (also called corporate card, business card, or purchasing card) is issued to an entity rather than an individual — typical examples are corporate Visa, Mastercard World Business, Mastercard Corporate, Visa Business. Interchange on commercial cards is materially higher than on standard consumer Visa or Mastercard credit cards because the issuer carries more risk on revolving corporate spend and the network adds a commercial surcharge. Indian gateways consistently route corporate and commercial Visa or Mastercard transactions to the same 3% premium slab as Amex and Diners — Razorpay's published pricing footnote, PayU's FAQ pricing, and Cashfree's rate card all confirm this. Consumer credit cards run roughly 1.4% to 2.5% in the negotiated range, with published gateway cards clustered around 2%. The leakage signal is the gap between those two slabs landing on the wrong side of the BIN tier.

The BIN (Bank Identification Number — the first six to eight digits of the card number) carries the issuer-product attribute that distinguishes a consumer Visa from a Visa Business or a Mastercard World Business. Indian gateways expose the card-type or product-tier attribute on the per-transaction settlement file in different shapes: Razorpay surfaces a card-subtype field; PayU exposes card-category; Cashfree exposes card-type-detail. Where the field is sparse, source the BIN-tier table from the acquirer (HDFC Acquiring, Axis Acquiring, ICICI Acquiring, RBL Bank, Worldline) and join on the first six digits of the card number. The acquirer's interchange schedule is the binding reference for which BIN ranges are commercial and which are consumer; the gateway's classification is a derivative that can drift from it.

Both directions are real, but the direction that hits the merchant's P&L is consumer-card-billed-as-commercial: the gateway charges the 3% premium slab on a transaction the contracted consumer slab would have priced at 2% (or 1.6% on a negotiated enterprise rate), and the merchant absorbs the gap. The reverse direction — commercial-card-billed-at-consumer-slab — erodes gateway margin and is generally self-correcting because the gateway notices and reclassifies. For a merchant with a high share of commercial cards (B2B SaaS, enterprise services, hotel chains billing corporate stays), the leakage compounds month after month because the merchant never sees the per-card economics, only the blended fee column. The audit lift is to surface both directions per network per BIN tier and quantify the gap monthly.

Build the table as: per network, per card tier, total gross processed, total fee billed, effective rate (fee divided by gross). For Visa or Mastercard, a clean file shows the consumer tier at the contracted consumer slab (around 2% or the negotiated enterprise rate of 1.4% to 1.6%) and the commercial tier at the contracted commercial slab (typically 2.5% to 3%). If the consumer tier is reading above 2.5%, transactions are being routed to the premium bucket. If the commercial tier is reading below the contracted commercial slab, the gateway is under-recovering and a reclassification correction is coming. The same analysis on Amex and Diners is structurally pinned at the 2.95% to 3% premium slab. For RuPay credit, the consumer credit slab is the binding reference; corporate RuPay credit volume in India is small but growing and merits the same BIN-tier check.

The international cross-border slab is a separate audit path covered in the international-card billed-as-domestic leakage pattern of this cluster. The relevant interlock is that an international corporate card sits at the intersection of two premium slabs — international scope and commercial tier — and is typically billed at the international slab (2.69% to 3.5% plus forex) rather than the commercial-domestic slab. Verify which contracted slab the merchant agreement actually names for that combination. Cashfree publicly excludes American Express issued abroad from its 2.69% international promo; Razorpay adds an optional 1% chargeback protection on international cards. Read the merchant agreement against the settlement classification.

The 3% slab is not arbitrary — it follows the underlying network interchange. Visa and Mastercard publish higher interchange on commercial products (Visa Business, Visa Corporate, Mastercard World Business, Mastercard Corporate) than on standard consumer credit because the issuer carries more risk on revolving corporate spend, the average ticket is larger, and the network adds a commercial product surcharge. Indian gateways pass through that cost basis at 3% across the board. Razorpay's pricing footnote, PayU's pricing FAQ, and Cashfree's rate card all converge on the same 3% bucket for commercial cards alongside Amex, Diners, EMI, and international cards. The interchange-driven economics are public; the contractual permission to bill the slab without per-transaction itemisation is the audit problem.

The decision is mechanical and BIN-driven. The first six to eight digits of the card number (the Bank Identification Number, formally the Issuer Identification Number under ISO 7812) are looked up against the network's published product schedule. A Visa BIN beginning 4XXXXX may be a consumer Visa, a Visa Business, a Visa Signature, or a Visa Infinite — the product attribute is carried in the BIN range and the issuer's BIN allocation table. The acquirer aggregates these into a BIN-tier schedule. The gateway's classifier reads the schedule, matches the BIN, and routes to whichever slab in the merchant's rate card applies. The classifier is deterministic per BIN — once a BIN is in the commercial bucket, every transaction on that BIN goes to the 3% slab until the bucket changes.

The rate card needs to enumerate every card tier the merchant agreement contemplates and assign a specific slab to each. Sloppy contract language — for instance, a rate card that says only 'standard credit 2%, premium 3%' without defining premium — gives the gateway billing engine wide latitude to fold rewards, signature, infinite, and commercial all into the 3% bucket. A tight rate card specifies: standard consumer credit (Visa, Mastercard, RuPay) at the negotiated slab; commercial / corporate / business at a separate explicit slab; premium signature / infinite / rewards at a third slab if the merchant wants to keep them distinct; Amex and Diners domestic at the 3% premium slab; international cards on a separate scope clause. Without the enumeration the slab application is contractually indefensible to dispute.

Yes, the inverse case happens, and it matters more than it appears at first glance. A commercial-tier BIN that is mis-tagged consumer by the gateway billing engine gets billed at the consumer 2% slab. The merchant sees a lower fee that month and no audit signal fires. Two or three settlement cycles later, the gateway's own reconciliation engine catches the gap and processes a retroactive fee true-up — appearing as an unexplained 'fee adjustment' line on a later settlement. Without the BIN-tier reconciliation, the merchant cannot tie the true-up back to the originating transactions or contest its basis. The merchant cash-flow impact is real even when the contractual position is correct. The audit hygiene is to flag both directions of mis-tier so the true-up never arrives unaccounted for.

Yes — GST at 18% applies on the MDR or platform fee only, never on the transaction value, and the gateway raises a tax invoice naming the GSTIN of the merchant. The ITC is claimable in the normal GSTR-2B reconciliation cycle, provided the merchant's GSTIN on file with the gateway matches the GSTIN under which the input services are being consumed. The audit-trail point is to keep the GST line separately reconciled — never fold it into the MDR percentage — and to match every gateway invoice and credit note to GSTR-2B. When a BIN-tier dispute is resolved and the gateway issues a credit note for the over-billed MDR, the 18% GST on that credit note reduces ITC in the period the credit note is issued, which is a standard GSTR-2B reconciliation event.

Diners Club is a three-party (closed-loop) network — historically the original closed-loop charge card brand, now operated globally under the Discover Global Network and in India through HDFC Bank's issuing relationship. In a three-party network the network is also the issuer and the acquirer, so the interchange that Visa and Mastercard split between issuer and acquirer banks is consolidated into a single higher merchant fee. Visa and Mastercard consumer credit lands at roughly 1.4-2.5% in negotiated India pricing; Diners lands at 2.95-3.5% across every gateway with a published rate card. The 1 percentage-point spread is structural, not a gateway markup — but the merchant only realises it as a separate line item when the rate card is itemised by network, which a blended 2% quote will not do.

Cashfree's pricing page lists Diners Club explicitly at 2.95% (alongside Amex at 2.95%) — the most transparent disclosure in the Indian market. Razorpay's pricing page footnote groups Diners with Amex, corporate cards, international cards, and EMI at a 3% slab. PayU's FAQ-pricing page similarly buckets Amex, Diners, international, and EMI at 3%. PhonePe PG does not publish a per-instrument rate card — the published Standard Plan is a single blended 1.95% (currently struck through under a 'Free' launch promo) and per-instrument percentages must be requested through the Business Dashboard. The practical takeaway: in any contract that does not name Diners on a separate line, the merchant is paying the gateway's blended quote against a network whose true cost is 2.95-3.5%.

Diners Club has a small but persistent base in India — concentrated in HDFC Bank-issued Diners cards held by affluent and corporate customers, frequently used for travel, hospitality, dining, and high-ticket retail. At a representative Indian merchant the Diners share of total card volume is typically below 2%, often closer to 1-1.5%. The share is rarely large enough to draw attention in a monthly settlement review — which is precisely why the cost is easy to miss. A blended 2% deduction line across all card volume averages the Diners cost into the deduction; the merchant sees no separate Diners line and no exception is raised, even though every Diners rupee is being billed at roughly 50% more than a Visa or Mastercard rupee.

GST is 18% on the MDR or platform fee value, not on the transaction value. A Diners transaction of ₹50,000 at a 3% MDR carries ₹1,500 of fee and ₹270 of GST on that fee — total deduction ₹1,770. The GST must appear as a separate line on the gateway tax invoice and is fully ITC-recoverable for a GST-registered merchant. The reconciliation rule is identical across networks: never fold GST into the MDR percentage, and always reconcile fee plus GST back to the gateway tax invoice for the period. Where a settlement file shows a single combined deduction without the GST split, request the per-cycle tax invoice and reconcile the GST line independently — a missing tax invoice means no ITC, which is a separate and additional leakage on top of the MDR itself.

When a gateway prices a blended rate it implicitly assumes a network mix — typically a small Amex and Diners head at 3% premium cost, a Visa and Mastercard middle at 2% consumer cost, and a UPI tail at 0%. If the merchant's actual Diners share is higher than the priced share — common in hospitality, travel, and high-end retail — the gateway is under-recovering on the premium tail. Three contractual mechanisms close the gap. First, retrospective reclassification — re-categorising a tranche of Diners transactions in a later cycle as 'premium' and billing the differential as a settlement-adjustment line. Second, a notice-period rate revision invoking the carve-out clause that exists in nearly every gateway agreement. Third, an opaque true-up at the next contract renewal. The merchant experiences these as an unexplained settlement deduction, a 'rate change' letter, or a renewal quote materially above the published headline — at a moment the CFO has not budgeted for it.

The Bank Identification Number is the first six digits of a card's primary account number. It identifies the issuer institution and, by extension, the issuer's country. Visa, Mastercard, RuPay, American Express and Diners all maintain BIN registries that map the first six (and, in newer BINs, the first eight) digits to issuer and country. The acquirer is contractually required to use the BIN-derived issuer country to determine MDR scope — a transaction on a card whose BIN says India is a domestic transaction, regardless of where the cardholder is currently located or where the merchant is. Charging an international MDR slab on a domestic BIN is a mis-classification, not a legitimate cross-border assessment.

Three common paths. First, BIN-table staleness — the acquirer's BIN-to-country map is out of date, and newer Indian BINs (especially those issued by smaller PSU banks, co-operative banks, or fintech card programmes) are not yet classified as IN. Second, fallback logic — when a transaction comes in with a missing or unrecognised BIN, the acquirer's processing rules default to the international slab as a conservative choice (and the higher-revenue choice). Third, dispute-cycle adjustments — a transaction initially scoped as domestic gets re-scoped during a forex-fluctuation adjustment, with the cross-border assessment and forex margin layered on without a notification to the merchant.

They are two separate charges and should appear on two separate lines in the settlement file. The international MDR slab (2.69 to 3.5 percent depending on gateway and network) is the merchant discount rate that compensates the acquirer for cross-border interchange and assessment. The forex line is the conversion margin charged when the transaction value needs to be settled to the merchant in INR but the cardholder paid in another currency. For a domestic-BIN transaction in INR, there is no currency conversion happening — so a forex line on a domestic-BIN transaction is unambiguously wrong. The MDR mis-classification and the spurious forex line tend to travel together.

Yes. GST at 18 percent applies to the MDR and any platform fee as a separate line, not to the transaction value. If the acquirer over-charges MDR by mis-scoping a domestic BIN as international, the GST on that over-charge is also over-billed and follows the recovery symmetrically. When the acquirer issues a fee-adjustment credit note, it must reverse both the MDR and the GST. The merchant claims input tax credit on the corrected, lower GST figure in GSTR-3B for the period — a smaller fee base is still a smaller working-capital drag, even where ITC is fully claimable.

Monthly is the minimum cadence for any merchant with material card volume; weekly if you sit above one crore monthly card GMV or are running a promotional period that has pulled in new customer cohorts (and therefore new BINs). You need per-transaction settlement detail with at minimum: full card BIN (first six or eight digits), card network, MDR rate applied, MDR amount, forex amount (if any), declared transaction scope (domestic versus international), and the settlement currency. If your current gateway report only shows blended MDR by day, request the per-transaction extract — every Indian payment aggregator can produce one, and the SLA on this request is usually under three business days.

The e-commerce operator is the entity that owns, operates or manages the digital or electronic facility through which the sale of goods or services takes place — the platform. Amazon, Flipkart, Meesho, Ajio, Myntra, Nykaa, BigBasket, Swiggy and Zomato in their marketplace capacity are operators. The e-commerce participant is the resident person selling goods or providing services through that platform — the seller or merchant. The deduction obligation sits squarely on the operator, not the participant. The participant only receives the credit and reconciles it. Where the same group operates multiple platforms each platform's separate TAN deducts on its own settlements, and the participant must split Form 26AS by deductor TAN rather than treating it as one stream.

Generally no. A pure payment aggregator such as Razorpay, Cashfree, PayU or BillDesk that only acquires the customer payment and remits it to the merchant is not itself running the marketplace that brought the sale together, and is not an operator under Section 194O. Where the marketplace operator has already deducted under 194O on the same transaction, no other section requires the gateway to deduct again on that flow. A gateway only enters the operator definition where it actually performs a marketplace role — for example by hosting product listings, surfacing seller catalogues, or directing buyer demand to specific sellers. The test is whether the entity is the facility through which the sale is concluded, not whether it merely settles the resulting payment.

No. The statutory rule under Section 194O (and the Income-tax Act 2025 successor §393(1) Sl. 8(v) payment code 1035) is that where the operator has deducted at source on a transaction, that transaction is not subject to TDS under any other provision for that flow. The gateway settling the same payment does not deduct again. The corollary the finance team must police is the reverse case: if the channel is not a 194O channel at all — for example a sale on the brand's own website acquired through a gateway — there is no operator-side deduction, and no second TDS layer attaches to the customer payment either. The buyer-side 194Q on B2B purchases is a different obligation that sits on the buyer, not on the gateway.

Download Form 26AS or AIS from the income-tax portal and split entries by deductor TAN. Amazon, Flipkart, Meesho, Ajio and any other operator each file under their own TAN, so per-operator buckets are the only correct reconciliation grain. For each operator, compare the cumulative 0.1% credited against the cumulative gross amount credited or paid on that operator's settlement statements for the quarter. From FY 2026-27 onward the credits surface under §393(1) Sl. 8(v) payment code 1035 rather than the legacy 194O code, so a reconciliation engine keyed only on the old code will miss them; build the rate calendar across the 1 October 2024 rate cut and the 1 April 2026 code transition. The remaining channels — own website and direct B2B — must show no 194O credit at all, and any stray entry there is a deductor classification error worth chasing back.

For the food delivery flow Zomato and Swiggy are e-commerce operators under Section 194O on the restaurant participant's earnings. They deduct 0.1% on the gross amount credited or paid to the restaurant after the rate cut effective 1 October 2024. This is distinct from the GST Section 9(5) liability, under which the aggregator is the deemed supplier and discharges GST on the restaurant supplies — that GST treatment does not change the 194O TDS mechanics. A multi-outlet QSR therefore sees, from a single aggregator, three separate reconciliation lines: gross sales as reported by the aggregator, 0.1% TDS in Form 26AS under the aggregator's TAN, and GST 9(5) supplies discharged by the aggregator on the restaurant's behalf. The platform commission and gateway fees inside the aggregator's economics are separate again.

EMI MDR is the merchant discount rate charged when a customer pays in equated monthly instalments rather than as a single capture. The instrument is still a card or a credit line, but the rail underneath now involves the issuing bank or the lending partner converting the order value into a tenure-based loan to the customer. That conversion carries its own interchange and processing economics, which gateways recover as an uplift over the standard card slab. Cashfree publishes the uplift explicitly — debit-EMI at 1.5 percent, credit-EMI at the base platform fee plus 0.25 percent, cardless EMI at 1.9 percent, and Pay Later at 2.2 percent. Razorpay and PayU instead apply a single 3 percent plus GST slab across every EMI rail. The economic effect is that a credit-card EMI on a debit card running at 1.5 percent on Cashfree is being billed at 3 percent on Razorpay, and the merchant absorbs the 1.5 percentage point gap on every instalment-flagged transaction.

Debit-card EMI is a relatively new rail in India. The customer's bank converts the debit amount into a fixed-tenure loan against an existing relationship, typically with a pre-approved limit, which means the issuer carries less of the underwriting and tokenisation cost than on an unsecured credit-card EMI. Cashfree's published rate card captures this differential — 1.5 percent on debit-card EMI versus the standard credit-card EMI uplift of platform fee plus 0.25 percent. For a merchant whose customer base skews toward salaried buyers using a pre-approved debit-EMI offer at a public-sector or large private bank, biasing the checkout toward debit-EMI rather than credit-EMI on Cashfree saves a meaningful slice of MDR on every transaction. The same biasing on Razorpay or PayU saves nothing because both rails are billed at 3 percent.

Cardless EMI is an instalment loan originated by a lending partner — typically a Bajaj Finserv, HDB Financial, ZestMoney class of lender — at the point of checkout against the customer's pre-approved limit. No card is involved. The customer completes a one-time verification, picks a tenure, and the lender disburses to the merchant net of the agreed MDR. Pay Later is a smaller short-tenure credit instrument, typically interest-free for 15 to 30 days, originated by a wallet or fintech partner like Simpl, LazyPay, ICICI PayLater. The economics differ — cardless EMI involves longer-tenure underwriting and is published by Cashfree at 1.9 percent, Pay Later involves shorter-tenure underwriting at higher per-transaction settlement frequency and is published at 2.2 percent. On Razorpay and PayU both rails sit inside the flat 3 percent EMI bucket. Treating them as one line in the settlement file is a common reconciliation error that hides which rail is actually carrying the cost.

GST at 18 percent is applied on the MDR fee itself, not on the order value and not on the instalment loan disbursed to the merchant. A ₹50,000 consumer-electronics order paid via debit-card EMI on Cashfree at 1.5 percent attracts ₹750 of MDR plus ₹135 of GST on that MDR, for a total fee deduction of ₹885. The merchant receives ₹49,115 net into the nodal account, regardless of the tenure the customer has picked. The gateway issues a monthly GST invoice covering the MDR and the GST line, which the merchant uses to claim input tax credit in GSTR-2B against the registered GSTIN. Reconciliation discipline keeps the gross order value, the per-rail MDR, the GST on MDR, the tenure flag, and the lending-partner identifier as separate columns. Collapsing any of them into a single deduction breaks the GSTR-2B claim trail and obscures which EMI rail is driving the fee.

Not in isolation. The cheapest rail on a Cashfree rate card is debit-card EMI at 1.5 percent, but debit-EMI eligibility is gated by the customer's bank, the issuing bank's pre-approved-limit logic, and the order ticket. For a ₹6,000 to ₹20,000 consumer-electronics ticket, debit-EMI conversion rates are typically lower than credit-EMI because fewer customers have a live debit-EMI offer at checkout. The right discipline is to instrument the rail-mix on every checkout cycle, measure the conversion and the MDR jointly, and bias the surface only where the combined economics favour the cheaper rail. On Razorpay and PayU the question is moot because all four rails settle at 3 percent — the only lever is moving EMI volume to a per-rail gateway like Cashfree where the per-rail rate card actually rewards mix optimisation, then steering the mix toward the customer-bank pairs that maximise debit-EMI conversion.

When a subscription merchant triggers a debit against an active eNACH mandate and the destination bank rejects the debit — insufficient balance, account closed, mandate inactive, signature mismatch, technical failure at the bank — the destination bank issues a return message with one of the published NPCI return reason codes. The sponsor bank passes a return-handling charge through the payment aggregator to the merchant. The widely published rate is around ₹15 plus 18 percent GST per failed debit, though the exact rupee figure varies by aggregator contract and sponsor-bank pairing. The fee covers the cost of the return-message handling on the NACH rail, not the successful debit. The merchant pays it whether the debit fails on the first attempt or on a retry, so every retry cycle is a fresh fee event.

A typical NBFC EMI policy is a first attempt on the due date, a T+3 retry, and a T+5 second retry. A book of 38,000 mandates with a 12 percent first-attempt rejection rate produces 4,560 first-cycle failures. If the T+3 retry recovers 60 percent of those, the second-cycle base is 1,824 mandates, and on a similar destination-bank profile a comparable proportion of those will fail again. The merchant pays approximately ₹15 plus GST on every failed attempt — 4,560 first-cycle failures plus roughly 1,800 retry failures equals a monthly rejection fee bill of around ₹1.13 lakh before any collection-cycle delay-cost on the loan book itself. The annual figure crosses ₹13 lakh on rejection fees alone, before counting the days-past-due impact.

The aggregator's monthly fee invoice gives the merchant a single number for mandate-rejection fees with no breakdown by sponsor bank, destination bank, or return reason code. That number cannot be acted on. The per-batch reconciliation pulls the eNACH return file for every settlement batch, attaches each failed debit to its mandate identifier, retrieves the published NPCI return reason code, and totals the rejection-fee plus GST burden per code. A rejection caused by insufficient balance has positive retry economics — the customer is solvent, the salary credit will arrive, the T+3 retry will land. A rejection caused by mandate inactive has negative retry economics — the underlying mandate has been revoked or expired and every retry is a guaranteed fee burn. The reconciliation makes the retry policy code-aware.

A rejection-trap sponsor bank is one where the realised first-attempt rejection rate on outbound debits is materially higher than the cluster mean even after controlling for customer profile and mandate vintage. The detection is a per-batch attribution: for every settlement batch, compute the rejection rate by sponsor bank, average across thirty days, and rank. A sponsor bank running 18 percent rejections against a cluster mean of 10 percent on the same destination-bank mix is a rejection-trap candidate. The cause is usually one of three: a stricter destination-bank acceptance check on that sponsor's mandate-creation messaging, an operational delay in the sponsor's daily file submission missing the destination cut-off, or a higher rate of legacy paper-mandate conversions that fail signature validation. The reconciliation surfaces the pattern, the procurement team raises it with the aggregator, and a sponsor-bank re-routing decision becomes evidence-based.

The headline ₹15 plus GST is the visible cost. The hidden cost is the working-capital impact of the delayed collection. An NBFC with a ₹1,200 average EMI ticket and a 7-day average delay between the first failed debit and the eventual successful retry holds the receivable on book for those 7 days at the marginal cost of funds. Across 4,560 first-cycle failures with an average ₹1,200 ticket and a 9 percent annualised marginal cost, the daily carry-cost on the rejected receivables runs roughly ₹13,500 per day, and across a 7-day average delay the monthly delay-cost lands around ₹2.34 lakh. That is more than double the rejection fee itself. The full annual eNACH cost picture for the 38,000-mandate book is around ₹41.5 lakh — rejection fees, retry-cycle fees, and delay-cost combined — against a headline rejection-fee bill that on its own would have looked like ₹13 lakh.

A flat 2% is a problem of structure, not of contract breach. Bank-account UPI carries zero network MDR by statute; RuPay debit is zero; Visa/Mastercard debit is capped at 0.40% to 0.90% by the RBI 2017 circular; Visa/Mastercard credit runs 1.4% to 2.5% negotiated; Amex and Diners sit at 2.95% to 3.5%. When the bulk of your method mix is bank-account UPI, a flat 2% is several multiples of the method-mix-weighted true cost. The gateway is not breaching contract; the contract architecture pre-dates the UPI-dominated method mix you actually have today. The remediation is to renegotiate to a per-network rate card or an interchange-plus structure where each cell is priced separately.

Network MDR is the regulated or contracted instrument cost — zero on bank-account UPI and RuPay debit by statute, capped on Visa/Mastercard debit by the RBI 2017 circular, and negotiated on credit cards and premium networks. Gateway platform fee is the payment aggregator's charge to the merchant for routing, dashboard, settlement, and risk services. On a UPI bank-account transaction the network MDR is zero, but a positive platform fee is legitimate. The method-mix-weighted expected cost in this article uses contracted-rate proxies that bundle both components for compactness, and the recovery quantum from the worked example must be parsed back into the platform-fee portion (renegotiable to a sub-cell rate) and the network-MDR portion (which is zero by statute on UPI bank-account). Pattern #1 of the merchant-fee leakage taxonomy addresses the network-MDR labelling specifically.

Method-mix-weighted expected cost is the dot product of (a) the percentage share of each instrument and network in the merchant's transaction mix and (b) the contracted or regulated rate for that instrument and network cell. For an OTT subscription business with 80% of its volume on UPI-family rails (bank-account UPI, RuPay credit on UPI, PPI on UPI) and 20% on cards, the weighted cost is dominated by the near-zero UPI cells and is dramatically lower than a flat 2% applied across the whole mix. The gap between the flat rate billed and the weighted expected cost is the apparent over-recovery, parsed in this article between a platform-fee renegotiation opportunity and a network-MDR leakage on the zero-MDR cells.

It applies, but the magnitude is much smaller. If the method mix is 60% credit Visa/Mastercard, 20% debit, 15% UPI bank-account, and 5% Amex/Diners, the method-mix-weighted expected cost computed at standard slabs sits closer to 1.5% to 1.7%, which is much closer to a 2% flat rate. The pattern still surfaces a renegotiation opportunity (an interchange-plus structure typically prices a card-heavy book at 1.4% to 1.6% for crore-scale monthly volume), but the apparent gap is not the order-of-magnitude gap that a UPI-heavy OTT business sees. The decision rule is the same: build the method-mix-weighted model, compare it to the flat rate, and price each cell to its contracted rate.

The TDS overlay is a separate reconciliation line and does not change the MDR economics. Under the Income-tax Act 2025 framework live since 1 April 2026, where the merchant is an e-commerce participant selling through a third-party operator the operator deducts 0.1% on gross transaction value under Section 393(1) Sl. 8(v) payment code 1035 (this is the legacy 194O rate carried forward from October 2024; the older 1% rate is pre-October 2024 and should not appear in current reconciliations). 5% applies under the PAN/Aadhaar default rule. None of this changes the per-network MDR or the method-mix-weighted cost. The three lines — gross with code 1035 deduction where applicable, MDR/platform fee with 18% GST as a separate line, and net settlement credit — are kept strictly separate in the reconciliation.

Indian payment aggregators publish international Visa and Mastercard MDR in a 2.69 to 3.5 percent band before forex. Cashfree quotes 2.99 percent as its standard international card rate, with a 2.69 percent promotional band applicable up to ₹10 lakh of international GTV per merchant per month and 2.99 percent on overflow above that cap. Razorpay and PayU both publish a flat 3 percent for international cards. American Express issued abroad sits at the top of the band — 2.95 percent and above, and Cashfree explicitly excludes Amex-abroad from the international promo. The spread reflects scheme cross-border assessment fees, issuer reimbursement fees, and the acquirer's currency-handling overhead, all of which are absent on a domestic transaction. For a finance team, the working assumption is that the international cell is roughly twice the domestic blended rate before forex even enters the calculation.

Forex conversion is charged separately from MDR on every gateway studied. The published international MDR — 2.69 percent, 2.99 percent, 3 percent — covers the per-transaction merchant discount only. When a cardholder transacts in a currency other than INR and the merchant receives settlement in INR, a forex conversion margin of roughly 1 to 1.5 percent is layered on top of the published MDR. The exact spread is set by the acquiring bank against the relevant scheme reference rate, not by the payment aggregator. Reconciliation discipline keeps forex conversion as a separate column on the settlement file — folding it into the MDR percentage destroys the audit trail and makes the international card book look more expensive at the gateway level than it actually is, which in turn makes renegotiation conversations harder. The all-in cost on a non-INR international card transaction is therefore the published MDR plus 1 to 1.5 percent forex plus 18 percent GST on the MDR.

Cashfree's 2.69 percent international card rate is a promotional band that applies only up to ₹10 lakh of international GTV per merchant per calendar month. International GTV above ₹10 lakh in the same month reverts to the 2.99 percent standard rate for that overflow volume. The threshold is computed on international Visa and Mastercard volume only — domestic volume and Amex volume are tracked separately. A merchant whose international book sits at ₹8 lakh per month will pay 2.69 percent on the entire monthly volume; a merchant whose international book runs at ₹2 crore per month will pay 2.69 percent on the first ₹10 lakh and 2.99 percent on the remaining ₹1.9 crore. The threshold resets each calendar month. Finance teams should monitor a running international GTV ledger inside the month, not wait for month-end exports, because the rate inflection happens silently the moment the cumulative ₹10 lakh line is crossed.

GST at 18 percent applies on the MDR fee only, never on the gross transaction value, and never on the forex conversion charge if the acquiring bank issues it as a separate non-GST line. A ₹50,000 international card transaction at 2.99 percent MDR attracts ₹1,495 of MDR and ₹269.10 of GST on that MDR, for a fee deduction of ₹1,764.10 before any forex margin. The payment aggregator issues a monthly GST invoice to the merchant's registered GSTIN; that invoice line must reconcile to the GST-on-MDR amounts shown in the settlement export for the same period. GST-registered merchants can claim input tax credit on the GST-on-MDR amount after matching the gateway invoice in GSTR-2B. Forex conversion charges levied by the acquiring bank typically carry their own tax treatment — generally GST applies on the bank's currency-conversion service fee but not on the underlying margin. Reconciliation keeps gateway MDR, GST on MDR, forex conversion, and any acquirer-bank forex GST as four separate columns.

The reconciliation is a four-layer join. Layer one matches the gateway settlement file to the order management system on payment_id and order_id, capturing gross amount in the foreign currency where applicable, the INR settlement amount, the MDR line, the GST-on-MDR line, and any forex margin reported by the gateway. Layer two segregates international transactions from domestic by issuer-country BIN — never trust a transaction labelled domestic if the BIN resolves to a foreign country and never accept an international charge on a BIN that resolves to India. Layer three checks the per-transaction MDR against the expected slab: for a Cashfree merchant under the 2.69 percent promo, the cumulative international GTV running tally determines whether each transaction sits in the promo band or the overflow band. Layer four validates that any refunded international transaction has the MDR retained as a non-recoverable cost — international MDR is not reversed on refund any more than domestic MDR is, and on a high-refund travel or hotel book that retained cost is one of the larger leakage cells. The output is a per-merchant monthly effective international rate computed as total international fees plus GST plus forex divided by international GTV in INR.

Juspay is neither — it is a payment ORCHESTRATION layer that sits between the merchant's checkout and one or more underlying payment aggregators (such as Razorpay, PayU, Cashfree, BillDesk). Juspay routes each transaction to a chosen rail, retries on failure, and exposes a single integration. The actual money movement and RBI-regulated aggregator licence sits with the underlying PA. Juspay does not collect a percentage MDR; the underlying gateway's MDR still applies on every transaction.

Juspay's pricing is custom and quote-only. Industry-reported figures place the per-transaction SaaS routing fee at approximately ₹0.50 to ₹1.50 per transaction for enterprise merchants, with an annual maintenance contract on top. No public per-instrument rate card exists. This is a fixed per-transaction fee — not a percentage of GMV — and it does not replace the underlying gateway's MDR, which is still billed on the same transaction by Razorpay, PayU, Cashfree, or whichever PA Juspay routed the transaction through.

Carry Juspay fees in a separate ledger line from instrument MDR. The settlement file from the underlying gateway already deducts MDR plus GST on MDR. Juspay's invoice — typically monthly — separately bills its per-transaction routing fee plus AMC plus 18% GST on its own fee. Do not net Juspay's fee against gateway MDR or treat it as an MDR component; that would double-count the cost and break the per-instrument effective-rate calculation. Reconcile each as its own settlement line, then build a combined cost-per-transaction view for management reporting.

Savings come from ROUTING — directing transactions to the cheapest viable rail per instrument and per acquirer — not from Juspay being a cheaper gateway. For example, routing a UPI mix to a gateway with a lower published UPI platform fee, or routing card volume between two acquirers based on contracted rates and success rates. A merchant who moves blended cost from a single-gateway 2 percent rate to a routed mix of 1.8 percent on cards and 1.6 percent on UPI is saving on rail selection, not on Juspay's per-transaction fee — which is an additional cost layer.

Indirectly, yes — by giving the merchant leverage to negotiate harder with each underlying PA and by routing volume to whichever acquirer offers the best contracted rate per instrument. Juspay itself does not set the gateway MDR; it only chooses which gateway processes each transaction. A multi-gateway merchant on Juspay with crore-scale monthly GMV typically negotiates enterprise rates with each PA (often 1.4 to 1.6 percent on cards) and then uses Juspay to direct traffic. The MDR reduction comes from the negotiation and the routing decision — Juspay enables both, but does not bill it as an MDR discount.

Yes. UPI P2M settled directly from a payer's bank account remains zero network MDR under Section 10A of the Payment & Settlement Systems Act 2007 and Section 269SU of the Income-tax Act 1961 read with Rule 119AA — the regime has been continuous since 1 January 2020 and Budget 2026-27 has allocated Rs 2,000 crore to sustain the incentive scheme. The Parliamentary Standing Committee on Finance tabled a report on 12 March 2026 and the Payments Council of India have proposed a tiered MDR for large merchants (PCI proposed 0.30% above Rs 20 lakh turnover), but no binding RBI or CBDT notification has been issued as of 23 June 2026. Treat zero-MDR as current law while monitoring for any 2026 notification.

Network MDR is the regulated or contracted instrument cost — for UPI bank account and RuPay debit it is zero by statute. The gateway platform fee is what the payment aggregator charges the merchant for routing, reconciliation, dashboard, and risk services. Headline 1.95%-2% gateway pricing on UPI is a platform fee, not MDR. The leakage is when the settlement report labels that line 'MDR' (creating an audit confusion), when the platform fee is billed at the card-grade rate instead of the contracted UPI-specific rate, or when both an MDR line and a platform-fee line are deducted on the same UPI transaction.

No. The zero-MDR mandate covers bank-account UPI (P2M) and RuPay debit (P2M). RuPay credit card on UPI is a separate instrument: zero interchange at or below Rs 2,000 per transaction, approximately 2% above Rs 2,000 (split roughly 1.5% issuer / 0.5% network and acquirer) per the NPCI circular operative since October 2022. PPI and wallet-on-UPI also carry interchange of 0.5% to 1.1% above Rs 2,000. Many settlement files lump these high-cost cells under 'UPI' — a structural source of confusion that the per-instrument decomposition flagged in this pattern is built to expose.

Build a per-network effective rate (fees divided by network volume) over a settlement period and tie it back to your master service agreement. If the contracted UPI platform fee is 0.6% but the effective rate billed is 2%, the gap times your UPI volume is the disputable leakage. For each transaction reclassify the line: zero network MDR is statutory, any positive 'MDR' line on UPI bank-account or RuPay debit is incorrect labelling, and any platform-fee line above the contracted percentage is a billing exception. Present this as a transaction-level exception report to the gateway's account manager, escalate to relationship leadership if unresolved, and reference the NPCI zero-MDR public position and the Income-tax Act Section 269SU language.

The Income-tax Act 2025 framework live since 1 April 2026 replaces legacy Section 194O with Section 393(1) Sl. 8(v) using payment code 1035 at 0.1% for the e-commerce operator scenario. This is the TDS the operator deducts on payments to the e-commerce participant on gross transaction value, not on the MDR or platform fee. It is distinct from the zero-MDR question. The merchant still owns three separate reconciliation lines per UPI transaction: gross sale (with code 1035 at 0.1% deducted by the operator where applicable), platform fee (with 18% GST as a separate line), and the net credit to bank. None of these introduces any network MDR on a bank-account UPI debit.

The published merchant agreements of Razorpay, PayU, Cashfree, PhonePe, Paytm and BillDesk all carry the same clause: MDR is earned on authorisation of the transaction and is non-refundable on subsequent reversal. The economic basis is that the interchange the gateway pays to the issuer bank (the largest sub-component of MDR) is itself not reversed by the network on a refund — the issuer keeps the interchange, the network keeps the scheme fee, the acquirer keeps the acquirer margin, and the gateway therefore cannot reverse the merchant-facing MDR without absorbing the loss itself. Some gateways now offer a partial refund-MDR rebate on enterprise contracts, but the default is zero reversal.

Yes — they are two separate losses on the same transaction. (1) The MDR on the original sale stays with the gateway. (2) A chargeback dispute fee is levied per dispute regardless of whether the merchant wins or loses the dispute; published rates across major Indian gateways sit in the ₹200 to ₹750 band, with international card chargebacks at the upper end. (3) If the merchant loses the chargeback, the transaction value is debited from the next settlement on top. The dispute fee is the predictable, recurring leakage line; the transaction loss is event-driven.

The GST follows the underlying fee. Because the MDR is not reversed, the 18 percent GST on that MDR is also not reversed — the gateway has already paid the GST to the exchequer and the merchant has already claimed ITC against it. On the refunded order the merchant has lost the MDR and absorbed the GST as a sunk cost, even though the original sale itself is reversed and the merchant must refund the GST collected from the customer separately. This GST-on-fee asymmetry is a meaningful component of the leakage on a high-refund-rate business and is rarely modelled.

Each refunded month carries the original MDR loss. A subscriber who joins, pays four monthly cycles, and refunds the fifth has had MDR deducted on all five charges; the refund reverses only the fifth charge to the customer but leaves the merchant with the fifth-month MDR loss on a transaction that yielded zero revenue. On a steady-state subscriber base with 6 percent monthly churn-with-refund, the merchant pays MDR on roughly 6 percent of GMV that produced no realised revenue every month, indefinitely. The annualised drag is meaningfully larger than a one-time refund analysis suggests.

A refund-MDR retention flag is enabled at the gateway-rule level so every refund event is reconciled against the originating sale's MDR line. The reconciliation produces a monthly REFUND_MDR_LOSS variance that aggregates by gateway, network, instrument and SKU. Chargebacks are reconciled separately: a CHARGEBACK_DISPUTE_FEE variance tracks the per-dispute fee against the contracted rate card, and a CHARGEBACK_TXN_LOSS variance tracks the debited transaction value. The three lines together produce the audit-ready refund-and-dispute cost dashboard the CFO can table at the monthly close.

No. Net banking MDR is not subject to a regulatory cap. The Reserve Bank of India's 2017 circular DPSS.CO.PD No.1633/02.14.003/2017-18 capped non-RuPay debit card MDR at 0.40% for small merchants (turnover up to ₹20 lakh) and 0.90% for other merchants, with per-transaction caps of ₹200 and ₹1,000 respectively. The zero-MDR mandate of January 2020 (under Income-tax Act §269SU read with Section 10A of the Payment and Settlement Systems Act 2007) covers UPI bank-account P2M and RuPay debit. Neither regime touches net banking. The fee that lands on a merchant's net banking line is therefore the bilaterally contracted rate between the merchant and the payment aggregator, and the choice between a flat fee and a percentage is itself a negotiation variable. A controller pricing net banking should treat the published 1.95% to 2% headline as the starting position, not the floor.

The break-even ticket size is the point at which the flat fee per transaction equals the percentage applied to that ticket. For a ₹12 flat fee at 1.8%, the break-even is ₹12 divided by 0.018, which is ₹666.67. Below that ticket size, the percentage produces a smaller per-transaction cost; above it, the flat fee does. For ₹10 flat at 2%, the break-even is ₹500; for ₹20 flat at 2%, it is ₹1,000; for ₹7 flat at 1.8%, it is ₹388.89. The practical range to remember for negotiated net banking in 2026 is ₹500 to ₹700 — most merchant ticket distributions fall on one side of that band clearly enough that the dominant structure is obvious once it is computed.

GST at 18% applies on the MDR or platform fee itself, never on the transaction value. The gateway issues a consolidated monthly tax invoice that totals MDR, platform fees, and any subscription or AutoPay add-ons, and applies one 18% GST line on the sum. A merchant whose net banking line is ₹1 crore in a month pays ₹18 lakh as GST on that line, claimed back as Input Tax Credit in GSTR-3B against GSTR-2B presence in the same period. The reconciliation engine should never fold the 18% into the per-transaction percentage or the flat fee — the 18% is recoverable and folding it into the unit cost overstates the cost of payments by roughly one-fifth. GST law on payment fees is unchanged; only the underlying MDR structure is negotiable.

A flat-fee net banking line shows the same rupee deduction per transaction regardless of ticket — every transaction in a given bank corridor reads ₹12 or ₹15 against the gross. A percentage line shows a deduction that scales linearly with the gross, with the same percentage applied per transaction in that corridor. The two are easy to distinguish on a sample of ten transactions of widely different ticket sizes. The leakage flag in either structure is the same: any deduction that does not match the contracted line. A merchant on a flat ₹12 net banking contract who sees a ₹150 deduction on a ₹7,500 transaction is paying 2% under what looks like flat-fee pricing — the gateway has billed percentage where flat was contracted, and that is recoverable. The reverse — flat where percentage was contracted, on a low-ticket cohort — is over-recovery for the merchant and under-recovery for the gateway, and is usually corrected in the gateway's favour at the next reconciliation cycle.

It can. The acquirer-side cost of net banking varies modestly by bank — public-sector bank corridors and some mid-sized private bank corridors are routinely cheaper to acquire than the largest private bank corridors, and the gateway's blended net banking rate is a weighted average of those corridor costs. A merchant whose customer base is heavily concentrated in one or two bank corridors can therefore negotiate a corridor-specific rate that is materially better than the gateway's headline blended net banking rate. The reconciliation engine should carry the bank corridor as a column on every net banking transaction and the expected-rate table should be keyed on the corridor where corridor-specific rates have been contracted, so that mis-routing between corridors at the gateway end can be detected at variance.

The monthly close runs seven steps in roughly three hours of analyst time on a ₹15 crore GMV book. Step one ingests the per-transaction settlement export from each payment aggregator into a single keyed file. Step two classifies every line by instrument, network, scope, and product flag — UPI bank-account, RuPay credit on UPI, PPI on UPI, Visa or Mastercard consumer credit, Amex, Diners, corporate, international, EMI, net banking, wallet. Step three computes a per-network effective rate by dividing the actual fee column by the network volume. Step four compares each per-network effective rate to the contracted slab, not the published headline. Step five flags the eight known leakage patterns. Step six produces the dispute and recovery pack. Step seven assembles the one-page board view. The first month takes longer because the classification and contract-rate tables have to be built, but a stable book settles into three hours by month three.

The published headline is a discoverability artefact aimed at sub-five-lakh-monthly merchants. A serious OTT or SaaS business processing ₹10 crore plus monthly is on negotiated enterprise pricing, commonly 1.4 to 1.6 percent on cards, sometimes lower on UPI platform fee, with specific addenda for premium and international cells. Reconciling against the published two percent under-detects leakage because it accepts a rate the contract no longer requires. The correct baseline is the live merchant-agreement schedule per instrument per network, refreshed each time the gateway updates a slab or a product is enabled. The seven-step playbook anchors every effective-rate comparison to that contracted baseline.

A single blended number conceals that bank-account UPI is zero network MDR while Amex is around three percent. A UPI-heavy OTT merchant on a flat blended rate overpays relative to a method-mix-weighted true cost. Per-network effective rate is fees divided by that network's volume in the period — UPI fees over UPI volume, Amex fees over Amex volume, RuPay credit on UPI fees over RuPay credit on UPI volume. Compared against the contracted slab for that network, the gap is the leakage. The discipline also separates legitimate gateway platform fee from network MDR, because a one to two percent platform fee on a UPI bank-account transaction is contractually billable while a network MDR line on the same transaction is not.

One — non-zero network MDR on bank-account UPI or RuPay debit, mandated zero by statute. Two — premium, rewards, signature, or infinite cards billed against a non-qualified surcharge or routed into the three-percent premium slab without the contracted basis. Three — domestic-BIN transactions billed at international rates or with forex layered on top. Four — commercial and corporate cards billed at the consumer rate or, more often, consumer cards routed into the three-percent commercial slab. Five — Amex and Diners cost hidden inside a blended flat rate. Six — flat-rate pricing concealing per-network cost differences for a UPI-heavy mix. Seven — MDR retained on refunds and chargebacks, with dispute fees stacked on top. Eight — recurring add-on and eNACH mandate-rejection fees stacked on base MDR without a matching contract line. The monthly playbook checks all eight against the same per-transaction file.

Three monthly reconciliations stacked produce a trend the board can act on. Effective rate per network over time shows whether a contract renegotiation is holding or whether the gateway has reclassified a cell. Recovery realised over recovery identified shows dispute throughput. The eight-pattern flag count over time shows which leakage class is becoming structural — a rising count on pattern five typically means the method mix is shifting toward Amex without a renegotiated rate, while a rising count on pattern eight means the recurring product was enabled on more SKUs than the contract anticipated. The one-page board view lands as a single chart: contracted blended rate, actual effective rate, gap in basis points, gap in rupees, ninety-day trend, and the dispute pipeline.

No. Paytm Payment Gateway is a payment aggregator product — a checkout that accepts cards, UPI, net banking and wallets and settles a net amount via NEFT to the merchant after the cycle. The Paytm wallet is a Prepaid Payment Instrument (PPI) issued by Paytm Payments Bank; when a customer pays a merchant using the wallet on the UPI rail, the transaction routes through NPCI's interoperable-PPI interchange structure (NPCI circular dated 24 March 2023) and carries 1.1% interchange above ₹2,000. From the merchant's GL the two flows look like 'UPI' in the settlement file, but the underlying economics differ: bank-account UPI is zero network MDR, wallet-on-UPI is 1.1%. Without per-instrument tagging, the wallet-on-UPI line silently inflates the merchant's effective rate on 'UPI'.

Paytm PG exposes a settlement report keyed on its internal transaction identifier and the merchant's order reference. For each settled transaction it carries the payment method, the gross amount, the deducted fee (MDR or platform fee per contract wording), the GST on the fee, and the net settlement amount. A settlement batch identifier ties a group of transactions to a single NEFT credit into the merchant's bank account. The disciplined reconciliation join is three-sided — order side (ERP/OMS), settlement side (Paytm PG settlement file), bank side (the merchant's bank statement with the Paytm nodal-account narration and UTR). Where the gross-to-net bridge in the settlement file does not match the rate model, the row is an MDR variance. Where the batch total does not match the bank credit, the variance is an unposted refund, a chargeback, or a timing artefact. Beyond the public field categories above, the precise column header schema should be locked from the merchant's own first exported file rather than assumed.

The premium 3% slab — applied across Indian aggregators to American Express, Diners, corporate and commercial cards, international cards and EMI — appears in the Paytm PG settlement file at the line level on each individual transaction, not as a separate fee bucket. The leakage is not concealment of the rate; it is concealment of mix. A merchant looking at a blended monthly MDR percentage cannot see that Amex volume is being billed at the premium slab while UPI bank-account volume is being billed at the standard slab. Per-network effective-rate reporting — computing fees ÷ network volume for each network — surfaces this immediately. A 3% Amex line on 3% of GMV is a quarter of a percentage point on the blended rate; for a ₹2.8 Cr-a-month merchant that is ₹84,000 of monthly cost that the blended view does not separate.

Because the customer paid using the wallet on the UPI rail. NPCI's interoperable-PPI circular dated 24 March 2023 created the structure where a wallet (PPI) holder can spend at any UPI-accepting merchant via the UPI handle, with the wallet acting as the underlying funding source. From the routing perspective the transaction traverses UPI. From the pricing perspective it carries 1.1% interchange above ₹2,000. The settlement file's 'UPI' label is rail-correct, but it is reconciliation-misleading: the merchant's per-instrument cost model must subdivide 'UPI' into bank-account UPI (0% network MDR), wallet-on-UPI (1.1% above ₹2,000, nil at or below), and where applicable RuPay credit-on-UPI (~2% above ₹2,000) and credit-line-on-UPI. The Paytm settlement file gives the merchant a rail line; the merchant's reconciliation must add an instrument tag.

It is a separate line and it is recovered separately. The MDR is the rate billed per successful transaction at settlement. A chargeback is an issuing-bank-initiated reversal of a disputed transaction; the dispute fee is the network's processing fee for adjudicating the dispute. On Paytm PG, as on every Indian aggregator, the dispute fee is recovered from the merchant's nodal account through an adjustment posting that is visible in the merchant dashboard but does not appear inline against the original settlement row. The risk for the finance team is that, unless the dispute-fee adjustment is parsed and tagged in the bank-statement reconciliation, it appears as an unexplained debit and gets absorbed as a fee variance. Combined with the broader rule that MDR is non-refundable industry-wide on refunds, the two — MDR not reversed on refunds plus the chargeback dispute fee — compound on a high-refund or high-dispute product line every cycle.

The published 2% + GST on PayU's pricing page covers domestic Credit Card, Debit Card, NetBanking, UPI and Wallet — the high-frequency rails for an Indian D2C or subscription merchant. It excludes American Express, Diners Club, all international cards, EMI (debit, credit and cardless), and commercial or corporate-issued cards. Those route to the 3% + GST premium slab as a separate line in the settlement file. The exclusion is footnoted on PayU's pricing page rather than displayed prominently, which is the structural source of confusion for finance teams reconciling for the first time.

International acceptance on PayU is not enabled by default and requires separate approval from a banking partner — typically expressed as a distinct merchant-category onboarding step. Once enabled, international card volume is billed at 3% + GST on the MDR side, with a forex conversion line settled separately for non-INR currencies. The leakage cell here is that international volume sometimes appears in the settlement file without the forex line invoiced cleanly to the merchant's books, or with a domestic-rate label applied to a domestic-issuing BIN that was mis-classified during routing. Reconcile by isolating cross-border transactions on the issuer-country attribute from the card BIN, then verifying the 3% slab applies only to genuinely international issuers.

PayU's pricing page indicates custom rates above approximately Rs 10 lakh per month in gross merchandise value. The negotiated rate is not published — typical achievable rates at scale fall in the 1.4 to 1.7 percent blended band on Cards plus NetBanking plus UPI, but the actual contracted rate depends on method mix, average ticket size, refund ratio and chargeback exposure. Below Rs 10 lakh per month the published 2% applies as the reconciliation baseline; above it, the contracted rate from the signed Merchant Service Agreement is the truth — not the headline.

Commercial card identification on PayU runs on the card BIN. A BIN flagged by the network as commercial, corporate, business or purchasing routes automatically to the 3% + GST slab on the settlement file, regardless of whether the merchant has explicitly contracted to accept commercial cards at that rate. This auto-flag is the leakage exposure — the merchant should reconcile every transaction labelled commercial in the settlement file against the BIN attributes returned by the acquirer to confirm the slab is correct, and should track the share of commercial-card volume month over month, because a sudden increase usually points to a B2B customer cohort that needs to be re-priced in the contract.

Where PayU operates as an e-commerce operator and the merchant is the e-commerce participant — the typical D2C and marketplace pattern — Section 393(1) Sl. 8(v) of the Income-tax Act 2025 (payment code 1035) applies at 0.1% on the gross amount credited or paid, whichever is earlier. This rate has been 0.1% since 1 October 2024, replacing the original 1% rate of the legacy Section 194O regime. The deduction reconciles to the merchant's Form 26AS. GST at 18% on the PayU MDR fee (not the transaction value) is a separate line and is recoverable as input tax credit for registered businesses, subject to GSTR-2B reconciliation against PayU's tax invoice. Keep all three lines — MDR, GST on MDR, and TDS deducted by the operator — as distinct reconciliation columns.

No. As of June 2026 PhonePe publishes only a single Standard Plan blended headline of 1.95% (currently struck-through and shown as 'Free*' under a limited-time launch offer) and an Enterprise tier marked as custom. Per-instrument percentages — credit card vs debit card vs UPI vs net banking vs wallet — are not officially documented on PhonePe's pricing page. Merchants must request the working slab table via the Business Dashboard quote. Per-instrument numbers circulating on third-party comparison blogs are unverified and sometimes conflate PhonePe PG with the PhonePe consumer UPI app; treat them as low-confidence until your own Business Dashboard quote is in writing.

It is a limited-time launch offer, not a permanent rate. The Standard Plan headline of 1.95% sits behind the 'Free*' label, and PhonePe's pricing page positions the offer as time-bound. The reconciliation risk is that the promo lapses without an explicit revert-to-rate clause in the merchant's signed pricing schedule. Finance teams should treat the contracted promo end date and the post-promo revert rate as the single highest-priority document to file with the accounting team — without it, the day the promo ends a merchant processing ₹1.2 Cr a month silently absorbs roughly ₹2.34 lakh of new monthly MDR at the standard 1.95%.

These are two distinct rails and must be reconciled separately. The PhonePe consumer app is a UPI payment application — a customer can pay any merchant directly using their PhonePe handle and the merchant's UPI ID or QR code, settling through the customer's bank account on the NPCI UPI rail at zero network MDR. PhonePe PG (the Payment Gateway product) is an aggregator: it sits between the customer and the merchant, accepts cards, net banking, wallets and UPI through its checkout, deducts a platform/MDR slab, and settles a net amount via NEFT. The same brand appears in both flows, but the GL accounting, the settlement file, and the reconciliation logic are different. A merchant that accepts both should keep direct-collect UPI inflows and PhonePe PG net settlements on separate ledger codes.

Yes, for transactions above ₹2,000. Wallet/PPI-on-UPI carries a 1.1% interchange (NPCI's interoperable wallet circular dated 24 March 2023, effective 1 April 2023) above ₹2,000 and nil at or below ₹2,000. This applies regardless of which gateway routes the transaction. So a merchant accepting wallet-on-UPI through PhonePe PG should expect a 1.1% line on the slice of wallet volume above ₹2,000, separate from the 1.95% Standard Plan blended rate. This is one of the cells most often confused with 'UPI is zero MDR' — bank-account UPI is zero, but wallet-on-UPI is not.

Promo lapse without a renegotiated revert rate. The 'Free*' promo materially understates the long-run MDR baseline, and finance teams that build their unit economics on the promo figure are exposed to a single-step rate jump of ~1.95 percentage points the day the promo ends. The secondary risk is the absent per-instrument rate card: without a written slab table from the Business Dashboard quote, premium cards, Amex/Diners, international cards and EMI cannot be slab-verified against the settlement file. The mitigation is to (a) get the post-promo revert rate in writing now, and (b) request and file the working per-instrument slab table even while the promo runs.

Pine Labs is a POS terminal acquirer for card-present payments at a physical counter — the merchant swipes, dips or taps a card on a Pine Labs terminal in a restaurant, retail store, hotel or quick-service outlet. A payment aggregator like Razorpay or PayU sits in the online checkout flow and processes card-not-present transactions over a web or app surface. The economics are governed by the same RBI debit-card caps and the same Visa, Mastercard, RuPay, American Express and Diners network slabs, but the settlement file structure differs materially. Pine Labs settles per terminal per day to a per-outlet nodal credit, with Terminal ID (TID) as the primary join key; an online aggregator settles per transaction batch (settlement_id) to a single merchant nodal credit. For a multi-outlet operator the Pine Labs reconciliation surface is wider because each outlet is a separate settlement leg.

The Pine Labs terminal MIS report exports per-day settlement for each Terminal ID under the merchant account. Each row corresponds to a single transaction captured at that terminal — the columns that matter for MDR reconciliation are Terminal ID, Transaction Date, Card Number masked, Card Type (Credit, Debit, Prepaid), Card Network (Visa, Mastercard, RuPay, American Express, Diners), Card BIN, Gross Amount, MDR Amount, GST on MDR, and Net Settlement. The per-terminal aggregate rolls up to a per-day settlement batch with a settlement UTR that maps to a NEFT credit on the outlet's nodal bank account. The reconciliation join is two-level: TID plus date plus net amount against the bank credit, then per-transaction Gross minus MDR minus GST equals Net within the TID batch. A multi-outlet merchant with 24 outlets sees 24 separate per-day settlement batches landing as 24 separate nodal credits.

Five leakage cells recur on Pine Labs settlement files. First, a terminal misconfigured to bill debit at the credit slab — a debit transaction silently charged at 1.4 to 2.5 percent rather than the 0.40 or 0.90 percent debit cap. Second, RuPay debit volume billed at the Visa/Mastercard debit slab when the network mandate is zero MDR. Third, a commercial or corporate card billed at the consumer credit rate instead of the 3 percent premium slab (which understates the merchant cost of B2B transactions). Fourth, a domestically issued card billed at the international rate due to BIN misclassification or terminal routing error. Fifth, paper-roll fees, terminal rental, AMC and chargeback dispute fees stacked outside the MDR line that finance teams miss in their cost-of-revenue model. A 24-outlet operator with a single mis-configured terminal can absorb six-figure annual leakage before the variance surfaces on the consolidated P&L.

Pine Labs revenue from a multi-outlet operator comes from three layers. The first is the network MDR billed on each transaction at the contracted slab. The second is a per-terminal rental or AMC paid monthly, which varies by terminal model — counter-top, portable wireless, dynamic-currency-conversion capable, smart-Android — and by the contracted tenure. The third is consumables and incidentals — paper rolls, chargeback dispute fees on disputed transactions, and on rare occasions a transaction processing fee on certain prepaid or fleet-card volumes. Reconciliation discipline keeps the MDR line and the non-MDR lines distinct on the management report. A merchant who folds terminal rental into the MDR line will compute an inflated effective MDR rate that does not reconcile to the network slab, and will miss the negotiation lever on the rental separately from the slab.

Pine Labs operating as a card acquirer in the POS channel is not an e-commerce operator under Section 393(1) Sl. 8(v) — that provision targets digital marketplace and aggregator flows. For most POS merchants Pine Labs settles the net amount directly to the merchant's nodal account without deducting under code 1035, and the merchant accounts for the gross sale and the MDR cost in the normal course. Where Pine Labs invoices the merchant for MDR plus GST on a periodic statement, the GST at 18 percent on the MDR fee (not the transaction value) is recoverable as input tax credit for registered businesses, subject to GSTR-2B reconciliation against the Pine Labs tax invoice. Where the merchant is also an e-commerce participant on a separate aggregator surface — for instance a restaurant chain accepting Pine Labs at the counter and Zomato or Swiggy through delivery aggregators — the Section 393(1) Sl. 8(v) deduction at 0.1 percent applies on the aggregator side, not on the Pine Labs side, and the two reconciliation surfaces are kept distinct in the books.

Only above ₹2,000 per transaction. Under the NPCI 24 March 2023 circular, PPI merchant transactions at or below ₹2,000 carry NIL interchange, and tickets above ₹2,000 carry 0.5% to 1.1% depending on the merchant category. For a D2C cart with an average order value of ₹2,400, almost the entire wallet-on-UPI volume sits above the threshold and is interchange-bearing — for a quick-service restaurant aggregator with an AOV of ₹350, the wallet-on-UPI volume is overwhelmingly below threshold and effectively free of interchange.

The merchant absorbs it. NPCI's circular structures the interchange as an issuer-side fee paid out of the merchant's settlement — the consumer pays nothing additional at checkout. From the merchant's perspective the wallet-on-UPI deduction appears in the gateway settlement file the same way a card MDR deduction would, except that many gateways label it under the parent UPI rail rather than calling it out as a wallet interchange line. That labelling is the most common reason finance teams miss it.

No, the merchant does not pay it. The 15 bps (0.15%) wallet-loading fee on transactions above ₹2,000 introduced in the same NPCI 24 March 2023 circular is borne by the PPI issuer — the wallet operator (Paytm, PhonePe, MobiKwik, Amazon Pay, etc.) pays it to the remitter bank when the wallet is loaded from a bank account. It does not appear in the merchant's settlement file at all. It is worth knowing because internal-audit notes sometimes mis-cite it as a merchant cost — it is not.

The PSP-defined fields differ by gateway but the consistent signal is the payment-instrument sub-type field. Razorpay and PayU settlement APIs expose the wallet identifier (paytm, phonepe, mobikwik, amazonpay, freecharge, etc.) in the instrument-detail payload even when the parent method is UPI. Cashfree and Juspay similarly expose a wallet-on-UPI flag in their settlement webhook. A reconciliation engine should split the UPI bucket into three children — bank-account UPI, RuPay-credit-on-UPI, and wallet-on-UPI — using this sub-type field, and apply the correct interchange schedule per child.

GST at 18% applies on the interchange fee itself (not on the transaction value), the same way it applies on any MDR or platform fee. The gateway issues a monthly tax invoice consolidating MDR, interchange, and platform fees with a single 18% GST line. A GST-registered merchant claims the 18% as Input Tax Credit in GSTR-3B, cross-matched against GSTR-2B for invoice presence. Reconciliation should never fold GST into the interchange percentage — it always sits as a separate line.

Gateways apply card-tier slabs heuristically using the issuer BIN (first 6-8 digits of the card number) plus the network's published product code. When a card BIN matches a signature, infinite, rewards, commercial, corporate, Amex, or Diners product code, the gateway's classifier routes the transaction to the 3% premium slab (which is the published premium rate at Razorpay, PayU, Cashfree, and most gateways) instead of the standard 2% consumer slab. The merchant sees only the deduction in the settlement file — not the BIN, not the product-tier reason, and rarely a per-transaction itemised slab indicator. The mapping is opaque by default.

It is contractually permitted by most gateway agreements — the merchant signs a rate card with separate slabs for consumer credit, premium credit, Amex/Diners, and international cards, and authorises the gateway to apply each slab to qualifying transactions. The lack of per-transaction transparency is not a regulatory breach because credit-card MDR is uncapped under the RBI 2017 circular (which caps only non-RuPay debit at 0.40% / 0.90%). The remedy is contractual: insist on per-transaction BIN and card-tier columns in the settlement file, or run an independent BIN audit on the file you do receive.

The card networks publish BIN-tier mappings on a controlled-circulation basis to acquirers and acquirers' merchants under NDA — Visa's TC33/TC57 schedules, Mastercard's BIN Table, RuPay's bank-product schedule. For an independent merchant audit, you can use either (a) the BIN data your acquirer provides under your gateway agreement (often available on request as a CSV export), or (b) a third-party BIN database that reconstructs the schedule from public card-launch announcements and issuer disclosures. Either way, the audit needs a per-transaction BIN field — most gateways will provide the first six digits on request even when the default settlement file truncates them.

Most large gateways will process retrospective adjustments where the merchant produces BIN-level evidence that the card product was a standard consumer credit card and not a premium / Amex / Diners / commercial product. Recovery is typically credited as a settlement adjustment in the following month's cycle. For a 90-day window the credit covers the misrouted volume × (3% − contracted consumer rate) plus 18% GST on the recovered fee component. Gateways generally will not process recovery beyond 180 days because their own acquirer settlement is closed by then — flag findings within 90 days and dispute on the spot.

Yes — the GST follows the MDR. When the gateway processes a retrospective MDR adjustment, the 18% GST on that adjustment amount is also reversed via a credit note. If you have already claimed ITC on the original (higher) GST line in GSTR-3B, the credit note reduces your ITC in the period in which it is issued — handle it as a normal GSTR-2B reconciliation event. The net economic recovery to the merchant is the gross MDR delta (since GST was ITC-recoverable anyway), but the audit-trail discipline of matching the credit note to the original invoice is what keeps the GSTR-2B clean.

Premium, signature, and infinite are issuer-product tiers within a network. Visa carries the Signature and Infinite tiers (with Privilege and Reserve sub-grades on Infinite), Mastercard carries World and World Elite, RuPay carries Select and Platinum on the credit rail. The defining attribute for MDR is interchange: the issuer funds the rewards programme (airport lounge access, accelerated points on hotels and travel, concierge, complimentary insurance) from interchange revenue, which forces the interchange rate on a premium card materially above the standard consumer rate. The card carries the same Visa or Mastercard logo as a consumer card but a different product code in the issuer's BIN allocation. Indian gateways recognise this differential and either route the entire premium card to the published 3 percent slab or apply a non-qualified surcharge above the contracted consumer rate.

Non-qualified surcharge is the per-transaction uplift the gateway applies above the contracted consumer rate when the card BIN matches a premium product. Instead of pricing the transaction at a clean 3 percent slab, the engine takes the contracted 2 percent consumer rate and adds the interchange differential as a separate surcharge line (often 0.5 to 1 percentage point). The settlement file shows the consumer slab in the rate column and the surcharge in a separate fee column, which makes the leakage harder to spot on a blended effective-rate computation. Routing to the 3 percent slab is the cleaner mechanism — the rate column itself reads 3 percent. Both mechanisms charge approximately the same total fee on a premium card; only the line presentation differs. The audit needs to surface either mechanism with the BIN as the key.

The audit needs three references on every premium-card transaction. First, the BIN-tier classification from the acquirer schedule (HDFC Acquiring, Axis Acquiring, ICICI Acquiring, RBL Bank, Worldline) which is the network-truth source. Second, the gateway's classification field on the settlement file — Razorpay surfaces a card-subtype attribute, PayU exposes card-category, Cashfree exposes card-type-detail. Third, the contracted slab named in the merchant agreement for that BIN tier and network. The audit flags a transaction as misrouted when the gateway classification disagrees with the acquirer schedule, or when the billed rate (rate column plus any non-qualified surcharge line) differs from the contracted slab by more than a 5 basis point band. A consumer Visa BIN billed at 3 percent is the canonical leakage signal.

RuPay credit on UPI carries the NPCI interchange that runs ~2 percent above ₹2,000 and zero at or below ₹2,000 — that is the published network interchange and applies uniformly to RuPay credit regardless of issuer-product tier. RuPay credit on the card rail (not UPI) sits in the gateway's domestic credit slab and is closer to the Visa and Mastercard treatment. Where a RuPay Select or RuPay Platinum credit card carries elevated interchange, gateways may route it to the premium slab using the same BIN-tier classifier they apply to Visa Signature or Mastercard World. The audit logic is identical: derive tier from the BIN, compare to the gateway classification, verify the billed rate against the contracted RuPay credit slab. RuPay corporate credit volume is small but growing and merits the same BIN-tier check applied to Visa and Mastercard commercial cards.

EMI conversions on credit cards are priced as a separate slab in every gateway rate card we have audited. Cashfree publishes credit-card EMI at platform fee plus 0.25 percent, debit-card EMI at 1.5 percent, cardless EMI at 1.9 percent. Razorpay applies a 3 percent slab on EMI across the board. When a premium card runs an EMI conversion, the audit needs to verify two stacked references: that the EMI slab is applied at the contracted EMI rate, and that the premium-tier classifier does not also stack a non-qualified surcharge above the EMI slab. Stacking the two creates a 3.5 to 4 percent effective rate on a transaction the merchant believed was priced at the contracted EMI slab. Hotels, airline OTAs, and high-ticket retail with material EMI volume on premium cards are the merchants exposed to this stacking pattern.

A domestic prepaid card issued by an Indian bank or PPI issuer and processed through a payment aggregator like Cashfree, Razorpay or PayU is billed at the same standard domestic card slab as a Visa, Mastercard or RuPay credit or debit card under the gateway's blended rate. Cashfree's published pricing page explicitly includes domestic prepaid cards in the same 1.95% standard rate and 1.6% 10-year-anniversary promo as UPI, domestic credit and debit, NetBanking, and wallets. Razorpay and PayU bill all domestic standard methods at 2% plus GST. None of these gateways publish a separate per-instrument percentage for prepaid card — it lands in the standard bucket. The leakage risk is not the slab itself but mis-classification into PPI/wallet, which carries a different schedule.

A prepaid card here means a card-form-factor instrument carrying a Visa, Mastercard or RuPay BIN that is processed over the card networks at checkout — a corporate prepaid card, a gift card, a forex prepaid card, or a co-branded prepaid card issued by an Indian bank. A PPI or wallet means a prepaid payment instrument like Paytm, PhonePe wallet, MobiKwik, Amazon Pay or Freecharge, processed either through the wallet rail or through UPI under the NPCI 24 March 2023 wallet-interoperability circular. The cost schedule is different. A prepaid card rides the gateway's domestic card slab. A PPI on UPI carries 0.5% to 1.1% interchange above ₹2,000 and nil at or below ₹2,000. A wallet processed off UPI carries the gateway's wallet rate. Conflating them in the settlement file pushes cost into the wrong bucket and breaks both reconciliation and renegotiation.

Two reasons recur. First, the gateway's instrument taxonomy collapses card-form-factor prepaid and non-card PPI into a single parent label because both technically meet the regulatory definition of a prepaid payment instrument. Second, when a domestic prepaid card is used inside a wallet or super-app checkout flow, the gateway may receive the wallet identifier from the upstream PSP rather than the card BIN, and default-classify the transaction as PPI/wallet even though the underlying instrument was a card. Finance teams cannot rely on the parent rail label alone. The BIN, the network code, and the instrument sub-type field together identify whether the transaction belongs in the domestic card slab or the PPI interchange schedule.

GST at 18% applies to the MDR fee, not to the transaction value, and applies the same way whether the instrument is classified as a domestic prepaid card or as a PPI. A ₹6,000 transaction at 1.95% MDR attracts ₹117 of MDR plus ₹21.06 of GST on that MDR. The gateway issues a monthly GST invoice for the registered GSTIN and the GST-on-MDR amounts in the settlement report must reconcile to that invoice line for the corresponding period. GST-registered merchants claim input tax credit on this amount after matching the invoice in GSTR-2B. Reconciliation discipline keeps the gross transaction value, the MDR, the GST on MDR, refund value, and reversal entries as separate columns. Collapsing any of them into a single deduction figure breaks the GSTR-2B claim trail and the audit trail for the controller.

Mis-classification at the gateway level. A domestic prepaid card billed at the standard card slab is a known and contracted cost. A domestic prepaid card billed under the PPI/wallet schedule produces a deduction that does not match the contracted card slab and, depending on ticket size and rail, may either over- or under-recover relative to the contract. The merchant has no defensible audit trail in either direction. The second risk is a prepaid card transaction processed at the international slab because the BIN was treated as foreign-issued or routed through an international acquirer flow — that introduces a 2.69% to 2.99% rate plus forex assessment on what should be a domestic-slab transaction. Both risks require BIN-level reconciliation against the contracted instrument schedule, not against the gateway's parent rail label.

The published 2% plus GST applies to domestic standard methods only: Visa and Mastercard consumer credit, RuPay credit, Visa and Mastercard debit, net banking, wallets, and UPI bank-account transactions billed through the platform fee. The 3% plus GST slab applies to American Express, Diners Club, corporate and commercial cards, all international cards, every flavour of EMI including cardless EMI and Pay Later, and any premium rewards or signature card the network reclassifies into the non-qualified tier. International bank transfer is billed at 1% and international wallets at 3.5%. RuPay credit card on UPI has its own 2.15% platform fee line. A merchant reading only the headline 2% loses sight of seven distinct higher-cost cells.

The subscription add-on is a 0.99% per transaction fee that Razorpay stacks on top of the base MDR for any payment captured through the Subscriptions or Recurring product. A standard 2% domestic card recurring debit becomes 2.99% plus GST. A UPI AutoPay recurring debit, even though the underlying UPI bank-account rail carries zero network MDR, can still be billed with the 0.99% subscription add-on plus the gateway's platform fee, so the merchant pays for the subscription rail rather than the payment rail. The leakage pattern is that this add-on is sometimes activated automatically when the Subscriptions module is enabled, without an explicit contractual line item the finance team can point to. Verify it against your signed schedule before treating it as recovered cost.

Premium and corporate cards do not arrive as a separate column. They are settled inside the same fee column as standard credit cards, with the slab driven by the issuing bank's BIN range. The leakage signature is an effective rate on the credit card volume that drifts above the contracted standard rate without any change in customer behaviour. The audit move is to map every settled transaction's BIN to its network and tier, compute fee divided by gross per BIN bucket, and isolate Amex, Diners, corporate, and signature-infinite volumes. If the Amex volume is being billed at the standard 2% the gateway is absorbing the spread today and will reclassify silently tomorrow; if standard consumer cards are being billed at 3% the leakage is already live.

Razorpay does not refund MDR on refunded transactions. The 2% plus GST originally charged on the gross is retained when the order is reversed, so a refund flows back as gross less zero MDR, while the original capture flowed out as gross less MDR. The net effect is the merchant funds the gateway's fee on a transaction that earned no revenue. Chargeback dispute fees are billed separately at ₹200 to ₹750 per case depending on the network and product, and these accumulate even on disputes the merchant wins. The reconciliation discipline is to maintain a register that captures original MDR retained on every refund and every chargeback dispute fee debited, then compare the running total to contract.

Bank-account UPI carries a zero network MDR mandated by the Payment and Settlement Systems Act, so the only line item on a bank-account UPI transaction is Razorpay's platform fee. RuPay credit card on UPI is a different rail: it carries a network MDR of roughly 2% for transactions above ₹2,000, plus a 2.15% Razorpay platform fee line on the same instrument. Both flow through the UPI channel and many gateways display them under a single UPI heading, which is how a UPI-heavy OTT subscription mix can quietly accumulate 2-plus-percent on the credit-on-UPI slice while the finance team believes UPI is free. Separate the two lines in the settlement export before computing any per-instrument effective rate.

Yes. RBI/2017-18/105 dated 6 December 2017, effective 1 January 2018, has not been superseded. The two slabs — 0.40% POS-and-online with a ₹200 per-transaction cap for small merchants (annual turnover up to ₹20 lakh) and 0.90% with a ₹1,000 cap for everyone else; 0.30%/0.80% on QR — remain the regulatory ceiling on non-RuPay debit card MDR in India. The only change since 2018 is that RuPay debit went to zero MDR on 1 January 2020, so the 2017 caps now bind only on Visa, Mastercard, Diners and other non-RuPay debit networks.

No. RuPay debit P2M MDR was set to zero by government mandate effective 1 January 2020 under Section 10A of the Payment and Settlement Systems Act 2007 read with Section 269SU of the Income-tax Act 1961. A RuPay debit card transaction carries zero network MDR regardless of merchant turnover or ticket size. The RBI 2017 cap therefore binds only non-RuPay debit — primarily Visa and Mastercard debit, plus low-volume networks like Diners debit where issued. If your gateway statement shows any non-zero MDR on a RuPay debit transaction, that is a leakage flag — the merchant is not contractually liable for it.

The small-merchant slab — 0.40% POS-and-online with a ₹200 per-transaction cap, 0.30% on QR — applies to merchants with annual turnover up to ₹20 lakh in the previous financial year. The acquiring bank is responsible for classifying the merchant correctly when the MID is onboarded; the merchant should retain the turnover declaration as audit evidence. Most enterprise finance teams reading this article are on the large-merchant slab (0.90%/0.80%/₹1,000 cap) — the small-merchant slab is operationally relevant when reconciling settlements for a subsidiary, kiosk, or franchise outlet that genuinely qualifies.

No. RBI/2017-18/105 explicitly prohibits merchants from passing debit-card MDR through to customers as a surcharge. This is reinforced by Ministry of Finance directions, and earlier RBI guidance from 2013 had already barred surcharging on debit. A merchant who adds a card-handling fee on a debit transaction is in breach. Practically, this means the MDR is a non-recoverable cost line — it must be reconciled and budgeted as merchant cost, not pushed onto the buyer.

Your effective debit-card rate is the volume-weighted blend of (a) zero on the RuPay portion and (b) the contracted Visa/Mastercard rate (typically at or below the 0.90% cap for large merchants) on the non-RuPay portion, adjusted downward where the per-transaction ₹1,000 cap bites on high-ticket transactions. A hotel chain or hospital with a 35–45% RuPay share will see an effective debit rate materially below 0.90% — and that gap is exactly where gateway over-billing tends to hide, because a single blended quote conceals the per-network reality. Compute the effective rate per network monthly and reconcile against the contract.

Base MDR is the contracted rate the payment aggregator charges on the underlying instrument — typically 1.8% to 2.0% blended for cards on a mid-sized B2B SaaS book. The subscription add-on is a separate fee, billed at 0.99% per recurring transaction on Razorpay's published recurring product, that funds the mandate-management infrastructure: token storage, periodic debit triggering, retry cycles, and the dispute desk for recurring failures. The add-on stacks on top of base MDR, so a card transaction routed through a subscription mandate effectively pays 2.79% to 2.99% rather than the 1.8% the merchant negotiated. Most subscription merchants miss this in the contract review because the recurring-product schedule is a separate document from the base MDR rate sheet.

When a subscription merchant triggers a debit against an active eNACH mandate and the debit fails — insufficient balance, account closed, signature mismatch, mandate inactive, technical reject from the destination bank — the sponsor bank passes a return charge through the payment aggregator to the merchant. The published range is around ₹15 plus 18% GST per failed debit, though the exact rupee figure varies by aggregator and bank pair. The reconciliation problem is that retry cycles compound: a 7% mandate-rejection rate on 12,000 active mandates produces 840 first-attempt failures, and a two-cycle retry policy adds roughly another 1,200 failed debits in the same month. The merchant pays the rejection fee on every attempt, not just the first.

Pull the per-transaction settlement file for the recurring channel separately from the one-time channel. For each recurring transaction, compute expected base fee at the contracted card MDR slab and expected recurring add-on at the contracted subscription rate, and compare the sum to the actual fee column. Variances cluster around three patterns: the add-on applied where the contract said it would not apply (one-time card-on-file transactions inadvertently routed through the subscription product), the add-on rate higher than contracted because of an undisclosed schedule update, and the base MDR computed on a higher slab because the recurring instrument was reclassified as premium. The reconciliation surfaces all three. The contract review fixes the rate. The dispute desk recovers the historical variance within the platform window.

A subscription merchant typically configures a retry policy: if a debit fails on the due date, retry on day plus two, retry again on day plus five, and so on for one or two more cycles. Each retry triggers a fresh debit message, and each failed retry incurs the per-debit rejection fee. For a merchant with 7% mandate-rejection rate and a two-cycle retry policy where 60% of the first-cycle failures persist into the second cycle, the effective failure rate paid for is roughly 1.6 times the base rate. The reconciliation discipline is to separate first-attempt rejections from retry rejections, classify both against the published NPCI return reason codes, and decide per code whether retry economics are positive — a return reason code of insufficient balance has different retry economics from a code of mandate inactive.

GST at 18% is charged by the payment aggregator on the fee component, not on the gross transaction value, and it appears as a separate line on the monthly tax invoice. For a B2B SaaS merchant with input tax credit eligibility under Rule 36(4), the GST on MDR, the GST on the recurring add-on, and the GST on the eNACH rejection fee are all claimable. The reconciliation issue is that the per-transaction settlement file books these GST amounts daily while the aggregator's monthly tax invoice consolidates them month-end. If the per-transaction sum does not equal the monthly invoice within a small rounding tolerance, the merchant's GSTR-2B reconciliation will surface a variance that delays ITC claim. The fix is a structured GST reconciliation between the settlement-file GST totals and the aggregator's monthly tax invoice, run before GSTR-3B filing.

No. Bank-account UPI (P2M) carries zero network MDR under the January 2020 mandate rooted in Section 269SU of the Income-tax Act 1961 and Section 10A of the Payment & Settlement Systems Act 2007. RuPay credit card on UPI is a separate sub-instrument: the customer authorises a UPI flow but funds it from a linked RuPay credit card. NPCI's October 2022 circular permitted this rail, and the interchange schedule sets zero interchange at or below ₹2,000 and approximately 2% above ₹2,000 — split roughly 1.5% to the issuing bank and 0.5% to the network and acquirer. The customer is not charged. The merchant bears the full cost. Many gateway dashboards display this volume under a generic "UPI" label, which is the structural source of confusion.

Section 269SU of the Income-tax Act 1961 and Section 10A of the Payment & Settlement Systems Act 2007 jointly prohibit any merchant discount rate or charge on prescribed electronic payment modes. The CBDT notification under Rule 119AA prescribed UPI (bank-account) and RuPay debit as the modes. The effective date was 1 January 2020. Section 271DB of the Income-tax Act adds a ₹5,000-per-day penalty on businesses with turnover above ₹50 crore that fail to offer these modes. *Zero-MDR on UPI P2M is current law as of June 2026 but under active review — the Parliamentary Standing Committee on Finance (report tabled 12 March 2026) and the Payments Council of India have proposed tiered/30 bps MDR for large merchants; no binding RBI/CBDT notification yet.* The ~2% interchange on RuPay credit-on-UPI above ₹2,000 is permitted because RuPay credit is not within the zero-MDR prescription — only RuPay debit is.

Split the daily UPI settlement volume by sub-instrument code. NPCI settlement files and gateway reports carry an instrument-or-MCC-level breakout where RuPay credit-on-UPI appears as a distinct sub-instrument (often labelled CCoUPI, UPI-CC, or with a credit-card scheme tag). Compute the effective rate (total fee divided by gross volume) per sub-instrument. Any positive network MDR on bank-account UPI is a flag for misclassification; any UPI line with effective rate near 2% almost certainly contains RuPay credit-on-UPI volume above ₹2,000. The reconciliation discipline is to never let a single "UPI" bucket carry both zero-MDR and chargeable volume — split the column in the gateway feed mapping before settlement journal entries are posted.

No. NPCI's circular structure places the entire ~2% interchange burden on the merchant. The cardholder sees the standard credit-card transaction reflected on the next statement at face value, with the usual interest-free billing-cycle treatment. The merchant has no contractual basis to surcharge the customer for the choice of funding source on a UPI flow. The economic effect is that for any subscription business with mid-to-high ticket sizes (above ₹2,000), every percentage point of RuPay-credit-on-UPI mix substitutes a zero-MDR rail for a 2% rail, with the cost falling entirely on the merchant P&L.

Where the merchant is an e-commerce participant selling through a third-party operator, the operator deducts TDS at 0.1% on gross under Section 393(1) Sl. 8(v) payment code 1035 (previously Section 194O at 1% pre-October 2024). This is layered on top of, and entirely separate from, gateway MDR and the GST 18% charged on the MDR/platform fee. For reconciliation purposes the three components must sit on three columns: (a) gross to-customer value, (b) instrument-level MDR including the ~2% on RuPay credit-on-UPI above ₹2,000, (c) GST 18% on the MDR/platform fee only — never on transaction value, (d) TDS 0.1% deducted by the operator and traceable to Form 26AS. Folding any of these into a blended "settlement charge" line obscures the leakage and breaks the GST input-tax-credit chain.

Zero. RuPay debit person-to-merchant MDR has been mandated at zero since 1 January 2020. The legal basis is Section 10A of the Payment and Settlement Systems Act, 2007 read with Section 269SU of the Income-tax Act, 1961 and Rule 119AA, which prescribe UPI bank-account P2M and RuPay debit P2M as zero-MDR e-modes. The mandate applies to every RuPay debit P2M transaction regardless of ticket size or merchant turnover. This refers to the network MDR; a payment gateway may still bill a separate platform or technology fee, which is a distinct contracted line and is unaffected by the zero-MDR mandate.

Two things, in order of frequency. First, billing errors — the gateway or acquirer deducts a non-zero MDR on a RuPay debit transaction that should have been zero. This is auditable per-transaction from the settlement file and is recoverable. Second, routing errors — RuPay-issued debit cards that carry a co-badge with Visa or Mastercard are routed through the non-RuPay network at cap-bound MDR (0.40% small merchant or 0.90% other merchant), instead of through the RuPay rail at zero. This is not a billing error but a configuration choice at the acquirer; the merchant can request a change in the routing policy on co-badged cards.

Group every debit transaction in the settlement file by card network — RUPAY, VISA, MASTERCARD — derived from the BIN (first six digits of the card number). For the RuPay group, sum the MDR column. The expected value is zero. Any non-zero amount is a billing error and should be raised with the gateway as a fee-adjustment claim, with the per-transaction exception list as the documented basis. The same per-network slice also gives you the effective rate for Visa and Mastercard debit, which should be at or below the RBI cap (0.40% small merchant, 0.90% other) subject to the per-transaction caps of Rs 200 and Rs 1,000 respectively.

No. A merchant cannot force a customer to use a card they do not hold, and cannot surcharge a non-RuPay debit transaction — RBI explicitly prohibits passing debit-card MDR to the customer. What the merchant can do is BIN-tier routing optimisation: ensure that the payment aggregator and acquirer route co-badged cards (cards that carry both RuPay and Visa or Mastercard logos) through the RuPay rail wherever issuer and acquirer both support it. The customer experience is unchanged; only the network the transaction settles on changes.

No. The zero-MDR mandate covers RuPay debit P2M and UPI bank-account P2M. RuPay credit card on UPI is a separate instrument and carries interchange of roughly 2% on transactions above Rs 2,000 (zero at or below Rs 2,000). This is an NPCI-set interchange, not a zero-MDR instrument, and a common source of merchant confusion because gateway dashboards often surface it under a generic UPI label. Reconciliation should split RuPay debit (zero MDR) from RuPay credit on UPI (about 2% above Rs 2,000) as two distinct lines.

Yes. RuPay debit person-to-merchant (P2M) MDR has been mandated at zero since 1 January 2020, under Section 10A of the Payment and Settlement Systems Act, 2007 read with Section 269SU of the Income-tax Act, 1961. There is no ticket-size threshold and no turnover slab — every RuPay debit P2M transaction is zero network MDR. Note this is the network MDR only; if your payment gateway bills a separate platform/technology fee, that is a distinct line and is unaffected by the zero-MDR mandate.

RBI circular DPSS.CO.PD No.1633/02.14.003/2017-18 caps non-RuPay debit MDR at 0.40% (POS/online) and 0.30% (QR) with a per-transaction cap of Rs 200 for small merchants (annual turnover up to Rs 20 lakh), and 0.90% (POS/online) and 0.80% (QR) with a per-transaction cap of Rs 1,000 for other merchants. The cap is the upper bound — actual contracted rates may be lower. The cap remains current as of June 2026; only non-RuPay debit is subject to it, because RuPay debit is separately mandated at zero.

You cannot force a customer to use a card they do not hold, and you cannot legally surcharge a non-RuPay debit transaction (RBI prohibits passing debit MDR to customers). What you can do is BIN-tier steering — when the gateway presents card options, prefer the RuPay rail for cards whose first six digits indicate a RuPay BIN, and ensure your gateway is configured to route RuPay-issued cards through RuPay rather than co-badging them to Visa or Mastercard. Many issuer banks issue dual-badged cards; the routing choice changes the cost.

Credit-card MDR is uncapped in India and entirely negotiated. Visa/Mastercard credit typically runs 1.4 to 2.5 percent domestic; American Express and Diners are usually billed at a 2.95 to 3.5 percent premium slab; commercial and corporate credit cards are routed to the same approximate 3 percent slab. None of the regulatory caps discussed in this article apply to credit cards — the network differentiation is a debit-only feature.

Pull the settlement file with per-transaction detail (payment instrument, card network, MDR amount). Group by network. Compute the per-network effective rate as total MDR divided by network volume. The RuPay debit bucket should compute to zero MDR; if it shows any non-zero MDR, that is a billing error and recoverable. The Visa and Mastercard debit buckets should compute at or below 0.40% for small merchants or 0.90% for others (POS/online), subject to the Rs 200 / Rs 1,000 per-transaction caps. Anything above the cap, or any non-zero MDR on RuPay, raises a FEE_DEDUCTION exception.

The current rate is 0.1% of the gross amount of sale of goods or provision of services facilitated by the e-commerce operator. The rate was reduced from 1% to 0.1% with effect from 1 October 2024, under the Finance (No. 2) Act, 2024. From 1 October 2020 (when Section 194O first came into force) up to 30 September 2024 the rate was 1%. Under the Income-tax Act 2025 the same obligation is codified as §393(1) Sl. 8(v) at payment code 1035, still at 0.1%. Any operator deduction at 1% on a payment dated on or after 1 October 2024 is incorrect and should be flagged.

Section 194O contains a participant-specific threshold. If the e-commerce participant is a resident Individual or Hindu Undivided Family (HUF), and the gross amount of sales or services through that operator during the financial year does not exceed ₹5,00,000, AND the participant has furnished PAN or Aadhaar to the operator, no TDS is deducted. The threshold does not apply to companies, partnership firms, LLPs, or non-Individual/HUF participants — those entities have TDS deducted on every facilitated rupee from the first transaction. If PAN or Aadhaar is not furnished, the operator must deduct at 5% under what is now §394A of the Income-tax Act 2025 (the legacy §206AA non-PAN floor).

5%. The non-PAN floor under §394A of the Income-tax Act 2025 (legacy §206AA of the Income-tax Act 1961) overrides the 0.1% specified rate whenever the participant has not furnished PAN or Aadhaar to the operator. The 5% floor is unchanged across the rate-reduction history — it was 5% when 194O ran at 1%, it stays 5% now that 194O runs at 0.1%, because §206AA / §394A is a separate non-PAN remedial provision and not a specified-section rate. The threshold exemption for resident Individuals/HUFs up to ₹5,00,000 is also forfeited if PAN/Aadhaar is not furnished — without a PAN, every rupee of facilitated supply attracts the 5% deduction from transaction one.

The operator deposits the 0.1% to the Central Government and files the relevant TDS statement — under the new regime that is Form 168 (the consolidated quarterly TDS statement under the Income-tax Act 2025). The deduction reflects in the participant's Form 26AS view (carried forward into the new Annual Information Statement framework) and is auto-populated in the participant's Income Tax Return as TDS credit available against tax liability. The participant reconciles the operator's deduction certificate (Form 16A under the legacy regime; Form 131 under the Income-tax Act 2025 transition) against Form 26AS / AIS on a quarterly cadence and disputes any mismatch through the operator before filing the return.

On the gross amount. The statute language reads 'gross amount of sale of goods or provision of services facilitated by the e-commerce operator', which is the marketplace gross merchandise value before any deduction for marketplace commission, MDR, platform fees, logistics costs, or buyer refunds. The 0.1% is computed on that gross figure even though the operator's settlement remittance to the participant is net of all those deductions. This often creates a reconciliation mismatch — the participant sees ₹100 of gross sale, ₹15 of marketplace commission, ₹2 of MDR, ₹83 of net settlement, and ₹0.10 of TDS deducted from the gross — and the TDS sits as a separate deduction line on the settlement file. Internal accounting must accrue revenue at gross, expense the marketplace deductions separately, and post the TDS receivable against tax liability.

Any person carrying on business whose total sales, turnover or gross receipts in the immediately preceding previous year exceeded ₹50 crore. The threshold is read against the previous year, so a business that crossed ₹50 crore in FY 2024-25 is in scope for FY 2025-26 even if current-year turnover is lower. The statute applies to companies, LLPs, partnership firms, individuals, HUFs and any other person carrying on business — the form of organisation does not matter. Professionals whose income is purely from a profession (and who do not carry on a separate business) are outside the §269SU mandate and therefore outside §271DB.

Rule 119AA prescribes three electronic modes: debit card powered by RuPay, UPI (BHIM-UPI), and UPI QR code (BHIM-UPI QR). A business in scope must accept all three. 'Failure to provide' means the facility is not available to the customer at the point of sale on any channel through which the business accepts payment — website checkout, mobile app, in-store POS, B2B ordering portal, IVR or call-centre payment link, field collection. CBDT Circular No. 32/2019 clarified that the penalty under §271DB does not apply if the assessee can demonstrate good and sufficient reasons for the failure, but the burden of proof is on the assessee. Documenting acceptance on every channel is the practical evidence requirement.

Section 269SU was inserted by the Finance (No. 2) Act 2019 with effect from 1 November 2019. Rule 119AA, which prescribes the specific e-modes (UPI, BHIM-UPI QR, RuPay debit), was notified on 30 December 2019. CBDT Circular No. 32/2019 of the same date clarified that no penalty under §271DB would be levied if the facilities under §269SU were installed and operational by 31 January 2020. The penalty clock therefore starts on 1 February 2020 for any failure to provide the facility from that date onward — so a gap discovered in 2026 is measured against the date the gap actually opened, not the date it was discovered.

Not automatically. A gateway integration is a necessary but not sufficient condition. The §269SU mandate is that the customer is actually able to pay using UPI bank-account or RuPay debit at the point of sale. If the gateway supports UPI but the merchant has disabled the UPI option at the channel level — common on B2B portals that default to net-banking and RTGS — the facility is not 'provided' to the customer on that channel. A clean audit needs three confirmations per channel: (a) the gateway is configured to accept the prescribed modes, (b) the modes are enabled in the merchant's checkout configuration, and (c) the modes are actually visible and selectable in the customer-facing flow. Screenshots and checkout-flow walkthroughs are the standard evidence.

Section 271DB allows the Joint Commissioner of Income-tax to levy the penalty after giving the assessee a reasonable opportunity of being heard. The statute itself includes a 'good and sufficient reasons' defence — if the assessee can prove a justifiable cause for the failure, the penalty may not be imposed. There is no express compounding mechanism for §271DB in the Income-tax Act, unlike some other penalty sections. In practice, the most defensible posture is preventive: detect the gap on a regular channel audit, document the rectification timeline, and ensure the prescribed modes are restored before the next return-filing cycle. A finance team that can produce a quarterly checkout-audit log is in a substantially stronger position than one relying on a post-facto explanation.

UPI AutoPay is the cheapest recurring rail at the network-MDR layer because the bank-account UPI P2M rail carries zero network MDR by current law — Section 269SU of the Income-tax Act read with Rule 119AA and Section 10A of the Payment and Settlement Systems Act 2007. On a recurring ₹2,499 ticket, the merchant pays no percentage MDR on the underlying debit. The gateway typically charges a small platform fee for running the AutoPay mandate workflow — token storage, mandate-registration messaging, scheduled-debit triggering — which a ₹3 crore monthly book at sub-1% platform-fee rates produces a meaningfully lower stack than the card or eNACH rails. The constraint is that AutoPay mandate amount per debit is capped at ₹15,000 without additional-factor authentication, which is rarely a binding constraint for a B2B SaaS or OTT ticket but matters for higher-ticket NBFC EMI.

On the card-on-file recurring rail, the merchant pays the base card MDR — typically 1.4% to 2.0% depending on the network and whether the rate is published or negotiated — plus a subscription product add-on. Razorpay's published recurring product carries a 0.99% per-recurring-transaction add-on on top of the base MDR, which funds the mandate-management infrastructure: token vaulting, scheduled-debit triggering, retry handling, and the recurring-dispute desk. For a contracted 1.6% base card MDR on a recurring transaction, the all-in network plus add-on is 2.59% before GST. The add-on is published openly on the gateway's recurring-product page so it is not concealed — it is unbundled into a separate rate schedule that the merchant's legal team sometimes does not negotiate with the same intensity as the base merchant agreement.

eNACH is priced per-debit, not as a percentage of ticket value. The published structure is typically around ₹15 plus 18% GST per successful debit and a similar per-failed-debit rejection fee passed through by the sponsor bank. On a ₹2,499 ticket the per-debit fee is a much smaller fraction of the ticket than card MDR. The economics break when the rejection rate is high and retry policy is aggressive. A 7% to 10% first-attempt failure rate is normal on Indian eNACH books, and a two-cycle retry policy means each failed mandate generates one or two additional fee events. The merchant pays the rejection fee on every attempt. For a 12,000-mandate book the eNACH layer can add ₹20,000 to ₹25,000 per month before the recurring add-on or base MDR on the other rails. The classification of failures against NPCI return reason codes is what tunes retry economics.

Network MDR is the merchant-discount-rate charged by the underlying payment network — UPI in this case — to the merchant for using the rail. By current law that figure is zero on bank-account UPI P2M. The gateway platform fee is a separate billed line charged by the payment aggregator for running the merchant-facing workflow: the AutoPay registration interface, mandate-state management, periodic-debit triggering, retry-and-notification handling. The platform fee is a legitimate, contracted gateway charge and is not MDR. The reconciliation discipline is to keep them as separate lines on the merchant's books: the network MDR column should equal zero on every UPI AutoPay transaction, and the gateway platform fee column should equal the contracted rate. Any non-zero network MDR on a UPI AutoPay row is a leakage flag.

The routing mix is a product decision before it is a finance decision. UPI AutoPay is the cheapest rail but the customer has to be willing to authorise a UPI mandate, and not every customer is. Card-on-file is the most familiar rail in B2B SaaS and converts the highest, but it carries the recurring add-on. eNACH is the historical NBFC rail and the most resilient on monthly EMI ticket sizes that exceed AutoPay's ₹15,000 single-debit limit. A common pattern on a ₹2,499 ticket is to default new customers to AutoPay, fall back to card-on-file for customers who prefer card billing, and reserve eNACH for the segment that needs bank-account direct debit. A 60% AutoPay, 30% card, 10% eNACH mix on a ₹3 crore monthly book produces a meaningfully lower total stack than a 100% card book — the finance team's job is to make the routing mix visible in the unit-economics dashboard.

UPI AutoPay carries zero network MDR on the bank-account debit by the same zero-MDR mandate that covers UPI peer-to-merchant transactions (Section 269SU of the Income-tax Act and Section 10A of the Payment and Settlement Systems Act 2007). The gateway typically charges a platform fee on the recurring execution, but that fee is a percentage of a small ticket and is dwarfed by the per-debit absolute fee on eNACH. eNACH passes through a sponsor-bank charge that is around fifteen rupees plus eighteen percent GST per debit attempt, irrespective of ticket size. At a ₹199 ticket, the eNACH fee is roughly nine percent of the ticket. At a ₹2,499 ticket, it is still around seventy basis points. The UPI AutoPay platform fee at the same ticket sizes is materially smaller in absolute and percentage terms. The reliability gap reinforces the cost gap because every eNACH rejection is a fresh fee event.

Under the current NPCI framework, UPI AutoPay mandates execute auto-debits up to ₹15,000 without an additional-factor authentication step at every debit. Above ₹15,000, the customer has to authenticate the debit, which converts the rail from auto-debit to a customer-confirmed debit and breaks the headless recurring economics. For the ₹149-₹2,499 ticket band common in OTT, SaaS and edtech subscriptions, the threshold is not binding and the rail runs cleanly. For high-ticket NBFC EMI rails where the monthly debit exceeds ₹15,000, eNACH is structurally the only no-friction rail today, which is why NBFC mortgage and gold-loan books still default to eNACH while consumer subscriptions migrate to AutoPay.

Build a per-rail unit-economics model with three components: the per-successful-debit cost, the per-failed-debit cost, and the platform fee. For UPI AutoPay, the per-successful-debit cost is the contracted gateway platform fee on the recurring transaction, and the per-failed-debit cost is typically the same platform fee charged on the attempt or a small reduced charge depending on contract. For eNACH, the per-successful-debit cost includes the sponsor-bank pass-through plus the gateway processing charge, and the per-failed-debit cost is the published rejection fee plus GST. Multiply each by the expected success and rejection rates for your customer segment, multiply by the active mandate base, and compare monthly totals. For a consumer subscription book with the ₹149-₹2,499 ticket band, AutoPay almost always wins; for a high-ticket institutional collection book, eNACH wins on absolute cost stability and on the maturity of the dispute framework.

Three structural reasons. First, UPI AutoPay debits are executed through the customer's PSP application, which has a real-time view of the linked-account balance and can reject a debit cleanly before it hits the destination bank, so the merchant sees a deterministic outcome faster. Second, the UPI mandate framework binds the mandate to a UPI handle rather than a specific bank account, and customers more often update the handle than they update an eNACH mandate when they switch banks, which reduces silent mandate decay. Third, the AutoPay user experience on the PSP side has matured around recurring debits at small tickets, with reminders, retry-on-balance prompts, and inline pause-and-resume options that customers actually use. eNACH retries depend on sponsor-bank reachability and the destination-bank technical posture on a fixed window, with much less customer-side recovery affordance.

Run two parallel reconciliation tracks. For UPI AutoPay, reconcile the per-mandate execution file against the gateway settlement file, attribute the platform fee to each debit, and flag any non-zero network-MDR component on the debit line because the network MDR is zero by current law and a non-zero number is leakage. For eNACH, reconcile the per-mandate registry against the settlement file, classify each failed debit against the published NPCI return reason codes, attribute the per-debit rejection fee to the attempt and retry cycle, and total the fee plus GST. Both tracks feed a monthly subscription unit-economics dashboard that splits debits, fees, and success rates by rail. The dashboard is the artefact a CFO can defend; the per-mandate registry is the artefact an auditor can sign off.

No. Bank-account UPI P2M is zero network MDR at every ticket size — ₹49, ₹499, ₹4,999, or ₹49,999 are all charged the same: nothing. The legal basis is Income-tax Act §269SU read with Section 10A of the Payment and Settlement Systems Act 2007, which together prohibit charges on prescribed e-modes including UPI bank-account P2M and RuPay debit. Ticket size only becomes relevant for the adjacent UPI sub-rails — PPI-on-UPI and RuPay-credit-on-UPI — where interchange kicks in above ₹2,000. If your gateway statement shows a positive MDR on a transaction whose instrument sub-type is bank-account UPI, that is a leakage flag and a recoverable charge.

Because the gateway settlement file usually labels three different rails as 'UPI' and the ₹2,000 line separates the free portion from the chargeable portion of the other two. PPI / wallet-on-UPI carries 0.5% to 1.1% interchange above ₹2,000 under the NPCI 24 March 2023 circular; RuPay credit-on-UPI carries around 2% interchange above ₹2,000 (zero at or below). A merchant whose average ticket sits below ₹2,000 — a quick-service food brand, a microtransaction OTT, a UPI-Lite-skewed wallet top-up flow — sees almost no chargeable volume regardless of sub-rail mix. A merchant whose average ticket sits above ₹2,000 — a B2B SaaS, a hotel chain, an NBFC EMI collection — sees the entire PPI and RuPay-credit-on-UPI volume sit above the threshold, and that is where leakage builds.

Split the UPI parent in your settlement file into three children — bank-account UPI, RuPay credit-on-UPI, and PPI / wallet-on-UPI — using the payment-instrument sub-type field that gateways such as Razorpay, PayU, Cashfree, and PhonePe expose alongside the parent method. Any deduction on the bank-account UPI child is by definition a leakage flag and should be raised against the gateway. Deductions on the other two children are legitimate if they sit above ₹2,000 and match the published schedule (1.1% PPI ceiling, ~2% RuPay credit); deductions on the other two children at or below ₹2,000 are also a leakage flag, since both schedules are NIL in that band.

GST at 18% applies on the interchange fee itself, never on the transaction value. The gateway issues a consolidated monthly tax invoice that totals MDR, interchange, platform fees, and any subscription add-ons, and applies a single 18% GST line on the sum of fees. A GST-registered merchant claims that 18% as Input Tax Credit in GSTR-3B, cross-matched against GSTR-2B for invoice presence in the period. Reconciliation should never fold the GST into the interchange percentage line item; the 18% is recoverable as ITC and folding it into the MDR overstates the unit cost. If the gateway tax invoice does not appear in GSTR-2B in the period of recognition, the ITC parks in the open ITC ageing schedule and follow-up with the gateway is the recovery path.

As of June 2026, the zero-MDR regime on UPI P2M is current law and binding. The Parliamentary Standing Committee on Finance, in a report tabled on 12 March 2026, recommended introducing a tiered MDR for large merchants, and the Payments Council of India has separately proposed a 30 bps charge on UPI P2M for merchants with annual turnover above ₹20 lakh. The Department of Financial Services has noted that the current incentive scheme covers only a fraction of the industry cost of running UPI free. Neither RBI nor the Ministry of Finance has issued a binding notification. A controller building a reconciliation policy today should treat zero MDR as the operative rule, but the contracted gateway template should anticipate the schedule changing on a finite notice period and the reconciliation engine should be ready to switch on a UPI-MDR row the day a notification lands.

Yes. The platform fee is the payment aggregator's contractually agreed charge for routing the transaction, providing the merchant dashboard, running risk and fraud checks, delivering settlement files, and supporting refunds and disputes. It is a real service for which a positive charge is legitimate. What is not legitimate is labelling that charge 'MDR' on the settlement file or applying it as if it were a network MDR on a zero-MDR instrument. The reconciliation discipline is to carry the platform fee on its own line at the contracted enterprise rate, with 18% GST as a separate line, and to keep the network-MDR column at zero on bank-account UPI cells.

Historical convention. The pre-2020 industry treated the entire merchant cost as 'merchant discount rate', and most settlement-file schemas inherited the column header even after Section 10A of the Payment & Settlement Systems Act and Section 269SU of the Income-tax Act mandated zero MDR on UPI bank-account and RuPay debit. The column header is not by itself the leakage; the underlying classification is. Audit discipline is to separate network MDR (zero on UPI bank-account) from platform fee (contracted enterprise rate, billed at that rate, GST at 18% on the fee). The dispute language to the gateway must use the right terms — a positive 'platform fee' is defensible, a positive 'network MDR' on UPI bank-account is not.

Yes. GST at 18% applies on the platform fee — that is, on the gateway's charge to the merchant for its services — not on the gross transaction value of the UPI debit itself. The platform fee plus GST is the merchant's deduction from the gross UPI credit; the GST line is claimable as input tax credit subject to the standard conditions under the GST law. The leakage flag here is the file calculating GST on the gross UPI value (a compliance error) or folding the GST into the MDR percentage rather than carrying it as a separate line.

Contracted, every time. The headline 1.95% to 2% blended rate that gateways publish is a small-merchant baseline designed for sub-₹5-lakh-monthly volume; a crore-scale UPI-heavy account is on a negotiated enterprise rate (commonly a fraction of the card-grade percentage on UPI bank-account, often in the 0.4% to 0.8% range for high UPI mix). For reconciliation, the contracted enterprise rate per network is the truth — the published rate is a marketing baseline. Carry the contracted rate on a per-network table separately from any published-rate reference, and reconcile the effective rate (deducted fee divided by network volume) to the contracted rate on every settlement cycle.

Four lines, separated. (1) Gross sale at the transaction value. (2) Network MDR at zero — explicitly captured as zero so the audit trail records the statutory position rather than the absence of a line. (3) Platform fee at the contracted enterprise rate per the master service agreement, with the gateway and the network specified. (4) GST at 18% on the platform fee, not on the gross transaction value, with the input-tax-credit reference. Where the merchant is selling through a third-party operator that deducts TDS, a fifth line captures the operator-deducted amount under the Income-tax Act 2025 framework (Section 393(1) Sl. 8(v) code 1035 at 0.1%, reconciled to Form 26AS). On a direct-checkout UPI sale, lines 1 to 4 are the full set.

Both, working together. The statutory mandate to offer prescribed e-modes comes from Section 269SU of the Income-tax Act 1961 (inserted by Finance (No. 2) Act 2019, effective 1 November 2019) read with Rule 119AA, which prescribes UPI, BHIM-UPI QR and RuPay debit. The prohibition on the bank or the system provider levying MDR on those prescribed modes is anchored in Section 10A of the Payment and Settlement Systems Act 2007, also inserted by the Finance (No. 2) Act 2019. NPCI and acquiring banks then implemented zero interchange from 1 January 2020. So the regime is a Finance-Act-driven mandate that the RBI and NPCI operationalise — not an RBI circular standing alone.

No. Zero-MDR refers specifically to the network MDR — the interchange that would otherwise flow to the issuer bank, network and acquirer. The payment gateway or aggregator (Razorpay, PayU, Cashfree, PhonePe PG, Paytm, BillDesk, Pine Labs and others) still bills the merchant a platform fee for the technology layer, dashboard, settlement automation, refund handling and APIs. Headline platform fees of around 1.95% to 2% on bank-account UPI are common on published rate cards, dropping to roughly 1.4% to 1.6% for negotiated enterprise contracts at ₹1 crore plus monthly GMV. GST at 18% applies on the platform fee.

Three flows fall outside zero-MDR even though they ride the UPI rail. RuPay credit card on UPI: zero interchange up to ₹2,000 per transaction, around 2% above that (about 1.5% issuer plus 0.5% network and acquirer). PPI or wallet on UPI: nil up to ₹2,000, then 0.5% to 1.1% interchange above that — per the NPCI circular dated 24 March 2023 effective 1 April 2023. Credit-line on UPI: priced like a credit product, not a debit instrument. A settlement file that lumps all of these into a single 'UPI' bucket masks real merchant cost — the reconciliation must split them.

It is under active review, but unchanged in law as of June 2026. The Parliamentary Standing Committee on Finance report tabled 12 March 2026 recommended a tiered MDR on larger merchants; the Payments Council of India has separately proposed a regulated 30 basis-point MDR on UPI P2M for merchants with annual turnover above ₹20 lakh. The Department of Financial Services has flagged that the current incentive scheme covers only a fraction of industry costs. No binding RBI or CBDT notification has been issued yet, and the Union Budget FY27 allocation of ₹2,000 crore continues to fund the zero-MDR subsidy. Treat zero-MDR as current law and the most likely structural change in the near term.

Five disciplines. One — confirm the network MDR component on every bank-account UPI and RuPay debit P2M transaction is zero in the settlement file; any non-zero network MDR on these instruments is a hard exception. Two — verify the platform fee charged equals the contracted rate, not the published rate; the gap between 2% headline and 1.5% contracted on ₹3 crore monthly volume is ₹15 lakh a year before GST. Three — confirm the GST line is 18% of the platform fee only, never of transaction value. Four — split any 'UPI' bucket into bank-account, RuPay-credit-on-UPI and PPI-on-UPI before computing effective rate. Five — verify that platform fee on a refunded transaction is reversed where the contract says so, and flagged where it is not.

The small-merchant slab — 0.40% on POS-and-online, 0.30% on QR, with a ₹200 per-transaction cap — applies to merchants whose annual turnover in the previous financial year does not exceed ₹20 lakh. Turnover is computed at the legal-entity level, not per MID, per outlet or per gateway. The acquiring bank is responsible for classifying the merchant when the MID is onboarded and re-validating annually; the merchant should retain the turnover declaration and audited financials as evidence. A single GSTIN crossing ₹20 lakh in any prior year moves the entire entity to the large-merchant slab from the next financial year — there is no per-outlet re-segmentation.

Large merchants — anyone above ₹20 lakh annual turnover — are subject to 0.90% on POS-and-online and 0.80% on QR, with a per-transaction cap of ₹1,000. The cap bites on every transaction whose value would otherwise compute to MDR above ₹1,000. At 0.90% the breakeven ticket is ₹1,11,111 — above that the merchant pays ₹1,000 flat regardless of ticket size. At 0.80% on QR the breakeven is ₹1,25,000. Hotel bills, hospital settlements, jewellery purchases, B2B card payments and luxury retail are the typical sectors where a material slice of transactions sits above the cap, pulling the effective debit rate below the headline 0.90%.

The reverse pattern is more common — a small outlet of a large parent is misclassified at a higher rate. Each acquiring-bank MID is onboarded independently, and a kiosk, franchise or sub-outlet at a major hotel or hospital chain may be classified by the acquirer using the outlet's standalone turnover rather than the parent entity's consolidated number. The merchant nominally entitled to the 0.90%/₹1,000 cap finds the outlet paying 0.95% or a rate above the cap because the slab was set incorrectly at onboarding, or never refreshed when consolidated turnover crossed the threshold. The leakage is small per transaction but compounds across thousands of outlets and many months.

No. RBI/2017-18/105 explicitly prohibits merchants from passing debit-card MDR through to customers, and earlier RBI guidance from 2013 and Ministry of Finance directions reinforce this. The prohibition is absolute — it applies whether the customer is paying at POS, on a website checkout, on a QR code or through a payment link. A merchant that adds a card-handling fee on a debit transaction is in breach and exposes itself to acquirer chargeback, RBI complaint and reputational risk. Treat debit MDR as a non-recoverable cost line — reconcile and budget it as merchant cost, not as a buyer charge.

Build a row-level audit on the settlement file with three columns: transaction value, MDR deducted, and computed expected MDR equal to minimum of (rate times value) and the slab cap. Filter to non-RuPay debit transactions where MDR deducted exceeds expected MDR. Sum the variance by MID and by month. Present the acquirer with the settlement IDs, the cap-breach amount per row, the contracted rate, the slab the merchant qualifies for, and the cumulative recoverable amount. Most acquirers will settle a documented cap-breach claim without protracted dispute because the regulatory rule is unambiguous. The dispute window is typically 90 to 180 days from settlement, so run the audit monthly.

The Reserve Bank of India's 2017 rationalisation circular (RBI/2017-18/105 DPSS.CO.PD No.1633/02.14.003/2017-18, effective 1 January 2018) imposed merchant-discount-rate caps only on non-RuPay debit cards — 0.40 percent for merchants with annual turnover up to ₹20 lakh and 0.90 percent for larger merchants, with per-transaction caps of ₹200 and ₹1,000 respectively. The policy rationale was to push small-ticket debit-card acceptance and to align with the broader zero-MDR objective for RuPay debit. Credit cards were deliberately left outside the cap because the credit product carries a different cost structure — interchange funds the issuer's interest-free period, the rewards programme, and the unsecured-credit risk. The RBI's view, consistent with global precedent, was that competitive negotiation between acquirers and merchants would discipline the rate without regulatory intervention. The practical effect for an Indian merchant in 2026 is that Visa/Mastercard consumer credit MDR is a bilateral negotiation outcome, not a regulated number, and the gap between the published gateway card (around 2 percent) and the enterprise-negotiated card (1.4-1.6 percent) is large enough to fund a meaningful share of contribution margin.

Industry practice in India in 2026 places the threshold at roughly ₹1 crore of monthly processed volume on the network in question. Below ₹1 crore monthly the merchant sits inside the published-rate band — Razorpay 2 percent, PayU 2 percent, Cashfree 1.95 percent standard, PhonePe 1.95 percent blended — because the acquirer has no margin to give up at that volume and no commercial reason to offer custom pricing. Between ₹1 crore and ₹5 crore monthly Visa/Mastercard consumer-credit volume, negotiated rates of 1.55-1.75 percent are typical. Above ₹5 crore monthly, 1.40-1.55 percent is achievable. The threshold is not the merchant's total processed volume across all instruments — it is the specific Visa/Mastercard consumer-credit slice, because that is the slice the negotiation operates on. UPI, RuPay debit and high-cost premium cards do not contribute negotiating leverage on the consumer-credit slab.

Lever one is committed monthly volume — a minimum ₹1 crore monthly Visa/Mastercard consumer-credit floor written into the agreement, below which the rate reverts to a published slab. Lever two is method-mix commitment — a clean instrument shape with low premium-card and low international-card weight, because Amex, Diners, corporate and international all sit at the 3 percent premium slab and dilute the acquirer's effective margin if they ride the same agreement. Lever three is multi-year term — a 24 or 36-month commitment with rate locks tied to performance milestones; the acquirer earns predictable volume in exchange for giving up around 40-60 basis points. Lever four is dispute and chargeback service level — a contractual chargeback ratio ceiling (often 0.9 percent of count, 1.5 percent of value) and a turnaround commitment on representment that gives the acquirer a quality signal. Negotiating one lever in isolation typically moves the rate 10-20 basis points; negotiating all four in combination unlocks the 1.4-1.6 percent band.

Goods and Services Tax is charged at 18 percent on the MDR or platform fee only — never on the transaction value, which is a fundamental distinction the gateway invoice must reflect. A ₹3 crore monthly Visa/Mastercard consumer-credit volume at a negotiated 1.55 percent attracts MDR of ₹4.65 lakh and GST of ₹83,700, for a gross deduction of ₹5.48 lakh against gross settlement of ₹3 crore. The GST is creditable as input tax credit to the merchant against the gateway's monthly tax invoice provided the merchant is registered and the invoice carries the correct GSTIN, place of supply and HSN. Reconciliation discipline keeps MDR and GST on separate columns of the settlement journal — folding GST into a blended deduction percentage breaks the input-tax-credit chain and silently inflates the reported MDR by 18 basis points per percent of MDR. Goods and Services Tax law is unchanged in 2026 — the 18 percent rate on payment-aggregation services has not moved.

Where the merchant is an e-commerce participant selling through a third-party operator, the operator deducts tax at 0.1 percent on the gross amount under Section 393(1) Sl. 8(v) payment code 1035 of the Income-tax Act 2025 (this is the recodification of the legacy Section 194O, with the rate reduced from 1 percent to 0.1 percent effective 1 October 2024). This deduction is layered on top of, and entirely separate from, gateway MDR and the 18 percent GST on the MDR. For a ₹3 crore monthly Visa/Mastercard consumer-credit volume routed through a marketplace acting as the operator, the participant merchant should see four distinct lines on the reconciliation: gross customer value ₹3 crore, MDR at the negotiated 1.55 percent (₹4.65 lakh), GST at 18 percent on the MDR (₹83,700), and TDS at 0.1 percent on the gross (₹30,000) reconciling to Form 26AS. Folding any pair of these into a single deduction percentage destroys the audit trail and triggers downstream notices.

Seven classes show up at every Tier-1 month after month. Class 1 — OEM deducted but not deposited or not filed yet, so the entry hasn't reached Form 168 even though the supplier's invoice ledger shows the deduction. Class 2 — wrong section code, where the OEM has deducted at code 1024 (contractor) when the underlying contract was a goods purchase (code 1031). Class 3 — wrong PAN, where the OEM has used a historical sister-concern PAN or a typo'd PAN. Class 4 — amount difference, where the OEM has deducted on a value that includes GST when the contract specifies pre-GST value, or vice versa. Class 5 — period difference, where the OEM has booked the deduction in a different quarter from the supplier's invoice recognition. Class 6 — Section 393(1) Sl. 8(ii) versus Section 394(1) confusion on transactions that have both purchase and scrap legs (a Tier-1 buying a tool that includes its own scrap-recovery on a coil purchase). Class 7 — timing, where the deduction quarter and the invoice quarter straddle a quarter-end, especially Q4 / Q1 across FY transitions.

Through at least FY 2026-27, an OEM-TAN deductee's Form 168 view will show fresh deductions under codes 1001-1092 alongside legacy 194x entries that are still being corrected, supplemented or revised. The reconciliation register must hold the two lineages on parallel tracks — never netting a legacy 194C deduction against a new code-1024 deduction, even when both relate to the same supplier-OEM pair. The discriminator is the date of credit or payment (whichever is earlier): pre-1-April-2026 sits on legacy 194x lineage and reports on legacy Form 26Q (deductor) / Form 26AS (deductee); post-1-April-2026 sits on new section lineage and reports on Form 131 (deductor) / Form 168 (deductee). The supplier reconciles both monthly during the FY 2026-27 overlap window, with separate dispute-register columns for legacy entries (TRACES corrections under 194x) and new entries (TRACES corrections under 393 / 394 / 413).

Section 393(1) Sl. 8(ii) at payment code 1031 covers buyer-side purchase TDS — a Tier-1 buying steel coils from Tata Steel above ₹50 lakh per FY deducts 0.1% under code 1031. Section 394(1) at payment code 1071 covers seller-side scrap TCS — a Tier-1 selling skeleton scrap to a merchant collects 1% under code 1071. The confusion arises on transactions that carry both legs, especially raw-material purchases where the supplier provides credit for return scrap (the Tata Steel coil contract with a built-in return-scrap clause). On the buyer-side leg the Tier-1 deducts code 1031 TDS; on the return-scrap leg the supplier (now buyer of the scrap) collects code 1071 TCS — two separate flows on what looks like one transaction. The reconciliation register must split the gross transaction into the purchase leg and the scrap leg, and reconcile each to the appropriate Form 168 deductee. Misclassification typically shows up as a single combined entry in the OEM's Form 168 that does not match the Tier-1's books, until the split is identified.

Five-step monthly routine. First, between the 12th and the 15th of every month, download Form 168 from the TRACES portal (and legacy Form 26AS where any FY 2025-26 lineage is still in correction). Second, segregate downloaded entries by deductor TAN — a typical Tier-1 has 4 to 8 OEM TANs and 1 to 3 large customer TANs. Third, match each line against the supplier's books — original invoice number, gross billing, TDS deduction percentage, deducted amount, payment code (1024 for contractor under Section 393(1) Sl. 6(i).D(b), 1031 for purchase under Section 393(1) Sl. 8(ii), 1057 for foreign commission, 1071 for scrap TCS). Fourth, route mismatches into the seven-class dispute register with deductor-side correction action required. Fifth, file a quarterly controller-level reconciliation summary showing matched / mismatched / under-investigation / closed positions per OEM TAN. The discipline tightens during the cross-era window and during Q4 / Q1 transitions where timing-class mismatches spike.

Five-step correction protocol. First, the supplier raises a written dispute with the OEM's tax team referencing the original invoice number, the Form 168 entry that doesn't match, the supplier's books position, and the requested correction (change section code, change deductee PAN, change amount, change period). Second, the supplier provides supporting documentation — the original invoice, the contract reference, the payment advice with the deduction shown. Third, the OEM's tax team files a TRACES correction statement under the appropriate provision (legacy 194x correction for FY 2025-26 entries, new section correction for FY 2026-27 entries). Fourth, the correction reflects in the supplier's Form 168 within 2 to 6 weeks of filing. Fifth, the supplier verifies the correction and closes the dispute register entry. For OEMs that delay correction filings (typical for smaller customers, less common for the major OEMs), the supplier may need to escalate through the commercial-relationship team or, in extreme cases, claim the credit directly in the ITR with an Annexure explaining the deductor-side default.

8D — Eight Disciplines — is a structured problem-solving framework originated at Ford and now codified by the AIAG (Automotive Industry Action Group). The eight disciplines run D0 (plan) through D1 (team formation), D2 (problem description), D3 (containment), D4 (root cause), D5 (corrective action), D6 (implementation), D7 (prevention), D8 (close-out and team recognition). Indian OEMs that mandate 8D for supplier quality investigations include Maruti Suzuki, Tata Motors, Mahindra & Mahindra, Bosch India, ZF India, Cummins India, Ashok Leyland, and most Tier-1 export-oriented suppliers shipping to global OEMs. The framework is the standard, not optional — a failed or absent 8D triggers escalation and typically a warranty back-charge.

D3 (containment) — sorting cost at the OEM plant or at the supplier's expense, often back-charged. D4 (root cause) — engineering investigation cost, ECN (engineering change notice) drafting, validation testing. D5 (corrective action) — tooling modification cost capitalised under Ind AS 16 if it extends asset life, expensed otherwise. D6 (implementation) — production qualification batch cost, scrap during qualification. D7 (prevention) — PPAP (production part approval process) re-submission cost. D8 (close-out) — release of the quality reserve provisioned at problem identification under Ind AS 37. The reconciliation must track all of these against the underlying defect campaign and against the OEM debit-note exposure.

When a defect campaign breaks containment (defective parts reach the OEM line or, worse, the end-customer), the OEM raises a warranty back-charge under the supplier quality agreement. The back-charge covers: (a) the cost of containment and replacement at the OEM line, (b) downstream warranty exposure if defective parts reached customers, and (c) the OEM's investigation overhead. The debit advice is raised against the supplier's next payment; reconciliation must split this into the goods-supply portion (held against future invoices via Section 34 credit note mechanics) and the service portion (warranty-replacement labour, typically treated as a service charge by the OEM and attracting Section 393(1) Sl. 6(i).D(b) TDS at 2% under payment code 1024 — the post-1-April-2026 successor to the retired 194C code).

If the corrective action at D5 requires a physical tooling modification (die-face repair, fixture redesign, additional inspection gauge) that extends the useful life of the asset or measurably improves its function, the cost is capitalised under Ind AS 16 PP&E, added to the carrying amount of the tool, and depreciated over the tool's remaining useful life. If the modification merely restores the tool to its original capability (a like-for-like repair after wear), the cost is expensed in the current period. The reconciliation must classify each D5 corrective action correctly — auditors at the supplier and at the OEM (which often owns the tooling on the supplier's floor) will examine the treatment at year-end. Mis-classification creates restatement risk.

At problem identification — typically D3 containment — the supplier finance team books a quality reserve under Ind AS 37 covering expected sorting, rework, scrap, and OEM debit-note exposure. The reserve is recognised as a present obligation arising from a past event (the defect campaign) with a reliably estimable amount. As the 8D progresses through D4 to D8, actual costs are charged against the reserve. At D8 close-out, when the OEM signs off on the corrective action and prevention measures, any unutilised reserve balance is released to P&L. If the reserve is insufficient, the shortfall is recognised in the period of detection. The 8D close-out date is therefore a financial close event, not just a quality event — it triggers the reserve release entry.

The standard structure is a hub-and-spoke distribution model. The manufacturer holds inventory at 4-8 Master Stocking Locations (MSLs) — typically Mumbai, Delhi-NCR, Bangalore, Chennai, Kolkata, Hyderabad, plus a regional plant. From MSLs, stock moves to a network of authorised distributors (200-500 for a mid-sized Tier-1), each covering a defined geographic territory. Distributors in turn supply a second tier of retailers and mechanic shops. Some manufacturers also run direct online supply via e-commerce platforms (Boodmo, PartsBig, brand portals). The commercial terms shorten as you move down the chain — distributor credit is typically 30-45 days from manufacturer, retailer credit from distributor is 7-15 days or cash.

OEM-fitment supply is priced on a negotiated scheduling-agreement basis — the supplier sells to the OEM at a contracted unit price, typically well below MRP, with the OEM bearing distribution margin. Aftermarket supply is priced as a percentage of MRP — distributor margin (typically 22-35 percent off MRP), retailer margin (typically 18-25 percent), and the consumer pays MRP. The manufacturer's realisation on the same physical part is materially higher in aftermarket than OEM-fitment — a brake pad set selling at ₹950 MRP yields manufacturer realisation of around ₹540-620 in aftermarket versus ₹280-340 in OEM-fitment. This realisation gap funds the channel-discount and warranty-pass-through costs that aftermarket carries.

Section 9(5) of the CGST Act and the corresponding notifications make the e-commerce operator (Amazon, Flipkart, Boodmo etc.) liable to collect and pay GST on certain notified categories of supply where the supplier is unregistered or below threshold. Auto-spares supplied through e-commerce by registered Tier-1 manufacturers are not under the Section 9(5) regime — the manufacturer remains liable for output GST as the supplier. However TCS under Section 52 of the CGST Act applies — the e-commerce operator collects 1 percent (0.5 percent CGST plus 0.5 percent SGST, or 1 percent IGST for inter-state) of the net taxable consideration, which the supplier claims as TCS credit in GSTR-2X reconciliation. Distributor and inter-state stock transfer rules apply on top.

OEM-fitment warranty failures are back-charged to the supplier through the OEM debit-note mechanism — a structured commercial recovery with PPM-penalty overlay. Aftermarket warranty is end-customer claim through the distributor and retailer — the consumer returns a defective part to the retailer, who passes it to the distributor, who passes it to the manufacturer. The manufacturer issues a replacement (free of charge to the channel) and reverses the original sale through a Section 34 credit note within the 30 November cutoff. Volumes are typically lower than OEM-fitment warranty (because aftermarket parts are not always lifecycle-monitored), but the unit cost of each claim is higher because it includes reverse logistics, examination and replacement-part value.

Aftermarket parts have a much longer lifecycle than OEM-fitment supply because end-of-production vehicles continue to need spares for 10-15 years. But slow-moving and obsolete stock builds quickly — a brake-pad SKU for a discontinued passenger-vehicle model can sit at MSLs for years. Standard practice is age-based provisioning: 0-12 months in stock no provision, 12-24 months 25 percent provision, 24-36 months 50 percent provision, beyond 36 months 75-100 percent provision. The provision is reversed when the stock moves at MRP-minus-distributor-margin. Ind AS 2 inventory at lower of cost or net realisable value (NRV) provides the technical anchor; the practical NRV for aged spares is the distributor-discounted clearance price.

Tier-1 auto programmes are governed by long-lived schedule agreements, not transactional POs. The OEM issues rolling delivery schedules (weekly or daily) referenced against a cum-quantity (cumulative quantity) counter, and the supplier dispatches against the schedule. The contractual handshake that triggers the receivable, the GRN, and the tax invoice is the ASN (EDI 856 advance shipping notice) crossing the OEM dock — not a discrete PO. The three-way match must therefore start at the ASN, walk forward to the OEM dock-receipt timestamp (which becomes the GRN), and only then reconcile against the supplier's downstream tax invoice carrying the e-invoice IRN. PO-anchored AP matching is structurally the wrong starting point for auto.

Cum-quantity is the cumulative count of parts the supplier has dispatched against a schedule agreement since the agreement was opened (or since the last cum-quantity reset). The OEM's schedule release calls for a new cum-quantity target by a delivery date; the supplier dispatches the delta. Reconciliation must walk every ASN-GRN-invoice triplet against the running cum-quantity ledger — if a single ASN is lost in transit, all subsequent cum-quantities drift by that quantity, and every downstream triplet appears mismatched even though the underlying records are correct. The remediation is a cum-quantity reset event mid-window, signed off by both parties; without that, exception aging compounds.

Dispatch clock — when the supplier physically ships and generates the ASN (EDI 856). Transit clock — the in-transit period (varies by lane: Pune→Chennai might be 36 hours, Pithampur→Manesar 24 hours). GRN clock — the OEM dock-receipt timestamp scanned at the inward goods station. E-invoice IRN clock — when the supplier raises the tax invoice and the IRN is generated by the IRP. These four can desynchronise: an ASN generated Friday evening, dispatched Saturday, received at OEM dock Monday morning, with the tax invoice raised Tuesday and the IRN minted Wednesday produces a five-day window across four timestamps. The match must tolerate this without flagging false exceptions, while still catching real drift.

Four classes. (1) ASN sent but no GRN — lost-in-transit shipment that the OEM dock never scanned. (2) GRN created but no ASN — manual PI (perpetual inventory) receipt, typically an ad-hoc emergency dispatch outside the schedule. (3) Cum-quantity drift — running cumulative quantity counters on supplier and OEM ledgers diverge after an ASN-GRN mismatch upstream. (4) Partial rejection at incoming inspection — quantity received is less than ASN quantity, with the rejected balance returned via debit note. Generic PO-GRN-invoice flows model none of these; they were designed for transactional procurement, not schedule-driven serial production.

GST law is unchanged by the Income Tax Act 2025. Every B2B auto-component tax invoice continues to require an IRN from the GST e-Invoice portal. The IRN is the artifact the OEM AP team matches against the ASN and the GRN — it is the proof of supply for ITC purposes. The Income Tax Act 2025 affects TDS only: the OEM deducts under Section 393(1) Sl. 8(ii) at 2% (payment code 1031) on the conversion portion of the invoice on payment release. The goods supply portion attracts no TDS. The three-way match must therefore split the matched invoice into goods value (no TDS) and conversion value (TDS payable) at payment release, and route the TDS into the OEM's TRACES ledger under the 1031 code, not the legacy 194Q code that retired on 31 March 2026.

OEM-fitment payment terms typically run 60-90 days from invoice date, with the OEM buyer holding pricing power and running structured debit-note recovery on PPM, line-rejection, sorting and engineering-change disputes. Aftermarket distributor terms are tighter at 30-45 days, with the manufacturer holding pricing power and channel-discount accrual replacing debit-note recovery as the main negative cash item. OEM-fitment runs on a Long-Term Agreement with annual price-revision mechanism; aftermarket runs on MRP-driven pricing reviewed quarterly or half-yearly with channel-margin policy. The two channels also differ on dispute window — OEM debits must be challenged within 30-60 days of remittance; aftermarket distributor disputes typically resolve within the next monthly settlement cycle.

OEM-fitment price is the outcome of a sourcing negotiation — a scheduling-agreement unit price established at programme award, indexed to raw-material variance per a defined index (steel, copper, aluminium, plastic resin), and revised annually or on a defined trigger. The negotiated price is below MRP because the OEM bears distribution margin to its dealer network. Aftermarket price is MRP-driven — the manufacturer sets MRP based on competitive positioning, allows distributor and retailer margins off MRP (typically distributor 22-35 percent, retailer 18-25 percent), and consumer pays MRP. Manufacturer realisation on the same physical part is materially higher in aftermarket because the MRP base captures full channel margin headroom.

OEM-fitment warranty failures are back-charged to the supplier through the OEM debit-note mechanism — a structured commercial recovery typically running PPM penalty plus per-piece value plus sorting back-charge under the contractual schedule, with 8D-linked dispute window. The financial event is a debit on the supplier's running settlement, with Section 34 credit-note treatment on the returned-goods component. Aftermarket warranty is end-customer claim through retailer to distributor to manufacturer — a reverse logistics flow with the manufacturer issuing a Section 34 credit note to the distributor and dispatching replacement free of charge. Volumes are lower than OEM-fitment warranty but unit cost is higher because of reverse-logistics overhead. The dispute resolution mechanism is different — OEM-fitment warranty disputes run through formal 8D channels, aftermarket warranty disputes are resolved at the distributor level by examination evidence.

OEM-fitment debit notes typically fall into six classes: (1) PPM quality penalty, (2) line-rejection material value, (3) sorting back-charge, (4) engineering-change cost recovery, (5) packaging non-conformance, (6) logistics under-recovery or delay penalty. Each carries its own contractual schedule, dispute window and evidence requirement. Aftermarket distributor debit notes are simpler: (1) returns under Section 34 for defective stock, (2) channel-discount accrual settled annually or quarterly, (3) volume-tier rebate at year-end, (4) occasional price-protection on MRP changes. The OEM debit-note stack is recovery-led — short-pay first, dispute later — while the aftermarket flow is accrual-led — book the rebate now, settle on cycle close.

Ind AS 115 applies the same five-step revenue model to both, but the application differs. OEM-fitment supply has one performance obligation (transfer of goods at scheduling-agreement quantity and price) with control transfer at OEM GRN, recognised on a periodic consolidated tax invoice for the billing window. Variable consideration includes PPM penalties, sorting back-charges and line-rejection credit notes — adjustments to transaction price under step 3, often constrained to most-likely-amount at period end. Aftermarket supply also has one performance obligation typically (transfer of goods to distributor at MRP-less-channel-discount) with control transfer at dispatch from MSL or OEM GRN basis, recognised on the dispatch invoice. Variable consideration includes channel-discount accruals, volume-tier rebates and Section 34 returns, similarly adjusted at step 3.

RoDTEP — Remission of Duties and Taxes on Exported Products — remits embedded central, state and local duties and taxes that are not otherwise refunded, on exported goods. The benefit is granted as a transferable electronic scrip (e-scrip) credited to the exporter's ledger in the ICEGATE customs system, computed as a percentage of FOB value at a rate that varies by HS code (most auto-component HS lines fall in a low single-digit percentage band, subject to a per-unit value cap). Reconciliation ties three things: the RoDTEP entitlement claimed in the shipping bill (per HS code on FOB value), the e-scrip actually credited to the ledger, and the realisation of that scrip — either used to pay basic customs duty on imports or sold to another importer in the scrip market. A gap between claimed and credited scrip is the core RoDTEP control.

Under the Export Promotion Capital Goods (EPCG) scheme, an exporter imports capital goods — presses, CNC machines, moulds, testing equipment — at zero or concessional customs duty, against an export obligation (EO) equal to six times the duty saved, to be fulfilled over six years. Reconciliation tracks the EO in two layers: the total EO against the duty saved, and the block-wise milestones (typically 50% in the first block of four years and the balance in the next two years), plus an average-export-obligation maintenance requirement based on past exports. Each export shipment is tagged to the EPCG authorisation and counted toward the EO. Shortfall at a block boundary triggers proportionate duty plus interest, so the running EO-fulfilled-versus-EO-required position is the central reconciliation.

Advance Authorization lets an exporter import inputs duty-free against an export obligation to use those inputs in exported products. The permitted input quantity is governed by Standard Input-Output Norms (SION) — published input-to-output ratios per product, or, where no SION exists, a self-declared or fixed norm. Reconciliation has to prove that the duty-free inputs imported under each authorisation were actually consumed in the exports against which the authorisation was issued, within the SION ratio — input consumed must not exceed the SION-permitted quantity for the exported output. Excess imports over SION, or under-export against the authorisation, create a duty-and-interest liability and block authorisation redemption. The SION input-output reconciliation per authorisation is the key control.

A supply of goods to an SEZ unit or developer is a zero-rated supply under the IGST Act, and a supply to an Export Oriented Unit (EOU) is a deemed export under the Foreign Trade Policy. For zero-rated supplies the supplier can either export under bond/LUT without paying IGST and claim refund of accumulated input tax credit, or pay IGST and claim refund of the IGST paid — both routes under Section 16 of the IGST Act read with Section 54 of the CGST Act. Reconciliation ties the zero-rated outward supply (in GSTR-1, with the SEZ/EOU GSTIN and the LUT/bond reference), the IGST or ITC refund claim filed, and the refund actually sanctioned and credited. Refund lag between claim and sanction is the main working-capital control here.

Section 393(2) Sl. 17 of the Income Tax Act 2025, payment code 1057, governs withholding on payments to non-residents — replacing legacy Section 195. For an auto component exporter, this commonly arises on commission paid to a foreign sales agent or buying house that sources orders abroad. The exporter must determine whether the commission is chargeable to tax in India (often it is not, where the agent operates wholly outside India with no business connection or permanent establishment, subject to the relevant DTAA and a tax-residency certificate), and withhold under Section 393(2) Sl. 17 code 1057 where chargeable. The reconciliation ties the foreign agent commission booked, the withholding applied (or the no-PE / DTAA position documented with Form 15CA/15CB), the FIRC/BRC on the underlying export realisation, and the RBI A2 remittance for the commission payout.

The cross-era window arises because deductions made under legacy 194x sections of the Income Tax Act 1961 in Q4 FY 2025-26 (1 January 2026 to 31 March 2026) continue to flow through legacy Form 26Q (deductor) and Form 26AS (deductee) for at least 6 to 9 months after the regime change — the Q4 Form 26Q filing is not due until end-July 2026, the resulting Form 26AS entries refresh after that, and any TRACES corrections raised against those entries open a further 2 to 6 weeks of resolution cycle. In parallel, deductions made from 1 April 2026 onwards under the new Section 393 / 394 / 413 framework flow through Form 131 (deductor) and Form 168 (deductee). The two lineages coexist on the same deductee's tax-credit view through FY 2026-27 and into Q1 FY 2027-28, with the practical end of the cross-era window typically falling around the September 2026 quarter for most Tier-1s and stretching to March 2027 for those with active legacy disputes.

The time of deduction under both Acts is the date of credit or the date of payment, whichever is earlier. For an auto-component invoice raised 28 March 2026 paid on 15 April 2026, the OEM has typically not credited the supplier's account before payment (most OEM AP systems credit and pay in the same accounting event), so the date of payment (15 April 2026) governs — the deduction sits under Section 393(1) Sl. 6(i).D(b) of the Income Tax Act 2025 at payment code 1024. If instead the OEM credited the supplier's account on 30 March 2026 (some OEMs run credit-then-pay accounting), the deduction sits under legacy Section 194C and reports on Form 26Q. The discriminator is the earlier of credit and payment, not the invoice date alone. Every straddling transaction needs explicit attention because the section, the code and the form all depend on the answer.

The ITR for FY 2026-27 (assessment year 2027-28) consolidates all TDS / TCS credits the supplier is entitled to claim against its FY 2026-27 income, regardless of which Act the deduction was made under. The Schedule TDS / TCS section of the ITR will need to capture both legacy 194x entries from Form 26AS (for Q4 FY 2025-26 deductions where the income was recognised in FY 2025-26 — these go into the FY 2025-26 ITR, not FY 2026-27) and new 1001-1092 entries from Form 168 (for FY 2026-27 deductions — these go into the FY 2026-27 ITR). The cross-era complication arises where an invoice raised in March 2026 but paid in April 2026 generates a deduction under the new Act on income that may be partially recognised in FY 2025-26 — the supplier's revenue recognition and the deductor's deduction event may sit in different financial years, requiring careful matching at ITR filing. The cross-era reconciliation register the supplier maintains through the year feeds directly into the ITR Schedule TDS / TCS preparation.

A Q4 FY 2025-26 conversion-charge deduction discovered missing in May 2026 — say an OEM did not deduct TDS on a ₹6 lakh conversion-charge payment made on 12 March 2026, which the supplier identifies during the Form 26AS reconciliation in May — stays under the legacy Section 194C framework because the time of deduction (12 March 2026) is pre-1-April-2026. The OEM is technically in default under legacy Section 201(1A) for the period from 7 April 2026 (the deposit due date) until the date the deduction is now belatedly deposited. The OEM files a TRACES correction statement under legacy 194C identifiers, reports the deduction on a revised Form 26Q for Q4 FY 2025-26, and the entry reflects in the supplier's Form 26AS within 4 to 8 weeks. The deduction is not migrated into the new Section 393(1) Sl. 6(i).D(b) code 1024 framework because the underlying event predates the regime change. The supplier's books and ITR claim continue to track the deduction on legacy lineage.

Two parallel filing tracks run through Q1 to Q3 of FY 2026-27. Track 1 — legacy Form 26Q for Q4 FY 2025-26 (due end-July 2026 originally; revised filings can stretch through the year for corrections). Track 2 — new Form 131 for Q1 FY 2026-27 (due end-July 2026), Q2 (due end-October 2026), Q3 (due end-January 2027), Q4 (due end-May 2027). The Q1 FY 2026-27 Form 131 filing in late July 2026 is the most operationally important — it is the first filing under the new framework, the schema and the validation rules are new, and any deductor-side errors in this filing cascade into supplier-side Form 168 mismatches and TRACES correction cycles. Most Tier-1 supplier reconciliation teams plan for an elevated dispute volume in August / September 2026 as the consequences of the first Q1 FY 2026-27 Form 131 filing become visible. By Q3 FY 2026-27 the new filing track tends to normalise, and the legacy track winds down naturally.

A line rejection happens when a supplied part is found defective at the OEM assembly line — it fails an inspection, does not fit, or causes a build fault — and is pulled out of production. The OEM logs the rejected quantity against the supplier with a rejection slip or quality notification number, and raises a quality debit note for the part value plus any associated cost (line-stop time, expediting, sorting). The debit is deducted from the supplier's running settlement. Reconciliation must match each quality debit to a rejection slip ID and then to the supplier's own internal rejection/return record, because the part value, the replacement obligation and the GST treatment all hang off whether the supplier accepts or contests the rejection.

PPM — parts per million — measures defect rate: defective parts found per million supplied. The contract sets a PPM threshold per part or per supplier (commonly tens of PPM for a mature programme). When the rolling defect rate breaches the threshold, the OEM applies a contractual PPM penalty, often a graduated charge that rises as the breach widens, sometimes alongside a supplier-rating downgrade that affects new-business allocation. The penalty is separate from the per-part value of the rejected pieces. Reconciliation must compute the supplier's own PPM from its rejection records, compare it to the OEM's asserted PPM, and validate the penalty calculation against the contractual band before accepting the debit.

An 8D (Eight Disciplines) is the structured corrective-action report the OEM demands when a quality problem occurs — it walks through containment, root cause, corrective action and prevention across eight defined steps. The 8D is the technical document; the quality debit note is the commercial document. They are linked by the same quality notification ID. The OEM may hold or escalate the financial debit until the 8D is closed, and a poorly closed 8D can lead to repeat rejections and a widening PPM breach. Reconciliation should cross-reference each open quality debit to its 8D status so that finance and quality are working the same claim ID rather than two disconnected lists.

When a defect is found, the OEM often deploys a resident supplier engineer or a third-party sorting agency to 100% inspect suspect stock at the line, and back-charges the supplier for the sorting hours, the agency fee and any rework or scrap. This sorting back-charge is separate from both the per-part value and the PPM penalty, and it can be large when a containment runs across multiple days and plants. Reconciliation must match the sorting back-charge to the sorting authorisation, the agency timesheet/invoice and the quantity sorted, and confirm it ties to the same quality notification as the rejection — otherwise a supplier can be charged sorting cost for an event it never authorised or that belongs to another supplier.

When the OEM returns rejected parts, the correct GST mechanism is a supplier-issued credit note under Section 34 of the CGST Act for the value (and GST) of the returned goods, reducing the supplier's output liability provided it is issued within the window (until 30 November of the following financial year or the annual return, whichever is earlier) and the OEM reverses the matching ITC. The replacement dispatch is a fresh supply with its own tax invoice, e-invoice and e-way bill. A PPM penalty or a sorting back-charge, by contrast, is generally a commercial damages/service recovery rather than a price reduction on goods — its GST treatment depends on how the contract characterises it, and reconciliation must not net it against the goods credit note.

The Tier 2 invoices the Tier 1 directly — there is no privity of contract with the OEM. When the OEM short-pays the Tier 1 for a quality issue traced to the Tier 2's part, the Tier 1 issues a debit note against the Tier 2's account citing the back-charge code and the OEM's debit reference. Reconciliation must tie three documents — the OEM's debit note to the Tier 1, the Tier 1's debit note to the Tier 2, and the Tier 2's original invoice — by part number, vehicle programme and warranty claim ID. Without that three-way link the Tier 2 cannot dispute the back-charge or claim recovery from sub-tier suppliers.

The PLI Auto scheme, with a ₹26,058 crore outlay over a five-year tenure, releases incentive against incremental sales above a base year, weighted by value-add criteria. The disbursement comes as a single bank credit per quarter from MoHI's nominated agency after the value-add audit closes. Reconciliation ties the audited eligible sales figure to the incentive percentage band claimed (typically 8% to 18% based on value-add) to the actual bank credit, with the GST treatment booked as a subsidy not chargeable to GST in most interpretations. Any difference between claim and credit is logged as a PLI variance for the next quarter's appeal.

Job-work and sub-contracting charges paid to a heat-treatment, plating, machining or assembly vendor fall under Section 393(1) Sl. 6(i).D(b) of the Income Tax Act 2025, payment code 1024 (which replaced legacy Section 194C). Rate is 1% for individual/HUF vendors and 2% for company/firm vendors, with a per-transaction threshold of ₹30,000 and aggregate annual threshold of ₹1 lakh. The same vendor invoice will also carry GST on the job-work service, and the dispatch of inputs to the job-worker is governed separately by Section 143 of the CGST Act with a one-year return window.

An OEM typically pays one-time tooling cost upfront against a committed annual volume — say ₹40 lakh for a die expected to produce 80,000 parts over the programme life. Some OEMs treat tooling as their asset (the supplier holds custody and depreciates against the commitment); others let the supplier own it and recover via a per-part tooling amortisation line of ₹50 on each invoice. Reconciliation has to track cumulative tooling recovery against the contractual cap per programme — if actual volume runs ahead of forecast, the over-recovery sits as a credit due to the OEM; if volume falls short, the unamortised balance is at supplier risk at programme exit.

FOMP — Field-Originated Material Performance — is the OEM's back-charge regime for warranty claims traced back to a supplied part. Indian OEMs typically charge between 1% and 3% of monthly billing as a FOMP debit, sometimes structured as a rolling running account and sometimes as a per-claim debit. Reconciliation must split the FOMP debit by warranty claim ID, validate against the Tier 1's own warranty database, age unresolved disputes, and pursue recovery from the sub-tier supplier whose part caused the failure. Many Tier 1s carry 4-6% of revenue as a FOMP provision before reconciliation closes the actual exposure.

Two-wheeler Tier-1 supplier payment terms with Bajaj Auto and TVS Motor typically run T+45 to T+60 days from GRN (goods-receipt-note) date at the receiving plant. Bajaj's typical contracted band runs T+45 to T+55 for established suppliers, with new suppliers starting at T+60. TVS typically runs T+45 to T+60 with similar rating-linked variability. The clock starts at GRN, not invoice date or dispatch date. Settlement cadence is typically monthly with the highest-volume two-wheeler suppliers (fasteners, plastics, rubber, electrical) running fortnightly settlement against the combined plant book.

Two-wheeler debit notes are dominated by per-100-piece quality penalties and JIT shortage charges rather than the per-vehicle FOMP / warranty claims that anchor passenger-vehicle debit workflows. A Bajaj fastener supplier ships 6-12 million pieces per month per part at ₹0.50 to ₹4.00 per piece — a typical quality penalty is ₹0.20 per affected piece over a 50,000-piece rejected batch, generating a ₹10,000 debit line. The rupee value per debit line is smaller than passenger-vehicle but the line count per month is higher (a busy Tier-1 fastener supplier might generate 80-150 debit lines per month across Bajaj + TVS combined). The reconciliation engine handles a higher line count with smaller per-line rupee values.

Two-wheeler Tier-1 parts typically have smaller absolute rupee deltas from commodity variance than passenger-vehicle parts because the per-part rupee content of aluminium, copper or steel is lower. A two-wheeler fastener carries ₹1.20 of steel content where a passenger-vehicle bracket carries ₹85. When the steel benchmark moves 8%, the two-wheeler delta is ₹0.10 per piece versus ₹6.80 per piece on the passenger-vehicle bracket — the operational overhead of monthly RMPV reconciliation exceeds the rupee benefit on most two-wheeler parts. Bajaj and TVS instead handle commodity movement through annual or semi-annual cost-up / cost-down negotiations on each scheduling agreement, with RMPV reserved for the highest-rupee-content two-wheeler components (engine castings, frames, exhaust systems).

Both Bajaj Auto (Chakan, Waluj, Pantnagar) and TVS Motor (Hosur, Mysuru, Nalagarh) operate a pull-system in-line stores discipline at the receiving plant. The Tier-1 supplier delivers parts into a near-line buffer store at the receiving plant, with consumption (kanban card pull or barcode scan at the line side) triggering the formal GRN. This means GRN can lag delivery by hours or days depending on consumption rate. The supplier's reconciliation engine must distinguish delivery date (ASN-confirmed at the dock) from GRN date (consumption-confirmed at the line) because the payment clock starts at GRN — not at delivery.

Both Bajaj and TVS deduct contractor TDS on the Tier-1 supplier's job-work component under Section 393(1) Sl. 6(i).D(b) of the Income Tax Act 2025 using payment code 1024 (1% for individual / HUF suppliers, 2% for other entities). The Tier-1's own Tier-2 chain — heat-treatment vendors for fasteners, plating vendors for chrome / nickel finish, stamping job-workers — carries the same Section 393(1) Sl. 6(i).D(b) code 1024 deduction at each Tier-1-to-Tier-2 payment. For a Tier-1 with substantial Tier-2 outsource (typical for fastener suppliers running 60-80% outsourced manufacturing), the Tier-2 TDS register can carry 200-400 lines per month across heat-treatment, plating, packaging and inspection vendors. Form 168 reconciliation against Tier-1 books before the quarterly return cut-off is the operational control.

SupplyOn is the supplier collaboration platform that Bosch uses globally for supplier interaction across forecasting, delivery scheduling, ASN, quality, capacity, and document exchange. The platform supports EDI message families in both X12 (the North American standard family — 830 forecast, 862 firm call-off, 856 ASN, 810 invoice) and EDIFACT (the European standard family — DELFOR forecast / firm, DESADV despatch advice, INVOIC invoice), which matters because Bosch India routinely processes message traffic in either family depending on the originating Bosch entity. SupplyOn also supports a web portal interface for suppliers that cannot run EDI integrations end-to-end — most smaller Indian Tier-2 suppliers fall into this category and work with SupplyOn primarily through the portal.

A Tier-2 supplier supplying ₹50 crore per year to Bosch India typically does not have full EDI integration with SupplyOn — the volume does not justify the integration build and the supplier's ERP (often Tally Prime, occasionally a basic SAP B1 or Oracle NetSuite install) does not expose native EDI message mapping. The practical pattern: a finance / planning analyst logs into the SupplyOn portal daily, downloads the delivery schedule for each part in CSV or Excel, downloads the ASN-acknowledgement status, downloads quality notifications, and feeds the data into the supplier's internal reconciliation workbook. The reconciliation engine therefore runs against periodic structured exports from SupplyOn — not against a real-time EDI feed — and the discipline gap (a missed download day equals a delivery-schedule blind spot) is the operational risk.

CUM (cumulative quantity) accounting tracks the running cumulative shipped quantity against a scheduling agreement, against the running cumulative confirmed-received quantity at Bosch's plant. SupplyOn carries the CUM-shipped position from the supplier's ASN and the CUM-received position from Bosch's GRN. The reconciliation discipline runs continuously — a Tier-2 supplier supplying critical injection-system components, fuel-pump assemblies or sensor sub-assemblies cannot tolerate CUM drift the way a domestic-OEM supplier can, because Bosch's global tolerance for CUM-mismatch as a forecast input is lower than Maruti's or Tata's. Bosch typically expects CUM-shipped and CUM-received to reconcile within a tight tolerance band per part per period, with any persistent drift triggering a structured escalation to Bosch supplier-quality engineering.

CRX0 (Bosch's customer requirements zero-defect programme) is the global quality framework Bosch applies across its supplier base targeting zero-defect supply. Practical PPM thresholds at Bosch typically run tighter than the domestic-OEM standard — 10-25 PPM for safety-critical and injection-system components against the 50 PPM domestic standard, 100-300 PPM for functional-critical parts against the 200-500 PPM domestic standard, and 500 PPM for non-critical parts. The calculation runs on the same rolling 12-month window (line-rejection plus field-traceable failures over parts dispatched, all over 1,000,000). Breach triggers contractual penalty on trailing-period billing, mandatory 8D corrective action, and escalation through Bosch's supplier development programme — sustained breach risks supplier-rating downgrade and exclusion from new-programme bidding.

Bosch India often sources sub-assemblies from Bosch Germany or Bosch Hungary for higher-value injection-system, electronics, or sensor components — billed in EUR with INR-equivalent at booking-date FX. On the supplier side this matters when a Tier-2 raises foreign-currency invoices to Bosch India (less common — most Indian Tier-2s invoice in INR). More commonly, the Tier-2 may receive associated technical-service support from Bosch Germany / Hungary engineers for programme launch, fixture commissioning, quality investigation, or audit support — and any fees paid by the Indian Tier-2 to those Bosch-side non-resident entities attract Section 393(2) Sl. 17 / payment code 1057 TDS on the supplier's pay-leg under the Income Tax Act 2025 framework effective from 1 April 2026. The supplier's reconciliation engine must track these pay-leg payments separately, apply the correct rate per Double Taxation Avoidance Agreement, file Form 168A (the equivalent quarterly statement for non-resident TDS), and reconcile against Form 49B issuance.

An aluminium casting line moves the ingot through six named stages — charging (ingot plus return-scrap into the melting furnace), melting (electric or gas-fired furnace to around 700 degrees Celsius for aluminium), holding and degassing (refining the melt, removing hydrogen and oxide), pouring (HPDC injection, GDC gravity pour or sand-mould pour), trimming (cutting away gates, runners and overflows), and finishing or machining (fettling, shot blast, machining to spec). Each stage produces a discrete material loss: oxidation skim (dross) at melting, runner and gate residue at trimming (which is recycled in-house), reject castings (which are recycled in-house), and finishing fines (which are partially recoverable). The closing identity is ingot charged equals finished casting weight × good piece count plus melt loss skim plus permitted process loss plus the recycled return-melt that is in balance over time.

Aluminium reacts strongly with oxygen at melt temperature. The surface of the molten bath in the furnace continuously forms an oxide skin which traps liquid aluminium underneath and floats up as dross. Dross is skimmed periodically and disposed. Even at mature aluminium foundries with covered furnaces, controlled flux additions and minimal turbulence, dross loss runs 2-4 percent of charged metal — a structural cost of having molten aluminium in contact with air. Returned in-process scrap (runners, gates, rejects) tends to lose marginally more on remelt because of the surface area exposed during cutting and granulation. Cast iron and copper-alloy castings have different melt-loss profiles but the structural principle is identical.

Rejection in auto casting is a structural part of the process, not an exception. A mature HPDC plant runs 3-5 percent rejection on cosmetic and dimensional defects (porosity, cold-shut, mis-run, sink); GDC 4-7 percent; sand casting 5-10 percent. Rejected castings are typically remelted in the same furnace as part of the next charge — they re-enter the casting cycle as return-scrap. The reconciliation closes ingot purchased equals good casting weight × good piece count plus melt loss plus net change in return-scrap stock plus permitted process loss. Reject castings are not separately written off because the metal value is recovered in the next charge; the conversion cost (energy, time, die-cycle, labour spent producing the reject) is the real loss and shows up as a higher per-good-piece conversion cost when rejection ages above the contracted norm.

Auto-grade aluminium ingot (LM2, LM6, LM24, A380, A413 and similar) is benchmarked against the LME aluminium 3-month price plus a regional premium and a grade-specific alloy adjustment. Indian auto-component contracts typically reference the LME 3-month closing on a specified day of the prior month (often the last business day) plus the published India premium for that month. The supplier's RMPV claim is calculated as the differential between the contractual reference and the actual landed ingot cost for the period, multiplied by consumed tonnage at the contracted yield norm, then either invoiced as a separate RMPV claim or netted on the conversion-charge invoice. Aluminium price has high volatility (LME swings of 10-25 percent inside a year are routine) and a robust RMPV mechanism is essential to keep the supplier-OEM commercial relationship sustainable.

Under the new TDS payment-code rail operative from 1 April 2026 (Income Tax Act 2025), conversion-charge billing on free-issue or principal-supplied-material casting falls under Section 393(1) Sl. 6(i).D(b) work-contract or job-work payment code 1024 (typically 1 percent for individual or HUF job-worker and 2 percent for any other entity) on the conversion charge net of GST. Pre-1 April 2026 deductions follow legacy Section 194C lineage. Where the supplier sells the finished casting as a goods sale (rather than as a job-work conversion service on customer-owned material), Section 194Q purchase-side TDS applies and the payment-code rail is different. The reconciliation must keep the conversion-service stream and the goods-sale stream on separate payment-code maps because they hit different TRACES code series and reconcile to different lines on Form 26AS for the OEM.

Consignment stock and VMI both defer the supplier's tax invoice to the point of consumption at the OEM rather than the point of dispatch from the supplier, but the operational mechanics differ. In a consignment-stock arrangement the supplier dispatches stock to an OEM-controlled consignment store at the OEM's premises, ownership stays with the supplier, the OEM picks from the consignment store as production calls and triggers an invoice on each pick or on a periodic consumption summary. In a VMI arrangement the supplier replenishes minimum-maximum bin levels at the OEM dock or production line directly, ownership stays with the supplier, the OEM consumes from the bin as production calls, and the supplier invoices against the consumption report — typically weekly or monthly. VMI is the more operationally automated pattern and is the standard for high-volume low-value commodity items (fasteners, clips, grommets, gaskets). Consignment is more common for medium-value programme-specific items where the OEM wants tighter control of the on-site inventory.

Section 31(1) ties the time of invoice for goods to the time of supply, which under Section 12 is the earlier of the date of dispatch and the date of issue of invoice. In a consignment or VMI arrangement the dispatch under Rule 55 challan is not a supply — ownership has not moved — so the time of supply has not yet arisen. Supply arises on consumption (drawal from the consignment store, or pull from the VMI bin). Section 31 invoice attaches to the consumption event. Practically the supplier invoices against an OEM-issued weekly or monthly consumption report. The invoice carries the consumption period as the supply period and the consumed quantity as the supply quantity. Stock in the consignment store or VMI bin that has not yet been consumed remains the supplier's inventory and is not yet a supply.

Schedule I para 2 of the CGST Act treats supply between related persons or distinct persons under Section 25 as supply even without consideration. An OEM and an independent Tier-1 are typically not related or distinct persons, so Schedule I para 2 does not directly apply on its face. The deemed-supply risk on long-held consignment-or-VMI stock arises through a different reading — where stock sits at the OEM premises for an extended period without consumption, with no realistic alternative disposition, and where the goods are heavily customised to the OEM such that no other buyer would commercially take them, the tax administration position has been that an effective transfer has occurred regardless of the documented consignment status. The operational safe-harbour pattern most disciplined Tier-1s follow is a six-month ageing limit on any consignment-stock or VMI SKU at any OEM location, with explicit consumption, return, or provisional accrual triggered before the six-month line. The wider deemed-supply analysis is in [Section 143 deemed supply for auto components](/insights/section-143-deemed-supply-auto-component-india/).

Ind AS 115 recognises revenue at the point control transfers to the customer. In a consignment-stock or VMI arrangement control transfers on consumption, not on dispatch — the supplier retains the right to direct the use of the stock and the OEM has not taken control until pull-to-line. Revenue is therefore recognised on the consumption event, aligned with the Section 31 GST invoice. The supplier's books carry the consignment-or-VMI stock as inventory (at the supplier's cost) until the consumption event, at which point revenue is recognised at the agreed price, inventory is de-recognised at cost, and the difference is the gross margin on the SKU. This is materially different from a regular dispatch where revenue would be recognised on dispatch under the standard incoterm.

The OEM's MRP system generates a weekly consumption report by SKU for each VMI vendor — the report carries SKU code, opening bin level at the start of the week, replenishment receipts during the week, consumption pulls during the week, closing bin level. The supplier reconciles this to its own dispatch register (replenishment receipts at the OEM should equal supplier dispatches less in-transit), its own GRN-acknowledgement file from the OEM (each dispatch acknowledged by an OEM GRN), and its inventory ageing model (closing bin level by SKU with days-since-last-consumption). The reconciliation drives the monthly invoice — total consumption for the month by SKU at the agreed rate equals the monthly invoice value. SKUs with closing bin level above the maximum and no consumption pulls in 30+ days are flagged for replenishment-pause; SKUs with consumption pulls exceeding maximum and stock-out events are flagged for replenishment-acceleration.

Yes. Under the Companies (Cost Records and Audit) Rules 2014 as amended, auto-component manufacturing falls under the regulated sector category. The CETA (Central Excise Tariff Act) headings for auto parts — primarily Chapter 87 (vehicles other than railway), and components classified under various other chapters depending on material — are listed in the regulated sector table. The turnover threshold for cost records maintenance under CRA-1 is ₹35 crore and the cost-audit threshold is ₹50 crore aggregate turnover with ₹25 crore individual product turnover for regulated sectors. Most Indian Tier 1 and many Tier 2 auto-component manufacturers cross these thresholds, making the cost audit regime applicable.

Statutory financial audit under Section 143 of the Companies Act 2013 forms an opinion on the truth and fairness of financial statements under Ind AS or Indian GAAP. Cost audit under Section 148 reports on the cost records — how cost of production, cost of sales, and margin are computed per product or service. The two regimes share underlying data (raw material consumption, labour, overhead) but report different views: financial audit reports a consolidated profit and loss; cost audit reports per-product cost of production, capacity utilisation, normal capacity, abnormal loss, and per-product margin. Cost audit findings feed into pricing, transfer pricing, and competition-law defensibility. The cost auditor is appointed under CRA-2 separately from the statutory auditor.

Only a Cost Accountant in practice — that is, a member of the Institute of Cost Accountants of India (ICMAI) holding a certificate of practice — can be appointed as cost auditor. The appointment is made by the Board of Directors on the recommendation of the Audit Committee (or the Board where Audit Committee is not mandated). The CRA-2 e-form is filed with MCA within 30 days of Board approval. The cost auditor cannot be the statutory auditor of the same company — this is a clear separation under the Act. The cost audit report is signed under CRA-3 within 180 days of close of the financial year and the XBRL CRA-4 is filed by the company within 30 days of receipt of the report.

Five data sets are cost-audit-specific. First, capacity utilisation per cost centre — installed capacity, normal capacity, actual production, idle capacity, and the reasons for idle capacity. Second, yield ratios per process — input consumption to output ratio per stamping coil, forging billet, casting melt, machining stock with the standard yield and actual yield variance. Third, overhead allocation methodology with the basis (machine-hour, labour-hour, units produced) and the per-unit absorption rate per cost centre. Fourth, abnormal loss per process with the cause analysis. Fifth, related-party transaction pricing for transfer-pricing defensibility. These data sets are operational rather than financial — the cost auditor probes the production records, not just the books.

A ₹220 crore Tier 1 auto-component manufacturer crosses both the cost records threshold (₹35 crore) and the cost audit threshold (₹50 crore aggregate plus ₹25 crore individual product). The Board appoints a cost auditor through CRA-2 within 30 days of the AGM. The cost auditor conducts the cost audit between October and February of the following financial year, examining CRA-1 cost records covering raw material consumption per product, labour per product, overhead allocation per cost centre, capacity utilisation per furnace and machine line, yield ratios per process, abnormal loss per process, and inter-unit / related-party transaction pricing. The CRA-3 cost audit report is signed by 30 September of the following year and the CRA-4 XBRL is filed by 31 October.

CUM accounting is the running total quantity the OEM and supplier carry against a scheduling-agreement line since the last reset point — usually 1 April for Indian fiscal alignment, or a model-start date. The 862 firm shipping schedule carries CUM-required (total quantity the OEM expects shipped to date), the 856 ASN carries CUM-shipped (the supplier's running total dispatched), and the OEM GRN carries CUM-received. The open delivery requirement is CUM-required minus CUM-received. No quantity in the chain is a discrete order — every number is a running cumulative against a reset marker.

If ASN #41 carrying 600 units is transmitted twice during a portal timeout, the OEM de-duplicates the GRN and records CUM-received once; the supplier's dispatch log counts CUM-shipped twice. From that moment the supplier's CUM-shipped runs 600 units ahead of the OEM's CUM-received and the gap never closes by itself — every subsequent 862 carries a CUM-required that is computed against the OEM's true CUM-received, so the supplier sees a phantom 600-unit open requirement that does not actually need shipping. The only fix is a joint CUM reconciliation where both sides agree the duplicate and the supplier reverses 600 from its CUM-shipped.

Each new call-off looks normal in isolation. The OEM portal shows a CUM-required figure; the supplier ships the next 600 units; the gap to the visible CUM-required closes for that delivery; nothing flags an exception. The drift only becomes visible when someone compares CUM-shipped on the supplier side to CUM-received on the OEM side — which most finance teams only do at month-end, quarter-end or model-end. By then the drift has been carried for two to six weeks and traceability to the originating ASN is much harder.

If the supplier has billed against ASN quantity (CUM-shipped) rather than confirmed-received quantity (CUM-received), output GST is overstated for the period and the OEM's ITC claim in GSTR-2B will fall short, breaking GSTR-2A/2B reconciliation. If the drift goes the other way and the OEM has received goods that the supplier has not yet invoiced, the supplier carries an under-billed position that turns into a deferred-supply risk and a year-end provisioning question. Either way the fix is a periodic tax invoice that reconciles to OEM-confirmed received quantity for the billing window, not raw ASN quantity.

Where the supplier is working on free-issue steel or sub-contracted job-work moving on a Rule 55 delivery challan, the Section 393(1) Sl. 8(ii) TDS on services at 2% (payment code 1031) is computed on the conversion charge for goods actually received and billed. If CUM drift causes the supplier to bill conversion on phantom quantity, TDS is over-deducted; if the supplier bills less than received, TDS is under-deducted and a Section 143 deemed-supply risk also opens. The cumulative reconciliation must therefore feed both the GST invoice and the TDS deduction base — not just the operational dispatch register.

D365 F&O's India localisation, particularly from the FY 25-26 patch onwards, covers GST registration and return generation (GSTR-1, GSTR-3B, GSTR-9), TDS / TCS configuration including the Income Tax Act 2025 payment codes 1001-1092 (Section 393(1) Sl. 6(i) codes 1023 / 1024 contractor, Section 393(1) Sl. 8(ii) code 1031 purchase, Section 394 code 1071 scrap, Section 393(2) Sl. 17 code 1057 non-resident), e-invoice integration with the GST Invoice Registration Portal (IRP), e-way bill generation, withholding tax reporting and the standard statutory output. The Procurement and Sourcing module provides the Blanket Purchase Agreement document type for the inbound procurement side, the Supply Chain Management module covers warehouse and production, and the Cost Management module handles the three-way match through the standard invoice register reconciliation. For a typical non-auto-component manufacturer at ₹100-300 crore revenue, D365 is a credible ERP choice.

Seven recurring gaps. First, scheduling-agreement equivalent — D365 has Blanket Purchase Agreement (a procurement-side multi-release document), but no native LP / LPA equivalent at the SAP S/4HANA grade for outbound supply against an OEM-issued SA with EDI 830 forecast and EDI 862 firm call-off. Second, ASN inbound from OEM EDI — no out-of-the-box mapping for Maruti e-Nagare, Tata SRM, Mahindra Supplier Portal or Bosch SupplyOn portal formats; requires Logic Apps integration build per OEM. Third, cum-quantity drift — no standing exception engine. Fourth, ITC-04 multi-hop job-work — D365's job-work module handles single-hop; multi-hop requires custom extension. Fifth, free-issue / Rule 55 challan tracking on the supplier side — no native concept of supplier-receives-free-issue-from-customer. Sixth, RMPV index linkage — no commodity-index-driven supplementary pricing engine. Seventh, OEM portal extracts and parsing — handled through Logic Apps custom flows per portal.

Industry observation: smaller than the SAP user base, by a wide margin. SAP S/4HANA dominates the upper Tier-1 segment in Indian auto-component (₹400 crore revenue and above), where the established ABAP customisation ecosystem and the multi-decade SAP-on-auto-component installed base in India make SAP the default. Oracle ERP Cloud (Fusion) has a smaller but established presence at parent-company-standardised Tier-1s. D365 F&O is most often seen at mid-Tier-1 (₹100-300 crore revenue) where the SAP licensing economics are challenging but the company has outgrown Tally Prime. The Indian D365 ISV add-on landscape for auto-component-specific functionality is thinner — fewer pre-built modules, fewer system-integrator partners with auto-component domain depth, fewer reference implementations. The result is that a Tier-1 evaluating D365 typically discovers that the gap-closing burden falls more on internal customisation and on companion-product integration than on plug-in ISVs.

Three places. First, total cost of ownership — D365's licensing and implementation costs are typically lower than SAP S/4HANA or Oracle Fusion at the ₹100-300 crore revenue band where SAP / Oracle TCO becomes hard to absorb. Second, integration with the Microsoft ecosystem — companies already standardised on Office 365, Power BI, Teams and Azure AD often find the D365 fit-and-finish smoother than SAP's. Third, the Logic Apps integration layer — the modern API-based integration pattern is genuinely productive for Maruti e-Nagare, Tata SRM and similar portal integrations where SAP's legacy IDoc-and-PI patterns can feel heavier. The trade-off is the thinner auto-component-specific ISV ecosystem and the gap-closing burden, which is where a companion reconciliation product becomes the natural complement.

D365 F&O retains the books-of-account and procurement / supply-chain system-of-record status — chart of accounts, AR / AP, Cost Management, Inventory, Sales and Purchase Order processing, Blanket Purchase Agreement for inbound multi-release supply, GST returns through the India localisation, TDS / TCS deduction under Income Tax Act 2025 codes 1001-1092, e-invoice through IRP, e-way bill, withholding tax reporting. The companion reconciliation product consumes D365 Data Entities exports (sales orders, purchase orders, customer invoices, vendor invoices, inventory transactions, withholding tax register, GST output) via Logic Apps scheduled flows, plus OEM portal exports (e-Nagare, TML SRM, M&M Supplier Portal, SupplyOn), and runs the auto-component reconciliation streams (SA equivalent, ASN with cum tracking, RMPV claim, ITC-04 multi-hop, free-issue Rule 55 tracking, Section 143 alerting) externally.

From 1 August 2023 the e-invoice IRN is mandatory for every B2B taxable supply made by any registered person with aggregate turnover above ₹5 crore in any preceding financial year from 2017-18 onward. Virtually every Tier-1 and most Tier-2 auto-component manufacturers cross this threshold, so e-invoicing is a hard precondition for despatch. The IRN must be generated through the Invoice Registration Portal (IRP, operated by NIC) before or at the time of the tax invoice; the invoice carries the IRN and the IRP-signed QR code; transport without a valid IRN is treated as movement without an invoice for Section 129 detention purposes.

Rule 138 of the CGST Rules requires an e-way bill when goods are moved for a consignment of value exceeding ₹50,000. The threshold is per consignment (single document or aggregate of invoices in one vehicle) — not per day, not per OEM, not per supplier. For an auto-component JIT supplier despatching sub-threshold consignments — say 8 ASNs of ₹35,000 each on the same truck to Maruti Manesar — Rule 138(7) requires the transporter or the consignor to generate a consolidated e-way bill at the conveyance level if the aggregate value in the vehicle crosses ₹50,000, before movement begins. Single-consignment e-way bills handle large despatches; the consolidated bill handles the JIT aggregation.

An e-invoice IRN can be cancelled on the IRP within 24 hours of generation if the underlying invoice has not been reported in GSTR-1. After 24 hours the IRN cannot be cancelled — the supplier must issue a credit note for any commercial reversal. An e-way bill can be cancelled within 24 hours of generation if the goods are not transported or are transported but not as per the bill; after 24 hours cancellation is blocked. The two clocks run independently — a Tier-1 that cancels the IRN within 24 hours but forgets the linked e-way bill is exposed to a stale e-way bill in the system, which surfaces in next-month GSTR-1 / e-way bill cross-checks.

A returnable KLT bin, trolley or stillage going out from a Tier-1 to an OEM for use as a packaging carrier and returning empty is movement of goods 'otherwise than for supply' under Rule 55 of the CGST Rules. The principal issues a delivery challan, not a tax invoice; no GST is charged; no IRN is required because there is no taxable supply. If the value of the bins moving in a single consignment exceeds ₹50,000 (which it usually does — a single truckload of metal stillages easily clears this), an e-way bill is still required under Rule 138, generated on the basis of the delivery challan rather than the tax invoice. The Rule 55 dispatch flows in [Rule 55 delivery challans for auto components](/insights/rule-55-delivery-challan-auto-component-fi-bins-job-work/) and the bin-float ledger in [returnable packaging and KLT bin reconciliation](/insights/returnable-packaging-klt-bin-reconciliation-india/).

The ASN (EDI 856) is the supplier's despatch notice to the OEM, declaring shipped quantities and the linked PO release. The e-invoice IRN is the GST system's authentication of the tax invoice for that despatch. The two must reconcile on three axes: (a) IRN exists for every ASN that crosses the ₹0 taxable supply threshold (returnable bins excepted); (b) ASN quantity equals invoice quantity equals e-way bill quantity within tolerance; (c) PO release referenced on the ASN ties back to the PO line referenced on the invoice. A break in any axis surfaces as a downstream reconciliation exception at month-end — either OEM goods-receipt rejection (short receipt), short-pay on the GR-IR side, or an IRN-without-ASN orphan that points to invoice raised without despatch. The EDI flow is covered in [EDI 830/862/856 for auto-component finance teams](/insights/edi-830-862-856-india-auto-component-finance-primer/).

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.

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.

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.

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.

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.

Because the reconciliation tool — internal Z-report, custom OTBI report, Logic Apps flow or companion product — is only as good as the data it can read. The reconciliation streams (cum-drift, ASN ageing, debit decomposition, RMPV, ITC-04, free-issue Rule 55 tracking, Section 143 alerting, Form 168 reconciliation) all depend on consistent, complete and timely access to the source ERP data. A poorly designed extract layer creates downstream problems that no reconciliation logic can fix — missing records, stale data, format mismatches, GSTIN-normalisation errors, date / decimal / number-format inconsistencies across heterogeneous ERPs. Most reconciliation-tool implementations that fail at Tier-1 fail at the extract layer, not at the reconciliation logic.

Four standard SAP extract patterns are in use across Indian Tier-1s on S/4HANA. First, IDoc-based extracts — message types ORDERS05 (purchase order), DELFOR01 (delivery forecast, used for EDI 830 inbound), DELINS01 (delivery schedule, used for EDI 862 inbound), DESADV01 (despatch advice, used for EDI 856 outbound), INVOIC02 (invoice). The ALE / EDI subsystem manages partner profiles and message control. Second, RFC-based extracts — direct ABAP function module calls returning structured data, typically used for on-demand reconciliation pulls. Third, OData extracts — the SAP NetWeaver Gateway exposes REST-style services over OData, increasingly preferred for cloud-companion integration. Fourth, scheduled custom report exports — ABAP Z-reports running on a job schedule, output to a file drop on SFTP or to the SAP application server file system, consumed by the downstream reconciliation tool.

Oracle ERP Cloud (Fusion) exposes four extract patterns. First, BIP (BI Publisher) reports — XML / CSV / Excel output from data models that join Procurement, Cost Management, AP, AR and India Localisation tables. Second, OTBI (Oracle Transactional Business Intelligence) subject areas — exposed through REST APIs or scheduled subscription delivery. Third, REST APIs — Procurement Cloud, Financials Cloud and Supply Chain Management Cloud expose REST endpoints for object-level queries. Fourth, FBDI (File-Based Data Import) for inbound loads and HCM Extracts for outbound batch data. The standard pattern at a Tier-1 is BIP for periodic batch extracts (daily AR / AP register, weekly BPA cum-tracking, quarterly ITC-04 base data) plus REST for on-demand object queries. OTBI subject-area subscriptions are used for scheduled push delivery of the cum-drift, programme-cumulative and exception-register reports.

Three patterns. First, ODBC pull — Tally Prime exposes a built-in ODBC interface on a configurable TCP port (default 9000) that a downstream tool can connect to and query Tally objects (vouchers, masters, registers) using a Tally-specific SQL-like syntax. Second, XML over Tally.ERP 9 protocol — Tally exposes an XML request-response interface over HTTP that returns voucher and master data; this protocol works on Tally Prime as well as on the legacy Tally.ERP 9. Third, Tally Server 9 — the multi-user Tally deployment exposes the same ODBC and XML interfaces with concurrent-user support. Standard pattern at a Tier-2 or Tier-3: a daily ODBC pull job extracts the previous day's voucher register (sales, purchase, journal, delivery note, receipt note), the TDS register, the GST output register and the bank reconciliation status, output to CSV or a staging database for the downstream reconciliation tool.

Three patterns. First, Data Entities — D365 exposes structured business objects (Sales Order, Purchase Order, Customer Invoice, Vendor Invoice, Inventory Transactions, Withholding Tax register, GST Output) as Data Entities consumable via REST API or scheduled bulk export through the Data Management Framework. Second, Logic Apps — Azure Logic Apps connectors for D365 F&O provide a no-code / low-code orchestration layer for scheduled extracts, with native error-handling, retry and credential management through Azure Key Vault. Third, Synapse Link — D365 F&O can stream change-data to Azure Synapse Analytics for near-real-time analytics use cases, which can also be used as a reconciliation-tool feed. Standard pattern at a mid-Tier-1 on D365: Logic Apps scheduled flows pulling Data Entities exports daily to a staging area in Azure Blob or Synapse, with the reconciliation tool reading from the staging area.

FOMP — Field Operating Manufacturing Plant — is the OEM-internal designation for a warranty back-charge that has been root-caused to a specific component supplier. A normal field warranty claim is registered by the OEM dealer when the customer reports failure, covered by the OEM's customer warranty, and processed through the OEM warranty system. The FOMP back-charge is a separate downstream event: the OEM's technical service team analyses the failed part, confirms the failure mode is supplier-attributable rather than design-attributable or misuse-attributable, traces the part back to a specific dispatch lot through batch coding, and raises a FOMP debit on the supplier. The supplier sees the FOMP debit on the running account 6-9 months after vehicle sale on average, sometimes up to 18 months for slow-failure modes like corrosion or fatigue cracking.

Ind AS 37 requires recognition of a provision when there is a present obligation (legal or constructive) arising from a past event, settlement is probable, and the amount can be reliably estimated. For FOMP back-charges the obligating event is the dispatch of the part — once the part is at the OEM and has been incorporated into a vehicle that has been sold, the supplier has a constructive obligation under the master supply agreement to bear back-charges on confirmed failures attributable to that part. Reliable estimation comes from the supplier's historic FOMP run rate (typically 1-3% of trailing monthly billing) trended by OEM and by part family. Indian Tier-1s with material OEM exposure typically carry a 4-6% FOMP provision on the balance sheet — ₹16-24 crore for a ₹400 crore revenue supplier — refreshed quarterly against actual claim closure.

Section 34 of the CGST Act allows the supplier (not the OEM) to issue a GST credit note when the originally supplied goods are returned, found deficient, or the originally charged value or tax is reduced. For FOMP back-charges with physical return of the failed part, the supplier issues a Section 34 credit note matching the back-charge amount to reverse the original output GST. The credit-note window runs until 30 November of the next financial year or filing of the annual return, whichever is earlier. FOMP claims with claim IDs raised after the cutoff cannot reverse GST through Section 34 — the back-charge becomes a commercial-only recovery and the GST liability stands. For FOMP back-charges where the part is not physically returned (rework done in field, scrap retained at OEM), the credit-note treatment is the same but with stronger documentation requirements to defend the credit at audit.

Yes, subject to root-cause traceability and Tier-2 contractual terms. The Tier-1 must establish through the 8D response and root-cause analysis that the failure is attributable to a component or sub-assembly supplied by the Tier-2 — typically a forging, casting, machined part, or sub-assembly that the Tier-1 has bought, assembled, and dispatched. Where the master supply agreement with the Tier-2 contains a warranty back-charge clause aligned to the OEM's regime, the Tier-1 raises a back-charge on the Tier-2 mirroring the OEM debit. Industry data suggests at least 30% of legitimate Tier-2 passthrough opportunities are never raised in Excel-based environments — the OEM claim ID is not linked to the Tier-2 batch in time and the recovery window expires.

8D (eight-disciplines) is the structured root-cause analysis methodology — D1 team formation, D2 problem definition, D3 containment, D4 root cause, D5 corrective action, D6 implementation, D7 prevention, D8 closure — used across the automotive industry to investigate field failures. The OEM requires the supplier to submit an 8D response within a contractual window (typically 14-30 days from claim ID notification) covering the failed batch, the suspected root cause, immediate containment measures, and the corrective action plan. The 8D itself does not credit back the FOMP debit — that requires the OEM's technical service team to accept the analysis and re-categorise the failure as design-attributable or misuse-attributable. But a missed 8D deadline forecloses the dispute option entirely; the FOMP debit becomes uncontestable.

A drop or press forging line moves the billet through five named stages — billet heating (induction or gas furnace to forging temperature), die-forging (the actual hammer or press stroke that imparts the geometry), trimming (cutting away the flash that has squeezed out between the die halves), heat-treatment (normalising, quenching, tempering for mechanical properties) and machining (rough or finish turning, milling, drilling). Each stage produces a discrete material loss: scale from the heating leg at 1-3%, flash from the die-forging leg at 15-30%, trim scrap at the trimming leg, descale from heat-treatment, and machining swarf from the machining leg. The closing identity is billet weight in equals finished forging weight × dispatched quantity plus scale plus flash plus trim plus descale plus machining swarf plus permitted process loss.

Forging die life is dominated by the operating temperature and the part complexity. Hot forging of plain-carbon steel components at around 1,150 to 1,250 degrees Celsius gives a typical die life of 5,000 to 30,000 forgings per cavity — heavy crankshafts and connecting rods sit at the lower end because the deformation is severe and the die-cavity surface degrades quickly; simpler bolts and small fittings sit at the higher end. Warm forging gives longer life; cold forging gives the longest life because there is no thermal fatigue. Under Ind AS 16, the die is capitalised if it is identifiable, controlled, has future economic benefit beyond one year, and exceeds the entity's capitalisation threshold — typically yes for any production forging die — and is depreciated over its expected forging-cycle life rather than calendar months. A revenue-expense treatment is appropriate only for trial-run or prototype tooling that does not meet the future-benefit test.

Forging is a closed-die metal-flow process. The billet is heated, placed in the lower die half, and the upper die half strikes (drop hammer) or presses (mechanical or hydraulic press) it into shape. To guarantee complete die-cavity fill, the billet must be deliberately oversized — surplus metal squeezes out radially through the die parting line as flash. The flash is then trimmed off in a separate trimming press. The structural reason the flash fraction is so high is metallurgical: under-filled die cavities give defective forgings (laps, folds, incomplete features), so engineers err on the side of flash. Total non-product loss across heating scale (1-3%), flash (15-30%), trim residue (small) and pre-machining envelope (5-10%) commonly puts billet-to-finished-forging yield at 60-75% before machining and around 50-65% after machining.

There is no GST-rate distinction between hot, warm and cold forging — all forging services rendered on free-issue material fall under HSN 9988 at 18%, and forged-component sales (where the supplier owns the steel) fall under the relevant chapter-heading for the finished part. The substantive accounting difference is on the cost side: hot forging carries higher furnace energy cost, higher die-amortisation per forging because of shorter die life, and higher scale loss (1-3%), while cold forging carries higher press tonnage and lubrication cost but lower scale loss and longer die life. The conversion-rate negotiation, the die-amortisation absorption and the yield-norm contracting differ for each process — and the supplier's master data must keep them on separate cost-stage maps so that an OEM yield audit on a hot-forged crankshaft line cannot be conflated with a cold-forged bolt line on the same shop floor.

Forged drivetrain components — crankshafts, connecting rods, axle shafts, gears in blank form — are usually single-source or dual-source at the OEM. The forging die is part-specific and expensive, the supplier-development cycle is long, and the OEM cannot quickly switch source if a forging defect surfaces on the production line. A latent defect — internal flow line, decarb, micro-crack from a heat-treatment cycle — that the supplier did not catch in inspection but that surfaces during OEM machining or assembly triggers a debit note covering not just the rejected forging value but the OEM's downstream rework and line-stop cost. The reconciliation must accept and book these debit notes against the original delivery, against the heat-treatment lot, and against the supplier's quality-cost reserve under Ind AS 37 — a practice covered in detail in our PPM debit-note article.

Form 26AS is the legacy consolidated tax-credit statement that ran through FY 2025-26 — generated under Rule 31AB of the Income Tax Rules, it consolidated TDS / TCS credits, advance-tax payments, refund details, AIR information and SFT entries. From FY 2026-27 onwards, Form 168 replaces it as the consolidated tax-credit statement under the Income Tax Act 2025 framework. The substantive content overlap is high — both carry deductor TAN, deductor name, transaction date, amount paid/credited, TDS deducted, payment code — but Form 168 uses the new 1001-1092 payment-code taxonomy (1024 for contractor, 1031 for purchase, 1057 for foreign commission, 1071 for scrap TCS) while Form 26AS used the legacy 194x codes (194C, 194Q, 195, 206C). During the cross-era window an auto-component supplier downloads both — Form 26AS for any FY 2025-26 lineage still in correction and Form 168 for FY 2026-27 onwards.

Five recurring mismatch causes. First, deductor error — the OEM has used wrong PAN (often historical PAN if the supplier merged or restructured) or wrong TAN section. Second, late deductor filing — the OEM has not filed its TDS return for the quarter, so the supplier's credit does not appear in Form 168 yet. Third, code mismatch — the OEM has deducted at the wrong payment code (e.g. code 1024 when the supply was raw material under code 1031). Fourth, value mismatch — the OEM has deducted on a value that includes GST when contracts specify TDS on pre-GST value. Fifth, missing deduction — the OEM has not deducted at all on a contractually-deductible transaction. Resolution runs through TRACES portal correction statements, OEM commercial team escalation, or in extreme cases an Annexure to the assessment for direct credit claim.

Foreign-currency commission paid to overseas sales agents on auto-component export orders attracts TDS under Section 393(2) Sl. 17 of the Income Tax Act 2025, with payment code 1057. The TDS rate is the applicable rate per the DTAA (Double Taxation Avoidance Agreement) with the agent's country of residence — typically 10% to 15% — and is deducted at the time of credit or remittance, whichever is earlier. The deduction appears in the supplier's outbound TDS register (it's a TDS the supplier is deducting on its outbound payment to the agent, not an inbound deduction from an OEM). It shows up in the supplier's Form 26Q quarterly return and the agent's Form 168 — but not in the auto-component supplier's own Form 168, because Form 168 captures inbound deductions only.

Five-step monthly routine. First, log into the TRACES portal on the 15th of every month and download Form 168 (and legacy Form 26AS where any FY 2025-26 lineage is still in correction). Second, segregate downloaded entries by OEM TAN — a typical Tier-1 has 4 to 8 OEM TANs. Third, match each line against the supplier's books — original invoice number, gross billing, TDS deduction percentage, deducted amount, payment code (1024 for contractor under Section 393(1) Sl. 6(i).D(b), 1031 for purchase under Section 393(1) Sl. 8(ii)). Fourth, route mismatches to a Form 168 dispute register with deductor-side action required. Fifth, file a quarterly Form 168 reconciliation summary at the controller-level review showing matched / mismatched / under-investigation / closed.

Cross-era handling follows the lineage of the original deduction. A deduction made by Tata Motors on 12 February 2026 under legacy Section 194C stays under that lineage even if the mismatch is discovered during the FY 2026-27 reconciliation cycle. The supplier raises the dispute with the deductor referencing the original Form 26AS entry, the deductor files a correction statement on TRACES under the legacy code 194C, and the corrected entry reflects in the supplier's Form 26AS (not Form 168). Form 168 carries fresh deductions from 1 April 2026 onwards under codes 1024 / 1031 / 1057 / 1071. The two streams must be reconciled separately during the cross-era window — never net legacy 194x deductions against new code 1001-1092 deductions in the same reconciliation register.

Free-issue steel does not sit in the supplier's financial books at all. It never crosses the purchase journal, never appears as inventory in the financial trial balance, and never enters the cost of materials consumed. Legal ownership stays with the OEM (or the nominated steel mill the OEM has price-protected under a nomination). The supplier holds the steel in a memorandum-only quantity ledger denominated in metric tonnes, with sub-ledgers per OEM principal, per grade, per coil. The supplier's P&L recognises only the conversion service it supplies. The memorandum ledger is the OEM's stock at the supplier's premises and must reconcile to the OEM's free-issue statement and to the supplier's physical FI stock.

Free-issue material is dispatched by the OEM to the stamping supplier on a delivery challan under Rule 55, with no GST on the dispatch, because the steel is not being supplied — it is being given for processing under the Section 143 job-work model. Under Schedule II of the CGST Act, any treatment or process applied to another person's goods is a supply of service. So the stamping supplier's invoice carries GST on its conversion charge only (the pressing service, typically at 18% HSN 9988) and not on the steel value. If the FI inputs fail to return as finished parts within one year, Section 143(3) deems the original dispatch a supply on its original date with GST and 18% interest under Section 50, but the obligation in that case falls on the OEM-principal, not the supplier.

Process-loss tolerance is set contractually with the OEM by material grade and part geometry. Indicative bands for cold-rolled mild steel (IS 513 commercial-quality grades) are around 1.0 to 1.5% beyond the theoretical yield; for hot-rolled commercial grades around 1.5 to 2.0%; for high-tensile and advanced high-strength steels (DP, HSLA, dual-phase) and stainless 2.0 to 3.0%, because formability is harder and trial reject is higher; for aluminium body-panel grades 1.5 to 2.5%. Yield itself depends on nesting and part geometry — small deep-drawn brackets can run 55 to 70% yield, large flat panels 80 to 90%. The contract pins both the yield norm and the process-loss tolerance per part and per grade; anything beyond the tolerance is a recoverable from the supplier at the contracted FI value.

An OEM free-issue audit is a physical reconciliation of every FI material location at the stamping supplier's plant against the memorandum ledger and against the OEM's FI dispatch statement. Auditors weigh or count coil stock in the raw-material yard, weigh or count WIP at every press line, weigh skeleton-scrap bunkers, count finished parts not yet dispatched, and reconcile to closing = opening + received − (finished dispatched + scrap returned-or-sold + process loss). They cross-check delivery challans under Rule 55, the supplier's memorandum ledger, the OEM's FI dispatch advices, and weighbridge tickets for both inbound coil and outbound scrap. The audit is typically annual or half-yearly, with surprise inspections for high-value grades. An unexplained shortfall beyond contracted tolerance is recovered from the supplier.

Section 394 of the Income Tax Act 2025 (payment code 1071, replacing legacy Section 206C(1)) requires the seller of scrap to collect TCS at 1% of the sale value from the buyer at the time of debiting the buyer's account or receipt, whichever is earlier. It is triggered when the supplier retains the skeleton scrap (under an agreed scrap-credit arrangement with the OEM) and sells it externally to a scrap dealer — the supplier is the legal seller and collects 1% TCS from the dealer. It is not triggered when the supplier returns the skeleton scrap to the OEM on a delivery challan (no sale, no TCS), nor when the OEM itself sells the scrap from its own premises. The economic benefit of the scrap may flow to the OEM via the scrap-credit netting, but the TCS obligation sits with whoever is the legal seller of the scrap to the external dealer.

Free-issue steel is steel coil that the OEM — or a steel major such as Tata Steel or JSW nominated by the OEM under a price-protected nomination — supplies to a stamping supplier at no charge, for the supplier to press into parts and return as finished components. The supplier never buys the steel and never records it in its purchase books; it is held memorandum-only, in a quantity ledger tracked in metric tonnes, because legal ownership of the FI material stays with the OEM throughout. The supplier bills only its conversion charge (the pressing labour, tooling amortisation and overhead), not the value of the steel. Reconciliation is therefore a quantity reconciliation — tonnes in, parts and scrap out — rather than a value reconciliation.

Where an OEM supplies steel free-issue and the supplier presses it and returns the finished part, the arrangement is treated as job-work. Under Section 143 of the CGST Act the OEM (principal) can dispatch the FI steel to the stamping supplier (job-worker) on a delivery challan without GST, provided the inputs return within one year. The supplier charges GST only on its conversion/job-work charge, not on the value of the FI steel — because the steel is not the supplier's supply. Schedule II of the CGST Act classifies treatment or process applied to another person's goods as a supply of service, which is what the conversion charge represents. No GST attaches to the free-issue steel itself when it is processed and returned within the statutory window.

Skeleton scrap — also called engineering scrap or web scrap — is the perforated steel lattice left after blanks are stamped out of a coil or sheet. Stamping yields are typically 65-85%, meaning 15-35% of the FI steel by weight leaves as skeleton scrap depending on part geometry and nesting efficiency. Because the steel was free-issue and owned by the OEM, the skeleton scrap is also OEM-owned by default, so it cannot simply be treated as the supplier's own waste. It must be reconciled: returned to the OEM (on a delivery challan), or retained by the supplier and sold under an agreed scrap-credit arrangement — in which case the sale attracts Section 394 scrap TCS at 1% (payment code 1071) and the scrap credit is netted against the supplier's conversion charges.

When the OEM allows the stamping supplier to retain and sell the skeleton scrap, the value of that scrap is usually credited back to the OEM rather than kept by the supplier — because the OEM owned the underlying steel. The mechanism is a scrap credit netted against the conversion-charge invoice: the supplier raises its conversion charge, computes the scrap recovery at the agreed scrap price per tonne on the actual scrap weight, and either deducts it from the conversion invoice or issues a separate scrap-credit note to the OEM. Reconciliation must tie the generated skeleton-scrap tonnage to the scrap-credit value, ensure the Section 394 TCS leg on any external scrap sale is closed, and confirm the net conversion charge ties to what the OEM pays.

A free-issue material audit is the periodic reconciliation of the memorandum FI quantity ledger against physical stock and against consumption. It closes the yield equation: opening FI steel balance + FI steel received − (finished parts dispatched + skeleton scrap returned-or-sold + permitted process loss) = closing FI balance, all in tonnes. Because the OEM owns the steel, any unexplained shortfall is the supplier's liability — the OEM will recover the value of missing free-issue material. OEMs commonly require a monthly or quarterly FI reconciliation statement, and a physical FI stock count at least annually. A persistent negative yield variance beyond the agreed process-loss tolerance is treated as a recoverable from the supplier.

Evaluated Receipt Settlement (ERS) is a procure-to-pay mechanic where the OEM, not the supplier, raises the document that triggers payment — typically a self-billed invoice or a consumption-evidenced settlement file — based on the OEM's own goods-receipt and consumption records. The supplier does not raise a tax invoice on dispatch to consignment stock; instead, the OEM consumes from stock at the point of production-line draw-down, the consumption is logged in the OEM's MES system, and at weekly or monthly intervals the OEM produces a self-billed invoice in the supplier's name. The supplier counter-acknowledges the self-invoice and reports it in the supplier's own GSTR-1 as if the supplier had raised it. The operational advantage to the OEM is huge — invoice-matching frictions disappear, payment cycles compress, and the supplier's working capital is locked into the consignment stock until consumption. The GST framework follows the consumption-date as the time-of-supply, not the dispatch-to-consignment date.

Section 31 of the CGST Act fixes the time of supply for goods at the earlier of the date of issue of the invoice and the last date on which the invoice is required to be issued under Section 31(1) — which is the date of removal of goods. For a normal dispatch the two dates collapse into the dispatch date. For a consignment-stock dispatch, the position is different because Section 31(7) explicitly carves out approval-and-consignment patterns: where goods are sent on approval or for sale, the time of supply is the date the goods are actually taken by the recipient — that is, the withdrawal-from-consignment date, not the deposit-into-consignment date. The Rule 55 delivery challan on initial dispatch to the OEM's consignment warehouse does not trigger GST. The Section 31 tax invoice is issued only at the point of withdrawal-driven consumption, and the supplier discharges output GST in the GSTR-3B of the consumption month. The wider consignment-stock and VMI mechanic, including the inventory-ownership question, is in [Consignment stock and VMI reconciliation for auto components](/insights/consignment-stock-vmi-reconciliation-auto-india/).

No. Reverse-charge under Section 9(3) applies to specific notified categories of supplies (goods transport agency services, legal services from advocates, sponsorship services and so on) and under Section 9(4) historically applied to procurement from unregistered persons (largely suspended for most categories since 2017). ERS in a Tier-1 to OEM relationship is a registered-to-registered B2B supply between two GST-registered businesses, and the supplier remains the actual supplier of the goods even though the OEM is operationally the document-raiser. Output GST is paid by the supplier, ITC is availed by the OEM, and the forward-charge mechanism continues to apply. The ERS self-invoice is not a reverse-charge document — it is a procedural delegation of invoice-raising from supplier to OEM, agreed contractually and acknowledged by both parties' GST registrations. This is a common confusion at first-time ERS implementations and is sometimes mishandled at the supplier's GSTR-1 stage as a reverse-charge supply.

Schedule I to the CGST Act deems certain transactions to be supplies even without consideration. Paragraph 1 of Schedule I read with the time-of-supply rules creates an operational reading: where goods are sent on consignment and remain in the consignment warehouse without withdrawal for more than 6 months, the position is no longer cleanly Section 31(7) approval-and-consignment — the goods are deemed to have been supplied at the original dispatch date and GST becomes payable from that date with Section 50 interest at 18% per annum from the original dispatch. The 6-month window is operationally driven by the audit position that has settled across most state jurisdictions, anchored in the broader principle that approval-and-consignment is a temporary arrangement and not an indefinite warehousing of supplier inventory at customer premises. A Tier-1 supplier sending fasteners to a Bajaj consignment warehouse must reconcile the consignment-position monthly and force-consume or withdraw any stock approaching the 6-month line.

Consumption-month, not dispatch-month. The Section 31(7) time-of-supply rule fixes the supply at withdrawal; the OEM's ERS self-invoice is dated as of the withdrawal-week or withdrawal-month; the supplier counter-acknowledges and reports the invoice in the GSTR-1 of the same calendar month as the OEM's withdrawal-stamped self-invoice. The supplier's GSTR-1 line item must carry the OEM's GSTIN, the self-invoice number issued by the OEM, the taxable value, the HSN and the GST. The OEM's GSTR-2B will pick up the same invoice in the same month and the OEM avails ITC in the consumption-month GSTR-3B. The reconciliation rule for the supplier: weekly ERS self-invoice files from the OEM must be loaded into the supplier's GSTR-1 staging table during the month and reconciled to the consignment-position movement at month-end. The wider Bajaj-style daily-consumption ERS workflow is below.

Section 34(1) requires a supplier to issue a credit note where the taxable value or tax charged in a tax invoice exceeds the taxable value or tax payable on the actual supply — typically because of post-supply price reduction, quality return, deficient supply, or rate-revision. In auto-component contexts the triggers are RMPV downward revisions (the JPC steel index drops between dispatch and revision review), OEM short-pay acceptance on quality or quantity issues, and full or partial physical returns of rejected parts. The credit note is issued by the supplier — never by the OEM — even where the OEM has raised a commercial debit note for the same transaction.

Section 34(2) sets the deadline at 30 November of the financial year following the year of supply, or the date of filing the annual return for that year, whichever is earlier. A credit note against an FY 2025-26 invoice must therefore be issued by 30 November 2026 (assuming the annual return is filed later). Beyond this date the supplier can still issue a commercial credit note for accounts purposes, but it cannot be reported in GSTR-1 Table 9B and the corresponding output GST cannot be reversed — the GST liability stands as a permanent leakage.

Section 34 does not retroactively shift the time of supply on the original invoice. The original invoice remains the supply-time anchor for the originally-billed value. The credit note is a separate document with its own date of issue, which becomes the reporting date in GSTR-1 (Table 9B) and the adjustment date in GSTR-3B (Table 4(B)(1) or Table 3.1(a) reduction depending on classification). The recipient (OEM) must reverse the proportionate ITC in the period in which the credit note is received, per Section 16(2) read with Rule 37.

GSTR-1 Table 9B captures B2B credit notes against registered recipients (Tables 9B(1) for credit notes against debit-card and 9B(2) for amended versions). The CDNR (Credit/Debit Notes — Registered) JSON section carries the original invoice number reference, the credit-note number, date, value, taxable amount, IGST/CGST/SGST split and reason. The GSTR-3B impact flows through the auto-population from GSTR-1 — the supplier's output tax liability in Table 3.1(a) is net of credit notes. There is no manual entry of credit notes in GSTR-3B if GSTR-1 has been filed correctly.

Yes. First, where there is no underlying reduction in taxable value or tax — for example an OEM debit purely for line-stop charges that is a separate supply of damages, not a value reduction. Second, where the recipient has already passed on the burden of GST to its customer and Section 34(2) proviso blocks the reduction. Third, where the original supply was zero-rated (export sales) — credit-note adjustment runs through different rules. Fourth, where the original tax invoice was an e-invoice but the credit note cannot reach the IRP because the recipient's GSTIN is inactive at the time of issue. These corner cases need separate accounting treatment outside the standard Section 34 flow.

On a typical end-customer warranty claim that travels Mahindra dealer to Mahindra OEM to brake-pad Tier-1, four GST-relevant documents move. Document 1 — the dealer issues either a replacement part to the customer free of charge (no GST document needed, the original sale invoice from dealer to customer covers the consideration), or a Section 34 credit note if the customer prefers a refund. Document 2 — the OEM either ships a replacement brake-pad to the dealer free of charge (a Rule 55 delivery challan with warranty-replacement narration, no GST), or raises a Section 34 credit note against the OEM's original sale invoice to the dealer. Document 3 — the OEM debits the Tier-1 supplier through the FOMP back-charge mechanism (a financial debit, not a GST document, accounted as receivable reduction). Document 4 — the Tier-1 ships a replacement brake-pad to the OEM on a Rule 55 delivery challan with warranty-replacement narration, no GST under CBIC Circular 195/07/2022. The four-document trail is reconciliation surface across three GSTINs.

Paragraph 2 of the circular says that supplier-borne warranty replacements are not fresh supplies and no GST is payable — this applies at the Tier-1 to OEM leg (document 4) and at the OEM to dealer leg (document 2 if the OEM ships a replacement rather than crediting). Paragraph 3 says the ITC on inputs used to manufacture warranty stock is preserved — applies at both legs. The dealer-to-end-customer leg (document 1) is outside the circular because the end-customer is typically a B2C unregistered party and the original sale invoice is treated as a B2C sale; the warranty replacement is part of the original consideration. The FOMP back-charge from OEM to Tier-1 (document 3) is a financial flow, not a supply — no GST document, no GSTR-1 line. The circular's two operational paragraphs cover the two B2B legs cleanly; the dealer-to-customer leg and the back-charge are outside the GST framework entirely.

Document 1 (dealer to customer): the original sale invoice from dealer to customer was issued at the time of original sale, typically months or years before the warranty claim. No fresh time-of-supply applies at the warranty replacement because the supply was already taxed. Document 2 (OEM to dealer): for a replacement supply, no time-of-supply because there is no fresh supply under the circular; for a Section 34 credit note, the credit-note date governs but Section 34 caps the credit-note window at 30 November of the following FY or the annual return filing date, whichever is earlier. Document 3 (FOMP back-charge): not a supply, no time-of-supply. Document 4 (Tier-1 to OEM): no time-of-supply because no fresh supply. The replacement-supply legs simply do not generate fresh tax-points. The Section 34 credit-note leg if used has the standard Section 34 timing rules.

The FOMP (Free-of-Material-Performance) back-charge is the OEM's mechanism for transferring the cost of a warranty replacement from the OEM's books back to the supplier whose part failed. Operationally the OEM debits the Tier-1's monthly settlement statement by the OEM's standard part cost (often a tabled rate, not the actual replacement-part value), reducing the Tier-1's cash receivable. In the Tier-1's books the back-charge is recorded as a reduction of revenue or as a warranty-cost charge against P&L; the exact accounting treatment depends on whether the original sale revenue is reclassified or whether a separate warranty-cost line is opened. The GST consequence is zero because the back-charge is a financial flow against an existing receivable, not a fresh supply or a return of an existing supply. There is no Section 34 credit-note from the Tier-1 against the back-charge because no original sale has been reversed — the parts physically went to production and the original sale stands. The full mechanic is in [FOMP warranty back-charge accounting for auto components](/insights/fomp-warranty-back-charge-accounting-auto-india/).

Six artefacts together: (1) the Tier-1's Rule 55 delivery challan for the replacement part to the OEM with warranty replacement against OEM original-sale-invoice and date narration; (2) the Tier-1's warranty-claim register tying the Rule 55 challan to a unique warranty-claim ID; (3) the OEM's warranty-claim system extract showing the dealer-side claim that triggered the chain; (4) the OEM's monthly FOMP back-charge debit-note tied to the warranty-claim ID; (5) the Tier-1's input-ITC trace showing the production run from which the warranty replacement was drawn (preserves the Rule 42 non-reversal under circular paragraph 3); (6) the dealer-side warranty claim record (typically obtained through the OEM if required at audit, not directly from the dealer). A Tier-1 maintaining the six-artefact pack live throughout the year defends the position cleanly; one that builds it retrospectively at audit usually surfaces material gaps in artefacts 3 and 6 and faces re-classification risk on the warranty replacements as fresh supplies subject to GST.

Most parts and accessories of motor vehicles of headings 8701 to 8705 — that is, components for tractors, passenger cars, commercial vehicles, buses and trucks — fall under HSN 8708 and attract GST at 28%. This covers engine parts (other than those classified under separate engine-component headings), transmission and gearbox parts, clutches, brakes and brake parts, road wheels, suspension components, steering wheels and columns, body panels, bumpers, fuel tanks, silencers and exhaust pipes, and most other identifiable motor-vehicle parts. The 28% rate has been the standing rate on HSN 8708 since the GST regime began on 1 July 2017 and has not been disturbed by subsequent Council notifications.

Several categories of auto-relevant goods sit at 18% under their own HSN headings rather than HSN 8708, because they have wider non-automotive use and the GST Council classifies by the goods themselves rather than by their automotive use. Ball, roller and needle bearings under HSN 8482 attract 18%. Many electrical and electronic items used in vehicles — ignition coils, starter motors and generators under HSN 8511, lead-acid batteries under HSN 8507, lighting equipment under HSN 8512, certain wiring harnesses — attract 18% under their respective electrical headings. Tyres for passenger cars under HSN 4011 attract 28%, while tyres for tractors and certain off-road vehicles sit at lower rates. The classification rule is that a component is taxed under its most specific heading; only when no more specific heading applies does it fall to the residual HSN 8708 at 28%.

Electric vehicles themselves — completely-built electrically-operated motor vehicles under HSN 8703 (passenger) and HSN 8704 (goods carriage) — attract a concessional GST of 5%, reduced from 12% via Notification 12/2019-Central Tax (Rate) with effect from 1 August 2019. The 5% rate also extends to chargers and charging stations for electric vehicles. Lithium-ion batteries for EVs under HSN 8507 60 00 attract 18%; lithium-ion batteries for other uses also attract 18%. EV-specific propulsion components — electric drive motors, controllers, power-electronics modules — when supplied as parts identifiable for EVs follow the HSN 8708 28% rate unless a more specific electrical heading at 18% applies, which is the substantive area of post-supply classification dispute and which the GST Council has periodically addressed.

Job-work services performed on goods belonging to another person — which is the dominant model for plating, heat-treatment, machining, painting, anodising, phosphating and assembly in the auto industry — fall under HSN 9988 and attract GST at 18% on the conversion charge. The supplier is not selling the goods, only the service, so the rate applies on the service value alone, not on the value of the input goods owned by the principal. Assembly services (HSN 9988 sub-headings) and engineering design services (HSN 998311) also attract 18%. The GST treatment runs in parallel with the Section 143 goods-movement model: the inputs move on Rule 55 delivery challan without GST, and only the conversion service carries the 18% rate.

Section 9(5) of the CGST Act empowers the government to notify categories of services where the electronic-commerce operator (ECO) — the marketplace — pays the GST on behalf of the supplier. For physical goods such as auto-spare-parts, however, Section 9(5) has not been triggered: the goods are supplied by the seller (the spare-part supplier) and tax is collected by the seller, while the marketplace separately collects 1% TCS on the supply under Section 52 of the CGST Act. So an aftermarket auto-spare platform like Boodmo or any other electronic marketplace does not pay output GST on behalf of the seller for the spare-part sale itself — the seller does — but the platform deducts and remits 1% Section 52 TCS to the credit of the seller, who then claims it as a credit through GSTR-2A / 2B.

The legal answer is driven by Section 2(19) of the CGST Act, which defines capital goods as goods the value of which is capitalised in the books of account of the person claiming the credit and which are used or intended to be used in the course or furtherance of business. In the most common OEM-funded tooling pattern — the OEM pays a one-time tooling charge, the supplier capitalises the die and recovers the tooling cost through a per-piece amortisation built into the part price — the supplier is the person who capitalises the asset and uses it in business, and the supplier is the person who claims the ITC. The OEM does not capitalise (it has expensed the tooling charge into programme-development cost) and therefore cannot claim ITC. Where the OEM both funds and retains ownership, capitalises the die in its own books, and bails it to the supplier on a free-issue or returnable-tooling basis, the position flips and the OEM holds the ITC — but this pattern is the exception in Indian Tier-1 to Tier-2 chains.

Rule 42 of the CGST Rules deals with the apportionment of input and input-service ITC where the registered person makes both taxable and exempt supplies. Rule 43 deals with the same apportionment for capital-goods ITC, but spreads the credit attribution over the useful life of the asset — 60 months from the date of invoice — instead of computing month-by-month on actual consumption. A stamping die or injection mould is a capital good (it lasts multiple years, depreciates, is not consumed in the act of production), so Section 16 of the CGST Act combined with Rule 43 puts the supplier on a 60-month ITC amortisation schedule. The monthly common-credit attribution under Rule 43 is one-sixtieth of the total ITC, and only the portion attributable to exempt or zero-rated supplies (proportionate to the exempt-to-total turnover ratio) reverses each month. The wider capital-goods ITC analysis is in [ITC on capital goods for auto-component manufacturers](/insights/input-tax-credit-capital-goods-auto-manufacturing-india/).

The standard mechanic is piece-rate amortisation invoicing. The supplier calculates the tooling cost per piece — ₹1.2 crore die divided by, say, 5 lakh forecast lifetime pieces equals ₹24 per piece — and adds that ₹24 to the part-sale price. Every shipped part carries the tooling-recovery wedge inside its taxable value, GST is charged on the full part price including the amortisation wedge, and the OEM gets its ITC on the part-purchase invoice. There is no separate tooling invoice raised. The supplier's books carry the die as a capital asset depreciating on accounting straight-line; the recovery on the receivable side runs in lockstep with sales volume. The full mechanic, including the Section 15 valuation question and the price-protection clause when actual lifetime pieces deviate from forecast, is in [Tooling cost recovery and amortisation for auto components](/insights/tooling-cost-recovery-amortisation-auto-component-india/).

Section 18(6) of the CGST Act and Rule 44(6) of the CGST Rules trigger a specific reversal on sale or transfer of capital goods. The amount payable equals the higher of (a) the ITC that remains unamortised on the remaining-useful-life proportion (computed as total ITC times the remaining months of the 60-month window divided by 60) or (b) the tax on the actual transaction value of the sale. If a Maruti-funded stamping die was capitalised on 1 April 2024 with ₹21.6 lakh of ITC and is sold at month 38, the remaining useful life is 22 months out of 60, the remaining unamortised credit is ₹21.6 lakh times 22 divided by 60 equals ₹7.92 lakh. If the sale value is ₹35 lakh and GST at 18% is ₹6.30 lakh, the reversal is the higher of the two — ₹7.92 lakh — paid in the GSTR-3B of the transfer month under Table 4(B)(2).

Yes, and this is a common source of reconciliation confusion. The OEM pays the one-time tooling charge — typically the full or near-full cost of the die — against a separate supplier invoice for tooling supply. That invoice carries GST at 18% (HSN 8207 for interchangeable tools) and the supplier remits the GST in the month of issue. The OEM does not capitalise the die (it expenses or amortises against programme cost) and the OEM's ITC position depends on whether the tooling charge is treated as a part-cost amortisation in its own programme accounting — most Indian OEMs do treat it as part of inward supply and avail the ITC. So the same ₹1.2 crore tooling can carry GST twice in the chain: once on the OEM-to-supplier tooling charge, once on the part-price amortisation wedge in every subsequent part shipment. The reconciliation requirement is that the supplier's books separate the two flows cleanly so that the 60-month Rule 43 schedule attaches only to the supplier's capitalised asset, not to the OEM-paid tooling-charge invoice.

CBIC Circular 195/07/2022 dated 17 July 2022 settled the position: where the supplier replaces a defective part during the warranty period without charging the recipient, the replacement is not a separate supply for GST purposes because the consideration for the replacement was already absorbed in the price of the original sale and GST was discharged on that original sale. No fresh GST is payable on the replacement and the supplier does not need to reverse ITC on inputs used for the warranty stock — the circular is explicit on both legs. The pre-circular position had been ambiguous, with some field officers treating free replacements as Schedule I deemed supplies between related or otherwise-engaged parties; the circular closed that interpretation. For unrelated-party warranty supply between a Tier-1 supplier and an OEM customer, the position is clean.

Schedule I to the CGST Act deems certain transactions to be supplies even when made without consideration — supplies between related persons or distinct persons under Section 25, supplies by a principal to an agent, and a few other narrow categories. A warranty replacement from a Tier-1 supplier to an unrelated OEM customer does not fall into any Schedule I category because the parties are not related under Section 15 (no common control, no holding-subsidiary, no common partner) and not distinct persons under Section 25 (different legal entities with different PAN). The transaction is between two arm's-length entities and the consideration for the original sale already accounted for the warranty obligation. Schedule I would only come into play if the Tier-1 were replacing parts for a related or branch-related OEM where the original sale had not borne GST on the warranty-loaded value, or if a Tier-1 were giving warranty replacements to its own employees free of charge against a separate end-customer warranty claim.

Pre-circular, this was the operational ambiguity. If a warranty replacement is treated as a non-supply, then the inputs used to manufacture it might be argued to be inputs used for a non-supply, triggering Rule 42 reversal of common credit. CBIC Circular 195/07/2022 closed this argument too. Paragraph 2 of the circular is explicit: ITC on inputs used to manufacture warranty replacement parts does not need to be reversed because the original sale on which GST was paid is treated as having absorbed the warranty-replacement consideration. The supplier retains the full ITC. This is a critical position for high-warranty-rate businesses like brake-pads, electronics and friction parts, where the supplier might consume 0.5% to 2% of monthly production as warranty replacement — reversing ITC on those inputs would have created a permanent leakage proportional to the warranty rate.

Three documents anchor the audit defence. First, a Rule 55 delivery challan from the supplier's plant to the OEM under the explicit description warranty replacement against invoice number and date, with no GST charged. Second, the supplier's internal warranty-claim register tying the replacement back to the original sale invoice, the failure-mode analysis, and the OEM's warranty-claim reference. Third, the original sale invoice on which the GST was paid — retrieved and cross-referenced for any audit query. Some Tier-1s additionally raise a zero-value tax invoice with explicit warranty replacement under CBIC Circular 195/07/2022 in the narration field; this is not strictly required but is helpful in some state-jurisdiction audits where the field officer asks for a tax-invoice trail rather than a challan-only trail. The wider documentation discipline, including the FOMP back-charge accounting where the OEM debits the supplier for warranty cost, is in [FOMP warranty back-charge accounting for auto components](/insights/fomp-warranty-back-charge-accounting-auto-india/).

Yes — fundamentally. CBIC Circular 195/07/2022 covers the supplier-bears-warranty pattern where the cost of the replacement is absorbed by the supplier and the original sale GST is treated as discharging the warranty obligation. If the OEM pays the supplier separately for the warranty replacement — for example under a paid-warranty programme or where the failure is outside the warranty terms and the OEM purchases the replacement — then the transaction is a fresh supply at the agreed consideration, GST applies at the standard part rate (typically 18% for HSN 8708 parts), and the original-sale-absorbs-warranty argument does not apply. The reconciliation must classify each replacement at the point of dispatch: warranty-bearing (no GST, no ITC reversal) versus paid-replacement (full GST, full ITC). Misclassification at dispatch is the single most common audit finding on warranty supplies.

GSTR-2B is generated by the GST portal on the 14th of every month for the preceding tax period and is then static for that recipient — it captures every supplier invoice with an IRN dated through the 11th of the month of generation that was uploaded to GSTR-1 or IFF by the supplier on or before the 13th. For an auto-component manufacturer the practical consequence is that any plater or heat-treater conversion invoice not on the supplier's GSTR-1 by 13th of the next month sits out of 2B for that tax period and the ITC moves to the next month at the earliest. Late-uploaded supplier invoices show up in the next 2B with the original invoice date preserved, which is why the running 2B-to-purchase-register cross-foot has to span at least three rolling tax periods.

The Invoice Management System (IMS) on the GST portal lets the recipient act on each inward invoice that appears in 2B with one of three actions: accept (the invoice flows into the recipient's GSTR-2B and ITC), reject (the invoice is removed and the supplier is notified to correct or cancel), or keep pending (the invoice stays in IMS for action in a later period, up to the limit set by the proviso to Section 16(4)). For auto-component principals the typical pending case is a conversion invoice received from a job-worker where the underlying Section 143 challan return is still open or the quantity on the invoice does not match the GRN — the recipient parks it in IMS until the physical reconciliation closes. Rejected invoices push the supplier to a credit note or correction; accepted invoices lock the ITC for the period.

Five patterns dominate. First, HR coil and special-bar invoices from multi-state mills uploaded under the wrong tax type (IGST entered as CGST+SGST or vice-versa) when the supplier's billing GSTIN, place-of-supply and ship-to plant fall across state lines. Second, conversion invoices from job-workers below the GST registration threshold under URP that the principal has to self-track without a 2B leg. Third, e-invoice-mandate suppliers whose IRN was generated but whose GSTR-1 upload slipped past the 13th. Fourth, supplier-side credit notes for post-dispatch quality rejections that lag the principal's debit note. Fifth, RCM-applicable purchases (transport of goods, legal services) that need a separate self-invoice flow and don't appear in 2B at all.

Section 16 sets four substantive conditions to claim ITC on any inward invoice: possession of a tax invoice or debit note, receipt of goods or services (deemed received under Section 143 when delivered to a job-worker on the principal's direction), tax paid by the supplier and reflected in GSTR-2B, and the recipient's GSTR-3B filed. Rule 36(4) constrains the claim further by requiring that the invoice appears in the recipient's 2B for the period of claim — claims on invoices not in 2B are disallowed. The provisional 20%/10%/5% buffer rules of earlier years are gone; from FY 2022-23 onward the rule is binary — in 2B and accepted in IMS, or no ITC. Section 16(4) caps the outer claim window at 30 November of the following year or filing of the annual return, whichever is earlier.

Operationally it is a service invoice under HSN 9988 (manufacturing services on physical inputs owned by others) at 18% GST. The principal's ITC eligibility is the same as on any input service — Section 16 conditions plus Rule 36(4). But the cross-reconciliation legs are different: the job-work conversion invoice ties back to the Section 143 delivery challan, not to a GRN of new material; the goods are deemed received by the principal even though they sit at the job-worker; the matching key is the principal challan and the job-worker invoice for the conversion charge, not invoice-against-PO. A 2B match on the conversion invoice does not by itself prove ITC-04 closure — those are independent disclosures that must both reconcile.

Three structural reasons. First, capital-goods ITC at an auto-component Tier-1 typically runs at 15% to 22% of total ITC because of the tooling, press-line and CNC-machining capex base — far higher than a services firm where input ITC dominates. Rule 43 attribution therefore becomes a Table 6 line that audits scrutinise closely. Second, Section 143 job-work flow creates open-balance positions that must reconcile to ITC-04 disclosures throughout the year — a position that simply does not exist for a services firm. Third, e-invoice mandates apply at higher volume to manufacturing supplies (every B2B invoice above the threshold carries an IRN) and Table 4 must reconcile to the IRN repository at line-by-line granularity. A services firm reconciliation pivots are mostly Table 8 (ITC versus 2B) and Table 5 (exempt supplies). An auto-manufacturer reconciliation pivots span all four of Tables 4, 5, 6 and 7 with specific manufacturing-side line items in each.

Pivot 1 — Table 4 outward supplies versus the e-invoice IRN repository for the FY. Pivot 2 — Table 4N inter-state versus intra-state place-of-supply classification across OEM plants in multiple states. Pivot 3 — Table 4I/4J credit notes versus the supplier's debit-note register against OEM short-pays. Pivot 4 — Table 5 nil-rated/exempt/non-GST outward supplies including SEZ exports and deemed exports. Pivot 5 — Table 5N supply on which no GST is payable (warranty replacement, samples, free-issue tooling). Pivot 6 — Table 6A total ITC availed versus GSTR-3B Table 4(A). Pivot 7 — Table 6B input ITC versus 6C capital-goods ITC split. Pivot 8 — Table 6E inward supplies under reverse-charge (legal services, GTA). Pivot 9 — Table 7A Rule 37 reversals versus 7B Section 17(5) blocks versus 7C Rule 42 versus 7D Rule 43 attribution. Pivot 10 — Table 8A GSTR-2B-as-on versus 8B ITC availed and the lock-in gap. Pivot 11 — Table 13 ITC availed on supplies of previous FY versus the GSTR-2B-pulled-forward. Pivot 12 — Table 17 HSN-wise outward summary versus the e-invoice IRN HSN data.

Table 6 of GSTR-9 splits total ITC availed across input ITC (6B), input-services ITC (6C in some forms and 6D in others depending on form version), capital-goods ITC (6C in the current form structure), and inward supplies under reverse-charge. The capital-goods row carries the full attribution for the year — that is, the sum of the 12 monthly one-sixtieth attribution entries that ran across the FY. Rule 43 reversals — both the proportionate Rule 43(1)(e) reversal for exempt turnover and any accelerated reversal under Section 18(6) for tools sold or transferred mid-life — land in Table 7. Table 7 separates Rule 37, Section 17(5), Rule 42 and Rule 43 reversals into distinct rows; the audit pivot is that the sum of the four reversal categories in Table 7 must equal the sum of all reversals filed across the 12 GSTR-3Bs of the year. A common audit finding is that Rule 43 reversals are aggregated with Rule 42 reversals into a single Table 7 line, breaking the pivot. The detailed Rule 43 mechanic is in [GST on auto-component tooling under Rule 43](/insights/gst-tooling-capital-goods-rule-43-auto-component-india/).

Table 8A of GSTR-9 carries the GSTR-2B aggregate ITC available for the FY as on the 30th of April following year-end — the cut-off date for ITC matching under Section 16(4). Table 8B carries the ITC actually availed by the manufacturer in its GSTR-3Bs across the FY. Table 8C carries the ITC availed in the subsequent year's GSTR-3Bs on supplies of the FY (the prior-year ITC pull-forward, capped by Section 16(4)). Table 8D is the residual gap — ITC available in 2B but not availed by the supplier. For an auto-component manufacturer with high job-work conversion-charge invoice volume from 25 to 40 sub-vendors, the 8D gap is structurally driven by vendor-side filing delays (the supplier files conversion-charge invoices in delayed GSTR-1s, the 2B is published with the entry, but the manufacturer's GSTR-3B already closed without availing). The Section 16(4) cut-off rule means the November-following-FY GSTR-3B is the last chance to avail; anything in 2B after that becomes a permanent leakage.

A clean audit-defence file has eight components. First, the FY e-invoice IRN repository extract aligned to Table 4. Second, the capital-goods register with the Rule 43 schedules for every capitalised tool and asset, aligned to Table 6C and Table 7. Third, the Section 143 job-work open-balance register with the year-end position from ITC-04. Fourth, the warranty-replacement dispatch ledger tied to original sale invoices, aligned to Table 5N. Fifth, the Rule 37 ageing register for vendor invoices past 180 days, aligned to Table 7A. Sixth, the GSTR-2B versus books reconciliation as on 30 April following FY, aligned to Table 8. Seventh, the credit-note register against OEM short-pays, aligned to Tables 4I and 4J. Eighth, the HSN-wise outward summary tied to the e-invoice IRN HSN data, aligned to Table 17. A Tier-1 that maintains these eight registers live throughout the year files GSTR-9 in two to three weeks; one that builds them at year-end takes six to ten weeks and surfaces the audit findings during the build.

Section 143 lets a registered principal (the auto-component supplier in this case) send inputs or capital goods to a job-worker on a delivery challan under Rule 55 without paying GST on the outbound movement, provided the material returns as inputs or finished goods within one year (three years for capital goods such as moulds, dies and fixtures). The principal must declare the job-worker's premises as an additional place of business if material is dispatched directly from there to the principal's customer; must file ITC-04 quarterly disclosing all challans dispatched, received-back and pending; and must reconcile against the one-year clock per challan. If the return clock breaches, the original dispatch is deemed a supply on its original date, with GST and 18 percent interest under Section 50 from that original date.

Process-induced weight loss is structural, not defect-driven, and the contract has to recognise it explicitly. In zinc electroplating, the part picks up plating mass (typically 5-15 micron coating, a small weight addition) but loses base metal to acid pickling and alkaline cleaning at the pre-plating stages — net weight change can be plus or minus 0.5 percent depending on the substrate. In nickel-chrome plating the net weight change is typically a small gain. In e-coat (cathodic electrodeposition) the gain is small but consistent at 0.3-0.8 percent. In carburising heat-treatment, surface scale loss is 0.5-1.5 percent. In induction hardening with quench-tempering, scale loss is 0.3-0.8 percent. Normalising and stress-relieving have negligible weight change. The contract must pin the expected weight-change band per process per part — anything outside that band on the returned challan triggers reconciliation.

ITC-04 is the quarterly statement that a job-work principal files on the GST portal, due by the 25th of the month following the quarter. It declares for each job-worker, for each challan: the challan number and date, the description and quantity dispatched, the corresponding receipt-back challan number and date and quantity returned, and the pending balance against the one-year clock. The reconciliation must tie the principal's outbound challan series under Rule 55 (consignor: principal, consignee: job-worker, no GST) to the inbound receipt-back challan or job-worker's tax invoice for the conversion service, against the one-year window per original-dispatch date. Material that has not returned at quarter-end is shown as pending; material whose clock has expired without return is deemed a supply on the original-dispatch date with GST and 18 percent interest.

Traditional hexavalent (Cr VI) chrome plating uses chromic acid solutions that release hexavalent chromium into wash water and fumes. Hexavalent chromium is a confirmed human carcinogen and is subject to tightening regulatory controls globally — EU REACH restrictions, Indian State Pollution Control Board limits on hexavalent chromium discharge, and OEM end-of-life vehicle directives. Trivalent (Cr III) chrome chemistry replaces hexavalent in the plating bath. The trivalent process is environmentally safer but generally more expensive per square decimetre of plated area, gives a slightly bluer chrome appearance, and requires tighter bath-chemistry control. Suppliers and their plating job-workers absorb the transition through revised plating-rate contracts and revised bath-chemistry control sheets. The reconciliation must track the chemistry generation of each plating line so the right rate is applied.

The plating job-worker raises a tax invoice for the conversion service only, at 18 percent GST under HSN 9988 (manufacturing services on physical inputs owned by others), on the per-square-decimetre, per-kilogram or per-piece rate contracted. No GST is charged on the substrate value — the substrate is the principal's, never owned by the job-worker. If the job-worker buys plating chemicals (zinc anodes, nickel salts, brighteners) and these are consumed entirely inside the bath, the chemistry cost is embedded inside the job-worker's conversion rate; there is no separate supply of chemicals. Section 194C TDS at 1 percent (HUF or individual job-worker) or 2 percent (other entities) applies to the principal's payment to the job-worker under the new payment-code rail, captured in Form 26Q quarterly.

Hero MotoCorp Tier-1 supplier payment terms typically run T+30 to T+45 days from GRN (goods-receipt-note) date at the receiving plant. The clock starts at GRN, not invoice date or dispatch date. Hero's cycle sits at the shorter end of the Indian OEM range, reflecting the operational discipline of a high-volume two-wheeler producer with a tight working-capital model. Higher-rated suppliers on critical programmes typically sit at T+30; lower-rated suppliers and entry-segment programmes typically sit at T+45. Settlement cadence is monthly across most programmes with fortnightly settlement on the highest-volume Splendor and Passion supply lines.

Splendor and Passion are India's longest-running, highest-volume two-wheeler programmes — together they account for the majority of Hero's annual production. For a Tier-1 supplier, the Splendor / Passion supply chain typically represents 50-70% of the Hero book by volume because these programmes consume the largest absolute quantities of aluminium die-cast engine cases, plastic body panels, steel frames, rubber components and fasteners. The reconciliation engine must key the Splendor and Passion volume-driver programmes separately from the discretionary-volume premium and EV programmes (Karizma, Xpulse, Xtreme, Vida) because per-part rate, RMPV exposure, FOMP running account and supplier-rating contribution differ materially between the high-volume mass programmes and the lower-volume premium programmes.

Hero operates RMPV (raw-material price variance) pass-through on commodity-linked Tier-1 parts where the rupee-content of aluminium, copper, steel or polymer is high enough that LME or domestic benchmark variance materially affects per-part cost. For aluminium die-cast engine cases on Splendor and Passion (where each engine case carries ₹180-₹260 of aluminium content), Hero typically operates a monthly RMPV settlement keyed to the LME aluminium cash settlement plus a contracted premium, with a 30-day lag from the LME settlement date to the RMPV settlement on the portal. For copper-content electrical components (wiring harness, ignition coil, stator), a comparable LME copper-linked mechanism applies. The supplier's reconciliation engine caps RMPV claims against the contracted formula and surfaces variance where the Hero RMPV settlement differs from the supplier's computed claim.

Hero applies per-piece quality back-charges on rejected lots — a defect rate above the contractual threshold triggers a debit at a contracted per-piece penalty rate applied to the rejected sub-batch. Typical penalty rates run ₹0.30 to ₹1.50 per affected piece on small components and ₹5 to ₹35 per affected piece on larger die-cast or plastic components. The per-piece structure (rather than per-100-piece) means the rupee value of an individual quality back-charge debit can be material — a 12,000-piece rejected lot of die-cast engine case at ₹18 per affected piece is a ₹2.16 lakh debit, comparable to a passenger-vehicle FOMP claim. The reconciliation engine validates the rejected-piece count against the supplier's OQC record and the contractual penalty rate against the scheduling agreement.

Hero deducts contractor TDS on the Tier-1 supplier's conversion / job-work component under Section 393(1) Sl. 6(i).D(b) of the Income Tax Act 2025 using payment code 1024 (1% for individual / HUF suppliers, 2% for other entities). The Tier-1's own Tier-2 chain — aluminium ingot suppliers (purchase TDS under 393(1) Sl. 8(ii)), die-casting job-work for partial outsource, machining / polishing job-work, plastic granule purchase, injection-moulding job-work, painting and surface-treatment job-work — carries Section 393(1) Sl. 6(i).D(b) code 1024 on each Tier-1-to-Tier-2 job-work payment. For an aluminium die-cast Tier-1 with substantial outsource to machining and polishing Tier-2 vendors, the Tier-2 TDS register can carry 150-300 lines per month. Form 168 reconciliation against Tier-1 books before the quarterly return cut-off is the operational control.

Hyundai Motor India (HMI) Tier-1 supplier payment terms typically run T+60 days from GRN (goods-receipt-note) date at the receiving Sriperumbudur or Talegaon plant. The clock starts at GRN, not at invoice date and not at dispatch date. A part dispatched on the 25th of a month but GRN-confirmed on the 3rd of the next month starts the payment cycle on the 3rd, with cash landing roughly 60 days later. Settlement cadence is monthly for most programmes, with fortnightly runs for the highest-volume Creta and Venue supply lines. A Tier-1 with ₹120 crore annual HMI billing typically receives 12 to 18 settlement runs per year against the Sriperumbudur book.

HMI Vaatika is Hyundai Motor India's supplier-side delivery, quality and settlement portal. Tier-1 suppliers use Vaatika to view scheduling-agreement call-offs and the rolling 7-14 day kanban release, transmit advance shipment notices, confirm GRN, view debit notes and settlement statements, and download payment advices. The settlement-statement export from Vaatika per period is the canonical input that feeds the supplier's OEM payment decomposition. The portal also carries the rolling PPM dashboard per part per supplier and the supplier-rating quarterly scorecard, both of which drive new-programme bidding eligibility.

Hyundai Motor Group operates Mobis (Hyundai Mobis) as the in-house Tier-1 for module supply — front-end module, cockpit module, chassis module, brake module. At Sriperumbudur, Mobis India sits as a near-plant Tier-1 that consolidates Indian Tier-2 supply into modules that ship to HMI on a separate commercial framework from direct Tier-1 supply. From the perspective of an Indian Tier-2 supplying into Mobis: the customer is Mobis India, not HMI, and the commercial terms, debit-note format, settlement portal and quality regime are Mobis-specific (broadly Korean-parent-influenced) rather than HMI-direct. The supplier's customer master must carry HMI and Mobis India as separate parent records, because settlement, payment and debit-note flows run separately.

Hyundai Motor India operates RMPV (raw-material price variance) pass-through on commodity-linked Tier-1 parts where the rupee-content of aluminium, copper, steel or polymer is high enough that LME or domestic benchmark variance materially affects per-part cost. For aluminium die-cast parts on i20, Creta and Venue (engine components, transmission housings, brake calliper bodies), HMI typically operates a monthly RMPV settlement keyed to the LME aluminium cash settlement plus a contracted premium, with a 30-day lag from the LME settlement date to the RMPV settlement on Vaatika. The supplier's reconciliation engine must cap RMPV claims against the contracted formula and surface variance where the HMI RMPV settlement differs from the supplier's computed claim.

HMI deducts contractor TDS on the Tier-1 supplier's job-work component under Section 393(1) Sl. 6(i).D(b) of the Income Tax Act 2025 using payment code 1024 (1% for individual / HUF suppliers, 2% for other entities). The deduction applies on the job-work / conversion component of each invoice, not on the pure-material pass-through component where that distinction is preserved in the commercial framework. Tier-1 suppliers reconcile the periodic Form 168 TDS certificate / statement against their own books per HMI invoice to confirm correct deduction, deposit and PAN-mapping before the quarterly return cut-off. The Tier-2 leg of the supply chain similarly carries Section 393(1) Sl. 6(i).D(b) code 1024 on heat-treatment, plating, machining and assembly job-work payments from the Tier-1 to its Tier-2 vendor base.

Section 16(1) of the CGST Act says that every registered person, subject to the conditions and restrictions, is entitled to take Input Tax Credit on the supply of goods or services or both which are used or intended to be used in the course or furtherance of business. For capital goods this translates into a 100% credit eligibility at the time of receipt of the asset, subject to four conditions in Section 16(2): possession of the tax invoice, receipt of the goods, payment of tax to the government by the supplier, and filing of GSTR-3B by the recipient claiming the credit. Capital goods specifically must also satisfy the Section 2(19) definition — capitalised in the books of the recipient and used in the course of business. Where the capital goods are used partly for taxable supplies and partly for exempt or zero-rated supplies, Rule 43 spreads the credit over a 60-month useful-life window with proportionate reversals.

Section 17(5) lists categories where ITC is blocked notwithstanding the general eligibility under Section 16. The relevant blocks for auto-manufacturing capex are: (a) motor vehicles and other conveyances with seating capacity up to 13 persons, except where used for further taxable supply, transportation of passengers or for training — this blocks forklifts only if classified as motor vehicles, but most industrial forklifts and trolleys are off-road equipment and ITC-eligible; (c) construction of immovable property except plant and machinery — this blocks civil-works ITC for sheds, offices, drains, except where the structure is plant and machinery (the boundary line is the most-litigated single capex issue); (d) goods or services received for personal consumption — blocks staff hospitality and employee-amenity ITC; (h) goods lost, stolen, destroyed, written off or disposed by way of free samples — blocks ITC on scrapped capital goods to the extent of unamortised remaining-useful-life. For a typical greenfield press shop the Section 17(5) blocks usually account for 2% to 6% of total capex ITC.

Rule 43 of the CGST Rules covers the apportionment of capital-goods ITC where the registered person makes both taxable and exempt (or zero-rated under LUT) supplies. The mechanic: total ITC available on the capex is divided by 60 to produce a monthly attribution; the monthly attribution is multiplied by the exempt-to-total turnover ratio for that month under Rule 43(1)(e); the resulting figure is reversed in Table 4(B)(1) of the GSTR-3B for that month. Where the registered person makes 100% taxable supplies, the reversal under Rule 43(1)(e) is zero and the full credit matures cleanly over 60 months. Where the registered person makes 100% exempt or zero-rated supplies, the reversal equals the monthly attribution and no credit is retained. For a typical Tier-1 with a 90% domestic taxable, 10% SEZ-export mix, the cumulative reversal over 60 months equals 10% of the original ITC. The full Rule 43 mechanic on tooling is in [GST on auto-component tooling under Rule 43](/insights/gst-tooling-capital-goods-rule-43-auto-component-india/).

The Export Promotion Capital Goods (EPCG) scheme under the Foreign Trade Policy allows zero-duty import of capital goods against an export obligation typically equal to six times the duty saved, to be fulfilled within 6 years from the EPCG authorisation date. When a CNC machine or robotic cell is imported under EPCG, the basic customs duty is zero but IGST on import is payable in cash — the supplier cannot use ITC to pay it because of the EPCG authorisation conditions. Once the IGST is paid in cash at the port of import, the supplier becomes eligible to take ITC on it as capital-goods ITC under Rule 43. The wrinkle: where the EPCG authorisation requires a minimum export ratio that does not match the supplier's actual export-versus-domestic split, the supplier may be forced into a refund-versus-utilise decision — either utilise the ITC against domestic output and meet the export obligation through alternative routes, or claim a refund of the IGST under the inverted-duty-structure provisions where applicable.

Section 18(6) of the CGST Act and Rule 44(6) of the CGST Rules trigger an accelerated reversal on disposal of capital goods. The amount payable equals the higher of (a) the ITC that remains unamortised on the remaining-useful-life proportion (computed as total ITC times remaining-months divided by 60) or (b) the tax on the actual transaction value of the disposal. If a CNC machine procured for ₹2.4 crore with ₹43.2 lakh of ITC is scrapped at month 38, the remaining unamortised ITC is ₹43.2 lakh times 22 divided by 60 = ₹15.84 lakh. If the scrap sale value is ₹45 lakh and GST at 18% is ₹8.1 lakh, the reversal payable is the higher = ₹15.84 lakh. The reversal lands in the GSTR-3B of the disposal month under Table 4(B)(2). Section 17(5)(h) also independently blocks ITC on capital goods written off — if the machine is junked without a sale (no consideration), the Section 18(6) mechanic still applies on the unamortised remaining-useful-life basis.

Generic AR internal audit tests invoicing accuracy, ageing, collection effort, and bad-debt provision. OEM receivables at an auto-component Tier 1 add four distinct risk layers. First, the scheduling-agreement-to-call-off-to-dispatch-to-GRN-to-invoice chain has cum-quantity drift risk where over-shipped quantities accumulate unreconciled. Second, the OEM debit-note regime can short-pay 8% to 12% of monthly billing for FOMP, quality, line-stop, or RMPV reasons. Third, RMPV claims are variable consideration estimated forward — material misjudgement risk under SA 540. Fourth, the OEM portal is the source of truth — internal audit must verify the company's books against the portal, not against internal records alone. These four layers require a domain-specific controls testing matrix.

The chain has six control points. Control 1 — scheduling agreement set-up in the customer master with authorised pricing and tooling annexure. Control 2 — call-off receipt from OEM portal and capture in the dispatch system. Control 3 — dispatch confirmation per call-off line with vehicle programme, part number, and quantity. Control 4 — GRN receipt from OEM portal with rejection slip linkage. Control 5 — invoice raise per call-off and GRN with three-way match against SA price. Control 6 — payment receipt with short-pay reason coding. Internal audit tests each control point with a 30-to-60 transaction sample, walk-through documentation, and exception analysis.

Authorisation matrix testing covers three risk areas. First, who can accept a debit note — typically restricted to the finance head or controller, with materiality threshold (e.g., above ₹1 lakh requires CFO sign-off). Second, who can dispute a debit note — typically the commercial team head with a documented dispute file. Third, who can issue a corresponding back-charge to the Tier 2 sub-supplier — typically the procurement head with an authorisation cap. Internal audit samples 30 debit-note acceptances and 15 disputes, verifies the sign-off chain, and tests the segregation of duties between acceptance and recovery.

SA 240 (The Auditor's Responsibilities Relating to Fraud) requires the internal auditor to assess fraud risk specific to the entity. For OEM receivables the four high-risk patterns are: round-tripping where dispatches and short-pays cancel out to mask phantom revenue; phantom RMPV claims where the claim register is padded for revenue smoothing; debit-note suppression where genuine OEM debits are not booked to inflate receivables ageing favourably; and DRC-08 type GST round-tripping where credit notes are issued without corresponding revenue reduction. Internal audit's fraud-risk procedures cover analytical review of dispatch-to-GRN-to-invoice trend, sample testing of claim acceptances, and reconciliation of GST credit notes against revenue movement.

A typical engagement at a ₹240 crore Mahindra Tier 1 surfaces four categories of findings. First, 30 to 60 unreconciled short-pays past 90 days totalling ₹40 lakh to ₹1.2 crore — recommendation to age, escalate, and accept-or-dispute with documented reason. Second, 5 to 12 cum-quantity drift exceptions per SA where dispatched quantity is ahead of invoiced quantity by 200 to 600 units — recommendation to reconcile monthly and book the receivables. Third, 8 to 20 RMPV claims pending OEM acknowledgement for 60+ days — recommendation to escalate and constrain the booked estimate. Fourth, 2 to 5 debit notes accepted without the prescribed sign-off chain — recommendation to enforce the authorisation matrix.

Paragraph 10 of Ind AS 2 includes three categories. First, costs of purchase — direct material (LME-linked aluminium, JPC-linked steel, copper, polymer granules) net of trade discounts and rebates, plus freight inward, customs duty, and other directly attributable acquisition costs. Second, costs of conversion — direct labour wages plus a systematic allocation of fixed and variable production overhead. Third, other costs incurred in bringing inventories to their present location and condition — but only where directly attributable. Excluded under paragraph 16 are abnormal amounts of wasted material above standard yield, storage costs unless necessary for the production process, administrative overhead, and selling costs.

Paragraph 13 of Ind AS 2 requires fixed production overhead allocation based on normal capacity — the production expected on average over a number of periods under normal circumstances, accounting for planned maintenance. If actual production runs below normal capacity, the overhead per unit is not increased — the unabsorbed portion is recognised as an expense in the period, not capitalised into closing inventory. If actual production exceeds normal capacity, the per-unit allocation is reduced so that inventory is not measured above cost. For a casting Tier 1 running a furnace at 78% capacity utilisation against a normal capacity baseline of 85%, the unabsorbed fixed overhead for the 7% gap goes straight to P&L and does not inflate closing WIP.

Under paragraph 16(a), abnormal amounts of wasted materials, labour, or other production costs are excluded from inventory cost and recognised as expense in the period. The benchmark is the company's standard yield — for stamping it is the coil-to-parts yield after engineered skeleton scrap, for forging it is the input-billet to finished-forging weight ratio after engineered flash and trim, for casting it is the melt-to-good-casting yield after engineered runner / sprue and acceptable rejection rate. Yield losses within standard are normal and capitalised; losses above standard are abnormal and expensed. The standard yield is set annually based on engineering studies and is documented in the inventory accounting policy. A 3% rejection rate exceeding a 2% standard means the excess 1% is abnormal waste and expensed.

Paragraph 9 requires inventory to be measured at the lower of cost and net realisable value. NRV is the estimated selling price less estimated costs of completion and costs to sell. For a part that is part-specific to a vehicle programme nearing end-of-life, NRV testing requires the supplier to estimate the residual demand from spares and aftermarket against the on-hand quantity. Stock above the residual-demand estimate is written down to scrap NRV. The standard provision matrix runs 25% for slow-moving (12 to 18 months without movement), 50% for very slow (18 to 24 months), and 100% for obsolete (24+ months or programme discontinuation). The matrix is documented as an accounting policy and applied consistently.

GST paid on direct material is excluded from inventory cost where input tax credit is available — the supplier claims it through GSTR-2B reconciliation and the cost layer is net of GST. Where ITC is blocked under Section 17(5) (rare for production inputs) or where the supplier is in an exempt category, the GST cost is capitalised into inventory. Customs duty on imported aluminium, steel, or specialised components is capitalised under paragraph 11 as a directly attributable acquisition cost. Anti-dumping duty and safeguard duty follow the same treatment — capitalised because they are duty levies, not refundable tax credits.

Every registered principal who has sent inputs or capital goods to a job-worker on a delivery challan under Section 143 of the CGST Act in a given period must file ITC-04. For principals with aggregate turnover above ₹5 crore the return is quarterly, due by the 25th of the month following the quarter (so 25 July for Apr-Jun, 25 October for Jul-Sep, 25 January for Oct-Dec, 25 April for Jan-Mar). For principals with aggregate turnover up to ₹5 crore the return is half-yearly, due by 25 October (Apr-Sep) and 25 April (Oct-Mar). A nil return is required for any period where no challans were issued but the principal otherwise files.

Table 4 reports goods dispatched by the principal to a job-worker in the period (Section 143 challan-out): GSTIN of job-worker, challan number and date, unique job-worker number or invoice reference, description, HSN, quantity, taxable value and tax rate even though no GST is paid on dispatch. Table 5A reports goods received back from the job-worker to the principal's premises (challan-in). Table 5B reports goods supplied from the job-worker's premises directly to a customer under Section 143(1)(b) — invoiced by the principal, not the job-worker. Table 5C reports goods sent from one job-worker to another (the multi-hop leg), which keeps the original-dispatch clock running. Opening and closing balances are computed from these four tables and the previous return.

Inputs sent to a job-worker must return to the principal — or be supplied from the job-worker's premises — within one year of the original dispatch date by the principal. Capital goods must return within three years. Jigs, fixtures, moulds and dies carry no return clock. If inputs miss the one-year window or capital goods miss the three-year window, the original dispatch is deemed a supply on its original dispatch date under Section 143(3) and 143(4), and the principal must pay GST with interest under Section 50 at 18% per annum from that original date. ITC-04 is the surfacing return for this risk: an open balance per job-worker whose original-dispatch date is approaching the window is the highest-priority alert.

ITC-04 and GSTR-1 are independent returns, but they intersect on two flows: goods supplied from the job-worker's premises directly to a customer under Section 143(1)(b) appear as outward supplies in the principal's GSTR-1 (because the principal invoices, the job-worker only ships) and as Table 5B entries in ITC-04 — the values must agree. The conversion-charge invoice raised by the job-worker appears in the job-worker's own GSTR-1 as an outward supply of service (HSN 9988) and in the principal's GSTR-2B for ITC. ITC-04 itself reports only the non-supply movement of goods on challans, but the GSTR-1 / GSTR-2B legs must reconcile to the same job-worker register or audit breaks.

ITC-04 attracts a general late fee under Section 47 of the CGST Act of ₹100 per day per Act (CGST + SGST) — ₹200 per day in total — subject to the standard cap. The bigger exposure is structural: a delayed ITC-04 means the principal's open-balance position is unreported, which makes it materially harder to defend against a Section 143(3)/(4) deemed-supply assertion in audit, because the principal cannot show on the return that the goods are within the one-year window. Late filing also signals systemic control weakness in any subsequent CGST audit under Section 65.

Day 180 is safe. The Second Proviso to Section 16(2) requires payment within 180 days from the date of issue of invoice. If the payment is credited to the supplier on or before the 180th day, ITC is not reversed. Clawback triggers only when the 180-day window is fully exhausted — i.e. from Day 181 onwards, the buyer must reverse the ITC availed on that invoice in the GSTR-3B for the tax period in which the 180-day window expires. This is a strict boundary — teams that count 'within 180 days' inclusive of the invoice date and treat Day 179 as the deadline over-provision; teams that count 'up to 6 months' calendar-style under-provision when a month has 31 days.

The count runs from the invoice date under Section 16(2) Second Proviso — the date printed on the tax invoice by the supplier, not the date on which the buyer received or booked the invoice. Case law (Suncraft Energy Pvt Ltd, Calcutta HC 2023) confirms this reading. This matters when invoices arrive late in the buyer's AP inbox — a supplier who invoices on 5 January but the buyer books on 20 January still has a 180-day clock ticking from 5 January. Auto component suppliers frequently deliver goods with an invoice packed in the consignment but the OEM's SAP posting can lag by 10 to 15 days on inspection and 3-way match; the SAP posting date is irrelevant.

The reversal is temporary. Section 16(2) Second Proviso itself permits re-availment: 'where the recipient pays the said amount subsequently, he shall be entitled to avail the credit'. When the buyer eventually pays the supplier, the reversed ITC can be reclaimed in the GSTR-3B for the tax period in which the payment is made, reported in Table 4(A)(5). The catch is interest — Section 50(3) charges interest at 18 percent per annum from the date the ITC was originally availed until the date of reversal, not until re-availment. This interest is a real cost and cannot be reclaimed.

Yes, the rule applies to the full invoice value including tax. Section 16(2) Second Proviso reads 'value of supply along with tax payable thereon'. Paying the base value but retaining the GST portion (a variant of a retention-money argument) does not stop the ITC clawback clock. The reversal is proportional to the unpaid amount — if 90 percent of the invoice is paid within 180 days and 10 percent is unpaid on Day 181, ITC on the unpaid 10 percent portion reverses, not the full ITC. CBIC Circular 170/2021-GST clarifies this proportional treatment, which is a common misinterpretation area.

They are two independent clocks running in parallel. Section 43B(h) of the Income Tax Act disallows the expense deduction if payment to a Micro or Small enterprise is delayed beyond 15 days (no written agreement) or 45 days (with written agreement). Section 16(2) Second Proviso reverses ITC if payment is delayed beyond 180 days regardless of MSME status. For an MSME auto component supplier, the 45-day income tax deadline expires long before the 180-day GST deadline — a buyer who breaches 45 days but pays before Day 180 loses the deduction for that expense but keeps the ITC. Both consequences need separate reconciliation registers.

No. Rule 37 of the CGST Rules — as amended by Notification 19/2022-CT effective 1 October 2022 — makes clear that the reversal is proportionate to the unpaid amount. If a ₹35 lakh invoice with ₹6.3 lakh ITC has ₹22 lakh paid within 180 days and ₹13 lakh outstanding, only the ITC attributable to the unpaid ₹13 lakh (approximately ₹2.34 lakh at 18%) is reversed. The naive reading that treats any short-payment as a full reversal event is inconsistent with the current statutory text and is the leading cause of over-reversal in auto-component AP reconciliation.

Yes. The Third Proviso to Section 16(2) permits re-availment when payment is subsequently made to the supplier. Rule 37 and CBIC Circular 170/02/2022-GST prescribe the mechanics: report the reversal in Table 4(B)(2) of GSTR-3B in the return period of the breach, and report the re-availed amount in Table 4(A)(5) with a reference in Table 4(D)(1) in the return period in which payment is made. There is no time bar on re-availment linked to the original Section 16(4) deadline — the re-availment right survives the annual cut-off.

The 180-day clock runs from the date of the original invoice, not from any subsequent adjustment. A credit note issued by the supplier under Section 34 reduces the effective payable — that reduction directly reduces the unpaid balance being tested at Day 181. A buyer-issued debit note (for rejection or price adjustment) does not reset the clock. The net effect is that credit notes reduce reversal exposure, while buyer debit notes only matter to the extent the supplier accepts them and issues a matching credit note.

The market position — supported by industry practice and consistent with the Suncraft Energy reading — is that retention is contractually withheld consideration, not a defaulted payment. Where the retention is clearly captured in the contract (typically 5-10% of value for warranty coverage), it is not treated as unpaid consideration for Section 16(2) Second Proviso purposes. The safer approach in auto-component AP is to track retention balances separately in the reversal register and provision only if the retention overruns the contractual release window.

The buyer's over-reversal is the buyer's problem for GSTR-3B, but it becomes the supplier's problem when the buyer withholds payment claiming a phantom ITC loss. Suppliers should maintain: (a) the original tax invoice, (b) the 2A/2B extract showing the invoice reported, (c) proof of goods movement (e-way bill, LR), (d) the ageing of payment against invoice date, and (e) a clean statement that the recipient's ITC obligation under Rule 37 is proportionate. This documentation supports both a commercial recovery conversation and a Section 74 defence if a notice ever lands on the supplier.

JLR (Jaguar Land Rover) and Tata Motors PV (passenger vehicle business — Nexon, Harrier, Safari, Punch, Curvy, Tiago, Tigor, Altroz) sit inside the same Tata Group corporate structure but operate completely different commercial frameworks for Tier-1 suppliers. Tata Motors PV runs standard Indian Tier-1 commercial terms — INR billing, TML SRM portal, T+45 to T+60 from GRN, Section 393 TDS on the job-work component, Section 34 GST credit-notes on debit-driven returns. JLR Sourcing India runs an export-oriented commercial framework — EUR or GBP billing for parts destined for JLR's UK (Solihull, Halewood) or Slovakia (Nitra) plants, LUT-eligible GSTR-1 Table 6A invoicing, RoDTEP claim filing on every export shipment, EPCG capital-goods import discipline, IEC (Import Export Code) registration discipline, and VDA-format EDI inherited from JLR's European operating standard. A single Indian Tier-1 supplying body-pressings to both runs two parallel commercial universes in one customer master.

Export sales to JLR Sourcing India under the LUT (Letter of Undertaking) framework are zero-rated for GST purposes — no IGST is charged at invoice but the supplier executes an LUT bond with GST authorities committing to export within the timeline. GSTR-1 Table 6A reports the LUT-eligible export invoice with shipping bill reference. RoDTEP (Remission of Duties and Taxes on Exported Products) provides a duty drawback at notified rates per HSN; the Tier-1 files RoDTEP claim against each export shipment via the ICEGATE portal. EPCG (Export Promotion Capital Goods) allows zero-duty import of capital goods (presses, dies, fixtures, robots) against an export obligation equal to six times the duty saved over six years. IEC (Import Export Code) is the foundational DGFT registration required for any export Tier-1 — without IEC, no export shipment, no shipping bill, no RoDTEP claim. The reconciliation engine maintains separate registers for LUT bond utilisation, GSTR-1 Table 6A submissions matched against shipping bills, RoDTEP claims filed and credited, and EPCG export-obligation progress.

The Production Linked Incentive (PLI) scheme for the Auto and Auto Component sector incentivises domestic value addition with eligibility tied to incremental sales of advanced automotive technology (AAT) products. Domestic supply to Tata Motors PV may qualify if the Tier-1 has approved AAT product registrations and meets the incremental-sales threshold against the base year. Export supply to JLR via JLR Sourcing India may qualify differently — export sales are eligible for PLI incentive on the same incremental basis, but the eligibility computation must separately track domestic-eligible and export-eligible sales. The reconciliation engine must tag each sales transaction with PLI eligibility status (AAT-approved or not), incremental-base-year tracker, and domestic-vs-export segmentation. A blended PLI claim that does not segment correctly is the most common audit finding at PLI compliance review.

Tata Motors PV runs TML SRM (Tata Motors Supplier Relationship Management portal) with Indian-convention structured exports — call-off schedules, ASN, GRN, settlement statements as portal exports. JLR Sourcing India inherits the JLR European parent's VDA-format EDI requirement — VDA 4905 delivery schedule, VDA 4906 ASN, VDA 4908 invoice — because the parts ultimately flow into the JLR UK / Slovakia plant systems that operate on VDA standards. The Indian Tier-1 must operate both EDI conventions simultaneously: the TML SRM portal flow for the domestic leg, and the VDA EDI flow for the JLR export leg. EDI middleware translates the Indian Tier-2 vendor base's Indian-convention messages into VDA on the export side. Translation variance is a distinct reconciliation exception category.

On the domestic Tata Motors PV leg, Section 393(1) Sl. 6(i).D(b) code 1024 contractor TDS at 1% / 2% deducted by Tata applies on the supplier's job-work / conversion component; Section 393(1) Sl. 8(ii) code 1031 purchase TDS at 0.1% on aggregate above ₹50 lakh applies on Tier-2 raw-material purchase; Section 394 code 1071 scrap TCS at 1% applies on Tier-2 scrap recoveries. On the export JLR leg, JLR Sourcing India does not deduct Indian TDS because the buyer is the inter-company entity routing to a non-resident end-customer — the export invoice flows under LUT zero-rated treatment without TDS at the receivable. However, the Tier-1's own Indian Tier-2 chain serving both domestic and export production carries Section 393(1) Sl. 6(i).D(b) code 1024 TDS on all Tier-2 job-work payments regardless of whether the downstream production is domestic-bound or export-bound. Form 168 TDS register must reconcile the deductions cleanly between the domestic-receivables leg (Tata-deducted TDS) and the supplier's outgoing Tier-2 TDS register.

The Joint Plant Committee, attached to the Ministry of Steel, publishes a monthly Indian steel price bulletin covering hot-rolled coil (HRC), cold-rolled coil (CRC), galvanised plain and galvanised corrugated (GP/GC), structural sections, wire rod, and pig iron. Prices are reported ex-Mumbai and ex-Delhi (the two reference markets), excluding GST and landing costs. The bulletin typically lands around the 15th of the following month — a Q1 close on 30 June produces a June bulletin around 15 July. JPC is the most widely cited Indian steel reference in auto-component RMPV clauses because it is statutory, monthly, and unambiguous on the published grades.

JPC reports Indian rupee-denominated published steel prices ex-Mumbai or ex-Delhi for standard mill grades. LME (London Metal Exchange) reports USD-denominated settlement prices for non-ferrous metals — aluminium, copper, nickel, lead, zinc. Auto-component RMPV clauses use JPC for the steel content of the part (HRC for stamping, CRC for cold-formed components, wire rod for fasteners) and use LME for aluminium castings, copper wiring harness, and other non-ferrous content. A multi-material part typically references both: JPC for the steel, LME for the aluminium, with the conversion portion held fixed. See the RMPV calculation formula companion piece for the multi-material worked example.

Walk three resolution rules in order. (1) Bill of material match — if the BOM specifies HRC E34, the JPC HRC of the closest published grade applies. JPC does not publish all auto-specific grades (E34, IF, BH), so the resolution is the standard HRC grade with a grade-premium adjustment held fixed at programme award. (2) City base — if the part is produced at Pune, ex-Mumbai applies; at Pithampur or Sanand, the contract should specify but commonly defaults to ex-Mumbai as the western-India reference. North-India OEMs (Maruti at Manesar, M&M at Mohali) commonly reference ex-Delhi. (3) Failing both, the resolution is the contractual escalation panel — typically a joint reconciliation between the supplier's CFO office and the OEM's purchase head, with the SIAM (Society of Indian Automobile Manufacturers) guideline as fallback.

JPC publishes around the 15th of the following month. For a Q1 ending 30 June using monthly average, the April and May bulletins are already available at quarter-end but the June bulletin lands only mid-July. The supplier must therefore book the Q1 provision at 30 June using April and May actuals plus a daily-observed estimate for June, then true up when the June bulletin publishes. Under Ind AS 37 this is a present obligation arising from a past event (goods supplied at base price) with a reliably estimable amount — provision recognition is required, not optional. The true-up entry on 15 July posts the difference between the provisioned estimate and the JPC actual; the supplementary invoice or Section 34 credit note follows.

The Income Tax Act 2025 changes TDS only; GST law is unchanged. An upward JPC-based RMPV claim is a supplementary (debit) invoice — GST on the differential at the component's applicable rate, output liability in the current period under CGST Section 12/13 time-of-supply. A downward claim (steel index falls below base) requires a Section 34 credit note, with the cutoff at 30 November of the following financial year or annual return filing, whichever is earlier. The material-portion RMPV claim is not subject to TDS — it is a revision to a goods supply, not a payment for services. The conversion portion of regular invoices continues to attract Section 393(1) Sl. 8(ii) at 2% under payment code 1031.

MRP (Material Requirements Planning) is push-based — the OEM's production plan generates scheduled releases through the EDI 830/862 chain or portal equivalents, and the supplier ships against those scheduled quantities at the scheduled dates. Kanban is pull-based — the OEM line consumes a bin of parts, the empty bin (physical card, electronic kanban signal, or RFID tag) triggers replenishment, and the supplier ships against the signal, not against an advance schedule. Under MRP the supplier sees the forecast horizon and firm window upfront. Under kanban the supplier sees only the most recent consumption signal and must hold buffer inventory to honour the next signal.

Under MRP the supplier transmits an EDI 856 ASN ahead of dispatch and the OEM raises a GRN against the ASN at receipt. Under kanban there is often no advance ASN — the supplier ships directly to a bin or rack location on the OEM line, the OEM records consumption rather than receipt, and settlement runs against monthly consumption reports. The financial-event chain becomes signal → dispatch → bin replenish → line consumption → monthly consumption-based billing, instead of forecast → firm call-off → ASN → GRN → periodic invoice.

Two reasons. First, the OEM-line kanban card or electronic signal is the dispatch trigger but does not flow into the supplier's ERP — there is no IDoc or portal payload the supplier finance team can pull, so the trigger event is invisible to the books and only the dispatch and the monthly consumption report are visible. Second, kanban is almost always paired with consignment or VMI stock at the OEM end, which means the supplier owns the inventory physically located at the OEM plant until it is consumed. The reconciliation must tie supplier dispatch quantity to OEM consumption quantity to billing quantity, with the consigned-stock register sitting in between.

When kanban is paired with consignment stock at the OEM premises, the supply event under GST is the consumption from the consignment stock, not the movement from supplier dock to OEM. The supplier raises a periodic GST e-invoice for consumed quantity at month-end (or the agreed billing window), referencing the consumption report from the OEM. The movement from supplier to OEM premises is a Rule 55 delivery challan, not a tax invoice. The GST e-invoice IRN, the consumption-quantity reconciliation, and the consigned-stock register at the OEM all need to tie. Where VMI is structured as a direct sale at receipt (not consignment), the tax invoice is raised at receipt and the reconciliation simplifies to the MRP shape — but kanban-plus-true-VMI in the Indian context is rare.

Generic three-way matching does not work for kanban supply because the trigger event (kanban card or e-kanban signal) is not in the ERP and there is no per-shipment PO or call-off reference. The reconciliation needs a kanban-aware layer that ingests the OEM monthly consumption report, ties it to the supplier's dispatch log via part code and OEM plant code, maintains the consigned-stock register at the OEM end (supplier-owned inventory until consumption), generates the periodic GST e-invoice against consumed quantity, and produces a month-end consigned-stock balance the supplier can audit. SAP supports this via consignment-fill-up and consignment-issue document types, but the daily kanban-signal-to-dispatch traceability is rarely built and almost always sits outside the ERP.

Indian OEMs encode line-stop rates in the commercial agreement at either a per-minute or per-hour rate, often varying by vehicle programme and plant. Maruti Suzuki, Tata Motors and Mahindra & Mahindra typically run rates in the ₹1-5 lakh per hour band depending on the vehicle programme — premium and high-volume programmes attract the upper end. Some OEMs run a tiered rate (lower rate for the first 30 minutes, higher for prolonged stoppage) to reflect the cost difference between a short downtime and a missed production target. The rate is encoded in the MSA's liquidated damages clause along with a force-majeure carve-out, an aggregate-liability cap (typically 5-10% of annual contract value), and the dispute window.

No. CBIC Circular 178/10/2022-GST dated 3 August 2022 clarifies that amounts received as liquidated damages, compensation for breach of contract, penal charges, late delivery charges, cancellation charges, and similar payments are not consideration for a taxable supply. These payments compensate for loss or damage rather than constitute consideration for any tolerated act or supply of service. The line-stop charge falls squarely in this category — the OEM is not supplying anything to the supplier in exchange; the charge compensates the OEM for production loss caused by the supplier's contractual breach. Therefore no GST on the LD charge, no Section 34 credit-note action required from the supplier on the LD component, and no input tax credit consequences for the OEM.

Ind AS 37 governs provisioning when a present obligation exists, settlement is probable, and the amount can be reliably estimated. For line-stop charges the obligating event is the actual production-line stoppage attributable to the supplier — typically captured by the OEM's line log on the day of the incident. The supplier provisions when the OEM communicates the line-stop event and the estimated charge, even before the formal debit-note posting which can lag 30-60 days. Where the supplier intends to contest the charge on force-majeure grounds or attribution grounds, the provision is held against the supplier's estimate of the probable settlement after contest. Aggregate line-stop provisioning at a multi-OEM Tier-1 typically runs 0.2-0.7% of trailing monthly billing — within the broader OEM short-pay band.

The aggregate-liability cap in the MSA limits the total liquidated damages the supplier can be charged in a contract period — typically a financial year — to a percentage of the annual contract value. The standard band is 5-10% of contract value, sometimes broken into separate sub-caps for line-stop, quality penalties, and other LD heads. Once the supplier hits the cap, no further LD charges can be debited for the period — the cap binds even if additional line-stop incidents occur. In practice the cap is rarely binding for well-performing suppliers (annual LD typically runs 0.5-3% of contract value), but for a supplier in distress with multiple programme issues it can become binding mid-year and the contest case becomes a cap-enforcement case rather than an incident-attribution case.

The force-majeure carve-out exempts the supplier from line-stop charges where the underlying shortage or quality issue is caused by events beyond the supplier's reasonable control — typically including natural disasters (monsoon flood, earthquake, cyclone), strikes and labour disputes (at the supplier or in the broader logistics chain), governmental action (sudden regulatory change, lockdown, customs disruption), war or terrorism, and large-scale infrastructure failure (extended power grid outage, port shutdown). The contemporary carve-outs added post-2020 often explicitly cover pandemic-related disruption. The supplier must give written force-majeure notice within a contractual window (typically 7-14 days from the event) for the carve-out to apply. Missing the notice window forecloses the force-majeure defence even if the underlying event clearly qualifies.

LME publishes both a cash settlement (spot, settled in two business days) and forward settlements out to 3 months and beyond. Auto-component RMPV clauses most commonly reference LME cash for monthly averaging — the daily cash settlement averaged across the calendar month. Some OEM contracts (typically those with longer order lead-times) reference the 3-month forward as a hedging proxy. The supplier must use whichever the contract names; arbitraging between cash and 3-month settlement is the most common dispute pattern after grade ambiguity. LME cash is typically the right choice for short-cycle automotive supply because it tracks physical-market reality closely; 3-month is appropriate where the contract embeds longer commitment terms.

Four layers. (1) LME cash settlement in USD per MT (e.g., LME aluminium $2,180/MT). (2) LBMA-published or contract-specified rupee FX rate (e.g., INR 83.50/USD) — the contract should specify whether this is daily, monthly average, or a contract-locked rate. Multiply: $2,180 × 83.50 = ₹1,82,030/MT. (3) Landed premium — for aluminium, the Mumbai aluminium premium published by trade journals (ALEM, CRU Group, Reuters Mumbai aluminium premium) typically runs 4–6% to cover shipping, handling, and import-duty-equivalent landing cost. Apply: ₹1,82,030 × 1.05 = ₹1,91,132/MT. (4) GST at the applicable rate is added at point of consumption, not embedded in the RMPV base. Divide by 1,000 to get ₹/kg: ₹191.13/kg.

A356 (LM25 in older UK nomenclature) is an aluminium-silicon-magnesium casting alloy with 7% silicon and 0.3% magnesium. It is the workhorse grade for automotive castings — engine blocks, cylinder heads, wheel hubs, transmission casings, HVAC condenser headers, structural castings. The reason it dominates: T6 heat treatment delivers a strength-to-weight ratio that suits suspension and powertrain components, the casting characteristics are well-understood across Indian foundries (Sundaram-Clayton, Endurance, Sansera, Rico Auto), and it is supplied in standard ingot form that prices off LME aluminium plus an alloy premium held fixed. The LME-published price is for LME-grade primary aluminium; A356 sits on top of that base with a fixed alloy-premium adjustment.

LME aluminium prices are for primary aluminium at LME warehouses. Physical aluminium delivered to a Mumbai foundry trades at a premium over LME — the Mumbai aluminium premium — published periodically by ALEM (Asian-region trade journal coverage) and other trade-press sources. The premium covers shipping, port handling, customs clearance, and the basis differential between LME-warehouse aluminium and Mumbai-port-arrival aluminium. The premium itself can move — historical range is roughly $80–$200/MT. RMPV clauses typically lock the premium at programme award and absorb the volatility outside the RMPV mechanism, with renegotiation only on macro shifts. The reconciliation rule: the LME differential is what flows through the RMPV claim; the premium is fixed.

GST is unchanged. An upward LME-based RMPV claim is a supplementary (debit) invoice — GST on the differential at the component's applicable rate, output liability in the current period under CGST Section 12/13 time-of-supply. A downward LME-based RMPV claim is a Section 34 credit note, with the cutoff at 30 November of the following financial year or annual return filing, whichever is earlier. The Income Tax Act 2025 affects only TDS: the material-portion RMPV claim is not subject to TDS, and the OEM's TDS deduction on the conversion portion of the next regular payment is at 2% under Section 393(1) Sl. 8(ii) payment code 1031 (replacing the retired 194Q code). FX gain or loss on the conversion between LME USD and INR is held inside the RMPV claim, not separately reported.

Mahindra & Mahindra Tier-1 supplier payment terms typically run T+45 from GRN date for the Automotive Sector and a slightly longer T+45 to T+60 band for the Farm Equipment Sector. The clock starts at GRN at the receiving plant — not at invoice date and not at dispatch date. Settlement cadence is fortnightly for high-volume SUV programmes (XUV 3XO, XUV700, Scorpio-N, Thar, Bolero) and monthly for lower-volume programmes. A Tier-1 with ₹180 crore annual M&M billing across two plants typically receives 24 to 30 settlement runs per year against the combined Chakan / Nashik / Igatpuri / Haridwar book, with each plant running a separate settlement statement and the FES book settled as a separate stream.

The M&M Supplier Portal is Mahindra's supplier-side delivery, quality and settlement interface. Tier-1 suppliers use it to view scheduling-agreement call-offs, transmit advance shipment notices, confirm GRN, view debit notes and settlement statements, and download payment advices. Functionally similar to Maruti e-Nagare and TML SRM, with three operational differences: the portal exposes Automotive Sector and Farm Equipment Sector as separate organisation hierarchies (a single Tier-1 supplying both books logs into one portal but works two separate sub-organisations), the debit-note reason taxonomy is Mahindra-specific (with explicit line-stop coding that some other OEM portals fold into general quality penalty), and the SUV-programme call-off granularity reflects Mahindra's nameplate-level commercial structure across XUV, Scorpio, Thar and Bolero.

Mahindra runs each SUV nameplate as a distinct commercial unit with its own scheduling agreement, tooling cap and FOMP running account. XUV 3XO, XUV700, XUV 9e (electric), Scorpio Classic, Scorpio-N, Thar (3-door and 5-door), Bolero / Bolero Neo and the BE 6 electric programme each carry separate commercial terms. A Tier-1 supplying brake systems across five SUV programmes runs five parallel FOMP accounts, five parallel tooling caps, five parallel PPM trackers per part-per-programme. Without programme-level decomposition, a profitable Scorpio-N programme can mask a loss-making legacy Bolero programme inside the same M&M customer master.

Mahindra's debit-note taxonomy covers FOMP (field warranty back-charge with claim ID, vehicle registration range, dealer reference), JIT shortage (shortage event ID with called-off vs dispatched quantity and expediting premium), quality penalty (line rejection slip ID, PPM excess against rolling 12-month threshold, audit non-conformance), line-stop charge (line-stop event ID with plant, programme, hours stopped and hourly rate applied — Mahindra codes this as a distinct line-item rather than folding it into general quality penalty), tooling amortisation cap-overflow adjustment (tool ID, programme, cumulative shipped vs committed volume), technical-service deduction (visit log reference with engineer-days and hourly rate), and premium-freight differential. Each debit memo cites the contractual per-unit rate, the calculation and the underlying claim ID for supplier-side validation.

Mahindra Automotive Sector and Mahindra Farm Equipment Sector run as separate businesses inside the same parent. A Tier-1 supplying both books faces two materially different commercial models — the auto book runs SUV-programme-keyed scheduling agreements with monthly or fortnightly settlement at T+45 and SUV-nameplate debit-note formats, while the FES tractor book runs tractor-platform-keyed scheduling agreements (Arjun, Jivo, Yuvo, OJA, NOVO ranges) with monthly settlement at T+45 to T+60 and platform-specific debit-note formats. PPM thresholds, FOMP attribution chains and tooling caps run separately. The reconciliation engine treats Auto and FES as two separate parent records with shared vendor-master linkage.

e-Nagare is Maruti Suzuki's supplier-side delivery and settlement portal. 'Nagare' means 'flow' in Japanese, reflecting the Suzuki and Toyota Production System heritage that underlies Maruti's supply-chain discipline. The portal carries rolling daily firm call-offs (next-day to next-few-days), weekly forecast horizon, ASN upload and acknowledgement, GRN confirmation per plant, debit-note and payment-advice surfaces. Every Maruti Tier-1 supplier interacts with e-Nagare daily — the portal is operationally inescapable and is the canonical input to a Maruti Tier-1 finance team's reconciliation engine.

Daily: firm call-off schedule per part per Maruti plant, ASN log, GRN confirmation log. Weekly: settlement statement preview, debit-note register update. Per payment cycle (fortnightly or monthly): payment advice with TDS deduction breakdown. Per quarter: programme-level cumulative position (parts dispatched, debits applied, net realised per vehicle programme across Brezza / Swift / Baleno / Dzire / WagonR / S-Presso / Ertiga / Ciaz / Grand Vitara / Jimny / Fronx / Invicto). For year-end audit support, the e-Nagare archive provides the canonical record per plant per programme.

Maruti runs production across Gurgaon (the original IMT plant), Manesar (Plants A / B / C), Suzuki Motor Gujarat Hansalpur (operated by the SMG joint-venture entity), and the upcoming Kharkhoda site. e-Nagare carries every transaction keyed to source plant code. A Tier-1 supplying brake systems to all four plants under a single scheduling agreement runs four parallel call-off streams, four parallel ASN logs, four parallel GRN confirmations, and four separate payment advices. The finance team must key every transaction to its source plant before any cross-plant aggregation.

Just-in-Sequence (JIS) supply requires the part to arrive at the OEM line in the exact sequence the assembly line will consume it — keyed to chassis number or vehicle build sequence. e-Nagare carries JIS sequence data on the firm call-off and the ASN acknowledgement for parts on sequenced supply (typically interior trim, seat assemblies, instrument-panel assemblies and exhaust systems). The financial reconciliation does not change at the periodic-invoice level — billing remains against confirmed-received quantity for the billing window — but the operational discipline tightens because a sequence mismatch can trigger a line-stop FOMP that is far more expensive than a quantity-tolerance miss.

Under the Income Tax Act 2025, Maruti deducts TDS on the conversion-charge portion of an auto-component supply at Section 393(1) Sl. 6(i).D(b) — payment code 1024 — where the supply is structured as a works contract or job-work flow. Where the supply is a straight goods supply with no labour conversion content, Section 393(1) Sl. 8(ii) at 2% (payment code 1031) applies. The legacy Section 194C reference is retained only for cross-era reconciliation of Form 168, Form 131 and Form 141 transitional cases. The Form 168 visibility in the supplier's tax dashboard reflects the deduction-code mapping at the OEM end.

Maruti Suzuki Tier-1 supplier payment terms typically run T+45 to T+60 days from GRN (goods-receipt-note) date at the receiving plant. The clock starts at GRN, not at invoice date or dispatch date — a part dispatched on the 1st of a month but GRN-confirmed on the 8th of the next month starts the payment cycle on the 8th. Settlement runs on a fortnightly or monthly cadence depending on the supplier's billing volume and programme assignment. A Tier-1 with ₹150 crore annual Maruti billing typically receives 24 to 30 settlement runs per year against the four-plant Maruti book (Gurgaon, Manesar, Suzuki Motor Gujarat Hansalpur, and the new Kharkhoda site).

e-Nagare is Maruti Suzuki's supplier-side delivery and settlement interface. Tier-1 suppliers use it to view scheduling-agreement call-offs, transmit advance shipment notices, confirm GRN, view debit notes and settlement statements, and download payment advices. The e-Nagare daily call-off output feeds the supplier's dispatch planning and the supplier's reconciliation engine on the back end. The settlement-statement export from e-Nagare is the canonical input for OEM payment decomposition at any Maruti Tier-1 supplier.

Maruti Suzuki operates across multiple plant codes — Gurgaon (the original IMT plant), Manesar (multiple production lines across Plants A / B / C), Suzuki Motor Gujarat Hansalpur (operated by SMG, the joint-venture entity), and the upcoming Kharkhoda site. A Tier-1 supplying brake systems may supply all four plants under a single scheduling agreement but each plant's GRN, settlement, and debit-note flow runs separately. The supplier's reconciliation engine must key every transaction to its source plant code, because the debit-note reason taxonomy, line-stop rate band, and FOMP attribution chain can differ between Gurgaon-built Swift and Hansalpur-built Brezza.

Maruti operates a rolling parts-per-million (PPM) quality threshold per part per supplier. The threshold is contractually specified in the supplier agreement — typical bands run 50 PPM for safety-critical parts (brake systems, airbag components, steering components) up to 500-1,000 PPM for non-critical body and trim parts. The PPM is calculated on a rolling 12-month basis from parts dispatched and parts rejected (line rejection + field warranty failure traceable to that part). Breach of the threshold triggers a contractual penalty on trailing-period billing plus mandatory 8D corrective action with response cycle. Persistent breach can trigger supplier-rating downgrade and exclusion from new programme bidding.

Maruti runs each vehicle programme (Brezza, Swift, Baleno, Dzire, WagonR, S-Presso, Ertiga, Ciaz, Grand Vitara, Jimny, Fronx, Invicto) as a distinct commercial unit with its own scheduling agreement, tooling cap, and FOMP running account. A Tier-1 supplying brake systems across five programmes runs five parallel reconciliation streams. Programme-level margin tracking — cumulative parts shipped × per-part margin minus programme-attributable FOMP, tooling clawback, and quality penalty — is the canonical management report. Without programme-level decomposition, a profitable Brezza programme masks a loss-making WagonR programme inside the same Maruti customer master.

Yes — but only within the Section 31 timing-of-supply window. Section 31(1) of the CGST Act, read with rule 47 of the CGST Rules, requires the tax invoice for goods to be issued at or before removal where the supply involves movement of goods. The standard industry workaround for periodic-dispatch supply is to treat a billing cycle as a continuous-supply window, raising one periodic invoice covering all dispatches in the cycle. Where the supply is not legally a continuous supply, the longest defensible window without specific contractual or notification basis is 7 days from the first dispatch in the cycle. Most Indian OEMs run weekly or fortnightly billing cycles structured exactly to fit this window.

Section 31(1) requires that for supply of goods involving movement, the invoice issue before or at the time of removal. The practical accommodation that industry has settled on for daily-dispatch JIS/JIT supply is that the supplier issues an e-invoice (IRN) at the close of the billing window — weekly is universally accepted, fortnightly is accepted in lower-volume programmes. Beyond 7 days without a documented continuous-supply contractual basis, suppliers expose themselves to a Section 122 invoicing penalty and to GSTR-3B output-liability mistiming. The safest construction is a weekly invoice issued within 24 hours of the close of the billing week.

Tata Motors Passenger Vehicles runs a weekly billing cycle for daily JIS supplies — the supplier raises one consolidated tax invoice each Monday covering all ASNs dispatched in the previous Sunday-Saturday week. Maruti Suzuki runs a monthly consolidation for cross-plant supplies where the contract specifically defines the supply as continuous, with the supplier raising one consolidated invoice at month-end covering all dispatches in the month — this works only under explicit contractual continuous-supply framing. Bosch runs fortnightly cycles for most non-JIS supplies and weekly for high-volume sequenced supplies. Hyundai HMI runs weekly. Mahindra runs weekly for PV and fortnightly for CV components. Each pattern has its own e-invoice-IRN sequencing and ASN-tagging convention.