What are “internal controls” in plain terms
Think of a business as a busy kitchen. Orders flying in. Plates going out. Money moving. Internal controls are the rules and tools that keep that kitchen from:
- Losing food
- Serving raw chicken
- Mixing bills
- Or letting staff walk out with the cash box
They do two big jobs: stop bad things from happening, and catch bad things fast when they do happen. That is it. Everything else is detail.
Name the potential misstatement, the wrong number that could show up.
Prevent it before it happens, or detect it fast after. Often you need both.
Build a control that is effective for this exact risk, and worth its cost.
Check that the control still runs and still fits, so it does not quietly rot.
Name the risk, pick prevent or detect, design it, then watch it. Every internal controls cycle.
Step 1: Spot the potential misstatement
You never start with the control. You start with the risk. In this frame, risk means: “what wrong number could show up in the books, and why?” This is what auditors call the potential misstatement. Some classic flavors:
- Sales recorded at the wrong price
- Stock missing from the warehouse
- Cash that “forgets” to reach the bank
- Fake suppliers paid
- Real expenses left out
The key is to describe the risk as a bad number in the accounts, not just as “bad behavior.”
Weak: “People might steal stuff.”
Strong: “Inventory balance might be overstated because items are stolen and never removed from the records.”
That shift matters. It links straight to assertions, tests, and later, your SOX or ICFR story.
Step 2: Prevent or detect?
Once you name the risk, ask a clean, sharp question: “Do we want to stop this before it happens, or is it fine to catch it after?” That gives you two big buckets.
Prevent controls
These stand at the door and say “no.”
- System rules that block a sale at the wrong price
- Two people needed to approve a payment
- A system that will not let you post a journal without all fields filled
Detect controls
These run after the fact and say “hey, that looks wrong.”
- Daily report of price overrides
- Weekly check of stock records vs physical count
- Review of exception logs from the bank or ERP
Often, you want both: a gate to keep most errors out, and a radar to spot the ones that get through.
Step 3: Design a control that actually works
Now you turn the idea into a real control. It has to be effective and efficient.
Effective means it really addresses the risk. If the risk is “wrong price charged,” a camera over the till is not effective. It might help as proof after the fact, but it does not stop or flag the wrong price. If the risk is “stock theft,” a strong price check is not effective either. You are guarding the wrong door.
Efficient means the cost and pain are worth it. You could put full airport body scanners at every store exit to stop theft. It would reduce theft a lot, and also drive customers insane, slow the line to a crawl, and cost a fortune. On paper: a very strong control. In life: totally dumb.
So you always balance impact of the risk, cost of the control, time friction for staff and customers, and tech complexity. In this step you also pick the type: manual (people do it) or automated (the system does it). Manual gives flex, but people make mistakes and get tired. Automated is fast and consistent, but only as smart as the config.
Step 4: Monitor the control so it does not rot
A control that worked great last year can be useless this year. Process changed. Staff changed. System changed. Risk changed. So you add a layer: monitoring. Plainly, “who checks that this control still runs, and still does what we think?”
Monitoring can look like:
- Daily or weekly review of exception reports
- Sample testing that staff really follow the process
- System alerts when a key control fails or is skipped
- Trend checks: a sudden drop in overrides, is that real or did people find a way around the log?
Two concrete examples from day to day life
Two easy cases, walked through all four steps.
Theft of inventory in a retail shop
Picture a nice store selling fancy notebooks. You run it, and you have one clear fear: people might just walk out with the notebooks, so your stock figure goes wrong and you lose money.
- Potential misstatement: inventory is overstated and cost of goods sold understated because goods are stolen and never removed from records.
- Prevent or detect? You want to prevent theft as much as you can. Catching it only after a stock take is painful.
- Design controls: security cameras to scare off easy theft, RFID stickers on each notebook, RFID gates at the exit, and bag checks for large bags on the way out.
- Monitoring: weekly report of alarms triggered at the gates, matched with staff notes: false alarm, suspected theft, caught person.
This closes the loop: a clear risk, a mix of prevent and detect controls, and a view on whether the controls still bite.
Wrong price charged to customers
Same notebook, different headache. Now your fear is that the price at the till might not match the price you planned, so sales come out wrong.
- Potential misstatement: sales revenue is misstated because customers are charged the wrong price at checkout.
- Prevent or detect? Again, mostly prevent. You do not want to learn at month end that you undercharged a lot of people.
- Design controls: move away from hand-typed prices: barcodes on each product, a scanner at the till, and a price file in the system that drives the scan result. Staff scans, not types.
- Monitoring: any override needs a manager code, an end-of-day report lists every override and refund, and a manager reviews why each one happened.
The main flow is controlled by tech (prevent); the rare price-change cases are watched by a human eye (detect and monitor).
How this links back to audits and assertions
Under the hood, all of this is still about assertions. Each risk lines up with at least one:
- Existence
- Completeness
- Accuracy
- Valuation
- Cut-off
- Rights and obligations
In the stories above, theft of notebooks hits existence and valuation of inventory; wrong price hits accuracy of sales. So when you design a control, a slick way to frame it is:
For SOX, ICFR, or any risk and control matrix, this makes life easy. You can later plug the control into your RCM, build test-of-design and test-of-effectiveness around it, then build your evidence story. We wrote more about what that evidence story actually needs to survive an external audit in our field notes.
Common mistakes when people design controls
- Starting with a control, not a risk: someone says “we should add a review here.” You ask, “for which risk?” Blank face. No risk, no point.
- Controls that sound strong but miss the risk: risk: wrong price. Control: CCTV at the till. Good for staff behavior, bad for pricing errors.
- All manual, no automation: if one person must check ten thousand rows by hand, that is not a control. That is a wish.
- No monitoring: a control gets added once and never checked again. Five years later, the SOP still has a lovely line. No one has done it in three years.
- Cost blind: layers of checks that slow work for a tiny risk, or refusing a simple automated control for a high risk because “we have always done it like this.”
Quick FAQ
{{ f.q }}
+{{ f.a }}
Next step
Next time you sketch a control for a client, a process, or a SOX flow, walk through these four steps on paper, in order:
- Name the potential misstatement
- Decide: prevent, detect, or both
- Design a control that actually hits that risk and is worth its cost
- Add a clear, simple way to monitor it
You are not just adding controls. You are building a quiet little defense system that lets the numbers tell the truth, every month, on time, without drama. If you want a second pair of eyes on how your own controls are designed and automated, that is exactly what we do.