Internal Controls Over Financial Reporting: A Practical Framework

5/22/2026

Most of the entities that genuinely need internal control over financial reporting are not required to have it.

A private company, a family business, or a nonprofit has no filing obligation compelling a control framework — and every practical reason to want one. The owner is making decisions on those numbers. A lender is lending on them. And the fraud exposure is highest precisely where controls are weakest, which at a small entity is nearly everywhere.

Our post on the SOX compliance checklist covers what public companies are required to do. This post is about designing controls for everyone else — and specifically about the part nobody teaches, which is how to write a control that actually works.

The Five Components, and the Two Nobody Has

An integrated control framework has five components, and describing them functionally is more useful than naming them:

Control environment. Whether the people who run the entity behave as though controls matter, and whether anyone would be held accountable for circumventing one.

Risk assessment. Identifying what could go wrong in the financial statements, so that controls can address it.

Control activities. The controls themselves.

Information and communication. Whether the right information reaches the right people in time, and whether staff know what is expected.

Monitoring. Whether anyone checks that the controls are still operating.

Here is the diagnosis for almost every small entity: they have control activities and nothing else. There is no risk assessment, so the controls that exist are the ones somebody once thought of rather than the ones the risks require. And there is no monitoring, so controls degrade silently — the reconciliation that stopped being reviewed, the approval that became a rubber stamp, the report that no longer generates.

Adding those two components is usually a bigger improvement than adding controls.

Start From What Could Go Wrong

The step that makes a control set proportionate rather than arbitrary.

Work account by account, through the assertions. For each significant account, ask what could be materially wrong: does the balance exist, is it complete, is it accurate, is it valued appropriately, is it recorded in the right period, and is it presented and disclosed properly?

For receivables, the risks are fictitious sales, unrecorded credits, uncollectible balances carried at full value, and revenue recorded in the wrong period. For payables, the risks are unrecorded liabilities, payments to fictitious vendors, and duplicate payments. Each of those is a specific thing to control against.

Two rules make this practical at a small entity:

Materiality scopes it. An account that could not contain a material misstatement does not need a designed control. Small entities exhaust themselves controlling immaterial things.

Cash and revenue always matter, at every entity, regardless of size — because they are where both the largest errors and virtually all the fraud live.

How to Design a Control

The most useful section here, because most control documentation is a description of work rather than a control.

A control has six elements:

The risk it addresses, stated specifically. Not "ensure accuracy" but "detect payments to vendors not authorized by an approved requisition."

A named performer. A role, held by a person, not "management" or "accounting."

A defined frequency. Daily, with each transaction, monthly, quarterly.

A stated action. What the person actually does — compares, recalculates, inspects, matches, approves, investigates.

A criterion. What constitutes an exception, and at what threshold. A review control with no threshold cannot be performed consistently or tested.

Evidence. Something that shows it happened — a signature, a system approval, a tick-marked report, an email, a completed checklist.

The test that separates a control from a procedure: ask "what happens if you find something?" If there is no defined response, it is not a control. "The controller reviews the aging" is a procedure. "The controller reviews the aging monthly, investigates any balance over ninety days exceeding a stated amount, documents the collection status, and initiates the reserve adjustment" is a control.

Two further design distinctions:

Preventive versus detective. Preventive controls stop the error — an approval before payment, a system edit rejecting an invalid entry. Detective controls find it afterward — a reconciliation, a variance review. You need both: preventive controls are cheaper and detective controls catch what prevention missed, including deliberate circumvention.

Manual versus automated. Prefer automated where the system can enforce it, because an automated control operates consistently and is far cheaper to verify. A required field, a three-way match enforced by the system, a posting restriction, and an approval workflow all beat their manual equivalents.

Control Versus Process

A distinction that prevents most documentation bloat.

A process is how work gets done — the invoice arrives, is coded, entered, approved, and paid.

A control is a step specifically designed to prevent or detect a misstatement.

Documenting a process is useful for understanding. Documenting every step of a process as a control produces a matrix nobody maintains, and it buries the six controls that matter among sixty that do not. When documenting, identify the process and then mark which steps are the controls.

