Your controls passed in March.
What happened in April?

Most SAP control environments are assessed the same way they were twenty years ago: an auditor selects a sample, tests it against a control description, and issues an opinion. If the sample passes, the control is deemed effective for the period.

Consider what that actually establishes. A typical mid-size SAP estate posts several million financial documents a year. An audit might test twenty-five of them. Passing means twenty-five documents behaved. It says almost nothing about the other few million, and nothing at all about what happened the week after fieldwork ended.

The gap is not sampling error. It is timing.

Statistical sampling is defensible when the population is uniform. Fraud and control failure are not uniform — they are deliberately concentrated in the places least likely to be looked at. Month-end. Public holidays. The week the control owner is on leave. A sample drawn evenly across a year is close to the worst possible instrument for finding activity that was designed to avoid attention.

The second problem is that a control can be effective on the day it is tested and ineffective a fortnight later, and nothing in the periodic model will surface that. A configuration is changed for a legitimate one-off reason and never changed back. A tolerance is widened during a system issue. A workflow approver leaves and their queue is reassigned to someone who approves everything. All of these pass an annual test that happened before they occurred.

What access controls cannot tell you

Segregation of duties is preventive: it stops one person holding a combination of access that would allow them to act unchecked. That is necessary, and it is where most SAP governance programmes concentrate.

But SoD answers a question about capability, not about events. It cannot tell you that a vendor bank account was changed, a payment released to it, and the account changed back within the same afternoon — because at no point did one user hold a conflicting role. Two users, each individually clean, produce an outcome neither was supposed to be able to reach.

This is the category of risk that access governance is structurally unable to see, and it is where the money usually goes.

What continuous controls monitoring actually catches

CCM tests the whole population, continuously, against rules describing what the business does not want to happen. In practice the findings that matter tend to be unglamorous:

• Vendor master changes followed by payment. Bank details amended and an invoice released against them inside a short window — the single most common payment fraud pattern in ERP.
• Duplicate payments. Same vendor, same amount, same invoice reference, different document. Usually error rather than fraud, and usually recoverable if found within weeks rather than years.
• Configuration drift. Tolerance limits, payment blocks and approval thresholds changed outside a change window, or changed and reverted.
• Emergency access with nothing behind it. Firefighter sessions opened where the log shows activity that has no corresponding incident ticket.
• Manual journals at the boundary. Entries posted after period close, or by users who post one journal a year, or reversing exactly in the following period.
• Purchase orders raised after the invoice date. Retrospective approval of spend that has already happened.

None of these require a fraudster. Most are process failures. That is the point — they are business risk whether or not anyone intended harm, and the periodic model finds them a year late or not at all.

The argument that actually persuades a finance director

Framing CCM as better assurance rarely lands, because the audit is already passing. Two framings work better.

The first is recovery. Duplicate payments and overpayments are found in most estates that look properly, and money identified within the same financial year is usually recoverable. The programme frequently pays for itself out of what it finds in the first cycle.

The second is audit cost. Once controls are monitored continuously and the evidence is produced automatically, external audit has a population-level basis to rely on rather than a sample. That is a defensible reduction in fieldwork, and the finance function feels it.

Where to start

The failure mode of CCM programmes is scope. Configure two hundred rules and the output becomes another report nobody reads — the exact fate of the SoD report it was meant to improve on.

• Start with five to eight rules covering the risks your business actually has, not the vendor's full library.
• Route each to a named owner who can act, not to a mailbox. An alert with no owner is noise.
• Tune to a volume that gets worked. If a rule produces two hundred exceptions a week it is misconfigured, and it will be ignored within a month.
• Measure time from detection to resolution. That, not the exception count, tells you whether the programme is real.

The uncomfortable part

The first cycle of continuous monitoring is unflattering. It surfaces things that have been happening for years underneath a clean audit opinion, and someone will reasonably ask why they were never found before. The honest answer — that nobody was looking at the whole population — is politically awkward in a way that has quietly killed a number of these programmes at the business case stage.

Agreeing in advance that the first run is a baseline rather than a performance review is usually what determines whether the programme survives contact with its own findings.