Epicor Is Full of Controls. How Do You Know They Still Match the Way the Business Operates?
Configured controls do not stay effective automatically. Epicor governance needs regular review of access, approvals, inventory exceptions, transaction timing, close discipline and system changes against the way the business actually works.
The short answer
Epicor controls remain useful only when they still match the way the business actually operates. Access rules, approvals, inventory disciplines, transaction timing, exception handling and system changes may all have been designed correctly at go-live, yet become weaker over time as people, products, sites and responsibilities change.
Management therefore needs a control system around Epicor, not just configured controls inside Epicor. That system should connect each important control to a real business risk, assign an owner, define what evidence proves the control is working, and review recurring exceptions before workarounds become normal practice.
The purpose is not to add more administration. It is to make sure the ERP continues to protect the business while allowing operations to move at the speed they need.
A configured control can become obsolete without breaking
One of the hardest control problems is that nothing appears technically wrong.
An approval still routes. A security role still works. An inventory adjustment still posts. A period can still close. A BPM still executes. Yet the business around those controls may have changed.
A manager who once approved a purchase category may no longer understand that category. A user may have accumulated permissions after covering several roles. A warehouse may use a new physical process that makes an old transaction sequence unrealistic. A customization may bypass a check that was introduced later elsewhere.
Because the system continues to function, these gaps can remain invisible.
This is why control effectiveness cannot be judged only by configuration status. It has to be judged against current operations.
Start with the business risk, not the screen
A useful control review begins by asking what the organization is trying to prevent or detect.
Examples include:
- unauthorized purchasing;
- inappropriate changes to master data;
- inventory movements without traceability;
- shipments before required checks;
- transactions posted in the wrong period;
- one person controlling incompatible parts of a process;
- repeated overrides that bypass standard workflow;
- system changes that alter business logic without review.
Once the risk is clear, the Epicor control becomes easier to evaluate.
A screen field, security role or approval rule is not valuable by itself. It is valuable because it reduces a specific business risk.
Separate preventive and detective controls
Some Epicor controls should prevent an action.
A user without authority should not be able to post a restricted transaction. A required approval may need to happen before release. A closed period should block normal posting.
Other controls are more effective as detection.
Management may review unusual inventory adjustments, repeated overrides, late transactions or changes made outside the normal process. Preventing every unusual action can create operational paralysis, especially in manufacturing environments where genuine exceptions occur.
A mature control system therefore decides deliberately which risks require prevention and which can be controlled through timely detection and review.
Access is the first layer of operational control
Permissions determine what users are capable of doing, but role design often drifts after implementation.
People change jobs, cover absent colleagues, join new projects or receive temporary permissions that are never removed. Generic roles may expand until they represent convenience rather than responsibility.
A useful access review does not ask only whether a user still needs Epicor. It asks whether the specific transactions, companies, sites and actions available to that user still match the current role.
The related cluster Who Can Do What in Epicor—and When Did You Last Review It? explores this in more detail.
Approval should represent a real decision
Approval workflows can look strong while providing little control.
If every request is approved automatically because the approver lacks context, the workflow becomes ceremony. If thresholds are too low, management spends time approving routine activity and begins to treat the process as noise. If thresholds are too high, meaningful decisions may pass without review.
The design question is therefore not “Can Epicor route an approval?” It is “Which decisions genuinely need a second level of authority, and what information does the approver need?”
Too Many Epicor Approvals—or Not Enough? How Do You Design the Right Control? examines that balance.
Inventory adjustments are control evidence
An inventory adjustment may be completely legitimate.
Damage, count differences, process loss or data correction can all require adjustment. The risk appears when repeated adjustments are treated as routine housekeeping instead of evidence.
If the same item, location or transaction type produces recurring corrections, management should ask what upstream process creates the difference.
The month-end balance may be correct because staff repeatedly fix it. That does not mean the operational control is strong.
Why Do Inventory Adjustments Keep Coming Back Even When the Month-End Number Looks Right? focuses on using adjustment patterns as diagnostic evidence.
Exceptions reveal the real operating model
Every business needs exceptions.
A customer may require an unusual shipment. A supplier issue may need an emergency override. Production may need to continue while a master-data issue is being corrected.
The important question is whether the exception remains exceptional.
When the same override happens every week, it may indicate that the standard process no longer reflects reality. Repeated exceptions should therefore be analyzed as improvement signals, not only approved and forgotten.
Your Epicor Exception List Is Growing. Which Overrides Are Becoming the Real Process? explains how to govern these patterns.
Month-end pressure is often created earlier in the month
Finance frequently becomes the final control point for operational problems.
Late receipts, incomplete shipments, missing labour, unclosed jobs, incorrect inventory timing and other execution gaps eventually appear during reconciliation.
Finance can correct or explain the result, but that creates recurring effort.
The stronger approach is to trace each repeated month-end adjustment back to the operational event that caused it and improve the transaction discipline at source.
Month-End Is Still Painful. Which Epicor Transactions Should Be Fixed Before Finance Reconciles Them? examines the upstream side of close quality.
System changes need business control review
Epicor environments evolve constantly.
A new BPM, form change, workflow rule, report, integration or field may solve a valid problem while changing another part of the control environment.
A technically successful change can still weaken approval, security, timing or data interpretation.
Change review should therefore ask what business control the change touches, not only whether the code or configuration works.
A Small Epicor Change Went Live. How Do You Know It Did Not Weaken a Control Somewhere Else? covers this control-impact discipline.
Build a control register that business owners can understand
A control register does not need to become a large audit document.
For each important control, record:
- business risk;
- process;
- control objective;
- preventive or detective nature;
- Epicor mechanism;
- business owner;
- technical owner where relevant;
- evidence;
- review frequency;
- known exceptions;
- last material change.
This creates a practical map of the control environment.
It also makes change easier because teams can see which business controls may be affected by a new requirement.
Use evidence that reflects real operation
Control evidence should prove that the process works in practice.
A configuration screenshot may prove that a rule exists. It does not necessarily prove that users follow the intended process or that exceptions are reviewed.
Better evidence may include:
- access-review decisions;
- approval samples;
- exception trends;
- inventory adjustment analysis;
- close reconciliation causes;
- change-test results;
- rejected transactions;
- override history.
The evidence should match the risk.
Review control effectiveness by exception pattern
A single exception may not justify redesign.
Patterns matter more.
If the same approval is repeatedly escalated, perhaps the threshold is wrong. If the same security exception is requested repeatedly, perhaps the role model no longer reflects responsibilities. If the same inventory correction recurs, perhaps the warehouse process needs redesign.
Control review becomes more useful when it asks why exceptions repeat.
This turns governance into continuous improvement rather than periodic administration.
Keep the control owner in the business
IT can configure a permission, BPM or workflow, but it should not own the business meaning of the control by default.
The business owner should understand what risk the control addresses, when exceptions are acceptable and what evidence indicates failure.
Technical teams can own reliability and implementation.
This division avoids a common problem where a technically correct control survives long after the business reason has changed.
What management should measure
Useful indicators include:
- users with access outside current responsibilities;
- temporary permissions not removed on time;
- approval steps with near-automatic acceptance;
- repeated overrides by process;
- recurring inventory adjustments;
- late or backdated transactions;
- month-end reconciliations by root cause;
- critical controls changed without business impact review;
- controls without named owners;
- controls with no recent evidence review.
The goal is not to maximize the number of controls.
The goal is to know which controls matter, whether they still work and where the operating model is drifting away from them.
A practical quarterly control review
Choose five to ten controls that protect material operational or financial outcomes.
For each one, sample recent real transactions and exceptions. Ask whether the intended control happened, whether the owner understood the decision and whether any workaround was used.
Then compare the result with the current process.
This small review often reveals more than a broad configuration checklist because it tests the control against actual operating behavior.
ACC context
ACC supports Epicor environments across implementation, process improvement and connected operational workflows. A sustainable Epicor environment depends not only on configuring the system correctly but also on keeping controls aligned as the business evolves. Explore ACC’s Epicor capabilities.
Use three tests for every important control
A practical review can use three tests.
Design: does the control still address the current business risk? A rule designed for a single-site organization may not fit a multi-site structure. An approval threshold set years ago may no longer reflect transaction values.
Execution: does the control actually happen in normal work? Users may have found a legitimate but undocumented workaround because the configured path creates delay.
Evidence: can management prove the control happened and understand the exceptions? A control that exists but produces no usable evidence is difficult to oversee.
These tests prevent the review from becoming a simple configuration inventory.
Rank controls by consequence
Not every control deserves equal attention.
Management should identify the controls whose failure could materially affect cash, inventory, financial reporting, customer commitments, regulatory obligations or operational continuity.
A smaller set of clearly critical controls can then receive deeper review, better evidence and more disciplined change testing.
Lower-risk controls can use lighter governance.
This risk-based approach reduces the temptation to create an enormous control catalog that nobody maintains.
Connect control design to the transaction lifecycle
Controls are easier to understand when they are placed along the transaction lifecycle.
For a purchase, for example, the business may care about supplier creation, purchase authorization, receipt, invoice matching, payment and later master-data changes. For production, the relevant controls may include material issue, labour, completion, scrap, inventory movement and job close.
Viewing the lifecycle prevents teams from reviewing each screen in isolation.
It also reveals gaps where one part of the process is tightly controlled while another part depends on manual judgment.
Avoid compensating controls becoming permanent
A compensating control is useful when the preferred control cannot be implemented immediately.
For example, management may review a report manually because a system rule is incomplete. That can be a sensible temporary measure.
The danger is forgetting why the compensating control exists.
Record the underlying gap and a review trigger. If the manual control remains necessary, keep it deliberately. If the root issue is fixed, retire the extra work.
Otherwise organizations accumulate layers of review that no longer protect a real risk.
Use control review to simplify, not only tighten
Control improvement does not always mean adding restrictions.
Some controls can be removed or simplified when better upstream design makes them unnecessary.
If master data is more reliable, a downstream approval may no longer need to check the same field. If warehouse scanning validates a movement at source, a later reconciliation may be reduced.
A mature control review therefore asks two questions: where is control too weak, and where are people performing control work that no longer adds value?
Keep the control language consistent
Different departments may use different names for the same control. Finance may call something a cut-off rule while operations thinks of it as transaction timing. IT may describe a security object while the business thinks of it as approval authority.
Use plain business language in the control register so owners across functions can recognize the same risk and evidence.
Consistency makes review faster and reduces gaps created by teams assuming another function owns the control.
Frequently asked questions
How often should Epicor controls be reviewed?
Review frequency should follow business risk and rate of change. High-impact access, approval and financial controls may need more frequent review than stable low-risk configuration.
Should every exception be prevented?
No. Genuine exceptions are part of operations. The important point is that high-risk exceptions are controlled and recurring exceptions are analyzed.
Is a control effective if Epicor technically enforces it?
Not necessarily. The control must still match current responsibilities, transaction meaning and business risk.
Who should own Epicor controls?
Business process owners should own the control objective and acceptable exceptions; technical teams can own configuration and reliability.
What is the best starting point for a control review?
Start with controls that protect cash, inventory, financial reporting, master data or high-consequence approvals, then test them with recent real transactions.