The Ten Controls That Matter Most at a Small Entity

Ranked roughly by error and fraud prevention per unit of effort. If a client implements only these, they have most of the available benefit.

1. The bank statement received unopened and reviewed by someone outside accounting — the owner, a board member, or a family member not involved in bookkeeping. Reviewing the actual statement and the cleared check images. This single control detects more small-entity fraud than any other, because most schemes eventually pass through the bank account.
2. Separation of cash receipt from recording. Whoever opens the mail or takes payment should not be the person who records it and reconciles the account. Where staffing prevents it, a daily deposit log compared to the deposit by a second person.
3. Vendor master change control. Adding a vendor or changing a vendor's bank details requires independent verification through a known contact and a second approval. This is the single most exploited fraud vector in accounts payable, and the control is nearly free.
4. Payment authorization with support attached, above a threshold, by someone who did not prepare it — and who sees the invoice rather than a payment list.
5. Bank and credit card reconciliations prepared monthly and independently reviewed, with the reviewer examining the outstanding items rather than initialing the summary.
6. Payroll change authorization and register review. New hires, rate changes, and direct deposit changes authorized outside payroll; the register reviewed by someone who knows who works there.
7. Journal entry review, focused on manual entries, entries after the close, and entries by anyone who does not normally post.
8. Physical controls over inventory, equipment, and cash, with periodic counts compared to records by someone independent of custody.
9. Monthly financial statement review by the owner against an expectation. Not reading the statements — comparing them to what the owner expected, with variances explained. An owner who knows their business will spot things no control catches.
10. System access control, including who can post entries, who can change master data, who can process payments, and removal of access on departure. Small entities routinely leave former employees with active access for months.

The Segregation Problem, Honestly

A four-person accounting department cannot segregate duties properly. Advising it to do so is not useful.

What is useful is the owner-review model: the owner or a governing body member performs specific, evidenced review procedures that compensate for the segregation that cannot exist. Controls one, four, five, six, and nine above are exactly that model, and they work because they are performed by someone with no ability to commit or conceal the error.

Two requirements make it real. It must be scheduled, because an owner who reviews "when they have time" reviews during quiet periods and not during the ones when something is happening. And it must be evidenced — a date and initials on the statement — because an unevidenced review cannot be relied upon by an auditor, a lender, or an insurer.

Monitoring: The Component Everyone Omits

Controls decay. The person who performed a reconciliation leaves and the task passes to someone who was never told it was a control. A system upgrade removes an edit. A report stops generating and nobody notices because nobody was looking at it.

Monitoring at a small entity does not require an internal audit function. It requires:

A periodic self-assessment — annually is adequate for most small entities — walking each significant process and confirming the documented controls are actually being performed, by the named person, at the stated frequency, with evidence.

Exception reporting reviewed by someone, rather than produced and filed.

Attention after any change — a system conversion, a departure, a new product, a new location. Change is where controls break silently, and a change without a control impact assessment is where the next surprise comes from.

Someone accountable for the control framework's continued operation, named.

Structured coverage is available through the internal auditing training courses catalog, the audit training courses listing, the Certificate in Forensic Accounting, Fraud Examination, and the fraud and forensic accounting training catalog.

Documentation Proportionate to the Entity

For a small entity this is ten to twenty pages, not a binder:

• A short narrative or flowchart for each significant process, with the control steps identified
• A risk and control matrix — the risk, the control addressing it, who performs it, how often, and what evidences it
• The evidence standard for each control, so the performer knows what to leave behind
• A statement of who owns the framework and when it is reassessed

That is genuinely sufficient, and it is far more useful than an extensive document nobody updates.

Fraud Is the Reason This Matters at a Small Entity

Small organizations suffer disproportionate fraud losses relative to their size, and the reason is structural: fewer people, less segregation, more trust, and rarely an internal audit function.

The scheme categories the controls above address:

Billing schemes — a fictitious vendor, or an inflated invoice from a real one. Addressed by vendor master controls, authorization with support, and the bank statement review.

