Testing segregation of duties from transaction data
Using the user and approval fields in a client's journal extract to find entries one person both created and approved, and what to do with the results.
By Achekam · · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
Ask a finance manager whether journals are approved by someone other than the person who prepares them and the answer is nearly always yes. A walkthrough of one or two entries usually agrees. What neither the interview nor the walkthrough tells you is whether that held for every entry, all year, including the ones posted late on the last day of the month by the only person who knew the password.
Most accounting systems record who did what. Every journal carries a user name for whoever created it and, where the system has an approval step, for whoever approved or posted it, usually with a date and time. That trail turns segregation of duties from something you are told into something you can test across the whole population. This article covers how to run segregation of duties testing on that metadata, what to watch for when mapping the fields, and how to report what you find.
The principle behind the test
AccountingTools puts the rule simply: no single person should control the authorisation, the recording and the custody of assets for the same transaction. Applied to the general ledger, it advises that the ability to create journal entries should be separate from the authority to approve them.
The reason is not bureaucracy. A person who can both raise and approve a journal can move value between accounts, hide a shortage or flatter results without anyone else seeing the entry before it lands. Segregation forces a second pair of eyes onto every change to the books.
ACCA lists segregation of duties testing using transaction metadata among its examples of procedures that data analytics makes possible, alongside matching purchase orders to invoices and payments. It belongs in the same family: a whole-population test of a control, rather than a sample.
What the metadata can show
With a complete journal extract and the right fields, you can look for:
- Same person, both roles. Entries where the creating user and the approving user are the same.
- Approval out of order. Approval timestamps earlier than creation, which suggest the field means something other than you think, or that someone edited after approval.
- Users outside their role. Postings by people whose job does not involve the ledger, such as a sales administrator posting to the bank account.
- Shared and generic logins. Entries under "admin", "finance" or a supplier's support account, where nobody can say who acted.
- Self-approved amendments. An entry approved by one person, then changed and re-approved by the person who changed it.
Each result is a list of entries, not a conclusion. Some will have good explanations; the point is that you now know which ones to ask about.
Mapping the right columns
The test is only as good as your understanding of the fields. Before running anything:
- Find out what each user field records. In some systems the "user" column is the last person to edit the entry, not the person who created it. In others, a batch posting overwrites the creator with the person who posted the batch.
- Check that approval exists at all. Many smaller packages have no approval step. If there is no approver field, you cannot test approval from data; you test who posts and who reviews outside the system instead.
- Get the user list. Ask for the system's list of users and their access rights at year end, so you can tie names in the extract to people and roles.
- Confirm the extract is complete before you rely on any of it, by reconciling it to the trial balance.
Flagged entries and walkthrough records in Achekam
In Achekam, staff load a whole-population journal extract as a CSV and map its columns, and Achekam flags entries such as manual, weekend, after-hours and post-close postings for staff to select and test. Those flags pair naturally with a segregation review: a manual journal posted after hours by the person who also approved it is a stronger candidate for testing than either feature alone. Treat the creator-and-approver comparison as your own documented step on the mapped data, alongside the flags, rather than assuming a flag already covers it. Our guide to journal entry testing goes through selecting from the flagged population.
The Controls & Walkthrough Studio keeps its work against the chosen engagement, so the walkthrough that described how approval is meant to work sits with the engagement the data test belongs to. The ISA numbers shown on its badges are labels; they are not evidence that the work meets a standard. That judgement remains the reviewer's.
Small clients where segregation is not possible
AccountingTools acknowledges that segregation of duties is harder to achieve in a smaller organisation with too few people, and that spreading tasks across too many people can slow processing. A family business with one bookkeeper will fail a creator-equals-approver test on almost every entry, and that is not news.
For these clients the useful question becomes: what compensates? Look for:
- the owner reviewing the bank statements and the monthly journal listing, and evidencing it;
- an external accountant posting year-end adjustments, so the bookkeeper does not;
- bank mandates that need the owner's approval for payments, whatever the bookkeeper records;
- the system's audit trail being switched on and not editable by the bookkeeper.
If none of these exists, your risk assessment should say so plainly, and the audit approach should lean on substantive work rather than on controls. See walkthroughs and controls for documenting the design of what does exist.
Turning results into findings
A clean result supports the control; exceptions need sorting before they become findings.
| Result | What to do |
|---|---|
| Self-approved entries, all routine and explained | Note the pattern; consider a management letter point on the control design |
| Self-approved entries that are unusual in amount, account or timing | Test them substantively: support, purpose, who benefited |
| Generic or shared logins | Report as a deficiency; nobody can be held to account for those entries |
| Users posting outside their role | Ask why; check access rights against the user list |
| Approval timestamps that make no sense | Go back to the client's IT staff before concluding anything |
Write findings in terms the client can act on: which entries, which users, what the control was meant to do and what happened instead. AccountingTools sets out the general principles in its explanation of segregation of duties, which some clients find a helpful starting point when redesigning roles.
On your next audit with an approval step in the system, ask for the user list and the approval fields at planning, not at fieldwork. The test is quick once the data is right, and the conversation it starts with the client is often worth more than the result.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
