For a controller team facing 6,000 journal entries in a month, reviewing 200 of them during each close means coverage of about 3%. The remaining 5,800 postings receive no direct review unless a reconciliation or another process brings one to someone's attention. A team of three controllers can easily find itself in that position. The unreviewed population is also where errors may remain hidden until they become most expensive to resolve.
The Distance Between Posting and Review
Journal entry review generally takes place in two stages. During the period, accountants investigate items that look unusual as they encounter them. At close, the team performs a more organized review, usually by selecting a sample. For a small finance function working against a fixed close timetable, manually examining every ERP posting is not practical, so sampling becomes the operating method.
Sampling is not inherently defective. Audit practice has used statistical sampling for a century. The more consequential limitation is when the review occurs. An error identified on day 8 of close may have been posted 20 days earlier. By then, the preparer is working on other tasks, the original rationale may no longer be readily available, and any approval override may require reconstruction. If the posting was part of an intercompany allocation, correcting it can also require the team to unwind three or four related reconciling items before reaching the source entry.
Consider a mid-size manufacturer using SAP. A cost allocation sent to the wrong legal entity can create a chain of intercompany imbalances that takes half a day to investigate during close. If the same posting is identified on the day it is made, correction takes roughly 15 minutes. The preparer still has the relevant context, and the remediation remains concentrated on one journal entry.
The distinction is therefore not simply between review and no review. It is between examining a posting while its context is available and investigating it after related activity has accumulated around it. A control that surfaces an exception close to the time of posting changes where resolution sits in the close timetable.
Rule Checks Where Journals Are Posted
Centinel connects to the journal posting layer of an ERP through read-only API access. It assesses each incoming entry against a configured set of rules and places matching entries in an exception queue. The mechanism is intentionally explicit. A rule defines a recognizable pattern, and a posting that meets that pattern produces a flag. The reviewer can see which rule was triggered and the reason for the flag, rather than having to interpret an opaque risk score.
The standard library addresses recurring patterns found in ERP journal activity. Examples include a manual entry to a period-end accrual account after the 25th of the month, a round-number posting above a configured materiality threshold, and an intercompany debit for which the corresponding credit is absent from the contra entity within the same posting batch. Other checks look for an accrual reversal whose original accrual cannot be found in the current or prior period, or for a posting to an account code outside the entity's configured account structure.
These checks do not depend on complicated logic. They represent the kinds of exceptions an attentive controller might identify during a manual review. Their practical value comes from applying the same defined tests to every posting shortly after it is made, rather than applying them to a sample weeks later.
It is important to describe the control accurately. Centinel provides rule-based pattern detection at the point of posting. We are not saying that a machine learning model is inferring risk from ledger history, and we are not saying that the system replaces the substantive judgment required in financial reporting. The product identifies entries that match configured patterns. Controllers still determine whether a flagged item is appropriate, what evidence supports it, and what action is required.
Integration Paths for SAP, Oracle, and NetSuite
Journal data follows a different path in each ERP, so the connection follows the relevant posting architecture.
In SAP S/4HANA, posted journals are written to the Universal Journal, table ACDOCA. Centinel reads that layer through the SAP OData service layer with a read-only service account. The setup does not require ABAP modifications or changes to the SAP authorization matrix beyond the service account, and it does not interrupt the posting workflow. The connection model is the same type used by SAP-certified reporting tools to access financial data.
Oracle Fusion Cloud Financials routes journal activity through subledger accounting before it reaches the general ledger. Centinel reads from the GL transfer layer, keeping the audit data aligned with the information presented in Oracle financial reports. The integration uses Oracle Financial REST APIs with read-only scope on the journal posting endpoints.
NetSuite posts an entry to the general ledger immediately after approval. Centinel reads through the SuiteAnalytics Connect layer, which creates a short latency window, typically under 5 minutes. As a result, a matching exception appears in the queue within minutes of posting rather than waiting for the end of a polling cycle.
Across these connections, the existing approval hierarchies, posting-period controls, and subledger cutoff rules remain unchanged. The operational difference is the point at which review begins. Instead of assembling the exception population at the start of close, the queue begins collecting relevant items from the first posting of the period.
How Continuous Exceptions Alter the Close
Teams using continuous journal review commonly describe close as less of a discovery exercise. Previously, two to three days could be spent determining which entries required attention before corrective work began. When exceptions are collected throughout the month, that identification work is distributed across the ordinary period rather than concentrated at close.
An accountant who receives a Slack notification about a flagged entry on the 12th of the month can investigate it that afternoon. The same item raised on day 5 of close competes with reconciliation sign-off, board deck deadlines, and other close-specific work. The journal itself has not changed. The time and surrounding workload have.
A flag is not automatically a close blocker. Rule calibration requires the team to distinguish items that require resolution before sign-off from items that should remain visible for information or follow-up. A round-number manual posting to an accrual account may merit review, while the decision to hold up close depends on the supporting documentation and the circumstances of the entry. That calibration generally takes 2-3 close cycles, after which the rules reflect the team's environment and risk tolerances more closely.
The queue also creates a period-end control record. At sign-off, a controller can produce the flags raised during the period, the resolution action associated with each item, and the current status of every exception. That record is different from a spreadsheet documenting only the sampled entries and the results of their review. It shows how the defined control operated across the period and how the resulting exceptions were handled.
The Controls Continuous Journal Review Leaves in Place
The scope should remain clear. Live journal review performs a first-pass mechanical check against defined rule patterns. It does not conduct substantive analytical procedures, assess whether an accrual estimate is reasonable, determine whether revenue recognition is appropriate under particular customer contracts, or evaluate whether the basis for a contingent liability provision is sufficient.
It also has a different purpose from reconciliation. Reconciliations establish whether ERP balances agree with source systems and external statements. Journal review examines whether the entries that make up those balances were posted in accordance with the control rules the organization has defined. The two activities address different questions and operate as complementary controls.
A rule can identify only the patterns it has been configured to test. An intentional expense misclassification that conforms to every configured rule will not be flagged. This type of control is suited to predictable error patterns, not to replacing management review, professional judgment, or the oversight of people who understand the business context behind the figures.
The clearest use case is a controller team that wants complete coverage of a specified set of posting patterns, with exceptions surfaced early enough to address them without adding unnecessary pressure to close. That is a defined improvement rather than a substitute for the broader control environment. For teams handling high posting volumes, moving this bounded mechanical review closer to the posting event can reduce reconstruction work and leave close focused on judgments that require finance expertise.