The first audit after an AP automation programme goes live is the one that surprises finance teams, because the questions arrive from an unexpected direction. Almost nobody asks for the vendor's headline accuracy rate. What the audit team wants is duller and much harder to produce after the fact.
They want to know that the control operated the way you described it, for the whole period, and that you can show them.
Why "can you show me" is the hard part
Auditors are required to understand the information system relevant to financial reporting, including the automated elements of it and the general IT controls that keep them reliable. That obligation sits in ISA 315 (Revised 2019), and the equivalent expectation for US filers runs through PCAOB AS 2110. If your group also carries an internal-control opinion, AS 2201 applies on top of that, which is a separate engagement with its own evidence demands.
The practical consequence is specific. If a rule inside your process decides that an invoice can be released for payment, that rule is part of a control, and the auditor's questions are about change management around it. Who can modify it. Who approved the last modification. What the rule said before. Whether the invoices processed under the old version were treated consistently.
Extraction accuracy does come up, though not in the form vendors expect. PCAOB AS 1105.10 requires the auditor to test the accuracy and completeness of information produced by the company when that information is used as audit evidence, or to test the controls over it. ISA 500 says the same on the international side. So if extracted field values drive a posting, the data itself is in scope, and the question you have to answer is whether you can show it was accurate and complete for the whole period. A vendor benchmark from a sales deck does not answer that.
What "on what basis" looks like for one invoice
Pick any invoice from the middle of the year and try to answer this now: what data was read, which version of which instruction was applied, what the system proposed, who accepted it, and how long they took.
Most AP teams can produce the first item and the fourth. The middle three are where the evidence usually stops, and reconstructing them from an ERP change log in audit week is how a routine engagement becomes a fortnight of work for your best analyst.
Who signs off, and why it has to be a person
There is a temptation, when automation gets good, to describe a decision as made by the system. That framing creates a problem the auditor will find, because a control needs an owner who can be asked why.
Good design is when the automated part proposes and a named person decides on anything material, with the threshold for material written down and approved in advance. That's not a limitation on the automation, but what lets it exist inside a control environment at all.
The five control points to map before the auditor arrives
Draw these on one page. It takes an afternoon and it changes the tone of the engagement:
- Instruction change. Who can edit a rule, who approves it, and how you would show what that rule said before the last change.
- Threshold ownership. Which limits exist, who agreed each one, and what happens when two systems disagree.
- Decision evidence. For a single invoice, the data read, the version applied, the proposal, the person, the timestamp.
- Exception handling. What happens when the system cannot decide, and who is accountable for the outcome.
- Access. Who can change any of the above, and how that access is reviewed.
Hand that page to your auditor at the planning meeting rather than at fieldwork. Every hour it saves them is an hour they don't spend testing around your process because they couldn't see into it.
The audit that reads instead of reconstructing
When this is in place, the engagement changes shape. Instead of sampling invoices and rebuilding the story behind each one, the audit team reads the control description, tests that the evidence matches it for a handful of cases, and moves on.
What Hypatos leaves in the audit file
Hypatos was designed on the assumption that an agent decision has to be explainable to someone who wasn't there. Instructions are written in plain language by the person who owns the policy, so the change-management question has an answer that doesn't require a developer to interpret it. The tax compliance validation skill and the platform's insights keep the inputs, the applied rule and the outcome together on the invoice rather than scattered across systems. Ask us, and ask anyone else you shortlist, to show that on one real invoice from the middle of a period.
The agents propose, a named person decides, and the record shows what was checked. Said in audit language, that sentence describes an automated control with a human sign-off and a complete evidence trail, which is the shape auditors already know how to test.
Hypatos fits when your close depends on automated decisions that a regulator, an auditor or a group controller will eventually ask you to explain one invoice at a time.
Ask early, but ask the right question
Your engagement partner cannot design your controls for you. Doing so would create a self-review threat, and for a listed group it is prohibited outright, so if you ask them to specify your design they will decline, in writing.
What you can ask, at the planning meeting rather than at fieldwork, is what evidence they will request when they test an automated posting decision. That answer is short, specific and free. Then take it to internal audit or an independent adviser and build to it, which is considerably cheaper than defending something different in March.
