At a 4.4% review rate, 8,600 of 9,000 journal entries receive no systematic examination before reaching the general ledger and, eventually, the year-end audit. For a controller team of three operating a mid-market NetSuite environment, reviewing 400 entries is often the full extent of structured review available to the remaining population. Ongoing accounting controls are designed to increase that coverage without adding headcount.
What Ongoing Accounting Controls Mean in Practice
An accounting control is a procedure intended to lower the chance of error or misstatement in the financial records. Conventional controls tend to run periodically: a monthly bank reconciliation, a quarterly management review, or an annual external audit. Each examines information after transactions have occurred, according to a recurring timetable.
Ongoing controls work at the transaction's operating tempo. Each journal entry is tested against defined criteria as it reaches the ERP, rather than waiting for a scheduled review window. In practical terms, an entry can be assessed when it posts, before it has remained unexamined in the ledger for 20 or 30 days.
That timing change has a direct effect on remediation effort. An exception raised at posting can usually be investigated within minutes, while the preparer still remembers the business context. The same issue discovered during close may require the team to reconstruct the entry, its support, and its downstream effects while competing with the rest of the close workload.
How This Differs from Point-in-Time Audit Work
Point-in-time review in an ERP usually takes place around close. The process may include extracting a trial balance, completing reconciliations, sampling manual journals, and resolving exceptions before the period is signed off. Most controller teams operate some version of this process, and it can remain effective while transaction volumes are manageable.
The constraint becomes visible as posting volume increases. A manual review that was workable at 500 entries per month may leave material blind spots at 3,000 entries per month. This is not a capability issue for the team. The population has outgrown what a point-in-time sample can reasonably cover.
Ongoing rule-based controls differ in three important respects. Coverage extends across every entry tested by the configured rules rather than a statistical sample. Timing moves exception identification to posting, when the entry is still discrete and easier to investigate. Documentation becomes a continuing record of entries reviewed, rules triggered, and disposition actions taken, rather than a spreadsheet listing the items selected during close.
That broader screening does not replace the controller's close review. A controller still has to decide whether an accrual is reasonable in light of the month's business activity, whether a revenue pattern fits the contract terms, and whether an intercompany balance agrees with the other entity. Those judgments require context that a rule cannot reproduce. The purpose of ongoing controls is to take on the mechanical screening that otherwise consumes a disproportionate amount of close-cycle capacity.
The Three Parts of an Operating Control Environment
A functioning ERP control program depends on three connected elements: an access path to posting data, a defined test library, and a process for handling exceptions.
Posting-data access is the connection between the control system and the ERP journal layer. It should be read-only. The system receives posting information but has no ability to write back to the ERP. This protects the ERP's native audit trail and keeps the monitoring process from interfering with posting. For SAP, the relevant source is the Universal Journal through OData services, including ACDOCA. For Oracle Fusion, the connection reads from the GL transfer layer through the Financial REST APIs. For NetSuite, it uses SuiteAnalytics Connect.
Entry tests are the conditions applied to each incoming journal. They can examine account codes, entity codes, amounts, dates, entry type, and combinations of those fields. For example, a test might identify a manual entry above $10,000 posted to accounts in the 7000 to 7999 range after the 28th of the month. Another might identify an intercompany debit where the designated contra entity has no matching credit in the same posting batch. When a condition is met, the system records a flag tied to the rule that produced it.
Exception handling determines how flagged entries are reviewed, resolved, or escalated. At a minimum, controllers need a queue showing the flagged item, a review status, and notes describing its disposition. More mature arrangements assign exception types to particular team members by account ownership or rule category and monitor time to resolution during close. The queue therefore functions as a control record, showing what was flagged, when it was flagged, which rule applied, and what action followed.
Designing Rules That Controllers Will Use
The most common operational failure is not too little configuration, but too much of it. A library containing 150 active rules and producing 400 exceptions per week can become ambient noise. When reviewers face a queue of hundreds of unresolved items, review discipline declines and the control becomes a reporting output instead of an operating procedure.
Rule design should begin with the areas where risk is concentrated in the actual business. Across ERP environments, journal risk often clusters in six recurring patterns:
- Manual entries to period-end accrual or provision accounts after the 25th of the month
- Entries reversing prior-period items without a corresponding original entry in the system
- Round-number entries above the materiality threshold, such as $50,000.00 or $100,000.00 exactly
- Intercompany entries with no matching contra posting on the other entity
- Entries posted to account codes outside the entity's normally active account range
- Journal entries posted by elevated-permission user accounts outside normal business hours
A practical starting point is 5-8 rules covering these patterns, followed by a full close cycle of observation. That sequence is more informative than attempting to configure the entire control library immediately. The first cycle establishes the local exception baseline and shows which rules provide useful signal and which need different thresholds or conditions.
A Three-Phase Route to Implementation
The implementation sequence that tends to work across ERP configurations and team sizes has three phases.
Phase one, connect and watch: establish the read-only ERP connection and activate no more than 5-8 initial rules in observation mode for one close cycle. Flags are generated, but the queue is not yet made part of the close checklist. The immediate objective is to measure volume and determine which thresholds need adjustment.
Phase two, tune and assign: use the observation results to reduce noise, turn off rules that create many flags without a corresponding risk signal, and route categories to named owners. Intercompany imbalance items can go to the consolidations controller. Restricted-account postings can go to the person responsible for account policy. Routing prevents one reviewer from becoming the bottleneck.
Phase three, make it part of close: once the queue reflects credible risk signals, add its review to the standard close checklist. An unresolved exception becomes a close item alongside reconciliation sign-offs, with an owner and a completion expectation. That step makes the system an accountable control rather than a dashboard reviewed at convenience.
Most teams reach a stable operating model by the end of the third close cycle after going live. Thereafter, maintenance primarily involves adding custom rules as the business changes and as new posting patterns become visible.
Custom Tests for Local Posting Patterns
A standard rule library captures patterns that recur across industries and ERP setups. It cannot, by itself, understand every posting relationship unique to a particular business. Environment-specific controls are useful when they express a known operational or accounting dependency.
For example, a distribution company could flag a cost-of-goods entry when the posting entity differs from the entity on the related purchase order. A professional services company could identify revenue recognition posted before the associated project milestone is marked complete in the project management system. A multi-entity holding company could flag an intercompany elimination account balance above a configured threshold when no matching consolidation entry exists.
These tests generally require initial configuration between the controller and the person managing the rules. The resulting control set is aligned with the company's actual risk topology instead of relying only on assumptions about an average ERP environment.
Where Rule-Based Ongoing Controls Stop
A rule-based control identifies the conditions it has been configured to test. It cannot identify a pattern that falls outside those conditions. That limitation follows from the operating model of rule-based monitoring and should be treated as a design boundary.
A deliberate misclassification that satisfies every active rule will not be flagged. An accrual below the materiality threshold that is consistently understated may also pass. Rules applied to individual journal entries cannot determine the substance of management estimates, the appropriateness of a revenue recognition judgment, or the reasonableness of provisioning levels.
Ongoing controls therefore sit within a wider control environment. They do not remove the need for management review, disciplined reconciliations, or oversight by people who understand the business context behind the figures. Their defined contribution is volume screening, allowing a small controller team to see more of the ledger than a periodic sample permits.
The strongest operating practice is to manage the exception queue like an open-items schedule for a reconciliation. Each item has to be reviewed, supported, resolved, or escalated. Treating it as a close workstream with ownership and completion criteria is what keeps the control active after implementation, rather than allowing it to become another report that is consulted only when close pressure is highest.