Check tampering and payment fraud, including altered payees and changed bank details. Addressed by controls one and three.

Payroll schemes — a ghost employee, an inflated rate, unauthorized overtime. Addressed by control six.

Expense reimbursement — fictitious, inflated, or duplicated claims. Addressed by review against receipts and by analytics on patterns.

Skimming — receipts taken before recording, which is the hardest to detect because there is no record of the missing item. Addressed by separating receipt from recording, by comparing deposits to independent records, and by margin analysis.

Financial statement fraud, which is rarer at small entities and more damaging, addressed by journal entry review and owner review against expectation.

The behavioral indicators worth mentioning to a client: an employee who never takes vacation or resists anyone covering their duties, resistance to a new control, lifestyle changes inconsistent with compensation, and an unusually close relationship with a particular vendor.

The Practitioner's Role and Its Limit

An accountant can add substantial value here — assessing the control environment, identifying the gaps, recommending the controls, and helping the client understand what they are exposed to.

With one limit worth naming. Where the firm also performs an audit, review, or other attest engagement for that client, designing and implementing the client's internal controls can impair independence — it can amount to performing a management function or designing a system the firm will later audit. Recommending is not the same as implementing, and where a client asks the engagement team to build what it recommended, that request needs an independence analysis before anyone agrees.

For a non-attest client, no such constraint applies, and control design is genuinely valuable advisory work.

Where This Goes Wrong

• Control activities with no risk assessment, so the controls address what someone thought of rather than what the risks are
• No monitoring, so controls decay unnoticed
• Documenting the process as though every step were a control, burying the ones that matter
• Controls with no defined exception threshold or response
• Review controls with no evidence, which cannot be relied upon by anyone
• Owner review that is unscheduled, and therefore happens in quiet periods
• Bank statements opened by the bookkeeper
• Vendor bank detail changes with no independent verification
• Access not removed when people leave
• No control impact assessment after a system change or a departure
• A firm designing and implementing controls for an attest client without an independence analysis

The organizing idea: internal control at a small entity is not a compliance exercise, it is a small number of specific things a person outside the accounting function does on a schedule and signs. Ten controls, documented in twenty pages, monitored once a year — that is a real framework, and it prevents most of what actually goes wrong.

Frequently Asked Questions

Do private companies and nonprofits need internal control over financial reporting?

No rule compels most of them, and they have every practical reason to want it: the owner makes decisions on those numbers, lenders lend on them, and fraud exposure is highest where controls are weakest. Small organizations suffer disproportionate fraud losses relative to their size for exactly that reason.

Which framework components do small entities usually lack?

Risk assessment and monitoring. Most have control activities and nothing else, which means the controls in place are the ones somebody once thought of rather than the ones the risks require, and they decay silently because nobody checks whether they still operate. Adding those two components usually beats adding more controls.

What makes something a control rather than a procedure?

A defined response when something is found. A control specifies the risk it addresses, a named performer, a frequency, the action taken, the criterion or threshold that constitutes an exception, and the evidence left behind. "The controller reviews the aging" is a procedure; the same sentence with a threshold, an investigation step, and a signature is a control.

What is the single highest-value control at a small entity?

The bank statement received unopened and reviewed by someone outside accounting — the owner or a board member — examining the statement and cleared check images. Most small-entity fraud eventually passes through the bank account, which makes this control the one that detects more of it than any other, at almost no cost.

How should segregation of duties be handled when the department is too small?

Through an owner-review model: specific, scheduled, evidenced review procedures performed by someone with no ability to commit or conceal the error — unopened bank statements, payment authorization with support, reconciliation review, payroll register review, and monthly statements compared against expectation. It must be scheduled and initialed, since an unevidenced review cannot be relied upon.

Can a firm design its audit client's internal controls?

Not without an independence analysis. Designing and implementing a client's controls can amount to performing a management function or building a system the firm will later audit, which may impair independence for an attest engagement. Recommending controls is different from implementing them, and a client's request that the engagement team build what it recommended needs to be evaluated before anyone agrees.