A company’s internal control documentation describes a procurement process with five controls: purchase requisition approval, competitive bidding for purchases above Rs 5 lakh, three-way match (PO-GRN-invoice), segregation of duties between ordering and payment, and monthly vendor reconciliation.
On paper, the process is well-controlled. In practice, the purchase requisition is approved retroactively after the goods have been ordered. Competitive bidding is bypassed for “urgent” purchases, which account for 35% of total procurement. The three-way match is performed by the same person who raised the PO. The segregation of duties exists on the organisation chart but not in the ERP, where the same user can process both the order and the payment. The vendor reconciliation is prepared monthly but reviewed by nobody.
Every control is documented. Every control is designed. No control is operating as intended. The gap between design and operation is the gap between the compliance the company reports and the protection the company actually has.
Design vs Operating Effectiveness
Accounting standards, audit frameworks and regulatory expectations distinguish between two dimensions of control effectiveness.
Design effectiveness: Is the control designed to prevent or detect the risk it addresses? A well-designed control targets a specific risk, operates at the right point in the process, involves personnel with appropriate authority and produces evidence of its operation.
Operating effectiveness: Does the control actually operate as designed, consistently, across all transactions, throughout the reporting period? A control that is well-designed but inconsistently applied, routinely overridden, performed by the wrong person or applied to only a subset of transactions is not operationally effective.
The distinction matters enormously, because most companies evaluate their control environment on design and assume that design implies operation. The documentation describes the design. Nobody tests the operation. The audit committee is told “we have five controls over procurement.” It is not told “three of those five controls do not operate as documented.”
Why Controls Fail in Practice
The override culture
In many Indian mid-market companies, controls are viewed as obstacles to speed rather than protections against loss. A procurement approval that delays a purchase by two days is bypassed because the business cannot wait. A credit limit that prevents a large order from being processed is overridden because the customer is “important.” A segregation of duties that requires two people to process a transaction is collapsed into one because the second person is unavailable.
Each override is individually rational. The purchase was needed. The customer was important. The second person was sick. Collectively, the overrides create a control environment that exists in documentation but not in practice.
The evidence problem
A control that produces no evidence of its operation is a control that cannot be verified. A manager who “reviews” a monthly reconciliation by glancing at it and moving on has technically performed the control. There is no evidence of what was reviewed, what was questioned, what was resolved and what was accepted. The control was performed. It was not effective.
An effective control produces evidence: a signature on a specific item after documented review, a system log showing approval with a timestamp, a reconciliation with identified exceptions and documented resolution. Without evidence, the control is an assertion, not a fact.
The competence gap
A control performed by a person who does not understand what they are looking for is not a control. A bank reconciliation prepared by a junior accountant who does not understand why outstanding items exist, what the ageing implies and which items require investigation is a mathematical exercise, not a control activity.
The control’s effectiveness depends on the competence of the person performing it. A reconciliation prepared by someone who understands the process, the risks and the significance of the exceptions is a genuine control. The same reconciliation prepared by someone who matches numbers without understanding is compliance theatre.
System vs process divergence
In many companies, the control is documented as a process (two approvals required before payment) but the ERP system permits a single approval. The process says one thing. The system permits another. When the two diverge, the system determines what actually happens, because the system processes the transaction regardless of what the process manual says.
The forensic test: compare the control as documented in the policy manual to the control as configured in the ERP system. Where the two diverge, the ERP configuration is the actual control. The policy manual is the aspiration.
Testing Operating Effectiveness
In Northrop Management Private Limited’s assurance and governance work, control effectiveness testing goes beyond design review to assess whether each critical control actually operates.
Step 1: Identify the critical controls. Not every control is equally important. Focus testing on the controls that mitigate the most significant risks: revenue recognition, cash disbursement, related-party transactions, period-end adjustments, management override and financial reporting.
Step 2: Test through evidence, not inquiry. Do not ask management whether the control operates. Examine the evidence: system logs, approval records, reconciliation files, exception reports, audit trails. If the evidence does not exist, the control cannot be verified.
Step 3: Test the full population where possible. Sampling provides statistical confidence. Full-population testing (enabled by continuous monitoring and data analytics) provides certainty. For critical controls, full-population testing is worth the additional effort.
Step 4: Test for override. For each critical control, determine whether the system permits override and, if so, how many overrides occurred during the period, who authorised them and what the financial impact was. A control that was overridden 200 times in a year is not a control. It is a suggestion.
Step 5: Test competence. Interview the person performing the control. Do they understand what they are looking for? Can they explain what an exception would look like? Have they ever identified and escalated an exception? The answers reveal whether the control is a genuine risk-mitigation activity or a procedural formality.
The Control Reality Assessment
The output of operating-effectiveness testing is a control reality assessment: a comparison of the control environment as documented to the control environment as it actually operates.
For each critical control, the assessment classifies it as:
Operating as designed: The control operates consistently, produces evidence, is performed by competent personnel and has not been materially overridden. The company can rely on this control.
Partially operating: The control operates most of the time but has been overridden, inconsistently applied or performed without adequate evidence in a material number of instances. The company can partially rely on this control but should strengthen it.
Not operating: The control exists in documentation but does not operate in practice. The company has no protection from this control and should either redesign it, automate it or replace it.
Ashish Chaudhary, Founder and Managing Director of Northrop Management Private Limited, frames the governance principle directly: “A control is only real when it changes behaviour or detects failure. A documented control that is routinely overridden, performed without evidence, executed by someone who does not understand it, or permitted by the system to be bypassed, is not a control. It is a policy that nobody follows. And a policy that nobody follows is not protection. It is the illusion of protection.”
Questions for the Boardroom
- For each of our ten most critical controls, do we have evidence that the control operated effectively throughout the period, or do we have documentation that it was designed?
- How many control overrides occurred in the last quarter, in which processes, authorised by whom and for what reasons?
- Does our ERP system enforce our documented controls, or does it permit actions that the control manual prohibits?
- When was the last time we tested the operating effectiveness (not the design) of our critical controls using transaction-level evidence?
- If a regulator or forensic investigator examined the operation of our five most critical controls using system evidence rather than management inquiry, what would they find?
Closing Implication
A control that exists on paper protects the company’s documentation. A control that operates in practice protects the company’s assets, revenue and reputation. The gap between the two is the gap between compliance and governance, and it is the gap that determines whether the control environment is a real defence or a documented fiction.
