Build the accounts payable rota backwards from the payment run. Work out which held invoices must be decided before each run, set a response target for each hold reason, then staff each day with a named primary reviewer, a backup, and at least one approver who can release payments.
Keep duties apart: whoever verifies a bank detail change never releases the payment.
What does the rota cover, and who owns it?
An accounts payable agent matches invoices to purchase orders and receipts, codes them, and schedules payment. It holds what it cannot settle within its bounds: price or quantity mismatches beyond tolerance, possible duplicates, invoices without an order, and every change to a supplier's bank details. The rota decides who clears those holds, and when.
The AP manager owns the rota. The financial controller agrees the approver mix, because payment release is a depth 4 action and sits with the finance leadership's authority. For the skills each role needs, see the guide to AI agent skills by role; for the basic idea, what a reviewer rota is.
What are the steps?
- Agent, depth 1: reports holds by reason and age. Mismatches, duplicates, no-order invoices, bank detail changes, items above limit. Pull a few weeks of history to see when holds arrive.
- Person (AP manager): maps holds to the payment calendar. Most AP holds have a natural deadline: the next payment run. Anything not decided by cut-off misses it, and suppliers chase.
- Person (AP manager): sets a response target per hold reason. For example, mismatches decided within one working day; possible duplicates the same day; bank detail changes not rushed, but verified before the next run that would pay the supplier.
- Person (AP manager with financial controller): sets the skills mix. Clerks decide mismatches and duplicates at depth 3. Bank detail verifications need someone trained in call-back procedure. Payment run release needs an approver at depth 4 with a current credential.
- Person (AP manager): staffs the rota. A named primary and backup for each day, extra cover in the two days before each run and through month-end close.
- Agent, depth 2: drafts the daily handover. Open holds, their ages, which are due before the next run.
- Person (financial controller): approves the run release. On the rota as a named release approver, with a named deputy.
- Person (AP manager): reviews the rota monthly against response targets met.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Hold report | Reports holds by reason and age | 1 | Reading the pattern |
| Payment calendar | Nothing | n/a | Mapping holds to runs |
| Mismatch holds | Matches within tolerance, holds the rest | 3 | Deciding mismatches |
| Duplicates | Flags possible duplicates | 2 | Confirming or releasing |
| Bank detail changes | Holds every one | 2 | Call-back verification |
| Payment run | Prepares the run and holds it | 4 | Release by a named approver |
How should duties be separated on the rota?
Payment fraud in AP usually comes through a supplier's "new bank details". The rota should make it impossible for one person to verify a change and release the payment that uses it. In practice: bank detail verifications and payment run release are never assigned to the same person on the same day. The workspace enforces it as one of the organisation's own limits; the rota makes sure there is always a second qualified person to call on.
The same logic covers the approver authority matrix for the accounts payable team: the rota says who is on duty, the matrix says what each person may approve.
Which controls matter, and what evidence do they leave?
- Named reviewer per day. Evidence: the rota, kept with the record, and the reviewer's name on every verdict.
- Response targets per hold reason. Evidence: hold age at decision, reported against target.
- Separation of verification and release. Evidence: two different names on the bank detail verdict and the run release.
- Current credentials for release approvers. Evidence: the approver's certificate status on the day of release.
- Handover. Evidence: the daily note, filed.
What should be measured?
- Holds decided before the run they were due for.
- Response targets met, per hold reason.
- Holds carried across a payment run, and why.
- Days a release approver was not available, and who covered.
- Decision quality on a weekly sample, so speed does not crowd out care.
The AI agent competency matrix for the accounts payable team helps decide who is ready to move from mismatches to bank detail verification.
Where does it usually go wrong?
The rota ignores the run. A flat rota with the same cover every day leaves the day before the run short-staffed and the day after idle.
One release approver. When the financial controller is away, the run waits or someone without the right authority releases it. Name a deputy, and make sure their credential is current.
Month-end overlaps a run. Close work pulls the same people away from the queue. Plan the two together.
Claims and compliance teams face different peaks with the same method; compare the rotas for the claims team and the compliance team.
Where the Academy fits
The Operator track covers human review and running the rhythm, which is what an AP reviewer does on the rota each day. Certified Pryme Operator includes a practicum signed off by a Pryme assessor and is valid for 12 months. A finance team can choose to put only people with a current certificate on the release approver line of the rota.
Questions people ask
How many people does an AP rota need?
Enough to meet the response targets on the busiest day before a run, with a backup for every role. Count holds per day from the agent's history rather than guessing from invoice volume.
Should clerks rotate through bank detail verification?
Yes, once trained. Rotation spreads the skill and keeps one person from becoming the only route for supplier changes, which is itself a risk.
What if a supplier needs urgent payment outside the run?
Treat it as an exception with its own approval, not as a reason to skip verification. The rota should name who can approve an off-run payment.