ControlsYou may know it as internal controls
Continuous control monitoring
Run your key control tests on every record each week, and send each exception to the person who owns it.
What to expect: ideas for what could change, what you need first, and how to test whether it helps. Nothing here is a measured result.
- Impact: High
- Ease: Medium
- Prep: Some
Indicative rating based on the workflow described. Your readiness and implementation effort may differ.
Evidence status: Editorial / indicative assessment
What it does
This runs your key control tests on every record, on a schedule. Each exception goes to its control owner with the evidence attached. It checks four things:
- Journal entries posted by their own approver, or on weekends.
- Users who can both create a vendor and pay it (conflicting access).
- Vendor master changes with no matching approval.
- Payments that skipped approval.
Results, resolutions and sign-offs are kept together, so you can show them to your auditor.
Why it may help
Your controls are tested on a handful of transactions.
- Each quarter someone pulls a few records and tests them by hand. It takes your team's time, and what turns up is months old.
- Weekly tests on every record may show a gap sooner, while it is still small to fix.
- The controller sees it first, with each exception arriving with its owner and its evidence, which may mean fewer audit questions.
Who does what
| AI prepares | A person decides |
|---|---|
| Pulls data from your ERP, payment platform and user-access system on a schedule | Which controls get tested, and the rule for each |
| Runs each rule over every record | Whether an exception is a real problem |
| Flags exceptions and attaches the evidence | How to fix it, or why it is acceptable |
| Routes each one to its owner and tracks the deadline | Whether a late item gets escalated |
| Stores results, resolutions and sign-offs together | What your auditor sees, and when |
The system never closes an exception or changes a rule on its own. The people who clear exceptions cannot edit the tests.
What it could move, and how you would check
Of the five measures below, this use case may help two. These are expected effects to test against your own baseline, not measured results. The last column says how to check each one.
| Fact | Expected effect | Why |
|---|---|---|
| Process steps | Depends on workflow design | Spot-checking by hand goes away, but each exception adds a review step. Count both. |
| Cycle time | Depends on workflow design | Measured here as days from exception to resolution, not invoice cycle time. |
| Exception loops | Possible downstream benefit | Problems surface early, while the fix is still small. Each exception has an owner and a deadline, so fewer go round twice. |
| First-time-right rate | Potential direct benefit | Errors such as misposted entries and duplicate payments may be caught closer to when they happen, so fewer items need fixing later. |
| Cost per invoice | Not directly addressed | Cost per invoice measures invoice work, and this use case does not act on invoices directly. |
What you need first
This is an illustrative improvement approach, not a final solution design. The workflow, level of automation, integrations, and review requirements will depend on your existing tools, available capabilities, data quality, company policies, and team needs. Confirm these during discovery and a controlled pilot before implementation.
Ease of getting started: Medium. The tools exist. Some of the setup work is yours.
- A list of your key controls, each with a named owner.
- A list of role pairs that should never sit with one person, for example create vendor and approve payment.
- Read access to your ERP, payment and user-access data.
- Owners who will clear exceptions every week.
- A conversation with your auditor on which tests they may rely on.
Evidence to keep
- Test definitions mapped to controls, with change history.
- Run logs showing date, record counts and completeness checks.
- Exception list with owner, resolution, explanation and sign-off.
What can go wrong, and how a pilot would show it
- Untuned tests send too many false alarms, and owners start ignoring them. Run each rule on last quarter's data first and tune until most hits are real.
- A missing data feed can make a control look clean when it is not. Check record counts against the source on every run.
- Monitoring finds problems and does not fix them. Give owners time to act, and escalate overdue items to the controller.
Year one, in hours
- Controls tested by hand each quarterassumption
- 20
- Hours per control per quarter, by hand todayassumption
- 6
- Hours per control per quarter, clearing exceptions afterassumption
- 2
- Hours saved per quarter (20 x 4)
- 80
- Hours saved per year
- 320
Illustrative, for a 300-person SaaS company. Every input is an assumption; replace it with your control count and last quarter's testing hours. Most of the value is in errors and fraud caught earlier, which this napkin leaves out.
Your next step
Pick the four highest-risk controls: journal entry approval, user access, vendor master changes and payment approval. Write each test as a plain rule, such as "no user both creates and approves a journal entry."
The pilot steps are under "See how to test it" in the Ways to start panel. Paid support is optional: use Get implementation support if you want help.