The two terms get used as synonyms in vendor decks and audit committee papers, and the confusion has a cost. When internal audit builds a duplicate-payment alert, routes it to accounts payable, and chases the exceptions itself, it has built a control and become part of the first line, which is the one thing the independence standards say it cannot be. When management calls its exception dashboard “continuous auditing,” it has claimed assurance it does not have. The difference is not the technology, which is identical, or the rules, which overlap heavily. It is who owns the output and what happens when an alert fires. Continuous monitoring is management’s control, operated by management, that catches and corrects exceptions as they happen. Continuous auditing is internal audit’s procedure, operated by internal audit, that tests whether the process and its controls, including the monitoring, are working, on a cadence closer to the transactions than an annual engagement allows.
This guide draws the line precisely and then shows how to build each side of it: a twelve-dimension comparison, the independence rules that keep continuous auditing from turning into a control, the architecture both share, a catalog of 22 rules with logic and thresholds across purchase-to-pay, payroll, the general ledger, access, and expenses, a phased implementation roadmap, a worked duplicate-payment implementation at MidState Beverage with real alert volumes and false-positive rates, an alert governance table, and what continuous auditing does to the annual plan and to sampling. It was rewritten in September 2026 to reflect the Global Internal Audit Standards and current tooling. The site’s separate deep dives on continuous auditing and continuous monitoring go further into each; this guide is the one to read first.
In this guide
- The distinction, in twelve dimensions
- Why the distinction matters: independence and the three lines
- The shared architecture
- The rule catalog: 22 rules with logic and thresholds
- Implementation roadmap
- Worked example: duplicate-payment monitoring at MidState Beverage
- Alert governance: triage, ownership, service levels
- What continuous auditing does to the audit plan and to sampling
- Common failures
- Adapting: small functions, tools, and when not to build
The distinction, in twelve dimensions
| Dimension | Continuous monitoring (CM) | Continuous auditing (CA) |
|---|---|---|
| Owner | Management: the process owner or a second-line function | Internal audit |
| Purpose | Detect and correct exceptions in the process as they occur; a detective control | Obtain evidence, at a higher frequency than an annual engagement, that controls and the process are operating; an audit procedure |
| Position in the three lines | First line (process owner) or second line (risk, compliance, finance) | Third line |
| What an alert means | Something needs fixing now: a duplicate to block, an unapproved change to reverse | Something to test: an exception rate to evaluate, a control to conclude on, a finding to consider |
| Who acts on an alert | The process owner, with a service level | The auditor, who evaluates and reports; the auditor does not fix |
| Frequency | Real-time to daily, tied to the process cycle | Weekly to quarterly, tied to the audit’s need for evidence over a period |
| Output | Exception queue, corrective actions, management metrics | Test results, control conclusions, findings, changes to the audit plan |
| Evidence use | The monitoring log is evidence that the control operated | The audit’s results are evidence that management’s controls, including CM, work |
| Thresholds | Tuned by management for operational tolerance and workload | Set by audit for risk; often tighter than management’s, and audit tests management’s threshold as a design question |
| Scope over time | Stable: the same rules run every day on the same process | Rotating: rules change with the plan and the risk assessment; some run all year, some for a quarter |
| Independence effect | None; it is management’s activity | Must be preserved: audit tests, reports, and does not own the exception queue |
| What it replaces | Manual after-the-fact review controls, with far better coverage | Some sample-based testing in the annual engagement; never the engagement itself |
The row that decides most arguments is “who acts on an alert.” If the answer is the process owner, it is monitoring, whoever wrote the rule. If the answer is the auditor, and the auditor’s action is to evaluate and report rather than to fix, it is auditing. Where the answer is that the auditor chases the process owner to fix it, the function has drifted into the first line and needs to hand the rule over.
Why the distinction matters: independence and the three lines
The Global Internal Audit Standards require internal audit to be independent of the activities it audits and require auditors to avoid assuming management responsibilities; the IIA’s Three Lines Model puts operating controls in the first line and assurance over them in the third. An alert that management relies on to catch duplicate payments is a control, and a function that runs it, tunes it, and works the queue has designed and operated a control it will later be asked to give assurance on. The practical consequences arrive within a year: the function cannot audit the process because it owns part of it, the external auditor cannot rely on the function’s work in that area, and management stops building its own monitoring because audit is doing it.
Four rules keep continuous auditing on the right side of the line. Audit builds rules for audit’s purposes and reports the results; it does not own an exception queue that management is waiting on. When a rule proves so useful that management wants it as a control, audit hands it over, documented, and then tests it as management’s control, which is the best possible outcome and is how most mature monitoring programs began. Audit’s rules and thresholds are its own and may differ from management’s, because audit is asking a risk question, not an operational one. And every alert audit acts on becomes an evaluated exception in a workpaper, with a conclusion, not a ticket for someone to fix. The Domain II guide covers the objectivity standards behind those rules.
Advisory work is the honest exception. A function may help management design its monitoring as an advisory engagement, with the boundaries the Domain III guide describes: management makes the decisions, owns the result, and the function does not audit its own design for a period. The “we built it, so we know it works” argument is the one to refuse.
The shared architecture
Both sides run on the same five components, and a function that understands them can evaluate a vendor’s platform or build its own in a database and a scheduler. What differs between CM and CA is the owner of each component and the retention rules, not the design.
| Component | What it does | Design questions | CM owner | CA owner |
|---|---|---|---|---|
| Data access | Extracts or reads the transaction, master, and log data the rules need | Direct read on the ERP, a replicated reporting database, or scheduled extracts? What latency? Who controls the extract logic, and is the extract complete? (The completeness and accuracy of the feed is an IPE question for every rule built on it) | IT, for the process owner | Audit’s own extract, or a read replica audit can query independently |
| Rules engine | Applies the logic: matches, thresholds, comparisons across sources, statistical outliers | SQL and a scheduler, a BI tool, a scripting language, or a platform? Who can change a rule, and is the change logged? Are rules versioned so that an alert can be traced to the logic that produced it? | Second line or IT, under change control | Audit, under audit’s own change control |
| Alert workflow | Routes each alert to an owner, records the disposition, tracks the service level | Ticketing system, workflow tool, or a shared queue? What are the disposition codes? Can an alert be closed without a reason? | Process owner, with second-line oversight | Audit’s workpaper, not a queue: each alert is evaluated and concluded on |
| Evidence retention | Keeps the alert, the data it fired on, the disposition, and who did what | How long? Immutable? Can the retained alert be reproduced from the retained data and rule version? | Management, to the record-retention policy; audit tests it | Audit, to the workpaper retention standard |
| Reporting | Metrics: alert volumes, false-positive rates, time to disposition, trends by unit | Who sees which cut? Does the report distinguish alerts closed with action from alerts closed as false positive? | Management information; second line to the risk committee | Audit to the audit committee, as results and as coverage |
The data-access component is where most programs are weaker than they look. A rule is only as good as the feed, and a feed that drops a subsidiary, a document type, or the last day of the month produces confident silence. Every rule in the catalog below carries an implicit first test: reconcile the feed to a control total before trusting a zero-alert day. The ITGC primer covers the change and access controls the rules engine itself needs, because a rule anyone can edit is a control nobody can rely on.
The rule catalog: 22 rules with logic and thresholds
Each rule below states the logic in words a data owner can implement, a starting threshold, and the risk it addresses. The “CM or CA” column says where the rule most naturally lives; several belong in both, with management running it daily as a control and audit running it quarterly to test that management’s version is catching what it should. Thresholds are starting points to be tuned against the first month’s alert volume; the tuning method is in the worked example. The domain guides on accounts payable analytics, payroll analytics, and journal entry analytics carry the full catalogs from which these were drawn.
| # | Domain | Rule | Logic | Starting threshold | Risk | CM or CA |
|---|---|---|---|---|---|---|
| 1 | P2P | Exact duplicate invoice | Same vendor, same invoice number, same amount, within 365 days, either not cancelled | Any match | Duplicate payment | CM daily; CA quarterly |
| 2 | P2P | Fuzzy duplicate invoice | Same vendor, same amount, invoice numbers differing only by punctuation, leading zeros, or one character; or same invoice number and amount across two vendor IDs with matching bank account or address | Amount over $500 | Duplicate payment; duplicate vendor | CM daily; CA quarterly |
| 3 | P2P | Invoice paid without PO where PO is required | Invoice with no PO reference where the vendor category or amount requires one per policy | Amount over $2,500 | Unauthorized purchase | CM weekly |
| 4 | P2P | Price variance within tolerance but material in aggregate | Invoice unit price above PO unit price, summed by vendor per quarter | Vendor total over $5,000 or over 2 percent of vendor spend | Overbilling under the match tolerance | CA quarterly |
| 5 | P2P | Vendor master change followed by payment | Bank account or address changed, then a payment to the vendor within 14 days | Any, for bank changes | Payment diversion | CM daily |
| 6 | P2P | Vendor–employee match | Vendor bank account, address, or phone matches an employee master record | Any match | Fictitious vendor | CA quarterly; CM monthly where tooling allows |
| 7 | P2P | Split purchases | Two or more POs to the same vendor by the same requester within 3 days whose sum exceeds the requester’s approval limit while each is below it | Sum over the limit | Approval circumvention | CA monthly |
| 8 | P2P | Payment run released outside dual control | Payment file uploaded and released by the same user, or released outside business hours | Any | Unauthorized payment | CM daily |
| 9 | Payroll | Ghost employee indicators | Active employee with no time entries, no badge events, and no benefits deductions for 60 days; or two employees sharing a bank account | Any | Fictitious or departed employee paid | CA monthly |
| 10 | Payroll | Termination after last pay | Payment dated after the termination date plus one pay cycle | Any | Overpayment after leaving | CM per pay run |
| 11 | Payroll | Pay rate change without approval | Rate changed by a user without HR approval role, or self-changed | Any | Unauthorized pay | CM per pay run |
| 12 | Payroll | Overtime outliers | Overtime hours above 2.5 standard deviations from the employee’s own 12-week mean and above the department’s 90th percentile | Both conditions | Time inflation; supervisory failure | CA monthly |
| 13 | GL | Manual journals by non-finance users | Journal posted by a user whose role is not in the finance role set | Any | Access; unauthorized entries | CM weekly |
| 14 | GL | Round-amount journals near period-end | Manual journals in the last 3 days of the period with amounts divisible by 1,000 and above a floor | Amount over $10,000 | Management override; estimates without support | CA quarterly |
| 15 | GL | Self-approved journals | Preparer equals approver, or approver lacks the approval role | Any | Segregation | CM weekly |
| 16 | GL | Suspense and clearing account aging | Balance items older than 60 days in clearing accounts | Item over $1,000 or account total over $25,000 | Unreconciled differences hidden | CM monthly; CA quarterly |
| 17 | Access | Terminated user with active account | HR termination date passed; account status active in any in-scope system | Any, after 1 business day | Unauthorized access | CM daily |
| 18 | Access | Segregation conflict created | Role assignment that creates a conflict in the SoD matrix | Any | Segregation | CM at provisioning; CA quarterly full re-run |
| 19 | Access | Privileged account activity outside change windows | Administrative or firefighter account used outside an approved change ticket window | Any | Unauthorized change | CM daily |
| 20 | T&E | Duplicate expense claims | Same employee, same amount, same merchant within 30 days; or same receipt image hash on two claims | Amount over $25 | Duplicate reimbursement | CM per claim |
| 21 | T&E | Just-under-threshold receipts | Claims between 90 and 100 percent of the receipt-required threshold, by employee per quarter | Employee with 4 or more | Threshold gaming | CA quarterly |
| 22 | T&E | Self-approved or manager-approved own claims | Claim approved by the claimant, or approver’s own claim approved by a subordinate | Any | Segregation; collusion | CM per claim |
Rules 1, 5, 8, 10, 17, and 22 are the six a function should expect management to run as controls, and where management does not, the absence is the finding, not the rule audit builds to fill it. Rules 4, 7, 9, 12, 14, and 21 are the ones that belong to audit, because they ask risk questions management has little incentive to ask of itself. The ERP SoD analysis guide and the user access review guide cover the access rules in depth, including why a quarterly full re-run by audit is not redundant with a daily provisioning check.
Implementation roadmap
The roadmap below is for internal audit building continuous auditing, with notes on where a management continuous-monitoring program differs. The timescale assumes a function with one person who can write SQL or use a query tool and a data owner who will provide extracts; a platform shortens the build and lengthens the procurement.
| Phase | Weeks | Work | Deliverable | Pitfall |
|---|---|---|---|---|
| 1. Select the domain and the rules | 1–2 | Pick one process with high transaction volume, a clean data source, and a risk on the annual assessment; choose 5 to 8 rules from the catalog | Rule specification: logic, threshold, data fields, owner, frequency, what an alert means | Starting with twenty rules across five processes; nothing gets tuned |
| 2. Secure the data | 2–5 | Agree the extract or read access with IT; document fields, period, and refresh; reconcile the first extract to control totals | Data feed with a completeness check that runs every refresh | Accepting a feed without a reconciliation; discovering in month three that credit memos were excluded |
| 3. Build and back-test | 4–8 | Implement the rules; run them on 12 months of history; evaluate every alert in the back-test to learn the false-positive rate and tune thresholds | Back-test results: alert volume, confirmed exceptions, false-positive rate, tuned thresholds, per rule | Going live on untested thresholds and drowning in alerts |
| 4. Define the evaluation procedure | 6–8 | For each rule, write what the auditor does with an alert: evidence to inspect, exception definition, conclusion options, workpaper format | Evaluation procedures in the work program; workpaper template | Treating alerts as tickets to chase instead of tests to conclude on |
| 5. Go live on a cadence | 9–12 | Run the rules on the agreed cadence; evaluate; report the first quarter’s results to the CAE and then the committee | Quarterly CA results: coverage, exceptions, findings, plan changes | Running daily because the tool can; audit does not need daily |
| 6. Hand over what management should own | 12–20 | Rules that are catching operational exceptions management should be catching become a finding and then, if management adopts them, a control audit tests | Handover document; management’s monitoring under change control; audit’s test of it | Keeping the rule because it is audit’s favorite |
| 7. Expand | 20+ | Next domain; retire rules that have produced no exceptions in four quarters or convert them to annual analytics | Rule inventory with retirement dates | Rules accumulating forever |
For a management monitoring program, phases 1 to 3 are the same, phase 4 becomes the disposition procedure with service levels (below), phase 5 runs at the process cadence, and phase 6 does not exist because management owns it from the start. Internal audit’s role in a management program is phase 3’s challenge, the design test of the thresholds, and the operating test of the dispositions; the management review controls guide treats a monitoring dashboard as the review control it is.
Worked example: duplicate-payment monitoring at MidState Beverage
MidState Beverage is the site’s running example: a three-state distributor with 12 depots, a 2013 ERP, two acquired distributors on their own systems, a lean finance team, and a six-person audit function. In FY27 the function built rules 1, 2, 4, and 5 from the catalog as continuous auditing over accounts payable, after the ICFR support engagement found that the ERP’s duplicate-invoice check matched on vendor and invoice number only and that nobody reviewed within-tolerance price variances. The numbers below are the first two quarters.
The data: the AP invoice table and the vendor master, extracted weekly from a reporting replica by a query the audit senior owned, with a completeness check that reconciled the extract’s invoice count and value to the ERP’s AP register totals for the week; two weeks in the first quarter failed the check because a depot’s batch posted late, and both were re-extracted before the rules ran. Annual volume: 41,600 invoices, $118 million. The back-test on twelve months of history produced the thresholds.
| Rule | Back-test alerts (12 months) | Confirmed exceptions | False-positive rate | Tuning applied | Live alerts, Q1–Q2 | Confirmed, Q1–Q2 |
|---|---|---|---|---|---|---|
| 1. Exact duplicate | 61 | 9 (all already caught by AP before payment) | 85 percent (recurring monthly invoices with the same number and amount by design) | Exclude vendors flagged as recurring-billing; require both invoices posted, not cancelled | 7 | 2 (one paid twice, $4,180, recovered) |
| 2. Fuzzy duplicate | 418 | 23 | 94 percent | Raise floor to $500; require bank account or address match for cross-vendor pairs; add invoice-date within 45 days | 38 | 6 (three paid twice, $11,940 total, all recovered; three blocked before payment by AP after the alert was shared as a finding) |
| 4. Price variance in aggregate | Not applicable (quarterly aggregate) | — | — | Vendor threshold set at $5,000 or 2 percent of vendor spend, whichever is lower | 14 vendors | 4 vendors overbilling on contract prices, $27,300 recovered; one vendor’s freight terms renegotiated |
| 5. Vendor bank change then payment | 52 | 0 (all legitimate, all approved) | 100 percent | Kept as a CA rule for one more quarter, then handed to AP as a control with a call-back requirement | 11 | 0; rule handed over in Q2 |
Three things about that table are the lesson. The back-test is where the false-positive rate is learned, and the exact-duplicate rule’s 85 percent false-positive rate was entirely explained by recurring-billing vendors, which one exclusion fixed. The fuzzy rule needed three tuning steps, and its live false-positive rate of 84 percent is still high, which is acceptable for a quarterly audit rule evaluated by an auditor and would be unacceptable for a daily management control worked by a clerk. And rule 5 produced nothing in eighteen months, which is a good result and the right reason to hand it to management: the risk is real, the control belongs in the first line, and audit tests it once a year.
What happened to the results is the independence lesson. The $16,120 of duplicates and the $27,300 of overbilling went into a finding on the AP duplicate-check configuration and the within-tolerance variance review, with the recoveries reported as management’s. AP adopted rules 1 and 2 as a daily control in Q3, with a disposition procedure and a service level; audit retired its weekly run of both and replaced it with a quarterly re-run against the whole population to test that AP’s version was catching what it should. Audit kept rule 4, because a quarterly aggregate is an audit question. The accounts payable audit guide has the full risk catalog that rules 1 to 8 were selected from, and the vendor master audit guide the tests behind rules 5 and 6.
What the auditor does with an alert
The evaluation procedure is what makes a continuous-audit alert an audit result rather than a ticket. For the fuzzy-duplicate rule at MidState it read: for each alert, inspect both invoice images and the purchase orders; establish whether the invoices are for the same goods or services (same PO line, same delivery reference, or same service period); if they are, establish whether both were paid, and if both were paid, whether AP’s own check could have caught it and why it did not; record the disposition as duplicate paid, duplicate blocked, or not a duplicate with the reason; and conclude quarterly on the AP duplicate control by comparing what the rule found with what AP’s check found. The workpaper for the quarter listed all 38 alerts with dispositions, the six confirmed duplicates with amounts and recovery status, and one conclusion: the ERP duplicate check, matching on vendor and invoice number only, did not detect three paid duplicates totaling $11,940 in which the invoice numbers differed by a suffix, and is not designed effectively for that pattern. That sentence became the condition of a finding. The recoveries were AP’s work, initiated from the finding, and were reported as management’s action; audit did not call the vendors.
A false positive is also a result. The 32 alerts that were not duplicates were classified by reason (recurring billing, credit and re-bill pairs, legitimate split deliveries, and data-entry corrections), and the reasons drove the next round of tuning. An evaluation procedure that records only the hits cannot improve the rule; one that records the misses by reason can, and it produces the false-positive analysis the committee will ask about when it hears that 84 percent of alerts were not exceptions.
Alert governance: triage, ownership, service levels
A monitoring program without alert governance is a dashboard, and dashboards do not prevent anything. The table is written for management’s continuous monitoring, because that is where alerts have to be worked; for continuous auditing the equivalent is the evaluation procedure in the work program, and the only service level is the audit’s own reporting cadence.
| Element | Rule | Why |
|---|---|---|
| Triage owner | A named role receives every alert for a rule; not a shared mailbox | Shared queues are nobody’s queue |
| Disposition codes | A fixed list: confirmed and corrected; confirmed and accepted with reason; false positive with reason category; referred for investigation; duplicate of another alert | Free-text closures cannot be analyzed and hide false-positive patterns |
| Service level by severity | Payment-blocking rules (1, 2, 5, 8, 17): same business day. Others: 5 business days | A duplicate caught after the payment run is a recovery, not a prevention |
| Escalation | Alerts open past the service level escalate to the process owner’s manager; past twice the level, to the controller; the second line sees the aging weekly | An unworked alert is a control that did not operate |
| Segregation | The person who caused the transaction cannot close its alert; closures by the same user as the transaction are themselves an alert | Self-closure is the monitoring equivalent of self-approval |
| False-positive review | Monthly review of false positives by reason; a rule above 70 percent false positives for two months is re-tuned or retired | Alert fatigue is the most common way monitoring dies |
| Rule change control | Rule logic and thresholds are versioned; changes are approved by the second line and logged; audit is told | A threshold quietly raised to reduce workload is a control quietly weakened |
| Evidence | Alert, underlying records, disposition, user, and timestamp retained for the record-retention period, immutable | The disposition log is the evidence that the control operated; audit will sample it |
| Metrics | Volume, confirmed rate, false-positive rate, time to disposition, open past service level, by rule and by unit, monthly | What the second line and the audit committee should see |
What continuous auditing does to the audit plan and to sampling
Continuous auditing changes three things about the annual plan. Coverage becomes partly continuous: the plan states which risks are covered by quarterly rules rather than by an engagement, and the committee’s coverage map shows both, which the annual plan template accommodates in its coverage section. Engagement scoping starts from the rule results: an accounts payable engagement at MidState in FY28 will spend its hours on the vendor master, contract pricing, and the acquired distributors, because duplicates are now covered by a tested management control and a quarterly audit re-run. And the risk assessment gets a data input it never had: exception rates by unit and by quarter, which is a better indicator of control health than a questionnaire.
Sampling changes in a specific way and not in the way vendors claim. A full-population rule replaces a sample for the attribute the rule tests: when every invoice in the year has been screened for exact duplicates, a sample of 25 for duplicates adds nothing. It does not replace samples for attributes the rule cannot see, such as whether the goods were received or whether the approver read what they approved, which still need a sample and a human; the sampling techniques guide draws the line between what a population analytic answers and what it cannot. And a rule’s output is only evidence if the feed it ran on was complete, so every continuous-audit conclusion carries the feed reconciliation as its first workpaper.
Common failures
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Audit becomes the control | Audit’s rule is the only duplicate check; AP waits for audit’s email | Independence lost; management never builds its own monitoring | Hand the rule over; test it as management’s control |
| Alert fatigue | Hundreds of alerts a week, 90 percent false positives, closures without reasons | The one real exception is closed with the rest | Back-test before go-live; monthly false-positive review; retire or re-tune rules above 70 percent |
| Trusting the feed | A zero-alert month celebrated; the extract had dropped a company code | Confident silence | Completeness reconciliation every refresh, filed as IPE evidence |
| Rules nobody can change, or anybody can | The analyst who wrote the SQL left; or thresholds edited in a spreadsheet with no log | Unmaintainable, or unreliable | Versioned rules under change control with a named owner |
| Daily because the tool allows it | Audit runs rules daily and evaluates nothing | Volume without conclusions; the queue becomes management’s problem by default | Audit’s cadence follows its evidence need: weekly to quarterly |
| Metrics that flatter | “Alerts closed” reported without distinguishing corrected from false positive | The committee sees activity, not control | Confirmed rate and time to disposition, by rule |
| Platform before rules | A twelve-month procurement for a tool with no rule specifications | The tool is configured by the vendor to its defaults, and nobody owns the logic | Write the rule specifications first; they are the requirements |
| Never retiring anything | Forty rules, half producing nothing for years | Maintenance cost; real signals buried | Annual rule inventory with retirement criteria |
Adapting: small functions, tools, and when not to build
A small function can run continuous auditing with a database view, a scheduler, and one person who can write a query, and the six rules to start with are 1, 2, 9, 14, 17, and 18, because they cover the most money and the most common findings with the least data. What a small function should not do is build management’s monitoring for it; the finding that management has no duplicate check is the product, and management’s adoption of the rule is the outcome. Tooling ranges from SQL and a scheduler, through the analytics modules in audit-management platforms, to dedicated monitoring platforms; the rule specifications above are tool-independent and are the requirements document for any of them. The journal entry analytics guide shows the scoring approach that turns several rules into one ranked list, which is how a function with limited evaluation hours decides what to look at first.
There are processes where neither should be built yet: where the data source is a spreadsheet, where the transaction volume is low enough that a quarterly sample sees everything, or where the process is about to move to a new system. In those cases the annual engagement with population analytics for the year, run once, gives the same assurance at a fraction of the maintenance. Continuous methods earn their cost where volume is high, the process is stable, the data is in a system, and the risk is on the annual assessment. Every guide on the site is indexed at All Guides and by subject on the Topics page; the free tools, including the sampling tool the sampling guide refers to, are on the Tools page.
Related guides
- Continuous auditing: a comprehensive overview — the deeper dive on the audit side
- Continuous monitoring: a complete guide — the deeper dive on the management side
- Accounts payable analytics catalog — 40 tests, from which the P2P rules were drawn
- Payroll analytics catalog — 30 tests, including the ghost-employee indicators
- Journal entry analytics — 25 tests and a composite risk score
- ERP segregation of duties analysis — the conflict matrix behind rule 18
- User access review — the quarterly re-run that complements daily provisioning checks
- IPE testing — why every rule starts with a feed reconciliation
- Management review controls — evaluating a monitoring dashboard as the review control it is
Leave a Reply