Building a Finance Shared Services Center: A Mid-Sized Indian CFO's Playbook

Most mid-sized Indian companies with three or four legal entities, two ERPs, and a finance team scattered across Mumbai, Pune and a plant town in Gujarat eventually hit the same wall: month-end close takes 12-15 days, the same vendor master gets maintained four different ways, and nobody can tell you group-level DSO without a week of Excel archaeology. The instinctive fix is to hire more people in each location. The better fix, and the one large enterprises figured out two decades ago, is to consolidate transactional finance work into one dedicated hub — a Finance Shared Services Center (FSSC).

This isn't a Global Capability Center (GCC) conversation aimed at Fortune 500 back-offices exporting services to a US or European parent. This is about an Indian company, serving Indian entities, under Indian GST and TDS law, trying to get more consistency and control out of the finance function it already has. That distinction matters more than most FSSC literature admits, because the compliance mechanics are genuinely different — and genuinely trickier — when every entity involved sits under Indian tax law with its own PAN and GSTIN.

What exactly should an FSSC take off your regional teams' plates?

An FSSC works by consolidating fragmented finance and accounting processes — Procure-to-Pay (P2P), Order-to-Cash (O2C), Record-to-Report (R2R) and FP&A — into one dedicated hub that eliminates redundancies and enforces a single, consistent set of controls across entities.

For a mid-sized company with, say, ₹800 crore revenue across three subsidiaries, that typically means moving these activities into the hub:

• P2P: vendor master maintenance, three-way invoice matching, TDS deduction and challan tracking, vendor reconciliation
• O2C: invoice generation, GST return line-item preparation, collections follow-up, customer credit control
• R2R: journal entries, intercompany eliminations, fixed asset accounting, bank reconciliation, trial balance close
• FP&A: budget consolidation, variance reporting, MIS packs for the group CFO

What stays at the plant or branch level is judgment-heavy work: negotiating with a vendor over a disputed rate, approving a large capex, or explaining a customer's payment delay to sales. The hub does the repeatable 80%; the business units keep the relationship-heavy 20%.

We've written separately about the reporting layer that sits on top of this — see our Cloud Reporting Architecture blueprint for how to structure compliance-first dashboards once the FSSC is generating clean, consistent data. This article stays one layer below that: how you actually build the hub.

How much does an FSSC actually save, and how fast?

The number CFOs want first is the payback period. Organisations building FSSCs typically recover their investment within 18 to 24 months, and realize a 30-40% reduction in finance operational costs within the first two years of setting one up.

Run the arithmetic on a realistic mid-sized case. Say your finance headcount across four entities is 42 people, with a fully-loaded average cost of ₹9 lakh per person per year — a total finance opex of roughly ₹3.78 crore. Consolidating P2P, O2C and R2R into a hub of 26 people (some transactional roles are automated away, others are pooled across entities) at a slightly higher average cost of ₹9.5 lakh (because hub roles demand more process and systems skill) brings staff cost to ₹2.47 crore. Add ₹35 lakh a year for the automation and workflow tooling layer, and total FSSC-model cost lands around ₹2.82 crore — a saving of roughly ₹96 lakh a year, or about 25%, once you're past the transition. Add in reduced TDS short-deduction penalties, fewer GST notices from mismatched invoices, and faster collections from centralized dunning, and the 30-40% range from the research becomes plausible within 24 months, not just theoretically but on your own P&L.

Set-up cost for a 25-30 person hub — furniture, workflow software, a leased floor in a Tier-2 city, three months of parallel run — typically runs ₹1.2-1.8 crore for a mid-sized company. Against ₹96 lakh in annual savings, that's an 18-month payback, right in the band the data suggests.

Is GST going to sabotage your intercompany model before you even start?

This is the part that trips up mid-sized Indian FSSCs and rarely gets discussed with any specificity. Unlike a US or European group where a parent can absorb shared costs without much tax friction, every rupee your Indian FSSC bills back to a sister entity is a supply under GST law — and India's GST framework has no group relief provision for entities holding different PANs, even if they're 100% commonly owned.

Two mechanisms exist to move common costs from the FSSC entity to the entities it serves, and both have sharp edges:

1. Input Service Distributor (ISD). From April 1, 2025, it has been made mandatory to register as an ISD if you're receiving common input service invoices — say, a single Zoho/Tally AMC bill, or a shared audit fee — against multiple GSTINs under one PAN. This is now compulsory, not optional, so if your FSSC entity procures a common software license centrally and distributes the benefit to plant-level GSTINs, you need the ISD registration in place. Miss this and you risk denial of credit at the recipient GSTIN.

