Continuous monitoring is sold as a platform purchase: a vendor, a connector to the ERP, a library of rules, a dashboard and a six-figure invoice. Most small internal audit functions look at that and conclude continuous monitoring is for someone else. It is not, if the ambition is right. A six-person function can run five to ten indicators that matter, weekly or monthly, from data it can already reach, using Power Query, SQL or Python it already has, with thresholds set from history and exceptions that land with someone who will act. That is continuous monitoring in every sense that counts, and it catches the duplicate payment, the ghost employee, the back-dated journal and the slow depot deposit months before an annual audit would.
This guide gives the build for a function with no budget beyond the tools it has. It covers what continuous means at this scale, the difference between monitoring the business owns and continuous auditing the function owns, how to choose the indicators, the minimum viable job, how to set and tune thresholds, who triages and how, the alert fatigue that kills most programs, the indicator register and how the output becomes audit evidence, a worked six-month build at MidState Beverage, and the failures that recur. It is the practical companion to the continuous monitoring and continuous auditing guides and to the continuous auditing versus continuous monitoring explainer, which cover the concepts; this one covers the Tuesday the first job runs.
In this guide
- What continuous means on a small budget
- Monitoring the business owns, auditing the function owns
- Choosing the five to ten indicators
- Candidate indicators by process
- The minimum viable job
- Setting and tuning thresholds
- Triage ownership
- Alert fatigue, and how programs die
- The indicator register and change control
- When the output is audit evidence
- A worked build: MidState Beverage’s first six months
- The six-month build plan
- Failures that recur
- Questions about continuous monitoring for small functions
- Related guides
What continuous means on a small budget
Continuous does not mean real time. For a distributor paying 8,000 invoices a month, a weekly duplicate-payment check catches a duplicate within days of payment and before the vendor cashes a second check in many cases; a monthly check catches it before the month closes. Real-time screening belongs inside the payment system as a preventive control, and if the ERP offers it, turning it on is the first recommendation, not a monitoring indicator. Continuous means the check runs on a schedule without anyone deciding to run it, against complete data, with the output going to a named person, and with a record that it ran. The frequency is set by how fast the risk moves and how fast anyone could act: daily for cash deposits that should be in the bank by the next business day, weekly for payments and payroll changes, monthly for journal entries and access reviews, quarterly for vendor master hygiene. Nor does it mean many indicators. A function that runs eight indicators well, with every exception dispositioned, has a program; a function that runs forty, with exceptions piling up unread, has a spreadsheet nobody trusts. The tools are the ones on the auditor’s laptop: Excel with Power Query for extract, join and rule logic; a read-only SQL account on the ERP’s reporting database or its scheduled extracts; Power BI’s free desktop for the dashboard if one is wanted; Python for anything the others cannot do; and the operating system’s task scheduler or the office suite’s automation service to run the job. The Power Query and Power BI comparison and the IDEA versus Excel and Power BI comparison cover the tooling choices; the small-team software guide covers when a platform becomes worth buying, which for most functions is after the first program has proven what it would automate.
Monitoring the business owns, auditing the function owns
The distinction in the continuous auditing versus continuous monitoring guide has a practical consequence for a small function: it cannot run the business’s controls for it. Monitoring that management owns (finance reviews the duplicate-payment exceptions every week and recovers the money) is a control, and internal audit tests it like any control. Continuous auditing that the function owns (internal audit runs the journal entry indicators monthly as part of a rolling engagement and uses the results as evidence) is audit work. A small function usually does both in sequence: it builds the first indicators because nobody else will, runs them for a period to prove their value and tune them, then hands the ones that are properly management’s to the process owner as a monitoring control and keeps the ones that serve its own assurance. The handover is the point at which the program becomes sustainable, because the function’s six people cannot triage 200 exceptions a month forever, and because an indicator owned by the person who can fix the cause is worth three owned by an auditor who can only report it. The handover also changes what the function documents: an indicator it runs for evidence follows the analytics evidence standard; an indicator finance runs is tested for design and operation like the account reconciliation control it resembles.
Choosing the five to ten indicators
Five tests decide whether a candidate indicator earns one of the ten slots. It addresses a risk the function’s risk assessment rates high or a control that has failed before (an indicator for a risk nobody rated is a hobby). The data exists, is reachable without a project (a table the function can query or an export someone already produces) and is complete enough to trust, which the completeness discipline tests on the first run. The rule can be stated in one sentence a process owner understands (“payments to a vendor whose bank account changed in the previous 30 days”), because a rule that needs a paragraph will not be triaged. Someone will act on the exceptions, has agreed to, and has the authority to fix the cause. And the expected volume is manageable: a rule that fires 400 times a month on a clean population is a report, not an indicator, and goes back for tuning or gets dropped. Start with indicators where a confirmed exception is money or a regulatory breach (duplicate payments, ghost employees, deposit lag, unauthorized access), because early recoveries buy the program credibility; add behavioral and quality indicators (manual journals outside hours, credit memos by driver) once the triage habit exists. The key risk indicator program guide covers the broader indicator discipline for the second line and the board; this guide’s indicators are transactional and exception-based, which is what a small function can run.
Candidate indicators by process
| Process | Indicator | Rule in one sentence | Typical frequency | Natural owner after handover |
|---|---|---|---|---|
| Accounts payable | Duplicate payments | Payments matching another on vendor and amount within 90 days, or on invoice number after normalization, or on amount and date across vendors | Weekly | AP manager |
| Accounts payable | Vendor bank account change followed by payment | Any payment to a vendor whose bank details changed in the previous 30 days, with the change not approved by a second person | Weekly | AP manager (fraud prevention) |
| Accounts payable | Invoices just under approval thresholds | Invoices within 5 percent below any approval limit, counted by approver and vendor | Monthly | Controller |
| Vendor master | Vendor and employee data matches | Vendor bank account, address or tax ID matching an employee record | Monthly | Procurement or AP |
| Payroll | Ghost and terminated employees | Employees paid with no time or activity record in the period; employees paid after termination date; duplicate bank accounts across employees | Each pay run | Payroll manager |
| Payroll | Pay changes above tolerance | Pay rate changes above 10 percent without a documented approval; changes entered and approved by the same user | Each pay run | HR |
| General ledger | Manual journals outside hours or by unexpected users | Manual entries posted outside business hours, on weekends, by users outside the accounting group, or back-dated across a period end | Monthly | Controller |
| General ledger | Round-amount and reversed entries | Manual entries in round thousands above a threshold; entries reversed within 5 days | Monthly | Controller |
| Cash | Deposit lag and shortages | Route collections not deposited within one business day; cash shortages by driver and depot above tolerance; credit memos and voided invoices by driver | Daily or weekly | Depot operations |
| Inventory | Adjustments by depot | Inventory adjustments above a value or frequency threshold by depot and user; negative stock balances | Weekly | Supply chain |
| Access | Segregation of duties and dormant accounts | Users holding conflicting ERP roles; accounts unused for 90 days; privileged role grants in the period | Monthly | IT or application owner |
| Travel and expense | Duplicate and split claims | Claims matching another on amount and date; receipts split under the receipt threshold; weekend and holiday claims by employee | Monthly | Finance |
The accounts payable, journal entry, payroll and segregation of duties analytics guides give the full rule sets each of these comes from, the vendor master guide the data hygiene that makes the AP indicators work, and the procurement fraud analytics and fraud red flags guides the schemes the indicators are watching for. A small function picks eight of the twelve rows above, not all of them, and picks the ones that fit its risks and its data.
The minimum viable job
| Component | Minimum viable version | What it must do |
|---|---|---|
| Data access | A read-only account on the ERP reporting database, or a scheduled export to a folder the function controls | Complete data for the period, with a control total (record count and sum) the job reconciles to the source system |
| Extract and transform | A Power Query workbook or a saved SQL script, with parameters for the period | Pull the population, normalize the fields the rule needs (invoice numbers stripped of punctuation, names upper-cased, dates typed), join the reference tables (vendor master, employee master, user roles) |
| Rule | One query or one script block per indicator, with the threshold held in a parameter table, not hard-coded | Produce the exception list with the context a triager needs: the record, the matched record, the amounts, the user, the approver, the reason it fired |
| Schedule | The operating system’s task scheduler running the script, or the office suite’s automation service refreshing the workbook, or a calendar reminder for a monthly manual refresh in the first months | Run without a decision; fail visibly (an email when the job errors or the control total does not reconcile) |
| Output | An exception workbook per run, saved to a dated folder; a shared sheet or ticket list where each exception receives a disposition | One row per exception, with columns for owner, disposition (confirmed, false positive, explained), action, date closed |
| Run log | A simple table: run date, period, indicator, records in, exceptions out, control totals, who reviewed | Prove the job ran and the data was complete; this is the evidence the analytics evidence guide requires |
| Code control | Scripts and workbooks in a version-controlled folder (a repository, or a dated-copy convention), with a one-page logic description per indicator | Know which version ran; change the threshold without changing the logic; let a second person review the rule |
The SQL for auditors guide gives the queries most of these rules reduce to, the Excel and data analysis tricks guide the Power Query habits, and the generative AI guide covers having an assistant write the first draft of the SQL or M code, with the code gate (review, known-sample test, completeness reconciliation) applied before the job is trusted. The whole build for one indicator is a day or two the first time and a few hours thereafter; the data access request is usually the longest step, and starting it in week one of the plan is the single best scheduling decision.
Setting and tuning thresholds
A threshold set by instinct produces either silence or noise. Set it from history: run the rule over the prior twelve months, look at the distribution of what fires, and choose the threshold that produces a volume the owner can triage (a dozen exceptions a week for a weekly indicator, a few dozen a month for a monthly one) while still catching the cases that matter, which the history also shows: if the known duplicate payments of the last year were all above $2,000, a threshold of $500 adds volume without adding catches. Record the rationale in the indicator register. Then tune: after three months of dispositions, compute the confirmed-issue rate (confirmed exceptions over total exceptions) and the pattern of false positives, and adjust the rule rather than the threshold where the pattern is structural (recurring monthly invoices with identical amounts are not duplicates; exclude them by vendor type rather than raising the threshold and missing a real duplicate at the same vendor). Two thresholds beat one for some indicators: an absolute value floor and a relative test (a pay change above 10 percent and above $200 a month), because each alone fires on noise. And keep a sample of the “below threshold” population: once a quarter, look at twenty items that did not fire, because a threshold that never changes is a threshold nobody tested. The non-financial risk indicators guide covers the indicators where a threshold is a trend break rather than a value, which matter more as the program matures.
Triage ownership
Exceptions without an owner are the end of a program, and the owner should be agreed before the indicator is built, not after it fires. The agreement covers who reviews the exceptions (named, with a deputy), by when (a service level: within five business days of the run), what dispositions exist and what each requires (confirmed issue with the recovery or correction recorded; false positive with the reason, which feeds tuning; explained with the evidence, such as the approval that the rule could not see), what escalates and to whom (a confirmed issue above a value, a pattern by one user, any indication of intent goes to the chief audit executive and, where the first 48 hours guide applies, is handled as a potential fraud), and who sees the summary (the controller monthly, the audit committee quarterly). While internal audit runs an indicator, the function triages and the process owner responds; after handover, the process owner triages and internal audit reviews the dispositions on a sample as a test of the monitoring control. A monthly thirty-minute meeting between the function’s analytics lead and the process owners, walking the open exceptions and the confirmed-issue rate, is the governance most small programs need. The issue tracking guide covers what happens when a disposition turns into a finding that needs an action plan.
Alert fatigue, and how programs die
Most continuous monitoring programs do not fail loudly. They fail when the exception list grows faster than anyone reads it, the owner stops opening the workbook, the job keeps running into a folder nobody visits, and six months later a real duplicate sits unread between four hundred false positives. The signs are a backlog of undispositioned exceptions, a confirmed-issue rate below a few percent on an indicator, dispositions that say “reviewed” with no reason, and a process owner who asks to be removed from the distribution. The cures are structural. Fewer indicators: cut any indicator with no confirmed issue in six months unless it exists for a regulatory reason. Tuned rules: every false positive pattern that recurs becomes an exclusion or a rule change at the quarterly tuning. Aggregation: a user with twelve small exceptions is one exception about a user, not twelve. Ownership: nobody triages what they do not own, and an indicator with no owner is retired. Closed loops: the owner who sees that last quarter’s confirmed issues were fixed and the rule was tuned keeps triaging; the one who sees nothing change stops. And a kill switch in the register: a stated rule that an indicator is reviewed for retirement when its confirmed-issue rate falls below a floor for two quarters. A program of six living indicators is worth more than one of twenty on life support.
The indicator register and change control
| Register field | Why it is there |
|---|---|
| Indicator name and one-sentence rule | The owner and the committee understand what fires |
| Risk addressed and link to the risk assessment | Every indicator traces to a rated risk |
| Data source, extract method, completeness check | Evidence the population is complete |
| Threshold, rationale, date last tuned | Thresholds are decisions with reasons |
| Frequency and schedule | Continuous means scheduled |
| Owner, deputy, service level | Exceptions land with someone who acts |
| Status: internal audit (continuous auditing) or management (monitoring control) | Decides how the output is documented and tested |
| Script or workbook version and location | Know what ran |
| Run statistics: records, exceptions, confirmed, false positive, explained, open | The health of the indicator and the program |
| Confirmed-issue rate and retirement review date | The kill switch |
Change control is light but real: a rule or threshold change is proposed by the owner or the function, reviewed by a second person who can read the code, tested on the prior period to see what the change does to volume, recorded in the register with the date, and reflected in the version. The register is the program’s governance document; it is what the function shows the audit committee (a one-page extract: indicators, owners, confirmed issues and value recovered in the quarter, changes made), what the external quality assessor asks for, and what the board risk reporting guide would fold into the pack once the committee asks to see it every quarter.
When the output is audit evidence
An indicator internal audit runs can support an engagement conclusion only if it meets the standard the analytics evidence guide sets out: a documented objective and population, completeness demonstrated against control totals for each run, the rule’s logic described and the script version retained, the exceptions dispositioned with evidence, and the limits stated (what the rule cannot see, such as an approval recorded outside the system). A rolling engagement built on indicators (journal entry testing performed monthly rather than once a year) documents each run as a test and the year as the engagement, and the run log is the workpaper index. The conclusion such testing supports is also specific: twelve monthly runs of a duplicate-payment indicator support a conclusion about duplicate payments in the year, not about the accounts payable control environment, and the small populations guide’s logic about what a test supports applies. When management owns the indicator, the function’s evidence is different: it tests that the indicator ran (the run log), that exceptions were dispositioned within the service level with reasons, that confirmed issues were corrected, and that the rule and threshold were tuned, and it reperforms a sample of dispositions. That is a test of a monitoring control, and it is often the most efficient evidence a small function can obtain about a process, because the control produces its own documentation every week.
A worked build: MidState Beverage’s first six months
MidState Beverage is the three-state drinks distributor used in examples across this site: twelve depots, about 1,400 employees, $221 million in revenue, 300 route drivers collecting about $31 million a year in cash and checks, a cloud payroll provider, no compliance function and a six-person internal audit function. The FY26 duplicate-payment analytic described in the analytics evidence guide found 41 duplicates worth $286,000 across two years of payments and recovered $241,000, and the audit committee asked the obvious question: why wait two years to find them? The function proposed a six-month build of eight indicators with no software spend, 180 hours of its own time (one auditor at roughly a day a week) and 40 hours from finance and IT, and the committee approved it in the FY27 plan.
| Indicator | Frequency and threshold | Six-month results | Status at month six |
|---|---|---|---|
| Duplicate payments (vendor and amount within 90 days; normalized invoice number; amount and date across vendors) | Weekly; $500 floor; recurring-contract vendors excluded after month 3 tuning | 26 runs; 212 exceptions; 9 confirmed duplicates, $41,300, all recovered; false positives fell from 71 percent to 38 percent after tuning | Handed to the AP manager as a monitoring control; internal audit reviews dispositions quarterly |
| Vendor bank account change followed by payment within 30 days | Weekly; any amount | 26 runs; 34 exceptions; 31 explained (approved changes the rule could not see until the approval field was added to the extract); 3 changes with no second approval, none fraudulent; one process fix | Handed to AP; approval field added to the extract reduced exceptions to about one a month |
| Vendor and employee data matches | Monthly | 6 runs; 11 matches; 9 were employees legitimately reimbursed through AP for route expenses; 2 were a driver’s relative set up as a vendor for depot supplies without disclosure, $18,400 in the year | Retained by internal audit; the relative-vendor matter handled as a conflict of interest with HR |
| Ghost and terminated employees; duplicate bank accounts | Each semi-monthly pay run | 12 runs; 7 exceptions; 5 terminations entered late (two pay periods paid after leaving, $6,900 recovered); 2 duplicate accounts explained (spouses) | Handed to the payroll manager |
| Pay changes above 10 percent and $200 without documented approval | Each pay run | 12 runs; 19 exceptions; all explained by seasonal reclassifications; rule changed to exclude the seasonal code | Retained by internal audit at quarterly frequency; retirement review set for month twelve |
| Manual journals outside hours, by non-accounting users, or back-dated across month end | Monthly | 6 runs; 48 exceptions; 44 explained (month-end close work by the controller’s team); 4 back-dated entries by a depot manager with posting access he should not have had, reversing shortage accruals | Retained by internal audit as continuous auditing for the FY27 financial close engagement; access removed; the entries became a finding |
| Route cash deposit lag over one business day; shortages above $100 by driver; credit memos by driver above the depot median plus two standard deviations | Weekly | 26 runs; 140 exceptions; deposit lag concentrated in two depots with a courier schedule problem (fixed); shortages by three drivers above tolerance in most weeks, one terminated after investigation ($4,200 over the period); credit memo indicator produced the finding that one depot issued 31 percent of all credit memos | Deposit lag and shortages handed to depot operations; credit memos retained by internal audit |
| Segregation of duties conflicts and dormant ERP accounts | Monthly | 6 runs; 23 conflicts at month one (the ERP access review’s known population), reduced to 4 accepted and mitigated by month six; 38 dormant accounts disabled | Handed to the application owner; internal audit reviews quarterly |
The six months produced $70,800 recovered or stopped, two findings that an annual audit would have reached a year later, one conflict of interest, one termination, and an accounts payable team that now owns two indicators and asks for a third. The cost was 164 internal audit hours (under the 180 planned) and 52 from finance and IT (over the 40, almost all on the data access and the approval-field extract). The function reported it to the audit committee as a one-page register extract: eight indicators, owners, confirmed issues, value, changes made and the three indicators scheduled for retirement review. The committee’s reaction was to ask the controller, not the chief audit executive, why finance had not built the indicators itself, which is the right question and the sign that the ownership model worked. The one-person shop guide describes the same build for a function with a sixth of MidState’s capacity, where three indicators rather than eight is the realistic number.
The six-month build plan
| Month | Work | Output |
|---|---|---|
| 1 | Select eight candidate indicators against the five tests; agree owners and service levels in writing; submit data access requests; set up the register, the version folder and the run log | Register with eight rows; access requests in progress; owners signed up |
| 2 | Build the first two indicators (the ones with money behind them); run each over twelve months of history; set thresholds from the distribution; completeness-test against control totals; second-person code review | Two indicators in production; historical baseline; first exceptions dispositioned |
| 3 | Build indicators three to five; schedule the jobs; first monthly triage meeting; first tuning of indicators one and two from dispositions | Five indicators running; tuning log started |
| 4 | Build indicators six to eight; add aggregation views (by user, by depot); fix the data gaps the first months exposed (missing approval fields, reference tables) | Eight indicators running; data extract improved |
| 5 | Quarterly tuning across all indicators; compute confirmed-issue rates; prepare the handover packs (logic description, threshold rationale, triage procedure, run log) for the indicators moving to management | Handover packs; retirement candidates identified |
| 6 | Hand over the management-owned indicators with training; define internal audit’s quarterly review of their dispositions; report to the audit committee with the register extract; set the month-twelve review | Program in steady state; committee report; FY plan updated with the rolling engagements the retained indicators support |
Failures that recur
Starting with the platform: a function that buys the tool before it has run one indicator by hand buys a library of rules it does not understand and cannot tune. Too many indicators: forty rules and no triage is the most common shape of a dead program. Thresholds by instinct: silence or noise, never tested against history. No owner: exceptions produced for nobody. Internal audit as permanent triager: the function becomes a control operator, its independence blurs and its capacity is consumed; the handover is the fix. No completeness check: an indicator running on an extract that silently dropped a depot’s transactions produces confident nothing, and the control total catches it. Hard-coded thresholds: a change means editing code, so nobody changes them. No run log: the job’s output cannot be evidence and the committee cannot be told the program ran. Never retiring anything: indicators accumulate until fatigue sets in. And reporting activity rather than results: “eight indicators, 480 exceptions reviewed” tells the committee nothing; “nine duplicates recovered, four back-dated journals found, one conflict of interest, two indicators retired” tells it the program works. The continuous monitoring guide’s maturity model places all of this on the path from a first indicator to a program; this guide’s claim is that a small function can walk the first half of that path with the tools it already owns.
Questions about continuous monitoring for small functions
Can a small internal audit function do continuous monitoring without buying software?
Yes. Five to ten indicators built in Power Query, SQL or Python, scheduled with the operating system or office suite, with thresholds set from history, named owners and a run log, is a working program. The platform becomes worth considering after the first program has shown what it would automate.
How many indicators should we run?
Five to ten, each passing five tests: it addresses a rated risk, the data is reachable and complete, the rule fits one sentence, someone has agreed to act on the exceptions, and the expected volume is manageable. Fewer indicators with every exception dispositioned beat many with a backlog.
How do we set thresholds?
Run the rule over the prior twelve months, look at the distribution, and choose the threshold that produces a triageable volume while catching the known cases. Record the rationale, tune after three months of dispositions, change the rule rather than the threshold where false positives are structural, and sample below the threshold quarterly.
Who should triage the exceptions?
While internal audit proves and tunes an indicator, the function triages and the process owner responds. Once the indicator is stable, indicators that are management’s controls are handed to the process owner, who triages against a service level, and internal audit reviews a sample of dispositions as a test of the monitoring control. Indicators that serve the function’s own assurance stay with the function as continuous auditing.
How do we prevent alert fatigue?
Fewer indicators, thresholds from history, quarterly tuning that turns recurring false positives into rule changes, aggregation by user or location, named ownership, visible closed loops, and a retirement rule for indicators whose confirmed-issue rate stays below a floor for two quarters.
Can the output be used as audit evidence?
Yes, when the indicator internal audit runs meets the analytics evidence standard: documented objective and population, completeness demonstrated per run, logic and version retained, exceptions dispositioned with evidence, limits stated. When management owns the indicator, internal audit’s evidence is its test of the monitoring control: the run log, dispositions within the service level, corrections made and a reperformed sample.
Related guides
- Continuous monitoring: the complete guide — the concepts and the maturity path.
- Continuous auditing: a comprehensive guide — the function’s own rolling assurance.
- Continuous auditing vs continuous monitoring — the ownership distinction.
- Documenting analytics as audit evidence — the standard the output must meet.
- Key risk indicator program — indicators for the second line and the board.
- Accounts payable analytics, journal entry analytics and payroll analytics — the full rule sets.
- ERP segregation of duties analysis — the access indicators.
- Vendor master audit — the data hygiene behind the AP indicators.
- Procurement fraud analytics and fraud red flags — what the indicators watch for.
- SQL for auditors — the queries most rules reduce to.
- Excel and data analysis tricks — Power Query habits.
- Alteryx vs Power Query and Power BI and CaseWare IDEA vs Excel and Power BI — tooling choices.
- Generative AI across the audit lifecycle — having the first draft of the code written for you, with the code gate.
- Testing controls in small populations — what a test supports.
- Auditing account reconciliations — the monitoring control the handed-over indicators resemble.
- When internal audit finds fraud: the first 48 hours — when an exception is more than an exception.
- Tracking internal audit issues — when a disposition becomes a finding.
- Non-financial risk indicators — trend-based indicators for a maturing program.
- Internal audit risk assessment — the rated risks the indicators trace to.
- Board risk reporting — the register extract in the pack.
- Audit software for small teams and the one-person internal audit shop — when to buy, and the three-indicator version.
- Best internal audit software in 2026 — 25 platforms and tools compared by use case, with prices and fit by team size.
Leave a Reply