Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Indian manufacturers running SAP MM-FI rely on the GR/IR clearing account to close three-way match, but SAP standard does not catch India-specific gaps — GST inclusive/exclusive variance between PO and invoice, TDS posting timing mismatches under Section 393, J1IGN stock-issue transactions outside MIGO, OBYC GR/IR account misassignment by valuation class, cross-GSTIN consolidation when one company code spans multiple plant GSTINs, and the post-cutover remapping from legacy 194-series WHT codes to Section 393 codes 1001-1092.
Treat SAP standard 3-way match as the rate-and-quantity backbone (GR/IR clearing closes to zero on clean matches) and layer an India-specific reconciliation rule set on top: (a) compare PO tax code to invoice tax code at MIRO and flag mismatches; (b) verify TDS WHT type and Section 393 code alignment per vendor; (c) consolidate cross-GSTIN at company-code level by plant GSTIN; (d) flag Section 17(5) blocked-credit material types at MIRO; (e) cross-era map legacy 194-series codes to new 393-series codes for pre-1-April-2026 transactions still being reconciled.
SAP TAXINN tax procedure with India GST condition records, OBWO withholding tax types per Section 393 payment code (1001-1092), OBYC GR/IR account determination per valuation class, plant master with GSTIN mapping, vendor master with PAN/GSTIN/MSME flag, J1IGN configuration for stock issues, e-invoice integration for IRN capture, and the India-localised reconciliation rule set on top of MIRO.
A daily SAP MM-FI close where GR/IR clearing balances to zero on matched invoices, India-specific exceptions (GST mismatch, TDS code error, Section 17(5) flag, cross-GSTIN drift, J1IGN open challan) surface in a separate exception queue with variance codes mapped to SAP-standard transactions, and cross-era 194-to-393 mapping handles the FY 2025-26 to FY 2026-27 cutover without losing audit traceability.
A controller at a heavy-machinery manufacturer in Pune running SAP S/4HANA finds the April GR/IR balance report (transaction MB5S) carrying ₹6.8 crore of open items across 1,240 line entries. Most are routine — invoices not yet booked against GRNs, GRNs reversed and pending re-receipt — but a long tail are India-specific: GST tax codes that drifted between PO and invoice, Section 393 TDS that posted at the wrong rate because the vendor master still carried a 194-series WHT type, plant GSTIN mappings that broke after a recent legal-entity restructure, and J1IGN stock issues sitting outside the MIGO clearing logic. SAP standard runs the rate-and-quantity three-way match cleanly through GR/IR. SAP MM-FI three-way match India done well requires an additional rule layer that catches what SAP standard does not natively know about. This guide walks through the standard logic, the India-specific gaps, and where a structured reconciliation layer sits.
The SAP standard 3-way match flow
SAP’s standard three-way match runs through the GR/IR (Goods Received / Invoice Received) clearing account, a balance-sheet liability account that absorbs the timing difference between physical goods receipt and vendor invoice posting.
The accounting entries:
| Event | Transaction | Dr | Cr |
|---|---|---|---|
| Purchase order created | ME21N | (no posting) | (no posting) |
| Goods receipt against PO | MIGO | Inventory / Expense (at PO rate × GRN qty) | GR/IR clearing (at PO rate × GRN qty) |
| Vendor invoice posted | MIRO | GR/IR clearing (at invoice rate × invoice qty) | Vendor account (at invoice rate × invoice qty + tax) |
| Vendor payment | F-53 | Vendor account | Bank |
On a clean three-way match, PO rate × GRN quantity equals invoice rate × invoice quantity, and the GR/IR clearing account nets to zero per line. The GR/IR balance report (MB5S) shows only items where this does not close — pending GRNs awaiting invoice, pending invoices awaiting GRN, or genuine price/quantity mismatches.
This is the elegant core of SAP MM-FI. It works. The problem at an Indian factory is that “PO rate × GRN quantity = invoice rate × invoice quantity” is necessary but not sufficient for an Indian invoice to be correctly reconciled. Six other things must also be true.
India-specific gap 1 — GST inclusive vs exclusive on PO vs invoice
SAP uses the TAXINN tax procedure for India, with condition records that map the combination of vendor + plant + material + tax classification to a specific GST tax code (IGST, CGST+SGST, exempt, RCM). At PO creation in ME21N, the buyer (or the system default based on vendor/plant master) selects the tax code based on the supply combination — interstate IGST, intrastate CGST+SGST, or zero-rated.
At MIRO invoice posting, the invoice tax code should match the PO tax code. The frequent mismatch is when the vendor’s invoice carries a different tax code than the PO defaulted to — for example IGST charged when the PO defaulted to CGST+SGST because the plant master GSTIN was set to the same state as the vendor at PO time, but the legal supply was interstate. SAP standard will let the MIRO user override at posting, but the override leaves a residual on GR/IR because the MIGO posting was at the PO tax code. The cleanup is a manual journal that breaks the audit trail.
The structural fix is a rule at MIRO that compares PO tax code to invoice tax code and routes the variance to an exception queue. SAP standard does not enforce this.
India-specific gap 2 — TDS posting timing under Section 393
SAP’s withholding tax functionality is configured per country in transaction OBWO. Each withholding tax type defines whether tax is posted at invoice booking or at payment. For Section 393(1)(a) contractor payments (replacing legacy 194C, payment code 1002), most Indian manufacturers configure WHT at invoice booking — at MIRO, the vendor payable line is net of TDS, and the TDS payable line credits the income tax liability GL.
The cutover problem at FY 2025-26 to FY 2026-27 is the payment code remapping. The WHT types must be reconfigured from the old 194-series codes (194C, 194J, 194Q) to the new Section 393 codes (1002, 1003, 1012 respectively). The Form 27Q quarterly return generation logic must point at the new section reference. Vendor master WHT codes must be updated en masse.
Older transactions — invoices booked in FY 2025-26 — keep the legacy 194-series code reference for cross-era Form 26AS matching. The reconciliation layer must handle both code histories side by side until the final FY 2025-26 returns are accepted. See Section 393 TDS new Income Tax Act reconciliation for the full cross-era handling.
India-specific gap 3 — J1IGN, J1IS and India-localised transactions
SAP’s India localisation carries a set of J1* transactions originally built for the excise-era stock movement, depot operations, and challan numbering. Several of these remain in active use even post-GST for specific configurations:
- J1IGN — India stock issues and re-determinations, sitting outside the standard MIGO flow for certain capital goods movements
- J1IS — challan numbering for stock transfers to job-workers under Section 143 of the CGST Act
- J1IFR — depot operations and stock transfer reconciliation
When these J1IGN/J1IS postings hit the same GR/IR or inventory accounts that the MIGO/MIRO flow uses, the GR/IR balance report includes line items that have no MIRO-posted counterpart, because the corresponding invoice (or job-work return) is routed through a different India-specific transaction. Cleaning these up requires a J1IGN-aware reconciliation layer.
India-specific gap 4 — OBYC GR/IR account determination
SAP determines the GR/IR account at MIGO using transaction OBYC account determination — driven by the material’s valuation class, the movement type, and the plant. A factory that maintains 15-20 valuation classes (raw material, packing, consumables, capital goods, scrap, etc.) often has a GR/IR mapping that drifts when new valuation classes are introduced and the OBYC table is not updated in parallel.
The symptom: a GRN posts to one GR/IR account, the corresponding MIRO posts to a different GR/IR account (because the user selected the wrong material code or the system defaulted differently), and the GR/IR balance report shows two open items that should net to zero but sit in different accounts. SAP standard does not flag this; it requires periodic OBYC mapping audits and a reconciliation rule that aggregates GR/IR balances by PO+vendor across all GR/IR sub-accounts.
India-specific gap 5 — cross-GSTIN consolidation
A company code in SAP often spans multiple plant GSTINs. Each plant files its own GSTR-1, GSTR-2B and GSTR-3B. When a vendor invoice straddles plants (one PO with materials delivered to two plants, or a stock-transfer PO routed inter-state), the GST ITC claim must split correctly per plant GSTIN.
SAP standard tracks plant on every line, but the consolidation back from plant-GSTIN-level GST filings to the company-code-level books, with the reverse mapping for ITC eligibility under Rule 36(4), is typically done outside SAP — in a spreadsheet or a custom report. A structured reconciliation layer that pulls GSTR-2B per plant GSTIN and ties it to the SAP MIRO entries per plant closes this gap.
India-specific gap 6 — Section 17(5) blocked credit flagging
Section 17(5) of the CGST Act blocks ITC on a defined list of inputs. SAP standard knows the tax code on each invoice line (the GST charged by the vendor) but does not natively know the blocking rule — that depends on material type, end-use, and accounting capitalisation, none of which sit cleanly in the SAP tax determination logic.
The result: blocked-credit inputs (motor vehicle services for non-business use, construction services for own building, employee insurance beyond statutory) get booked at MIRO with full ITC claimed in GSTR-3B. The reversal — required if discovered before September of the following financial year, with 18% interest if past September — happens at audit. A reconciliation layer that flags material types per Section 17(5) at MIRO catches these before the GSTR-3B claim.
Reference: variance taxonomy on SAP MM-FI India
| Variance code | SAP standard catches? | Resolution |
|---|---|---|
| Rate mismatch | Yes — GR/IR open balance | MIRO override or vendor credit note |
| Quantity mismatch | Yes — GR/IR open balance | Re-receive or re-invoice |
| GST tax code drift (PO vs invoice) | No | Manual review + journal |
| TDS WHT code wrong (Section 393 cutover) | Partial | Vendor master update + reposting |
| J1IGN challan open | No | India-localised reconciliation |
| OBYC mapping mismatch | No | Periodic OBYC audit |
| Cross-GSTIN consolidation | No | External reconciliation |
| Section 17(5) blocked credit claimed | No | Pre-MIRO material flag |
| Cross-era 194-to-393 mapping | No | Dual code reference table |
What a structured reconciliation layer adds
SAP standard handles the rate-and-quantity backbone cleanly. The India-specific overlay needs a separate rule layer. Purpose-built reconciliation software India for manufacturing sits alongside SAP MM-FI — typically pulling MIRO and MIGO extracts daily plus GSTR-2B per plant GSTIN — applies the India-specific rule set, surfaces variances in a SAP-aware exception queue with transaction codes mapped back to MIRO line references, and runs the cross-era 194-to-393 mapping for the FY 2025-26 to FY 2026-27 cutover. Build is two-to-four weeks on AWS Mumbai (ISO 27001:2022), with the manufacturer’s match rate moving from a 51% baseline to 88% across the broader AP surface. For the headline three-way match rail see three-way matching software India, for the broader SAP integration angle see SAP FI reconciliation in India, and for the pillar guide to all five manufacturing reconciliation rails see manufacturing reconciliation in India.
The current text of CGST rate notifications, Rule 36(4) ITC eligibility against GSTR-2B, and the e-invoice IRN requirements that affect SAP invoice posting are maintained on the GST portal.