2. Cross-charge for services rendered. Where the FSSC entity actually performs work — processing invoices, running payroll, closing books — for a sister company with a different PAN, that's a distinct supply of service, not a common cost eligible for ISD. You have to raise a tax invoice, charge GST, and the recipient claims input tax credit. The problem: there's no statutory valuation formula for what the FSSC should bill. Cost-plus-markup is common practice, but the appropriate markup, and whether it should include notional interest on working capital or an allocation of idle capacity cost, remains contested ground, and this exact ambiguity is what generates valuation disputes and ITC eligibility uncertainty in cross-charge arrangements.

The practical fix we recommend to clients: build your cross-charge methodology (cost-plus-8-to-10% is a defensible, commonly used band) into your FSSC's Standard Operating Procedure document before go-live, get it validated by your GST advisor, and raise monthly cross-charge invoices as a disciplined, dated process — not a year-end plug entry your R2R team scrambles to reverse-engineer during audit. Entities that treat cross-charge as an afterthought are the ones who get a GST audit query eighteen months later asking why FSSC billing has no documented basis.

One tailwind worth flagging for FSSCs with any export-facing component: the Finance Act, 2026 has omitted Section 13(8)(b) of the IGST Act, restoring export character for intermediary services. If any part of your shared hub eventually services an overseas group entity or supports outbound work, this removes an embedded GST cost that previously made such services look like domestic supply rather than exports — a meaningful competitiveness lever if your FSSC ambitions extend beyond India in a few years.

Why does TDS keep generating notices even after you've built the hub?

Centralizing P2P doesn't automatically fix TDS. In fact, it concentrates the risk: one team is now deducting tax at source for four entities' worth of vendor payments, and a single misclassification error replicates across all of them.

The recurring failure modes in Indian TDS compliance are ambiguity in classifying a payment (is a ₹4 lakh IT support invoice "fees for technical services" under Section 194J at 10%, or a works contract under Section 194C at 1-2%?), the reconciliation burden between books, challans and Form 26AS/AIS, and the cash-flow and penalty consequences when deduction, deposit or return filing slips. A short-deduction on a single ₹50 lakh contractor payment — deducting 1% instead of 10% because it was coded as 194C instead of 194J — creates a demand plus interest under Section 201 that can run into several lakhs by the time it's caught at the next TRACES reconciliation.

The FSSC advantage here, if you build it deliberately, is that you can bake a payment-classification decision tree directly into your P2P workflow tool, so the TDS section is proposed automatically based on vendor category and PO type, with an exception queue for anything the rules engine can't classify confidently. That single control — a rules-based TDS section suggestion at invoice entry — is the highest-ROI automation item most mid-sized FSSCs implement in year one, because it prevents errors at the point of entry rather than catching them at reconciliation. We've covered the reconciliation side of this problem in depth in Vendor Reconciliation Automation: Closing the GST-TDS-MSME Gap — worth reading alongside this if vendor master hygiene is a live issue for you.

How do you sequence the build without a "big bang" that stalls in month four?

Large enterprises can afford a simultaneous, multi-country transformation program with a ₹40 crore budget and a three-year timeline. Mid-sized Indian companies cannot, and shouldn't try to. The workable pattern is a three-phase rollout over 12-15 months.

Phase 1 (Months 1-4): Pilot with one process, one entity. Pick the highest-pain, most standardizable process — usually P2P — and migrate it for your largest single entity first. Keep O2C, R2R and FP&A where they are. This gives you a controlled environment to work out workflow tool configuration, approval matrices and TDS rules without risking the whole close cycle.

Phase 2 (Months 5-9): Extend process, add entities. Bring the remaining entities onto the P2P hub, then add O2C. This is where you start seeing the intercompany cross-charge and ISD registration questions become real, so loop in your GST advisor at the start of this phase, not the end.

Phase 3 (Months 10-15): R2R and FP&A consolidation, CoE transition. Move journal entries, reconciliations and consolidated MIS into the hub last, because this is the highest-trust, highest-judgment work and needs a hub team that has already proven itself on P2P and O2C. This is also the point where the hub philosophy shifts — the core idea behind a successful Indian FSSC is that it evolves from a simple "lift and shift" of existing tasks into a "transform and optimize" model, with process standardization and a genuine Center of Excellence mindset, rather than a cost-cutting back-office.

