CFO Strategy — India & Global
Building a Finance Centre of Excellence for Indian Companies
The group CFO of a ₹4,000 crore Indian manufacturing conglomerate — 18 entities, 7 states, 23 GST registrations — approved a Finance Shared Services Centre two years ago. The business case projected 35% cost savings through headcount consolidation. Eighteen months in, the numbers tell a different story. The SSC employs 42 people in Pune processing transactions for all 18 entities. Entity-level finance teams still employ 67 people — down from 85, not the projected 50. The 35% savings became 14%. Worse, the entity controllers now spend an additional 6 hours per week coordinating with the SSC: explaining entity-specific requirements, reviewing SSC output, correcting errors that stem from the SSC team not understanding local regulations, and escalating delayed filings. The CFO did not build a Centre of Excellence. He built a centralized processing pool that lacks the process ownership, regulatory expertise, and quality governance needed to actually run finance for 18 different entities across Indian regulatory complexity. The headcount moved to Pune. The problems stayed exactly where they were.
A Finance Centre of Excellence is not a shared services cost play. It is a service delivery architecture that centralizes process ownership, regulatory expertise, technology adoption, and continuous improvement — not just transaction processing headcount. For Indian companies, the CoE must be designed around regulatory density (GST, TDS, MCA filings across states and entities), multi-entity complexity, and talent market realities. The architecture that works: pod-based teams organized by process domain (not by entity), with regulatory specialists embedded in each pod, a service catalog with defined SLAs, and a governance layer that measures quality, not just throughput.
How to design and build a Finance Centre of Excellence for Indian companies — covering service model architecture, pod structures, regulatory specialization, technology enablement, and the governance needed to deliver quality at scale across entities.
Group CFOs at Indian enterprise groups (₹500 crore to ₹15,000 crore) considering or restructuring shared services, finance transformation leaders evaluating the GBS model, and PE-backed platforms building centralized finance functions across acquisitions.
Indian enterprise groups waste ₹2-5 crore annually on poorly designed shared services that deliver neither the cost savings nor the quality improvement they promised. A properly designed CoE reduces true finance costs by 30-40% while improving compliance accuracy and close timelines.
The Shared Services Mistake
Most Indian companies approach shared services as a headcount consolidation exercise. Take the AP clerk from Entity A, the AR clerk from Entity B, the reconciliation analyst from Entity C, put them in one office, and call it shared services. The math looks compelling on a slide deck: consolidate 85 people across entities into 50 centralized staff, save 35% on compensation costs, and add some technology to drive further efficiency.
The reality is different because the math ignores what actually makes finance work. When the AP clerk sat in Entity A’s office, she knew which vendors required TDS deduction under Section 194C versus 194J. She knew that the Rajasthan state warehouse invoices came in a different format. She knew that the promoter’s brother-in-law’s company needed payment within 7 days regardless of standard terms. She knew all of this because she had processed Entity A’s invoices for four years. Move her to the SSC and assign her invoices from Entities A through F, and she knows none of this context for five of her six entities.
Across 915 implementations we analyzed, shared services failures share a common pattern: they centralize the labor without centralizing the knowledge. The knowledge stays with entity-level staff who become “coordinators” — people who used to do the work and now spend their time explaining it to someone in another city. You have not eliminated work. You have split it across two locations and added a communication layer that did not exist before.
What a Finance CoE Actually Looks Like
A Centre of Excellence differs from shared services in three fundamental ways. First, it owns the process, not just the processing. The CoE does not receive invoices and post them — it designs the AP workflow, defines the approval matrix, sets the quality standards, builds the exception handling protocols, and then executes within that design. When something breaks, the CoE fixes the process, not just the transaction.
Second, it builds specialized expertise rather than generalized processing capacity. Instead of assigning staff by entity (“Ravi handles Entities A through D”), the CoE organizes by process domain (“the AP pod handles all entities, with specialists for TDS, GST input credit, and intercompany”). This pod structure concentrates expertise where it matters most.
Third, it drives continuous improvement. Shared services measures throughput — invoices processed, returns filed. A CoE measures outcomes — error rates declining, cycle times compressing, compliance costs dropping, entity satisfaction increasing. The distinction matters because throughput can increase while quality deteriorates.
Pod Architecture for Indian Regulatory Complexity
The pod model that works for Indian CoEs organizes around three dimensions: process domain, regulatory specialization, and entity complexity tier.
Process domain pods: Accounts Payable (invoice processing, vendor management, TDS compliance, payment execution), Accounts Receivable (billing, collection, TCS compliance, revenue recognition), Record-to-Report (journal entries, reconciliations, close activities, financial reporting), and Compliance (GST returns, TDS returns, MCA filings, advance tax, regulatory automation). Each pod has a lead, 3-6 processors, and at least one regulatory specialist.
Regulatory specialists: This is where Indian CoEs diverge most from Western models. Every pod needs someone who understands the regulatory implications of routine transactions. The AP pod needs a TDS specialist who can classify payments correctly across 15+ TDS sections. The compliance pod needs GST specialists who understand input credit matching, reverse charge, e-invoicing thresholds, and state-specific rules. These specialists do not process transactions — they design the rules the processors follow and review exceptions.
Entity complexity tiers: Not all entities are equal. A listed subsidiary with SEBI reporting requirements is fundamentally different from a single-state trading entity. Tier the entities by complexity (simple, moderate, complex) and assign pod capacity accordingly. A complex entity might require 1.5x the CoE resources of a simple entity, even with similar transaction volumes.
The Service Catalog and SLA Framework
The service catalog is the contract between the CoE and the entities it serves. Without one, every request is ad hoc, every priority is urgent, and every entity finance head believes their work should be done first. The service catalog defines what the CoE delivers, to what standard, and in what timeframe.
For each service, define: the trigger (what initiates the process), the inputs required from the entity (what the CoE needs to begin), the processing SLA (turnaround time from complete inputs to completed output), the quality standard (acceptable error rate), and the escalation path (what happens when the SLA is at risk). An AP service catalog entry might read: “Invoice processing — triggered by invoice receipt in the shared inbox, requires approved purchase order reference, 48-hour processing SLA from complete documentation, less than 2% error rate on TDS classification, escalation to pod lead if documentation incomplete after 24 hours.”
The discipline of writing a service catalog forces clarity that shared services centers typically lack. When the entity finance head says “your team processed my invoice wrong,” the service catalog provides the framework for diagnosis: was the input complete? Was the SLA met? Was the error within the quality standard? This transforms vague complaints into measurable service conversations.
Technology Enablement Layer
The CoE’s technology architecture serves three functions: workflow management, quality control, and performance visibility. Technology selection matters less than technology architecture — how the tools connect to create an end-to-end processing system.
Workflow management: Every process needs a defined workflow with task assignment, status tracking, handoff management, and SLA monitoring. The CoE cannot run on email and spreadsheets — it needs a system that makes work visible. This might be a dedicated workflow platform, an ERP workflow module, or a well-configured project management tool. The key requirement: every task has an owner, a status, a deadline, and an audit trail.
Quality control: Automated validation rules that catch errors before they reach the ERP. Structured data capture that prevents classification errors. Review workflows that route exceptions to the right specialist. The quality layer prevents the CoE from becoming a high-volume error factory — processing fast but inaccurately.
Performance visibility: Real-time dashboards showing SLA compliance by process, error rates by entity, workflow bottlenecks, and capacity utilization. This visibility serves both the CoE management (for operational decisions) and the entity stakeholders (for service transparency). When Entity C asks “where is my GST return?” the dashboard provides the answer without a phone call.
Governance That Drives Quality
CoE governance operates at three levels. Operational governance: daily standups within each pod, weekly cross-pod coordination, monthly SLA reviews with entity stakeholders. The pod lead runs daily standup — reviewing yesterday’s completed work, today’s priorities, and any blockers requiring escalation. This fifteen-minute meeting prevents the information vacuum that makes entity finance heads nervous about centralized processing.
Process governance: quarterly process reviews where each pod examines error patterns, identifies root causes, and implements process improvements. This is where the “excellence” in Centre of Excellence actually lives. Shared services processes transactions. A CoE improves the processes themselves. Every quarter, error rates should decline, cycle times should compress, and the ratio of exceptions to standard processing should shrink.
Strategic governance: semi-annual reviews with the group CFO covering standardization coverage (what percentage of finance processes run through the CoE), cost trajectory (cost per transaction over time), automation readiness (which processes are candidates for AI augmentation), and entity satisfaction (are the entities getting better service than they had before). If entity satisfaction is declining, something in the architecture is wrong — regardless of what the cost metrics show.
Building Sequence for Indian Companies
Months 1-3: Foundation. Define the service catalog for AP and bank reconciliation (highest volume, most standardizable). Establish the AP pod with 5-7 people including one TDS specialist. Pilot with 3-4 entities that have the cleanest data and most cooperative finance heads. Do not start with the most complex entities — earn credibility first.
Months 4-6: Expand and stabilize. Add AR and basic compliance services. Expand to 6-8 entities. Implement the workflow management system. Begin measuring SLA compliance. Address the quality issues that surfaced in the first quarter. This phase is about proving that centralized processing can match or exceed entity-level quality — not yet about cost savings.
Months 7-12: Scale. Add record-to-report and advanced compliance (GST reconciliation, TDS returns, MCA filings). Expand to all entities. Implement performance dashboards. Begin the continuous improvement cycle. By month 12, the CoE should be processing 70-80% of transactional finance work with measurable quality improvements over the decentralized model.
Year 2: Optimize. Layer in automation for standardized processes. Add advisory capabilities (variance analysis, trend reporting, compliance risk monitoring). Reduce the entity-level coordination burden by building enough context and expertise within the CoE that entities no longer need to explain their requirements. This is when the 30-40% cost savings materialize — not in month 6.
The sequence matters because premature scaling is the most common Indian CoE failure. Groups that try to centralize everything for all entities in month one create chaos. Groups that build methodically, prove quality with pilot entities, and expand based on demonstrated capability build CoEs that actually work. The pattern from US firms that centralized finance operations 3-5 years ago is consistent: discipline in sequencing predicts success more reliably than budget or technology.
Key Takeaways
A CoE designs, executes, and improves finance processes. Shared services just processes transactions. The distinction determines whether centralization improves quality or just moves problems to a new location.
Organize by process domain, not by entity. Embed TDS, GST, and MCA specialists in each pod. Indian regulatory density demands specialization that entity-based assignment cannot provide.
Define what the CoE delivers, to what standard, in what timeframe. Without this contract, every interaction is ad hoc and every complaint is subjective.
Start with 3-4 pilot entities and high-volume processes. Prove quality first. Expand based on demonstrated capability. The 30-40% cost savings materialize in year two, not month six.
The Bottom Line
The difference between a shared services center that disappoints and a Centre of Excellence that transforms is not technology, location, or headcount. It is architecture — the service model, the pod structure, the governance, and the disciplined sequencing that turns a cost play into a capability play. Indian companies face regulatory and structural complexity that makes this architecture more important, not less. Build the architecture first. The efficiency follows. The alternative — centralizing headcount without centralizing process ownership and expertise — creates a new set of problems without solving the old ones. Across 915 implementations, the companies that treated centralization as an architecture project achieved 30-40% cost reduction with improved quality. The companies that treated it as a headcount consolidation exercise achieved 10-15% savings with declining entity satisfaction. The architecture is the difference.
Frequently Asked Questions
What is a Finance Centre of Excellence?
A centralized unit that owns process design, execution, quality standards, technology adoption, and continuous improvement for finance operations across entities — not just a shared pool of transaction processors.
Why is building a Finance CoE different in India?
Regulatory density (GST across states, 15+ TDS sections, MCA filings), entity proliferation (10-30 entities in typical groups), and talent market dynamics (Tier 1 vs Tier 2 city cost-retention trade-offs) require India-specific architecture.
What processes should a Finance CoE handle first?
Start with accounts payable, bank reconciliation, and accounts receivable — highest volume, most standardizable, clearest quality metrics. Add compliance and record-to-report after the first processes stabilize.
How is a CoE different from shared services?
Shared services centralizes transaction processing. A CoE owns the process end-to-end: design, execution, quality, technology, and improvement. The CoE improves processes; shared services just runs them.
How do you measure CoE success?
Cost per transaction (declining), processing cycle time (compressing), error rates (shrinking), entity satisfaction (stable or improving), and standardization coverage (expanding). Cost without quality improvement is a failure mode.