Internal controls
Start with the objective and the failure that could prevent it. Choose a control that addresses that risk, give it an owner, retain evidence that it operated, and test exceptions. A written policy alone does not demonstrate an effective control.
A control needs a risk, an owner and evidence
- Prevent
- Block or authorize a transaction before the loss occurs.
- Detect
- Reconcile or review exceptions to identify a failure.
- Verify
- Inspect evidence and test that the control actually operates.
Separate authorization, custody and recording where practical; design compensating review when duties cannot be fully separated.
See the decision
Close the duplicate-payment gap
Accounts payable can enter a new vendor, record an invoice and release payment. A duplicate invoice was paid because its number was entered with an extra space.
- 01
Create vendor
Independent approval
- 02
Enter invoice
Normalize and check duplicates
- 03
Release payment
Separate authorization and review
Use a combination of preventive checks and independent detection. Documented execution supports the conclusion; the policy alone does not.
How to apply these ideas
1. Risk and assertion
Describe what could go wrong in a specific process.
For payments, distinguish an unauthorized vendor, a duplicate invoice and an incorrect amount. Each failure needs different evidence. A broad statement such as “reduce fraud” is too vague to select or test a control.
Watch for: Naming a control before identifying the failure it should prevent.
2. Prevention and detection
Stop errors where possible and detect remaining exceptions promptly.
Approval before vendor creation is preventive; a duplicate-payment exception report is detective. Both need a responsible person, a frequency and an action on failure. Segregation can reduce risk but collusion and override remain possible.
Watch for: Claiming controls guarantee that fraud cannot occur.
3. Design and operation
Test whether the control could work and whether it actually did.
Inspect the approval design and then evidence from the relevant period. A screenshot of a policy proves neither execution nor follow-up. Review exceptions and determine whether the control performed at a useful level of precision.
Watch for: Using one policy document as proof of operating effectiveness.
4. Remediation
Correct the cause, assign ownership and retest.
Record the deficiency, interim response, accountable owner and completion date. Verify the changed control with fresh transactions. Closing a ticket without evidence can hide a recurring failure rather than restore assurance.
Watch for: Treating a planned fix as an implemented and tested fix.
Study the topic
Internal controls: explanations and applications
Design controls around a business objective, test whether they operate and respond to exceptions. The framework application lesson develops one end-to-end process example.
By MiloPrep editorial team. Original teaching explanations and illustrative cases; official curriculum references are listed below.
Start with a specific failure that threatens an objective
An objective such as accurate supplier payments is more useful than a vague instruction to strengthen controls. Identify the failure: a duplicate invoice, a fictitious supplier, an incorrect bank-account change or payment without receipt of goods. Each failure needs a control that addresses its cause or detects its consequence in time to act.
Preventive controls act before an event, detective controls identify an event or exception, and corrective actions restore the process or remediate the cause. These roles can complement one another. A payment block may prevent an exact duplicate but miss slightly altered invoice numbers, so a detective review remains useful. State the residual risk after the controls, rather than implying zero risk.
| Risk | Control design | Evidence to inspect |
|---|---|---|
| Unauthorized supplier change | Independent callback using a trusted contact | Reviewer identity, callback record and approved change |
| Invoice paid twice | Duplicate matching plus exception review | Blocked items and resolved exceptions |
| Payment without receipt | Match order, receipt and invoice | Match result and authorized exception |
| Concealed payment error | Independent bank reconciliation | Timely review and cleared reconciling items |
Connect the control environment to the transaction
The control environment includes oversight, ethical expectations, accountability and competence. Risk assessment identifies threats as conditions change. Control activities implement responses. Information and communication provide usable evidence to the people responsible. Monitoring checks whether the system continues to work. A policy document is one input, not proof that these elements operate together.
Management owns the design and operation of internal control. Internal audit can provide independent assurance and advice but should not become the process owner for activities it will later assess. External audit has its own objectives and procedures; its existence does not transfer management’s responsibility or guarantee every fraud will be detected.
Separate incompatible duties or add a compensating review
Authorization, asset custody and recordkeeping create conflicts when concentrated in one person. Someone who can create suppliers, approve invoices and release payments may be able to initiate and conceal a fictitious payment. Restrict access according to duties and review changes as employees move or leave.
Small teams may be unable to separate every task. A compensating control must be specific enough to detect the risk, such as an owner independently reviewing bank activity against approved supplier records. A signature on a summary without supporting detail may provide little assurance. Consider reviewer knowledge, independence, frequency and authority to investigate.
Distinguish general IT controls from application controls
General IT controls support the environment: user access, privileged accounts, system changes, operations and recovery. Application controls address the completeness, validity and accuracy of a particular transaction or calculation. A well-designed invoice edit can still be unreliable if an administrator can change its rule without approval or alter the underlying records.
Input checks can validate required fields, acceptable ranges and authorized master data. Processing checks can reconcile batch totals and flag exceptions. Output controls can restrict sensitive reports and confirm distribution to the proper reviewer. Follow data from entry to report and identify where a transaction could be omitted, duplicated, changed or disclosed.
Test design, operation and remediation separately
A walkthrough asks whether the control, if performed as described, could address the risk. Operating-effectiveness work asks whether it actually ran consistently over the relevant period. Inquiry alone is weaker evidence than inspecting records, observing performance or reperformance. Define the population and select evidence appropriate to the risk; one clean example does not establish reliable operation for the year.
When an exception appears, assess its cause, frequency, financial exposure and whether other controls detect it. Correcting the individual transaction is different from fixing the process. Assign a remediation owner and date, preserve evidence of the change and retest it. Escalate deficiencies according to the applicable reporting framework and governance process rather than inventing a severity classification from one fact.
Treat continuity as a tested operating capability
A backup copies data; a recovery plan explains how systems and work resume; a continuity plan addresses critical business operations during disruption. Define acceptable downtime and acceptable data loss for the process. A successful backup job does not prove that the data can be restored within those objectives.
Test recovery with realistic dependencies such as network access, identity services, supplier interfaces and key staff availability. Protect copies from the same failure that affects the primary system. Record the results, reconcile restored data and resolve failed steps. Financial reporting depends on recovery quality as well as normal processing accuracy.
Work it through
Worked example: Close the duplicate-payment gap
Accounts payable can enter a new vendor, record an invoice and release payment. A duplicate invoice was paid because its number was entered with an extra space.
| Risk | Control response | Evidence |
|---|---|---|
| Fictitious vendor | Independent vendor approval | Approval and verified vendor record |
| Duplicate invoice | Normalize identifiers; block duplicates | Rejected duplicate log |
| Override or missed match | Independent exception review | Review sign-off and resolution |
- 1
Separate vendor approval from payment release and normalize invoice identifiers before matching.
- 2
Test a duplicate with whitespace and inspect the exception review. Test approved exceptions as well as blocked transactions.
Use a combination of preventive checks and independent detection. Documented execution supports the conclusion; the policy alone does not.
Work through the alternatives
More worked cases: internal controls
Original teaching scenarios. Each case states its assumptions, shows the working and explains the limits of the conclusion.
An access review that finds a real conflict
A clerk can edit supplier bank details and release payments. A supervisor approves invoice amounts but never sees bank-detail changes. No additional review is assumed.
| Observation | Why it matters | Control response |
|---|---|---|
| Bank-detail access plus payment release | Can redirect an otherwise approved invoice | Separate change approval from release |
| Approval checks amount only | Does not detect a changed beneficiary | Show beneficiary changes to an independent reviewer |
| No evidence of callback | Cannot substantiate independent verification | Document verification using an established contact |
- Map the authority the clerk holds across the whole payment process, not just the invoice screen.
- Remove incompatible access or require an independent, evidenced review before release. Test a sample of changes and trace them through the payment file.
What the result means: The current approval is incomplete because it addresses invoice amount without addressing the destination of the funds.
A successful backup can still fail the business requirement
The business requires recovery within four hours and loss of at most one hour of transactions. A daily midnight backup restores successfully in three hours after a failure at noon. Assume no transaction-log recovery.
| Requirement | Observed outcome | Assessment |
|---|---|---|
| Recovery time | Three hours versus four-hour limit | Within the time objective |
| Recoverable data age | Twelve hours versus one-hour limit | Exceeds acceptable loss |
| Next design question | More frequent recovery points and dependencies | Test the revised end-to-end recovery |
- Separate downtime from lost data. Restoring fast does not make the midnight copy current.
- Assess a recovery design capable of restoring transactions within the one-hour loss limit, and test it with the required applications and reconciliations.
What the result means: The restore test passes one objective and fails the other. Reporting only “backup successful” conceals the gap.
Practice this topic
Check your understanding
Try each short application before opening its explanation. These are original learning checks, not official exam questions or a score prediction.
1. A policy requires monthly reconciliations, but there is no evidence for three months. What can you conclude?
Show answer and explanation
The policy alone does not demonstrate operation during those months.
Investigate whether reconciliations occurred, whether evidence was retained and whether an alternative control operated. Do not equate missing evidence automatically with a quantified misstatement.
2. A system rejects invoices without a valid supplier ID. Is this preventive or detective for unauthorized supplier references?
Show answer and explanation
Preventive at input.
It blocks that specific input condition. It does not establish that every valid supplier ID represents a legitimate supplier.
3. Can the person creating a payment file provide the only review of whether its beneficiaries were altered?
Show answer and explanation
That is not an independent review of the risk.
Use a reviewer with appropriate access to reliable source records and no conflicting responsibility for the change being checked.
Questions about internal controls
- What if a small team cannot fully segregate duties?
- Use a documented compensating control, such as an independent owner reviewing bank activity and supporting evidence promptly. Assess whether the reviewer can detect the relevant error with sufficient precision.
- Can automation replace control ownership?
- No. Automated rules still need controlled changes, access restrictions, monitoring and a person responsible for exceptions.
Sources and scope
Curriculum mapping: Part 1, Section E, Internal Controls. The official outline assigns 15% to the entire domain, not to this individual technique. These are selected study notes, not complete curriculum coverage.
Official curriculum references establish scope and expected skills. The explanations, diagrams and numerical cases are independent teaching material from MiloPrep, not official questions or source-validated solutions. Curriculum references checked 2026-10-10.
- IMA Content Specification Outlines (effective September 2024) ↗
Supports: Part 1, Section E, beginning on printed page 8. Domain names, weights and curriculum boundaries.
- IMA Learning Outcome Statements (effective September 2024) ↗
Supports: Part 1, Section E, beginning on printed page 12. The calculations, analysis and professional judgments candidates are expected to perform.
Independent US CMA study material. Not affiliated with or endorsed by IMA. This covers management accounting, not medical-assistant certification or the separate ICMAI qualification.