TL;DR: Master data management in shared services is the discipline of giving each master data domain one accountable business owner, one set of creation rules and one approved record that every legal entity uses. Shared services reporting gets faster when master data errors are blocked at record creation, because each unmapped account or duplicate vendor otherwise resurfaces as a manual fix during the close. The first master data fixes to make are group account mapping and intercompany partner codes, since those breaks delay consolidation most directly. A shared services centre should measure its own duplicate rate and first-time-right creation rate before relying on any outside benchmark.
Master data is the slowly changing reference information that transactions point to: customers, vendors, materials, employees, cost centres and the chart of accounts. Every invoice, journal and payroll run inherits its account, segment, tax treatment and counterparty from those records, so one error in the master copies itself into every transaction that uses it. Shared services magnifies that effect in both directions, because a single desk creates records for many entities: one weak rule spreads to every entity, while one good rule repairs all of them at once.
Astravise is model-agnostic by design, and the ownership rules below hold whether the shared services centre is a captive global capability centre (GCC), an outsourced provider or a hybrid of the two. Astravise has also run finance and governance workstreams through complete GCC builds, including a Hyderabad GCC for a US-listed logistics company, and master data decisions sit inside both workstreams.
Bad master data slows reporting before the close begins
Reporting speed is decided when a record is created, long before anyone opens the close checklist. A transaction posts using whatever its master records say, and an attribute missing at creation stays invisible until reconciliation or consolidation exposes it. By then the fix is a manual journal under deadline pressure, made by someone who never saw the original record.
Consider a group where one packaging supplier exists as three vendor codes across three entities, each with different payment terms. Spend reports split that supplier three ways, the cash forecast misreads the real payment profile, and a volume discount negotiated at group level never triggers because no single code reaches the threshold. Nothing in the close checklist catches the problem, since each entity’s books balance on their own.
The general ledger fails in a similar way. An entity controller opens a new account to meet a local requirement, nobody maps it to the group chart, and at consolidation the balance lands in an unmapped bucket that a group accountant clears by hand. Related-party customers created without an intercompany partner code do equivalent damage to eliminations, a problem Astravise covers in its piece on how shared services fixes intercompany reconciliation and eliminations.
No published figure isolates the share of close delays that master data defects cause in India-based shared services centres. Gartner names inconsistency in data across sources as the most challenging data quality problem, the result of data stored and maintained in silos with significant overlaps, gaps or inconsistencies, which describes a multi-entity vendor or account master precisely. Whatever the proportion in a given group, every manual mapping journal at month-end is a master data decision someone deferred.
Who should own each master data domain in shared services?
Business functions should own master data definitions and quality, while the shared services centre maintains the records under their rules. A shared services centre can be the custodian of master data, but it should rarely be the owner.
A data owner is the business leader accountable for a domain’s definitions, quality standard and change rules. The data steward is the person who creates, validates and maintains records in that domain day to day, and in a shared services model that role sits in the shared services centre. Splitting the two roles keeps accountability with the people who use the data and execution with the people who handle it.
| Master data domain | Accountable data owner | Shared services role as steward | What breaks when nobody owns it |
|---|---|---|---|
| Chart of accounts and group mapping | Group financial controller | Opens entity accounts only with a group mapping attached | Balances land unmapped and consolidation needs manual journals |
| Vendor | Head of procurement | Validates PAN, GSTIN and bank details before activation | Duplicate codes split spend and leave payments exposed to stale bank details |
| Customer | Head of sales or credit control | Applies credit limits, tax attributes and billing hierarchy | Receivables ageing splits across duplicates and credit exposure is understated |
| Intercompany partner codes | Group financial controller | Assigns the partner flag on every related-party record | Intercompany balances post as third-party and fail to eliminate |
| Cost centre and profit centre hierarchy | Financial planning and analysis (FP&A) lead | Executes approved hierarchy changes outside the close window | Management reports show costs in the wrong segment |
Ownership by default is the failure to design out. When the shared services team becomes owner simply because it touches every record, no business leader answers for what counts as an active vendor or a separate customer, and the shared services centre ends up arbitrating disputes it has no authority to settle. A second failure is ownership by system rather than by domain, where the vendor master in one ERP instance sits with an entity finance team and in another with procurement, under two rule sets for the same supplier.
Governance works when rules apply at record creation
Master data governance is the set of standards, approval workflows and change controls that decide who may create or change a record and what that record must contain. Its job is prevention rather than repair. A one-off cleanse without creation controls decays back to where it started, because the channels that produced the bad records keep producing them.
The controls that carry most of the load in a shared services setting are these:
-
One request channel. Every new or changed record arrives through a single request workflow, with no back-door creation inside entity ERPs. Back doors are where duplicates and unmapped accounts come from, so closing them matters more than any cleansing tool.
-
Mandatory fields set by the data owner. Each domain has attributes a record cannot be activated without, such as PAN and GSTIN on a vendor or the billing hierarchy on a customer. A field that reporting depends on belongs in the mandatory set at creation, not in an optional field someone fills in later.
-
A duplicate check before activation. The steward searches existing records by tax identifier, bank account and normalised name before creating anything. Any match goes back to the requester instead of becoming a second code.
-
Dual approval on sensitive fields. Changes to bank details, payment terms and credit limits need an approver other than the person who keyed them. That control protects reporting accuracy and closes an obvious route to payment fraud.
-
A freeze window around the close. Cost centre and profit centre hierarchy changes wait until the period is locked. Management reports for the month then run on the structure the month started with.
Astravise does not publish numbers it cannot attribute, and governance targets deserve the same standard. Set targets for duplicate rate, first-time-right creation and manual mapping journals from the shared services centre’s own baseline, measured over at least two closes, rather than from a benchmark quoted without a source.
The master data fixes that shorten reporting, ranked by payoff
Astravise ranks master data fixes by how directly each break delays the group close, so the first items on this list pay back soonest. None of them needs a new master data management platform to begin.
-
Map every general ledger account to the group chart, and block posting to unmapped accounts. An unmapped account forces a manual consolidation journal every period, because the consolidation tool has nowhere to place the balance. Make the group mapping a mandatory field on account creation and run an unmapped-accounts report before each close.
-
Flag the intercompany partner on every related-party vendor and customer. Without the partner code, intercompany balances post as third-party balances and fail to eliminate. Fixing the flag at source removes a class of breaks that reconciliation teams otherwise chase every month.
-
Merge duplicate vendors and customers into golden records. A golden record is the single approved version of a vendor, customer or material that every system and legal entity in the group references. Merge duplicates into that record, keep the retired codes as cross-references for the audit trail, and block new postings to them.
-
Clean and lock the cost centre and profit centre hierarchies. Management reporting depends on every cost centre rolling up to exactly one profit centre and one segment. Orphaned or double-assigned cost centres produce segment reports that FP&A corrects by hand before leadership sees them.
-
Standardise tax codes and payment terms at creation. Inconsistent tax codes on similar vendors complicate input tax credit reconciliation, and free-text payment terms make the cash forecast unreliable. A controlled list for each, with the free-text versions retired, removes both problems.
Astravise’s view is that the tool decision comes after ownership and creation rules, because the rules define what any tool must enforce. Buying a platform first automates the existing confusion, with a licence fee attached.
AI in the close inherits every flaw in the master data
Automation and AI tools in a shared services close treat master data as ground truth, so a duplicate vendor or a mis-mapped account becomes a confident wrong answer produced at machine speed. Lumenalta, a technology consultancy that sells AI services, lists dependence on data quality among the five core limitations of AI it identifies. A shared services centre planning AI-assisted accruals, matching or variance commentary has a master data project first, whether or not anyone labels it that way.
Incidents involving AI are already being counted. According to Stanford’s 2025 AI Index, as cited by Lumenalta, 8% of surveyed organisations experienced AI-related incidents in 2024, and 42% of those affected reported one or two incidents over the year. That figure is not India-specific, and the source as quoted does not state the survey’s geography, sample size or definition of an incident. It shows that incidents happen, not how often master data causes them.
Detection is the part of master data work where AI earns its place. Matching models can propose likely duplicate pairs across entities, flag new records whose attributes look inconsistent with similar ones, and spot postings that look out of pattern for an account. Each of those outputs is a work queue for a steward, which is the right shape for the task.
Deciding what a match means still needs a person. Christopher Dede of Harvard’s Graduate School of Education argues in the Harvard Gazette that generative AI “doesn’t understand the human context”, while calling it “very good at absorbing large amounts of data and making calculative predictions”. Applied to a vendor master, that split is practical: the model proposes the merge, and a steward who knows that two similarly named suppliers became separate legal entities after a restructuring makes the decision.
Sources
-
Data Quality: Why It Matters and How to Achieve It (Gartner)
-
AI’s limitations: 5 things artificial intelligence can’t do | Limitations of AI | Limits of AI | Lumenalta (Lumenalta, 2024-08-27)
-
Is AI dulling our minds? — Harvard Gazette (Harvard Gazette (interview with Fawwaz Habbal, Senior Lecturer on Applied Physics, Harvard John A. Paulson School of Engineering and Applied Sciences))
Frequently asked questions about master data management in shared services
- What is master data management in shared services?
- Master data management in shared services is the practice of giving customer, vendor, material, employee, cost centre and chart of accounts records one accountable business owner, one set of creation rules and one approved version that every legal entity uses. The shared services centre maintains those records as data steward, under rules the business owners set.
- Who should own master data, the business or the shared services team?
- Business functions should own master data, and the shared services team should maintain master data records. Procurement owns the vendor master, sales or credit control owns the customer master, and the group financial controller owns the chart of accounts and intercompany codes. The shared services team acts as data steward, creating and validating records without setting definitions.
- How does bad master data slow down month-end close?
- Bad master data slows month-end close because every transaction inherits its account, segment, tax code and counterparty from master records. An unmapped account, a duplicate vendor or a missing intercompany partner code posts wrong without warning, and the error surfaces only at reconciliation or consolidation, where a group accountant fixes the break with a manual journal.
- What is a golden record in master data management?
- A golden record is the single approved version of a vendor, customer or material that every system and legal entity in a group references. When duplicates are merged into a golden record, the retired codes stay as cross-references for the audit trail, and new postings to the retired codes are blocked so the duplicates cannot return.
- Can AI clean up master data in a shared services centre?
- AI can find likely duplicates and flag incomplete records in master data, but AI cannot decide ownership or settle whether two similar suppliers are the same legal entity. Those calls need a data steward with business context. AI tools in the close also read master data as ground truth, so they repeat whatever errors the master data contains.
- How do you know master data governance is working?
- Master data governance is working when the duplicate rate, first-time-right creation rate and number of manual mapping journals per close all improve against the shared services centre’s own baseline. Creation lead time matters as well, because governance that makes record creation too slow drives business teams back to unofficial channels. Domain owners should review all four metrics monthly.
Map master data ownership before the next close
A close that still runs on manual mapping journals usually has an ownership gap behind it, and an ownership map for each master data domain is the quickest way to find it. Contact the Astravise team to review that map against your entities and agree which data fixes to make before the next reporting cycle.