Continuous Audit Monitoring Rules Template: RCM-Based Framework
Published: April 10, 2026 | Last updated: August 27, 2026 | Category: Template | Read Time: 8 minutes | Author: CORAA Team
How to Use This Template
This template helps firms define monitoring rules for continuous audit and internal audit implementation. Use it to design rules that will run in a spreadsheet, BI workflow or audit platform.
The rule is only one part of the working paper. A defensible monitoring file also needs the population, source report, extraction date, completeness check, reviewer conclusion, management response and follow-up status. For the broader methodology, read Continuous Audit Guide India and Internal Audit Automation in India.
Key Points:
- Define rules for high-risk areas (P2P, O2C, R2R, Cash & Bank, statutory compliance, payroll and treasury)
- Keep rules objective (not subjective judgment calls)
- Test rules with 3-6 months historical data before deployment
- Update rules annually or when control changes
- Document rationale for each rule
- Use "configured cadence" unless the source system genuinely supports event-level monitoring; daily, weekly and monthly rules can all be valid
Important limitation: A rule exception is not automatically an audit observation. The internal auditor still reviews the exception, obtains evidence where needed, records a conclusion and reports only validated issues.
Continuous Audit Monitoring Rules Template
═══════════════════════════════════════════════════════════════
CONTINUOUS AUDIT MONITORING RULES (Framework)
═══════════════════════════════════════════════════════════════
CLIENT NAME: [Client name]
IMPLEMENTATION DATE: [Month/Year]
MONITORING PERIOD: Jan 1 - Dec 31, 202X
RESPONSIBLE TEAM: [Audit partner/manager]
═══════════════════════════════════════════════════════════════
SECTION 1: PROCURE-TO-PAY / AUTHORIZATION CONTROLS
Objective: Monitor that transactions are properly authorized
per company policy.
─────────────────────────────────────────────────────────────
RULE 1: PURCHASES >₹50 LAKH REQUIRE CFO APPROVAL
Purpose:
- Control objective: Only authorized purchases processed
- Risk: Unauthorized purchases; fraud; related party abuse
- Source: Company purchase policy
Rule Definition:
- Population: All purchase invoices (GL account: [2100])
- Condition: Amount >₹50,00,000
- Flag if: Authorization field = blank OR Authorization ID missing
- Frequency: Configured cadence — daily where the ERP/export supports it; otherwise weekly or monthly
Expected Volume:
- Historical: ~120 purchases/month
- Expected flags: <3 per month (>₹50L purchases)
False Positive Mitigation:
- Exclude internal purchases (interdepartmental)
- Exclude auto-generated GL entries (system-initiated)
- Exclude items in purchase order queue (may be pending approval)
Exception Handling:
- Escalation: To AP Manager (within 30 minutes)
- Investigation: Confirm authorization status
- Resolution: Obtain retroactive CFO approval or reverse
─────────────────────────────────────────────────────────────
RULE 2: JOURNAL ENTRIES >₹20 LAKH REQUIRE MANAGER APPROVAL
Purpose:
- Control objective: Only authorized manual entries processed
- Risk: Unauthorized/fraudulent journal entries
- Source: Company GL entry policy; R2R RCM; SIA 320/SIA 330 documentation expectations
Rule Definition:
- Population: All manual GL entries (GL entry log)
- Condition: Amount >₹20,00,000
- Flag if: Approver field = blank OR Approval date missing
- Frequency: Configured cadence — daily during close week; otherwise per close-review schedule
Expected Volume:
- Historical: ~5-8 manual entries/month >₹20L
- Expected flags: <2 per month
False Positive Mitigation:
- Exclude standard period-close entries (pre-approved batch)
- Exclude reversing entries
- Exclude system-auto adjustments
Exception Handling:
- Escalation: To GL Manager
- Investigation: Verify business purpose
- Resolution: Obtain approval or reverse entry
─────────────────────────────────────────────────────────────
RULE 3: PAYMENTS >₹100 LAKH REQUIRE CFO + VP APPROVAL
Purpose:
- Control objective: Large payments have dual approval
- Risk: Unauthorized large payments; fraud
- Source: Company payment policy
Rule Definition:
- Population: All cash disbursements (GL account: [5000])
- Condition: Amount >₹1,00,00,000
- Flag if: CFO approval missing OR VP approval missing
- Frequency: Configured cadence — daily for payment-run monitoring where bank/ERP data is available
Expected Volume:
- Historical: ~3-5 payments/month >₹100L
- Expected flags: <2 per month
─────────────────────────────────────────────────────────────
RULE 4: SALES TO RELATED PARTIES FLAGGED
Purpose:
- Control objective: RP sales identified and monitored
- Risk: RP pricing; related party abuse
- Source: Related-party list approved by management; Ind AS 24 where applicable; audit programme/RCM
Rule Definition:
- Population: All sales invoices (GL account: [4000])
- Condition: Customer name contains known RP names (list below)
- Flag automatically: If RP identified
- Frequency: Configured cadence
RP Names to Monitor:
- Ramesh Kumar (Chairman)
- Kumar Associates (Owned by Chairman)
- Priya Desai (Director)
- [Add client-specific RPs]
False Positive Mitigation:
- Exclude legitimate third-party sales to unrelated parties with similar names
- Manual review: Customer name contains "Kumar" but not actual RP
Exception Handling:
- Escalation: To Audit Manager
- Investigation: Confirm RP status; verify pricing
- Resolution: Test for arm's length; document
─────────────────────────────────────────────────────────────
RULE 5: SEGREGATION OF DUTIES - PAYMENT RECORDING & APPROVAL
Purpose:
- Control objective: Prevents one person recording and approving payments
- Risk: Fraud; unauthorized transactions
- Source: Delegation of authority matrix; user access matrix; internal audit RCM
Rule Definition:
- Population: All payments >₹25 lakh
- Flag if: Same user recorded AND approved transaction
- Frequency: Configured cadence
Exception Handling:
- Escalation: To Finance Manager
- Investigation: Confirm user access permissions
- Resolution: Adjust user permissions OR approve retroactively
═══════════════════════════════════════════════════════════════
SECTION 2: REVENUE & CUTOFF CONTROLS
Objective: Detect revenue cutoff errors and suspicious revenue
transactions.
─────────────────────────────────────────────────────────────
RULE 6: REVENUE >10% ABOVE CUSTOMER AVERAGE
Purpose:
- Control objective: Detect unusually large revenue transactions
- Risk: Revenue cutoff; period-end revenue manipulation
- Source: O2C RCM; revenue policy; Ind AS 115 where applicable
Rule Definition:
- Population: All revenue invoices (GL account: [4000])
- Condition: Invoice amount >110% of customer's monthly average
- Calculate average: Sum of customer's prior 12 months ÷ 12
- Flag if: Current invoice >1.1 × monthly average
- Frequency: Configured cadence
Example:
- Customer average: ₹10 lakh/month
- Current invoice: ₹12 lakh (120% of average)
- FLAG TRIGGERED (exceeds 110% threshold)
False Positive Mitigation:
- Exclude new customers (no historical average)
- Exclude seasonal customers (note in control)
- Minimum customer transaction history: 3 months
Exception Handling:
- Escalation: To Sales Manager
- Investigation: Verify legitimacy of large order (valid customer order?)
- Resolution: Document business reason; compare to orders
─────────────────────────────────────────────────────────────
RULE 7: REVENUE RECORDED ON WEEKEND OR AFTER CLOSE
Purpose:
- Control objective: Detect cutoff errors and period-end manipulation
- Risk: Revenue recorded in wrong period; post-period close
- Source: O2C RCM; close calendar; revenue cut-off procedure
Rule Definition:
- Population: All revenue entries posted after close
- Flag if: Entry date = weekend (Saturday/Sunday) OR
Entry date = after official close date (e.g., 11 PM)
- Frequency: Configured cadence
Close Date Definition: [Specify: 5 PM last day of month]
False Positive Mitigation:
- Exclude correcting entries (if expected on close day)
- Exclude known automatic system entries (if close after hours)
Exception Handling:
- Escalation: To Revenue Manager
- Investigation: What business justifies weekend entry?
- Resolution: Determine if cutoff error or legitimate
─────────────────────────────────────────────────────────────
RULE 8: REVENUE WITHOUT SIGNED CONTRACT
Purpose:
- Control objective: Revenue recorded only when contract exists
- Risk: Fictitious revenue; revenue in wrong period
- Source: Ind AS 115
Rule Definition:
- Population: All revenue invoices >₹20 lakh
- Condition: Invoice recorded without linked contract
- Link verification: Contract file attached to GL entry OR
Contract reference documented
- Flag if: No contract documentation
- Frequency: Configured cadence; daily only where invoice and contract data refresh daily
False Positive Mitigation:
- Exclude standard products (if pre-authorized contracts)
- Include process: Contract upload required before GL posting
Exception Handling:
- Escalation: To Revenue Manager
- Investigation: Obtain contract; verify dates
- Resolution: Attach contract; confirm period is correct
═══════════════════════════════════════════════════════════════
SECTION 3: BANK RECONCILIATION CONTROLS
Objective: Monitor bank reconciliation timely completion and
accuracy.
─────────────────────────────────────────────────────────────
RULE 9: BANK RECONCILIATION NOT COMPLETED WITHIN 3 DAYS
Purpose:
- Control objective: Bank reconciliation completed promptly
- Risk: Errors undetected; fraudulent transactions
- Source: Cash & Bank RCM; bank reconciliation policy
Rule Definition:
- Population: Monthly bank reconciliations
- Condition: Reconciliation due by [Day 3 of following month]
- Flag if: Reconciliation still incomplete by [Day 4]
- Frequency: Configured cadence; daily exception check only where BRS status data refreshes daily
Expected Volume:
- Historical: 5 bank accounts = 5 monthly reconciliations
- Expected flags: 0 per month (control should be 100% on-time)
Exception Handling:
- Escalation: To Finance Manager (same day)
- Investigation: Why is reconciliation delayed?
- Resolution: Complete reconciliation within 24 hours
─────────────────────────────────────────────────────────────
RULE 10: BANK RECONCILIATION VARIANCE >₹5,000
Purpose:
- Control objective: Bank reconciliation balances to GL
- Risk: GL errors; missing transactions; fraud
- Source: Cash & Bank RCM; reconciliation procedure
Rule Definition:
- Population: All monthly bank reconciliations
- Condition: Reconciliation variance (GL balance - Bank balance)
- Flag if: |Variance| > ₹5,000
- Frequency: When reconciliation submitted
False Positive Mitigation:
- Exclude timing differences (in-transit checks)
- Define variance calculation: GL ending - Bank ending + Outstanding
(should = 0; flag if not)
Exception Handling:
- Escalation: To Bank Reconciliation Preparer + Manager
- Investigation: Identify outstanding items; locate discrepancy
- Resolution: Resolve discrepancy; update reconciliation
─────────────────────────────────────────────────────────────
RULE 11: CASH PAYMENT WITHOUT BANK DEPOSIT WITHIN 1 DAY
Purpose:
- Control objective: Cash received is deposited timely
- Risk: Cash misappropriation; theft
- Source: Cash & Bank RCM; cash-handling policy
Rule Definition:
- Population: All cash receipts
- Condition: Cash received on [Date 1]
- Flag if: Not deposited to bank by [Date 2 - within 1 day]
- Frequency: Configured cadence
False Positive Mitigation:
- Exclude weekend deposits (deposits on next business day)
- Exclude system latency (deposit recorded 1-2 days after actual)
Exception Handling:
- Escalation: To Finance Manager or cashier owner
- Investigation: Why wasn't cash deposited timely?
- Resolution: Confirm deposit; investigate any delays >2 days
═══════════════════════════════════════════════════════════════
SECTION 4: DUPLICATE & ANOMALY DETECTION
Objective: Detect duplicate transactions and unusual patterns.
─────────────────────────────────────────────────────────────
RULE 12: DUPLICATE PAYMENTS (EXACT MATCH)
Purpose:
- Control objective: Prevent duplicate payments
- Risk: Fraud; accidental double payment
- Source: P2P RCM; payment register; vendor master
Rule Definition:
- Population: All payments
- Flag if: Exact match on (Amount AND Vendor AND Date within 3 days)
- Condition: ₹ amount identical AND
Vendor ID identical AND
Entry date within ±3 days
- Frequency: Configured cadence
Example:
- Payment 1: Vendor ABC, ₹50 lakh, Date 5/1
- Payment 2: Vendor ABC, ₹50 lakh, Date 5/2
- FLAG TRIGGERED (likely duplicate)
False Positive Mitigation:
- Exclude partial payments (amt1 ≠ amt2)
- Exclude different payment methods (if split payment)
- Allow same vendor/amt if dated >5 days apart (likely legitimate)
Exception Handling:
- Escalation: To AP Manager
- Investigation: Confirm if duplicate or legitimate
- Resolution: If duplicate, reverse one; verify only one payment made
─────────────────────────────────────────────────────────────
RULE 13: ROUND NUMBER PAYMENTS
Purpose:
- Control objective: Detect suspicious round number entries
- Risk: Fraudulent entries often use round numbers
- Source: Fraud-risk brainstorming; payment RCM; manual-entry register
Rule Definition:
- Population: All payments >₹1 lakh
- Flag if: Amount is exactly divisible by ₹50,000
(e.g., ₹1,00,000; ₹50,00,000; ₹10,50,000)
- Condition: Amount MOD 50,000 = 0
- Frequency: Configured cadence
False Positive Mitigation:
- This rule generates HIGH false positives
- Many legitimate payments are round numbers
- Auditor investigates only highest-risk flagged items
- Manual entry payments prioritized for investigation
Exception Handling:
- Escalation: Batch review by Audit Manager
- Investigation: Legitimate business reason? Contract amount?
- Resolution: Document legitimacy; no adjustment needed if valid
─────────────────────────────────────────────────────────────
RULE 14: ENTRIES BY USER AT UNUSUAL TIMES (2-6 AM)
Purpose:
- Control objective: Detect entries recorded outside business hours
- Risk: Fraud; unauthorized access
- Source: Fraud-risk brainstorming; user access log; manual-entry register
Rule Definition:
- Population: All GL entries & payments
- Flag if: Entry timestamp between 2:00 AM - 6:00 AM
- Frequency: Configured cadence
False Positive Mitigation:
- Exclude automated system entries (auto-accruals, period close)
- Exclude entries by Finance Manager (known to work late)
- Include manual entries only
Exception Handling:
- Escalation: To GL Manager
- Investigation: Is user authorized? Was entry authorized?
- Resolution: If unauthorized, escalate to Finance Director
═══════════════════════════════════════════════════════════════
SECTION 5: RELATED PARTY & SPECIAL TRANSACTION CONTROLS
Objective: Monitor related party transactions and identify
special/unusual items.
─────────────────────────────────────────────────────────────
RULE 15: TRANSACTIONS INVOLVING KNOWN RELATED PARTIES
Purpose:
- Control objective: All RP transactions identified
- Risk: Arm's length not verified; disclosure missed
- Source: Related-party list approved by management; Ind AS 24 where applicable; audit programme/RCM
Rule Definition:
- Population: All transactions (sales, purchases, payments, receipts)
- Flag if: Vendor/Customer name = known RP name (list below)
- OR Recipient bank account matches RP account
- Frequency: Configured cadence
Known RP Vendors:
- Ramesh Kumar (Chairman)
- Kumar Associates (Owned by Chairman)
- Priya Desai (Director)
- [Add client-specific RPs]
Known RP Customers:
- [As applicable]
Exception Handling:
- Escalation: To Audit Manager
- Investigation: Confirm RP status; verify terms
- Resolution: Test for arm's length; add to RP disclosure
─────────────────────────────────────────────────────────────
RULE 16: CREDIT MEMOS >10% OF RELATED INVOICE
Purpose:
- Control objective: Detect suspicious credit reversals
- Risk: Fictitious sales followed by reversal; fraud
- Source: O2C RCM; credit note approval policy; fraud-risk brainstorming
Rule Definition:
- Population: All credit memos
- Flag if: Credit memo >10% of original invoice amount
- Condition: Credit memo matched to original invoice
Credit amount > (0.1 × original invoice amount)
- Frequency: Configured cadence
Example:
- Original invoice: ₹100 lakh
- Credit memo: ₹12 lakh (12% reversal)
- FLAG TRIGGERED (exceeds 10% threshold)
False Positive Mitigation:
- Legitimate returns can be large
- Auditor investigates: Was product actually returned?
Exception Handling:
- Escalation: To Sales Manager
- Investigation: Verify return authorization; inspect goods
- Resolution: Confirm legitimacy; document reason
═══════════════════════════════════════════════════════════════
SECTION 6: RULE DEPLOYMENT & MONITORING
─────────────────────────────────────────────────────────────
6.1 TESTING BEFORE DEPLOYMENT
Before implementing rules in production:
Historical Data Test:
- Period: [Previous 3-6 months of GL data]
- Results:
- Rule 1 (CFO approval): Expected X flags; Actual: Y flags
- Rule 2 (Manager approval): Expected X flags; Actual: Y flags
- [Continue for all rules]
False Positive Assessment:
- Rule 1: Y% false positive rate (acceptable? Y/N)
- Rule 2: Y% false positive rate
- [Continue]
Adjustment if Needed:
- Rule thresholds adjusted? ☐ Yes ☐ No
- Rule logic modified? ☐ Yes ☐ No
- Ready for production? ☐ Yes ☐ No
─────────────────────────────────────────────────────────────
6.2 MONTHLY MONITORING RESULTS
Month: [Month/Year]
Rule 1 (CFO Approval):
- Transactions monitored: [Number]
- Flags: [Number] ([%])
- Issues resolved: [Number]
- Status: ☐ On track ☐ Needs review
Rule 2 (Manager Approval):
[Repeat format]
[Continue for all rules...]
Summary Metrics:
- Total transactions monitored: [Number]
- Total flags: [Number] ([%])
- Critical flags: [Number]
- Management response time: [Avg. hours]
─────────────────────────────────────────────────────────────
6.3 ANNUAL RULE REVIEW
Rule Review Performed? ☐ Yes ☐ No
Date: ______________
Changes Made:
- Rule 1: ☐ No change ☐ Threshold adjusted to __________ ☐ Removed
- Rule 2: ☐ No change ☐ [Change description] ☐ Removed
- New Rule Added: [Description]
Reason for Changes:
- Business change: [Describe]
- Control change: [Describe]
- Volume change: [Describe]
═══════════════════════════════════════════════════════════════
MONITORING DASHBOARD
Sample Dashboard (Monthly):
Rule Performance Summary:
┌─────────────────────────────────────────────────────┐
│ Rule | Flags | Resolved | Status │
├─────────────────────────────────────────────────────┤
│ CFO Approval | 1 | 1 | ✓ OK │
│ Manager Approval | 0 | 0 | ✓ OK │
│ RP Transactions | 2 | 2 | ✓ OK │
│ Bank Reconciliation | 0 | 0 | ✓ OK │
│ Duplicate Payments | 0 | 0 | ✓ OK │
│ Round Numbers | 5 | 5 | ⚠ Review │
│ Unusual Times | 0 | 0 | ✓ OK │
└─────────────────────────────────────────────────────┘
Trend Analysis:
- Flags trending up/down? [Describe]
- New patterns emerging? [Describe]
- Process improvements needed? [List]
═══════════════════════════════════════════════════════════════
END OF MONITORING RULES TEMPLATE
Key Implementation Tips
-
Start Simple: Define 5-7 high-impact rules first; expand over time.
-
Test Before Deployment: Apply rules to 3-6 months historical data to assess false positive rate.
-
Document Rationale: Each rule should link to a control objective or audit risk.
-
Set Thresholds Carefully: Too low → excessive false positives; Too high → miss real issues.
-
Automation > Manual: Let system flag; let auditor investigate (not vice versa).
-
Escalation is Critical: Define who gets notified; how fast; what's expected action.
-
Review Monthly: Track metrics; adjust rules based on experience.
Related Resources
- Continuous Audit Guide India
- Internal Audit Automation in India
- Continuous Monitoring Internal Audit Procedures in India
- Internal Audit Continuous Monitoring Rules Repository
- Internal Audit Monitoring Rules Generator
- Internal Audit RCM Builder
- Internal Audit ATR Tracker
Frequently Asked Questions
What is a continuous audit monitoring rules template?
A continuous audit monitoring rules template is a structured format for defining recurring audit tests. Each rule should capture the population, source report, risk, control objective, rule logic, threshold, cadence, exception owner, false-positive handling, reviewer conclusion and reporting route.
How many monitoring rules should an internal audit team start with?
Start with 5-10 rules across the highest-risk cycles, not 100 rules at once. A small rule set lets the team validate source data, false positives, ownership and reporting discipline before scaling. Duplicate payments, stale BRS items, post-close journals, overdue statutory dues and vendor master changes are common starting points.
Should every monitoring exception become an audit observation?
No. A monitoring exception is only a signal. The auditor should verify the source data, obtain explanations or evidence, assess root cause and decide whether the matter is cleared, parked for trend monitoring, escalated, or converted into an audit observation with management response and ATR follow-up.
What fields should every monitoring rule include?
Every rule should include rule name, audit cycle, risk, control objective, population, source system, extraction date, rule logic, threshold, cadence, exception owner, reviewer, false-positive exclusions, evidence required, conclusion status and report/ATR reference. Those fields make the rule repeatable and reviewable.
Can monitoring rules be built in Excel?
Yes. Monitoring rules can start in Excel or Power Query if the source reports are stable and the formulas are protected, reviewed and retained. As rule volume, frequency and exception ownership increase, a workflow or audit platform becomes more useful because it preserves owners, review trails, dashboards and closure evidence.
How do monitoring rules connect to an RCM?
Each monitoring rule should trace back to a risk and control in the RCM. The RCM explains why the rule exists; the rule tests whether the control is operating as expected; the exception list and reviewer conclusion provide the evidence. Rules that cannot be mapped to a risk often become noisy dashboard metrics.
About CORAA
CORAA helps Indian audit and assurance teams design RCM-backed monitoring rules, run cycle-wise exception review and preserve the documentation trail behind management reporting.
Learn more: Visit our website
Sources
- ICAI Internal Audit Standards Board, Compendium of Standards on Internal Audit - as on February 2026 and listed by ICAI as applicable from 1 April 2026
- ICAI Internal Audit Standards Board, Standards on Internal Audit publications
- Continuous Audit Guide India
Topics
continuous audit monitoring rules templateinternal audit monitoring rulescontinuous monitoring internal auditRCM monitoring rulesaudit automation