Blog Post

Power BI Community Blog
4 MIN READ

Let AI Say No: Why Master Data Maintenance Should No Longer Be Left to Human Discretion

DataNinja777's avatar
DataNinja777
Icon for Super User rankSuper User
1 year ago

In many organizations, the process for maintaining master data—cost centers, chart of accounts, vendor codes, and the like—follows a seemingly structured flow. Requests are submitted, routed to the appropriate approvers (often Finance leadership), and entered into the system upon approval. On the surface, this appears to tick the box of SOX compliance.

 

However, in practice, it often leads to inconsistent and illogical data structures and lineage that cause long-term damage to reporting and analysis. Over time, left to human discretion, master data becomes cluttered with duplicative cost centers, poorly named GL accounts, and overlapping logic that blurs the lines between expense nature and responsibility center, due to lack of basic database training in finance leadership. The approval process, while formal, is frequently based on individual judgment without a holistic view of the existing data structure.

 

This is not a rare exception. It is a pattern across many organizations.

In some organizations, the average headcount per cost center drops to three or fewer, not by design, but because cost centers have been created liberally over the years to meet ad hoc managerial preferences. GL accounts replicate what is already captured by cost centers, and cost centers are created to mirror GL descriptions, such as "Tax" or "Share-based-compensations" (!!!) can you believe it 💦 when organization's internal reporting system doesn't require cost center aggregation for specific operating expenses.  These leaders, lacking basic knowledge of data management, insist that a cost center for specific operating costs such as 'Share-based compensations' be created instead of handling such reporting needs through aggregation of existing cost centers 🤐. This approach violates fundamental principles of dimensional modeling and creates unnecessary redundancy.

 

Such flawed structures often stem from decisions made by individuals who lack background in data modeling or systems thinking. Even at the finance director level, it is surprisingly common to encounter a lack of data literacy. In some cases, leaders may insist on booking all recruitment fees to an HR cost center because the reporting required it to be reported under HR grouping, without understanding such reporting can be done at backend logic of assigning recruitment costs to HR reporting line without pushing the reporting logic to the bookkeepers. These outcomes are not due to system limitations, but to misunderstanding how data should be structured at the transactional layer versus how it should be aggregated for reporting.

 

In large multinational companies, finance leadership is often not data-literate 😥, which leads to the creation of gnarly chart of accounts and cost center structures that sabotage data lineage. These self-inflicted structural flaws eventually require costly and time-consuming master data rationalization projects — often running into millions of dollars. This is precisely the type of task where AI will consistently outperform human decision-making and should take over entirely for better quality, efficiency, and cost effectiveness.

 

I have personally been placed in the approval flow for master data in various finance roles, and I can say it was one of my least favorite tasks— right up there with other routine approval duties. These traditional finance approvals are better handled by AI. Reviewing requests one by one to check for duplicates or obvious structural flaws always felt like something a machine could do better than a human.

 

For example, a well-trained machine would never approve material master data containing countless near-duplicate entries — like separate SKUs created for minor weight variations of essentially the same product. It was painfully obvious that a smarter approach would have been to use a base product with a variable attribute, such as weight, rather than creating thousands of nearly identical material codes. That approach only added unnecessary data bloat and complexity.

 

AI, when properly implemented, can enforce best practice in master data maintenance, naming conventions, prevent redundancy, and flag structural issues before they enter the system. It can be trained to recognize patterns, identify exceptions, and apply consistent logic without fatigue, bias, or political influence. It does not approve a new cost center because someone higher up in the org chart is persistent. It does not forget that a similar GL was created two years ago with a slightly different name.

 

AI consistently outperforms routine approvals where consistency, traceability, and structural logic matter most. Master data maintenance is exactly the kind of task that should be taken away from human finance leaders and handed over to AI. It’s foundational — and like any foundation, it requires logical consistency, not free-form variety or creativity in places where it’s unwelcome.

 

Once AI takes over the approval task, not only will data bloat disappear from the system, but so will much of the organizational bloat created by SOX approval requirements.

Power BI users know this well—when cost center structures are duplicated or GL accounts are duplicated for different cost centers, reporting becomes unreliable. Bookkeepers must choose from an ever-growing list of GLs — factory vs. back office — while also duplicating that same information in the cost center selection. The result? Conflicting intersections that undermine data reliability.

 

Handing master data governance to AI is about protecting systems from the inconsistency of human decision-making. Human time should be spent on creative work — not on tasks like master data maintenance, where creativity is unwelcome and often detrimental, and where the consistent application of rules is paramount. In data governance, consistency isn’t optional — it’s structural. And machines are simply better at it.

Updated 1 year ago
Version 1.0
No CommentsBe the first to comment