Multi-entity AP consolidation doesn't get easier as a company adds entities, it gets structurally harder, because ERP consolidation modules eliminate intercompany ledger entries but don't reconcile the vendor master underneath them. The same vendor often carries a different GSTIN per entity, and no ledger-level elimination catches that. Continuous, invoice-level validation is what closes the gap a bigger ERP module can't.
For a CFO running three or four legal entities, the ERP go-live was supposed to be the point where consolidation got simpler. Instead, close takes longer each quarter, and the reason rarely shows up on a standard AP dashboard. Go-live is a reset point, not an endpoint, and multi-entity consolidation is one of the places that reset most often stalls. The general ledger consolidates cleanly. Intercompany balances net out and eliminations post without incident. What doesn't consolidate is the vendor master sitting underneath it, and that's where the actual reconciliation work lives.
Why Does Consolidation Get Harder as You Add Entities, Not Easier?
The assumption behind most ERP consolidation projects is that scale makes consolidation simpler, fewer systems to maintain, one chart of accounts instead of several. For the general ledger, that assumption mostly holds. For accounts payable, it doesn't, because each new entity doesn't add a proportional slice of AP work. It adds an entirely new GST registration, a new set of TDS classification decisions, and a new vendor onboarding process, all layered on top of what already existed at the other entities.
This is the same compounding pattern described in our analysis of why B2B month-end close is harder than B2C, which flagged multi-entity consolidation, where intercompany entries and eliminations enter the picture, as a topic that needed its own article. This is that article.
ERP consolidation modules are built to solve a specific, narrower problem: matching and eliminating intercompany transactions at the ledger level so a consolidated balance sheet doesn't double-count internal trading. That's real, necessary work, and most modern ERPs do it well. What it assumes, though, is that the vendor master feeding those entries is already clean, one vendor, one record, consistently identified across every entity. In an Indian multi-entity group, that assumption is usually wrong before the first consolidation run.
What Breaks at the Vendor Level When You Add a Second GSTIN
India's GST structure requires state-wise and entity-wise registration. A single national supplier delivering to two legal entities, or the same entity operating from two states, often ends up registered under separate GSTINs for GST purposes, per Sections 22 and 25 of the CGST Act, 2017, which treat each state-wise or entity-wise place of business as a distinct person for registration. That's correct and expected under the law. What isn't automatic is what happens next inside the ERP: the same real-world vendor frequently gets onboarded as separate, unlinked vendor master records, one per entity, sometimes under slightly different legal name formatting, sometimes with no cross-reference between them at all.
IQInvoice has seen this pattern directly in multi-entity Indian deployments. An invoice discrepancy or payment-term inconsistency resolved at one entity never surfaces the same issue already sitting unresolved at another, because nothing connects the two vendor records. A ledger-level consolidation module has no visibility into this. It reconciles whatever balances each entity's books report, and if each entity's AP team resolved a vendor issue independently and inconsistently, the ledger looks clean even though the underlying vendor record was never fixed.
This is a data governance problem wearing an accounting problem's clothes. The symptom shows up at close, when eliminations don't tie out cleanly or take longer than expected to investigate. The cause sits earlier, at vendor onboarding, where nothing in a standard ERP workflow forces a check for whether a vendor already exists under a different GSTIN at a sister entity.
What Does Continuous Reconciliation Look Like Instead of a Bigger ERP Module?
The instinct, once this pattern is visible, is to look for a bigger consolidation module, one with better intercompany matching, more automated eliminations, tighter ledger controls. That solves the ledger-level symptom without touching the vendor-level cause. A better elimination engine still eliminates whatever the entity books report; it doesn't verify that a vendor invoice booked at Entity A and a vendor invoice booked at Entity B, for the same real vendor under two GSTINs, were ever cross-checked against each other before either entity closed its books.
What actually closes the gap is validation at the invoice level, continuously, not at the ledger level, periodically. The AP team checks a vendor's GSTIN and legal identity against a shared reference the moment an invoice is booked, not after the fact during a consolidation run, and the same check flags when that vendor already exists under a related GSTIN at another entity before a second, duplicate record gets created. Exceptions, mismatched terms, inconsistent classification, unresolved discrepancies, become a running list the team works down continuously, rather than a backlog that surfaces all at once during close.
This changes what a CFO should actually be measuring. Invoice volume tells you almost nothing about multi-entity AP health. Entity count, vendor-master duplication across entities, and the rate at which GSTIN mismatches surface during reconciliation are the leading indicators, and none of them are on a standard AP dashboard built for a single-entity business. The metrics that matter six months after go-live shift for the same reason: what mattered on day one of automation isn't what predicts whether the next close gets easier or harder.
See how IQInvoice handles compliance-native AP automation to evaluate whether invoice-level, entity-aware validation can close this gap before it reaches your consolidation run.
Key observations:
- Multi-entity AP consolidation gets harder with each entity added, not proportionally easier with scale, because ERP consolidation modules solve ledger-level elimination, not vendor-master-level reconciliation.
- India's state-wise and entity-wise GST registration structure means the same vendor commonly carries different GSTINs across a group's legal entities, per Sections 22 and 25 of the CGST Act, 2017.
- ERP consolidation modules assume the vendor master feeding them is already clean; in Indian multi-entity deployments, that assumption is frequently wrong before the first consolidation run.
- The fix is invoice-level, continuous validation at the point of vendor onboarding and invoice booking, not a bigger or better ledger-level elimination engine.
- The right measurement signals are entity count, vendor-master duplication rate, and GSTIN-mismatch rate, not invoice volume.