ICFR: designing controls that survive an audit — and a fraud

Internal Financial Controls over Financial Reporting arrived in Indian company law as a board responsibility, and in a good number of companies it has settled into an annual ritual — a binder of process notes, a matrix nobody reads, a sign-off. That is compliance. It is not control.

Two failure modes, two different designs

A control framework has to withstand two quite different pressures. The first is error: an honest mistake, a mis-keyed figure, a cut-off missed at year end. The second is override: someone with authority deliberately working around the process.

Controls designed for error are usually reconciliations and reviews. Controls designed for override are segregation of duties, independent confirmation and exception reporting to someone with nothing to gain. A framework full of the first kind and empty of the second will pass its audit and miss its fraud.

The tests we actually run

• Journal entries after the ledger closes. Who can post them, who approved them, and what proportion were made in the last three days of the period? A spike there is the single most reliable smoke signal in financial reporting.
• Vendor master changes. Particularly bank-account changes made shortly before a payment run, and vendors whose bank details match an employee's.
• Manual overrides of system limits. Every ERP permits them. The control is not preventing them; it is that each one is visible and explained.
• Credit notes and sales returns issued just after a period end, which is where revenue cut-off usually breaks.

Design tests, not documents

A control that cannot be tested is not a control. "The CFO reviews the monthly MIS" is unauditable. "The CFO reviews the variance report, investigates every line over ₹5 lakh or 10%, and signs the exception log by the 10th" is testable — you can pull the log, count the exceptions, and see whether anyone actually asked a question.

When we design ICFR frameworks we write the test alongside the control. If we cannot describe what evidence would prove it operated, the control gets rewritten.

The board's real question

Directors rarely want the matrix. They want an answer to: if something went wrong in this company, how would we find out, and how long would it take? A framework that can answer that in one page is doing its job. One that answers it in ninety pages is doing something else.

Two habits separate a framework that works from one that files. First, re-test it against real incidents rather than against last year's matrix — every write-off, customer dispute and payment that went to the wrong account is free evidence about where the controls are thin. Second, give each control a named owner senior enough to say no. A control whose owner cannot decline a request from the person it is meant to constrain is decoration.