A concrete milestone check we use with clients: if by month 9 your hub hasn't reduced month-end close from (say) 12 days to under 8 days for the entities already migrated, the workflow design has a gap — usually in approval routing or in how exceptions are escalated — and it needs fixing before you add R2R on top of it.

Can you actually staff and retain a hub team in today's talent market?

India's scale advantage is real and well documented — the country produces over 1.5 million finance, IT, accounting and analytics graduates annually, and labor and operational costs for shared services here run 50-70% lower than in the US. But access to talent isn't the mid-sized company's real problem; retention is.

A large GCC in Bangalore or Hyderabad can offer an 18-year career ladder, global mobility and a recognizable brand name on a resume. A 30-person finance hub inside a mid-sized manufacturer in Nashik or Coimbatore cannot compete on those terms, and if it tries to compete purely on salary, attrition will eat the savings you just built. High attrition, poor knowledge transfer when people leave, and lack of buy-in from the regional teams whose work is being centralized are the most common pain points that derail FSSC builds in the Indian market.

What actually works for mid-sized hubs:

• Design career paths within the hub itself. A P2P analyst who spends 18 months there should have a documented route to becoming an FP&A analyst or a process lead, not just a longer tenure at the same desk.
• Involve regional finance managers in the design, not just the handover. The single biggest predictor of pushback we see is a hub design done entirely by consultants or the group CFO's office, then announced to plant controllers as a fait accompli.
• Upskill toward analysis as automation eats transactional volume. As RPA and workflow tools absorb three-way matching and reconciliation, the hub's headcount mix should shift from 80% transactional / 20% analytical toward something closer to 50/50 within three years. Communicate this shift explicitly to the team; it's your retention story as much as your efficiency story.

What technology backbone actually makes this work, and what breaks it?

The success of any FSSC hinges on a robust technology backbone — seamless integration with existing ERP systems and workflow automation that minimizes manual data entry. For mid-sized Indian companies, this is harder than it sounds because the starting IT landscape is rarely uniform: one entity on Tally, another on an old SAP Business One instance, a third running everything through Excel and email.

This is precisely the scenario we've addressed in detail elsewhere — if you're bridging Tally-based entities into a modern reporting and workflow layer, see Tally to Power BI Guide, and if SAP is your backbone, Integrating SAP with Power BI covers the integration patterns. The FSSC-specific point to add here: don't wait for a single unified ERP before building the hub. Standardize the process first (a common chart of accounts mapping, a common vendor coding taxonomy, a common approval matrix) and let the technology integration catch up in Phase 2 or 3. Companies that insist on ERP unification as a precondition for FSSC launch typically add 12-18 months of delay for a benefit that could have been captured through process standardization alone.

The automation trend supports moving fast on this: by 2024, 72% of shared service centers globally had implemented at least one layer of process automation, up sharply from 38% in 2019 — a signal that automation-first hub design is now the default expectation, not a stretch goal. And it's not a peripheral bet: finance and accounting was the single largest segment of the global shared services market in 2024, holding a 45% share, in a market projected to grow at a 22.3% CAGR through 2035 to roughly USD 629.11 billion. If you're building an FSSC now, you're building into a segment that is structurally expanding, not a fad that will lose executive sponsorship in two years.

What should the first 90 days actually look like?

Concretely, if you're a CFO who has decided to build:

1. Weeks 1-2: Map every finance FTE across entities to a process (P2P, O2C, R2R, FP&A) and location. This single exercise usually reveals more duplication than anyone expected.
2. Weeks 3-6: Select the pilot entity and process, draft the SOP with the regional finance manager as co-author, and get your GST advisor to review the intercompany cross-charge or ISD structure before it's needed, not after.
3. Weeks 7-10: Configure the workflow tool for the pilot process, including a TDS-section rules engine at invoice entry, and run a parallel cycle against the existing manual process for at least one full month-end.
4. Weeks 11-13: Go live for the pilot entity, measure close-cycle time and error rate against baseline, and use that evidence to build the business case for Phase 2 funding.

Treat the pilot's numbers as your internal proof point — a 3-4 day reduction in close time for one entity is a far more persuasive argument to your board for Phase 2 investment than any industry benchmark.

How BiPivot helps

BiPivot works with mid-sized Indian finance teams on exactly this transition — mapping fragmented P2P, O2C and R2R processes into a workable FSSC design, building the intercompany GST and TDS controls into the workflow rather than bolting them on later, and integrating the hub with whatever ERP mix you already run. If you're weighing whether a phased FSSC build makes sense for your group, visit BiPivot to talk through where your finance function stands today.