Expert verified
You approved the ERP investment eighteen months ago. The implementation went well, the system went live across your three manufacturing plants, and the implementation partner signed off.
Now the cracks are starting to show. Month-end close takes nine days instead of six. Surat plant’s inventory report does not match the ERP. Your Chennai finance team is still working in Excel for some reconciliations because “the system doesn’t capture it right.” Ask for one consolidated working capital number, and you get three different answers.
The ERP may still be working as designed. The issue is how the system is being used across the business. New workarounds have appeared. Master data is no longer consistent across locations. ERP configurations have changed. Some controls that worked at go-live are no longer being followed in the same way.
This is what ERP drift looks like. For a ₹100–500 crore business running multiple plants, branches or legal entities, small changes can quickly affect financial reporting, inventory, working capital and internal controls.
A post-implementation ERP audit helps identify where the system and actual business processes have moved apart, and what needs to be fixed.
| TL;DRERP systems that go live cleanly still drift within 12-18 months, and the drift compounds fastest at ₹100 Cr+ enterprises running multiple plants or entities on one SAP, Oracle, or Dynamics instance.Nine signs point to drift: parallel Excel trackers, a slowing month-end close, reports that don’t match across plants, manual workarounds, access control gaps, poor data quality, unchecked customisation, low module adoption, and no single owner for ERP governance.A post-implementation ERP audit tells you exactly where the system has moved away from its original design, and what it will take to bring it back. |
Why ERP Systems Drift From Their Original Design Once You’re Running Multiple Plants
Your ERP was configured around the way the business operated when the implementation project was underway. The chart of accounts, approval hierarchy, material master, production workflows and reporting structure all reflected that point in time.
The business keeps moving after go-live.
A new plant is added, a product line changes, approval limits are revised, a finance manager moves into a different role, someone needs a report that the ERP does not provide, so they build it in Excel, a process that once required three approvals now needs one, yet the old workflow remains active in the system.
Each decision may solve a genuine business problem but over time, they can leave the ERP configuration out of step with actual operations.
Multi-plant operations make the problem harder to spot
At a single-location business, differences in processes are usually visible because the same finance and operations teams work closely together. In a multi-plant environment, each location can develop its own way of dealing with system limitations.
The Chennai plant may use an Excel file for part of its inventory reconciliation. Coimbatore may have a different approach to material codes. Another location may have customized an approval workflow to suit its local requirements.
The ERP continues to function. The difficulty appears when management tries to compare or consolidate information across locations.
You may see differences in:
- Inventory reports and stock valuations
- Month-end close timelines
- Approval workflows and delegation limits
- Customer and vendor master data
- Product and material codes
- Management reports and KPIs
- Manual reconciliations and spreadsheet usage
ERP drift is also different from an implementation failure.
The system may have gone live successfully, users may have received training and the data migration may have been completed properly.
The problem develops later. Without a clear process for managing configuration changes, master data, user roles and business process changes, the gap between the ERP design and day-to-day operations gradually widens.
New workarounds become normal practice. Old configurations remain in place. Local exceptions become difficult to distinguish from the standard process.
For a ₹100 crore-plus enterprise operating several plants, branches or legal entities on a common ERP platform, this can become a significant management issue.
What you need to ask is: Does the ERP still reflect how your business actually operates today?
The following nine red flags can help you find out.
Red Flag 1: Teams at Different Locations Still Rely on Excel Alongside the ERP
If your plants or branches still maintain Excel trackers for inventory, production, collections or dispatch after ERP go-live, it is worth finding out why.
Excel itself is not the issue. Finance teams will always use spreadsheets for analysis. The concern starts when Excel becomes a parallel system for information that the ERP is supposed to capture and control.
What This Looks Like
- A plant maintains a separate inventory tracker because goods receipts are not updated in the ERP on time.
- A warehouse keeps its own dispatch register because the configured workflow does not handle certain customer requirements.
- Finance teams maintain collection spreadsheets because the ERP ageing report does not reflect recent bank credits.
- Different plants prepare their own versions of the same management report before sending numbers to head office.
These workarounds usually have a practical starting point. A process was not configured correctly during implementation. A business requirement changed after go-live.
A report no longer meets management needs. Raising a system change request may also take longer than the business can afford.
So someone creates an Excel file to keep the process moving.
Why It Becomes A Problem
Over time, these local workarounds can create multiple versions of the same information. One plant may calculate inventory differently from another. Collection data may be updated at different intervals. The consolidation team then spends time reconciling numbers before management can rely on them.
For a multi-plant enterprise, this can lead to:
- Longer month-end close cycles
- More manual reconciliations
- Lower confidence in management reports
- Weak audit trails
- Difficulty establishing a single source of truth
Ask every plant or branch finance head to list the spreadsheets that duplicate information the ERP is expected to capture or report. Then ask why each one exists.
If the spreadsheet is used for analysis, there may be no concern. If it exists because the ERP cannot reliably support an operational process, you have found a potential area of ERP drift that deserves attention.
Red Flag 2: Month-End Close Takes Longer as You Add Entities and Branches
A well-configured ERP should make multi-entity consolidation more predictable as the business grows. If month-end close has stretched from five or six working days to eight or ten, it is worth examining what is happening between the individual locations and the corporate finance team.
Where The Delays Come From
The problem is often a collection of small issues rather than one major system failure.
- Intercompany transactions are not automatically matched between entities.
- Inventory valuation or standard costing is configured differently across plants.
- Individual locations have created their own chart of accounts mappings.
- Data is being re-entered between systems or uploaded manually.
- Finance teams rebuild consolidated reports in Excel because the ERP reports do not provide consistent results.
- Adjustments are being made outside the ERP and reconciled later.
Each issue adds work to the close.
A plant completes its books, corporate finance finds differences, someone traces the source, another team corrects the entry, and the consolidation process moves forward. Repeat this across several plants and entities, and a process that once took six days can gradually take nine.
A longer close has a direct operational cost. Finance spends more time reconciling and correcting numbers and less time analysing what those numbers mean.
It can also delay:
- Management reporting
- Board reporting
- Working capital decisions
- Performance reviews
- Financial planning and forecasting
For a multi-plant enterprise, consistency is as important as speed. If every location follows a slightly different process, consolidation becomes increasingly dependent on manual intervention.
Track the finance team’s time spent each month on activities that the ERP was expected to automate or standardise.
Look specifically at:
Intercompany matching + manual data entry + Excel consolidation + location-level reconciliations
Then compare that workload with your entity and plant count over the last 12–18 months.
If the business has expanded and the manual effort has increased with it, the issue deserves investigation. The ERP may still be processing transactions correctly. The surrounding configuration, processes and controls may have drifted enough to make the original design less effective.
Red Flag 3: Reports Don’t Match Across Modules or Plants
You are reviewing the monthly performance pack. Finance reports gross margin at 42%, operations reports 38%. Both figures came from the ERP, that should raise a question.
The same problem can appear with inventory, production volumes, sales, receivables or working capital. The inventory module may show one stock figure while the finance module shows another for the same plant and date.
Plant A may report production using different units or product categories from Plant B, making a group-level comparison difficult.
Why The Numbers Diverge
These mismatches often develop when configurations or processes change in one part of the ERP without corresponding changes elsewhere.
For example:
- A plant changes its inventory valuation approach without updating related finance configurations.
- A new SKU classification is introduced in the sales module but is mapped differently in reporting.
- Cost allocation rules change in finance while operations continue using the previous method.
- A new production process uses different units of measurement from the original configuration.
- Returns or adjustments are recorded differently across locations.
The ERP may continue processing transactions correctly within each module. The problem appears when data from different modules or locations is brought together.
What Happens Next
Once management notices repeated discrepancies, confidence in the system starts to fall.
Finance teams begin performing additional reconciliations. Plant teams maintain their own reports. Department heads ask for numbers to be verified before management meetings. Eventually, Excel becomes the layer used to reconcile information that should already agree within the ERP.
For a ₹100 crore-plus enterprise, this can can delay management decisions, increase the workload during month-end close and make it harder to identify the real drivers of margins, inventory and working capital.
A Simple Test
Pick three important metrics, such as revenue, inventory and gross margin, and compare the figures across the ERP modules and plants that generate or use them.
Check whether the definitions, source data, calculations and mappings are consistent.
If the finance team needs a manual reconciliation before every management review, the issue deserves a closer look. The underlying problem may sit in master data, configuration, process design or the way different locations are using the ERP.
Red Flag 4: Manual Workarounds Have Become “Normal” at Scale
Some manual workarounds are expected after an ERP goes live. A process may have an edge case that the system does not handle well, so the team finds a temporary way to keep work moving.
The warning sign comes when the temporary solution becomes the normal process.
Six months later, the workaround is still being used. A year later, new employees are trained on it. Different plants may even develop their own versions of the same workaround.
- Finance manually adjusts a recurring journal entry every month to correct a posting issue.
- A warehouse performs additional stock counts because ERP inventory does not consistently match physical stock.
- Purchase approvals are forwarded manually by email when the configured workflow does not reflect current reporting lines.
- Intercompany transactions are consolidated and reconciled in Excel.
- GST or other location-level compliance information is maintained outside the ERP.
- Payment gateway settlements are manually reconciled against accounts receivable.
Each workaround solves an immediate problem. The concern is the number of workarounds operating across the business and the controls they bypass.
Why the risk grows with scale
Every manual transfer, re-entry or adjustment creates another opportunity for an error. Processes performed outside the ERP can also leave weaker audit trails and make it harder to determine who performed a task, when it was performed and what information was reviewed.
At a multi-plant enterprise, the problem compounds when each location develops its own version of the workaround. The ERP may still be the official system, while important parts of the actual process happen elsewhere.
This can also weaken system-based controls. An approval workflow, validation rule or automated reconciliation has limited value when employees routinely bypass it through an offline process.
List the recurring manual workarounds used across each plant or business unit.
For every one, ask: Why does this step happen outside the ERP?
If the answer is unclear, or simply “that is how we have always done it,” investigate further. The workaround may be compensating for an outdated configuration, process gap, master data issue or system limitation.
A post-implementation ERP review should identify these workarounds, assess the risks they create and determine which ones should be eliminated, automated or formally controlled.
Red Flag 5: User Access and Approval Controls Have Drifted Across a Multi-Layered Hierarchy
Your ERP access was configured around the organisation that existed at go-live. Since then, people have moved roles, managers have left, reporting lines have changed and responsibilities have expanded across locations.
The ERP access model may not have kept up.
- A former plant manager still has active ERP access months after leaving.
- A finance manager promoted to a regional role still has the access rights from the previous position.
- A procurement employee can create vendors and approve related purchase transactions.
- A finance controller overseeing several plants cannot access the data needed for all locations.
- Approval limits in the ERP no longer match the current delegation of authority.
- IT copies an existing user’s access profile when creating a new account instead of assigning access based on the person’s current role.
Each access decision may have had a reasonable explanation when it was made. The risk appears when these permissions accumulate over time.
The Segregation Of Duties Risk
A user who can create a vendor, raise a purchase order and approve a payment has a very different risk profile from someone who can perform only one of those activities.
The same applies to journal entries, customer master changes, purchase approvals and payment processing.
When access rights are reviewed against old roles rather than current responsibilities, segregation of duties conflicts can remain hidden. Approval workflows can also continue routing transactions to people who no longer hold the relevant authority.
For enterprises subject to statutory audit and IFC requirements, this can become an important control issue. Auditors may examine whether access is appropriate, whether segregation of duties is maintained and whether periodic access reviews are supported by evidence.
Take the current employee list and compare it with the ERP’s user access report.
Then compare each user’s permissions with their current role, location, reporting line and approval authority.
Pay particular attention to employees who have changed roles, transferred between plants or taken on additional responsibilities.
If the ERP access report reflects the organisation from 18 months ago, rather than the organisation you have today, the access control environment needs attention.
Red Flag 6-9: Data Quality, Customisation Sprawl, Low Adoption, No Governance Owner
Four more signs tend to appear together at multi-plant enterprises, and each one reinforces the others.
Data Quality Issues:
Duplicate vendor or customer masters, inconsistent unit-of-measure entries across plants, and incomplete fields that were mandatory at go-live but have since been left blank all point to the same root cause: nobody owns data quality on an ongoing basis.
Master data that was clean at go-live degrades steadily unless someone is responsible for maintaining it, and at multi-plant scale, that responsibility often falls between plant-level teams and central IT, with neither fully owning it.
Customisation Sprawl:
Every reasonable one-off customisation made to solve a specific plant’s problem adds a small amount of complexity to future upgrades, patches, and troubleshooting.
Individually, each customisation was probably the right call. Collectively, after two or three years, they can turn a standard ERP instance into something closer to a custom-built system that few people fully understand end to end, which makes every future change slower and riskier.
Low Module Adoption:
Many ERP licences include modules, like advanced planning, quality management, or business intelligence dashboards, that were part of the original business case but were never fully rolled out.
If your business paid for functionality it isn’t using, that’s a direct cost with no offsetting benefit, and it’s usually a sign the implementation moved on to the next priority before adoption was complete.
No Governance Owner:
This is the underlying cause behind most of the other eight flags. Implementation projects have a project manager.
Once the system goes live, that role often disappears, and no one is formally responsible for reviewing configuration changes, monitoring adoption, or flagging drift before it becomes a control gap. Without a named owner, ERP governance becomes everyone’s part-time responsibility and, in practice, no one’s.
What a Post-Implementation ERP Audit Delivers for a ₹100 Cr+ Enterprise
A post-implementation ERP audit is a structured review of your ERP system’s health, configuration, usage, and value delivery. For a multi-location, multi-entity enterprise, it usually covers:
- Configuration Review: Comparing the current system configuration against the original design and against best practices for your industry and scale.
- User Access and Security Review: Assessing whether access controls and approval workflows reflect your current organisational structure and segregation of duty requirements.
- Data Quality Assessment: Identifying inconsistencies, duplicates, and gaps in master and transactional data across all locations.
- Customisation Inventory: Documenting all customisations, assessing their necessity, and identifying opportunities to revert to standard functionality.
- Adoption Analysis: Measuring usage across modules, locations, and user groups, and identifying barriers to adoption.
- Process Adherence Review: Assessing whether business processes are being executed as designed within the system or whether workarounds have become standard practice.
- Governance Assessment: Evaluating whether there’s clear ownership and accountability for the system’s ongoing health.
The output is a clear picture of where your ERP stands, what’s working, what isn’t, and what needs to be fixed. For a ₹100 Cr+ enterprise with multiple plants, this is essential for protecting your investment and ensuring the system continues to deliver value.
What PKC Offers
PKC’s software implementation and digital transformation services include post-implementation audit and optimisation engagements. With 35+ years of operating experience and expertise across 30+ ERP systems, we work with mid-market Indian enterprises to identify ERP drift, address root causes, and restore the system to its intended purpose.
Our approach combines process consulting with technology expertise, a combination particularly valuable for multi-location enterprises where process standardisation is as important as system configuration.
If your business is witnessing any of the above mentioned red flags related to ERP, it may be time for a post implementation ERP audit. Schedule a call with our experts and gain actionable insights to optimize your ERP system, improve performance, and ensure it continues to support your business goals.
FAQs
What is a post-implementation ERP audit and why does it matter more at multi-plant scale?
A post-implementation ERP audit reviews how your live SAP, Oracle, or Dynamics system is actually being used against how it was originally designed to work, covering configuration, workflows, access controls, data quality, and reporting accuracy. It matters more at multi-plant scale because drift at one location is easy to miss when it’s compensated for locally, and only becomes visible when numbers are consolidated across plants or entities.
How soon after go-live should a ₹100 Cr+ business run an ERP audit?
Most drift becomes measurable within 12 to 18 months of go-live, once at least one full year of operational and reporting cycles has run through the system, including year-end close and any statutory audit. Running a review around this point, and then periodically afterward, usually catches gaps before they compound into larger control or reporting issues.
Is a post-implementation audit different from an IT systems audit?
Yes. A general IT systems audit typically focuses on technical controls like data security, backups, and system access at an infrastructure level. A post-implementation ERP audit focuses on whether the business processes configured in the system, from procurement to production to financial close, still match how the business actually operates, which is a functional and process question rather than a purely technical one.
Why do teams at different locations keep using Excel even after ERP implementation?
Teams typically build Excel workarounds when a specific transaction type, exception, or reporting need isn’t well supported in the ERP’s current configuration, or when raising a formal change request takes longer than solving the immediate problem manually. Once one location’s workaround proves useful, other plants tend to copy it rather than raise the same request independently.
What does an ERP optimization engagement typically include for a group-wide rollout?
An ERP optimisation engagement generally includes a plant-by-plant review of current configuration against original design, a reconciliation check across modules and entities, a user access and segregation-of-duties review, a data quality assessment, and a prioritised remediation plan that separates urgent control gaps from lower-priority process improvements.
How does PKC combine ERP audit findings with process fixes across every plant on the system?
PKC Management Consulting pairs the audit findings with its process re-engineering and SOP work, so that a finding like a reporting mismatch between two plants is addressed both by correcting the ERP configuration and by updating the underlying process or approval workflow that caused the mismatch, rather than treating the two as separate exercises.
