Internal controls in accounting are the policies and procedures a business uses to support reliable records, authorised transactions and the protection of its assets. Useful controls have a defined purpose, an owner and evidence that they operated.
Automation can make a control more consistent and extend the transactions it checks. It also creates new questions about permissions, configuration and the completeness of the information the control receives.
Which risks should the control address?
Start with a specific failure. A supplier could receive payment twice. Someone could change bank details without independent verification. A journal could enter the wrong period, or a former employee could retain access.
Define the control around that risk. Record who performs it, when it runs, what evidence it uses and what happens when it finds a problem. “Finance reviews payments” leaves too much room for different interpretations.
For an automated workflow, document the rule and the exception path. The accounting workflow guide shows how to make those decisions visible in the process.
What does segregation of duties mean in practice?
Separate incompatible responsibilities where the team can do so. Creating a supplier, changing its bank details, approving an invoice and releasing payment should not become one unrestricted permission by default.
Small teams may need compensating review where full separation is impractical. Make that review explicit and retain evidence of it. Revisit access when someone changes role or leaves, including service accounts and agents.
An automated action still needs an accountable owner. The AI agents for finance guide explains how to distinguish read access, preparation and authority to act.
What evidence should a control leave?
Keep the relevant input, action, result and review record. For an approval, that means more than the approver's name: a reviewer needs to know what they approved and whether the transaction changed afterwards.
For automated checks, retain the rule or configuration version, the population covered, failed runs and unresolved exceptions. A successful job log does not prove that every required transaction reached the job.
If a threshold changes, document the reason, approver and testing. A system can apply the wrong rule consistently, so configuration deserves review alongside individual outputs.
How do you test an approval and its exceptions?
Consider an illustrative policy: a €12,000 supplier bill needs a reviewer other than its creator, and a bank-detail change needs independent verification before payment. These are example requirements for a demonstration, not Light's default thresholds.
- Record the invoice, entity, service period and proposed accounting treatment. If finance treats the annual service as a prepaid cost, retain that decision and its schedule.
- Route the bill to an eligible reviewer. Attempt self-approval and record whether the workflow blocks it.
- Change the supplier's bank details after approval. Check that the person releasing payment sees the change and that the required verification has occurred.
- Attempt to post an adjustment into a locked period. Record who can unlock or correct it and the evidence of that decision.
- Ask a second reviewer to reconstruct the transaction from the source document, approvals, changes and postings.
For an AI action, include the agent's identity, permission and proposed change in the same review. A readable explanation must agree with the underlying record. Use Light's approval workflow guide, period controls and Trust Center to examine workflow configuration, accounting restrictions and security evidence separately.
Does checking every transaction remove the need for audit sampling?
No. Full-population analysis can provide useful evidence, but its value depends on the data, the procedure and the risk under examination. It does not answer every audit question or automatically reduce the auditor's scope.
Audit sampling remains an established method. The PCAOB's AS 2315 standard addresses its use in an audit. The applicable standards and the auditor's assessment determine the procedures for a particular engagement.
Keep the distinction between management's controls and the independent auditor's work clear. Software can support evidence collection without determining the audit conclusion.
How can Light support the control process?
Light's accounting workflows describe approval routing, segregation of duties and an audit trail. Its bill payment product connects controls with the supplier transaction.
Ask the product team to show a rejected action, a changed approval rule and an exception that needs human review. Test whether the record lets someone outside the original process understand what happened.
Review controls periodically and after significant process changes. The goal is evidence that the control addresses its intended risk, rather than a long list of controls that nobody can explain or operate.
For programme-based businesses moving from development to production, see how accounting software for defence and robotics companies connects cost dimensions, supplier approvals and the accounting record.
