An AI SOX control testing agent takes each procurement-related control description and turns it into a repeatable test, such as every purchase over a limit had an authorised approval before ordering.
Reads how each control is meant to work.
Approvals, matches and postings for the period.
Picks items to test using the agreed approach.
Checks each item against the control steps.
A person judges failures and rates the control.
Records test results and evidence for each control.
It runs the test across the full population of transactions in the period rather than a small sample and lists each exception with the supporting records.
It prepares a workpaper for each control showing the population, the test, the exceptions and the evidence, ready for review by control owners and internal audit.
Control testing is usually done on small samples by hand. It is slow, tied to a few people, and a handful of items can be misread as a control working or failing.
A control can look fine in a sample and fail across the population.
Pulling documents and ticking attributes takes weeks each cycle.
A control written in general terms is tested differently by different people.
Failures are noted without the records needed to judge them.
Late discovery leaves little room to remediate before year end.
The agent restates each control as attributes it can check, and a person confirms the wording before it runs.
It identifies all relevant transactions in the period and records completeness checks on the population.
Each transaction is tested against the attributes, such as approval authority, timing and match.
Failures are listed with source records so a reviewer can verify them quickly.
The population, method, results and evidence are laid out for the control owner and internal audit.
Bring a small sample and watch Flo work through it.
| Aspect | By hand | With the agent |
|---|---|---|
| Sample selection | Testers choose samples by hand and by judgement. | Samples are drawn by a documented method and the method is stored. |
| Attribute testing | Each item is checked in a spreadsheet. | The agent checks each attribute and cites the evidence. |
| Coverage | Only a few items per control are tested. | The agent can test the full population for attributes it can read. |
| Evidence | Screenshots are collected one at a time. | Evidence links are saved with each test line. |
| Retesting | Fixes take another full cycle to verify. | Remediated controls can be retested on fresh items when asked. |
| If | Then | Who decides |
|---|---|---|
| Control requires evidence of approval before commitment | Test each sampled item for approval date versus order date | Control tester |
| Item fails an attribute | Record the failure with evidence and group failures by cause | Control owner |
| Control relies on judgement rather than data | Mark as not testable by the agent and pass to a tester | Control tester |
| Failure rate pattern suggests a design problem | Flag the control for a design review | Finance controller |
| Control changed during the period | Test each version on its own dates | Control owner |
| Evidence for an item cannot be found | Mark as unsupported rather than pass | Process owner |
The agent notes that the evidence is off-system and cannot test it. A tester must review the manual evidence.
The agent lists related controls and the failure they may cover. The controller decides if it counts.
Unusual postings are flagged for human judgement. The tester decides whether they are in scope.
The agent reports data gaps in the population. The controller decides whether the test can proceed and with what caveat.
Talk it through with the team. We will map it to your steps and show where a person stays in control.
Pick controls that have attributes visible in data, such as approvals and matches.
Run the agent beside manual testing on one control and compare results.
Move from small samples to full-population checks where the data allows.
Leave design and judgement-heavy controls with testers.
Read it with the population size and severity of the exceptions. A low rate on a complete population is stronger evidence than a clean small sample.
Quick answers to what people ask most about SOX control testing.
Book a demoIt is the process of checking whether internal controls over financial reporting, including procurement and payment controls, operated effectively over a period. Results feed management's assessment and the external audit.
If the data is available it can run an attribute test across the whole population, which gives broader coverage than sampling. People still review the exceptions and conclude.
No. It runs tests and presents evidence. Control owners, internal audit and management decide on effectiveness and any deficiency classification.
Common ones include approval authority, segregation of duties, three-way match, vendor master changes and access to payment. Your own control framework defines the exact list.
Audit preparation is collecting and checking the evidence an auditor will ask for before the audit begins.
→Segregation of duties means no single person controls conflicting steps of a purchase, such as requesting, approving and paying.
→A procurement audit trail is the connected record of everything that happened on a purchase from request to payment.
→Regulatory compliance in procurement means buying and contracting in line with applicable laws, such as sanctions, data protection, tax and anti-bribery rules.
→Bring a small sample of real items. We will show what Flo handles on its own and where it hands over to your team.
