How do you design accounts payable around the person who signs it off?

You design accounts payable backwards from the person who signs it off. Start with the finance owner and the way the team works today, agree with them the future way of working, and only then decide which tools, which data, which people and which process are needed to deliver it. Most AI projects do this in the wrong order: they start with the software, and the people who have to live with the result are consulted last, if at all.

Start with the person, not the product

In a services firm the person who owns accounts payable is usually a financial controller or finance director with a small team and a transaction volume that grows faster than it. They know which suppliers cause rework, which recharges get queried and where the month-end backlog comes from. None of that is written down, and none of it is in the vendor's demo data.

So the first step is not a requirements document. It is sitting with that person and their team, walking through a month of real invoices, and agreeing what the work should look like in future: which decisions a system should make on its own, which should come to a person, and what the team should stop doing by hand. That agreed picture is the target. Everything else is there to deliver it.

Then map what it takes to deliver it

Once the future way of working is agreed, the enabling capabilities fall into three groups. Each has its own questions, and each is a place where projects quietly fail.

Tools and technology

What does the system need to be able to do, and how does it connect to what the team already uses? For accounts payable that means reading invoices from the AP mailbox, matching suppliers and history in the ledger, proposing a code and routing the decision. The test is whether the decision happens where the work already is, in the ledger and the mailbox, rather than in a new screen the team has to log into.

Data

What data does the decision depend on, where does it live, and how does it flow in and out? In: the supplier record, posting history, the chart of accounts, dimensions and open orders. Out: the decision, the evidence behind it and the confidence score, written to a record that cannot be altered afterwards. If the data in is poor, the decision will be poor, and a confidence score should say so rather than guess.

People, process and operating model

Who approves, who is told, who answers when something goes wrong? Which roles change, and does anyone need new skills? This is the part most often skipped, and it is the part auditors ask about. The answer should be written down and signed: a mandate that says what the system may do, what must stop, who is told and who is accountable. Then the operating model is a document, not a memory.

Why the order matters

Databricks, in its State of AI Agents 2026 report, cites MIT NANDA research from 2025 finding that 95% of generative AI pilots never reach production. The pilots that fail rarely fail on the technology. They fail because nobody agreed the way of working first, so there was no answer to who authorised what, and no person who could say the result was good enough to rely on. Designing from the person outwards gives you those answers before the first invoice is decided.

What this looks like in practice

A sixty-day shadow period is the design phase done properly. The system decides alongside the team on live invoices without writing anything to the ledger. Each week the finance owner reviews what was escalated and adjusts the limits. By the end there is a record of how the firm actually codes, where the exceptions come from, where the system and the team disagreed, and an agreed split of decisions between the two. That is the future way of working, with the evidence attached, and it is the firm's to keep whether or not anything continues.

Mandate works this way. Its agent, Invoice Maestro, makes the posting decision on supplier invoices inside a mandate the finance owner signs, scores its confidence, escalates unclear cases to a named person and writes every decision to a tamper-evident, append-only audit trail. The 60-Day Proof is the design phase described above: sixty days on your own invoices, read-only and free, with a weekly review with whoever owns AP and a day-60 report you keep. Details at runmandate.co.uk/60-day-proof.

Frequently asked

Who should be in the room when the future way of working is agreed?

The person who signs off the ledger, whoever processes invoices day to day, and whoever answers the auditor. If the recharge affects client billing, the person who owns margin should see it too.

Does the operating model have to be written down?

Yes. If the split of decisions between system and people only exists in someone's head, it cannot be audited, measured or handed over. A signed, versioned mandate is the simplest form.

What if our coding rules are not written down?

That is normal. The shadow period is where they get written down, because every escalation is a rule that did not exist yet.