The Automated Close and the Missing Reconciliation
A services company has automated its month-end close. A rules engine posts standard accruals, reverses prior-month accruals, and calculates revenue recognition from timesheet data. The close now takes three days instead of eight. In the first quarter after go-live, the financial controller notices that the balance sheet reconciliation for 'Accrued Expenses' has not been performed for two months - the person who used to do it assumed the automation made it unnecessary. Separately, a senior analyst queries why revenue for one large client is $220,000 higher than the contract suggests; investigation shows the timesheet system recorded hours against the wrong project code for six weeks, and the rules engine recognised revenue on them without challenge. The audit committee asks how the team knows the automated postings are correct.
1. Explain what control has been lost in the move to automation and how it should be redesigned.
Read the worked answer
Two controls have been lost, and they are different in kind.
1. The reconciliation control was dropped, not automated. The controller's team treated automation as a substitute for reconciliation. It is not: automation changes how balances arise, not whether they are correct. The 'Accrued Expenses' reconciliation is the independent check that the rules engine posted what it should have. Without it, errors accumulate silently. The fix is to reinstate the reconciliation as a mandatory close step, with a named preparer and reviewer, and - better - to automate the reconciliation too: a system-generated comparison of the accrual balance to an independent expectation (e.g. prior-month run-rate plus known changes), with exceptions routed for human review.
2. There is no detective control over the rules engine's inputs. The $220,000 revenue error arose because the timesheet data was wrong and the engine applied the rule faithfully. The engine cannot know a project code is wrong. The missing control is a data quality check on inputs: validation that hours posted to a project are consistent with the contract, a threshold review of project-to-contract mapping, and a reconciliation of recognised revenue to contract value before posting. The engine should also flag, not silently post, movements above a set tolerance.
The general principle: automation moves the control point upstream (to inputs and rules) and requires more monitoring, not less, because errors are now systematic rather than one-off.
2. Draft the substance of the response to the audit committee, including how the team will know the automated postings are correct going forward.
Read the worked answer
The response should be direct about the failure and specific about the remedy.
What happened: The move to an automated close removed two controls without replacing them. The accrued expenses reconciliation lapsed for two months, and no input validation existed over timesheet project coding, which produced a $220,000 revenue overstatement for one client. Both were detected by manual query, not by a control - that is the core weakness.
What we are doing:
- Reinstating the accrued expenses reconciliation as a mandatory, signed-off close step, and building an automated expectation-vs-actual comparison with exception reporting.
- Adding input validation: project-code-to-contract mapping checks, hours-versus-contract reasonableness tests, and a pre-posting review of revenue movements above tolerance.
- Documenting the rules engine logic and assigning a named owner accountable for changes to it.
- Adding a post-close analytical review of revenue by client against contract, with variances investigated before sign-off.
How we will know postings are correct: every automated posting stream will have (a) a documented rule, (b) an independent reconciliation or expectation check, (c) exception reporting with a defined tolerance, and (d) a named reviewer who signs off monthly. We will report control exceptions to this committee quarterly, including nil returns, so that silence is evidenced rather than assumed.