Why accountants should learn to describe processes

For thirty years the bottleneck in business software was translation. The person who understood the process could not change the system; the person who could change the system did not understand the process. In between sat specifications, developers, delay and misunderstanding.

That gap is closing. Systems are increasingly built by describing what you need in plain language. Which means the description is no longer a document that precedes the work — the description is the work.

And most finance processes, as currently described, cannot be automated. Not because they are complex, but because they are vague.

The description that fails

Ask a finance team how supplier invoices are handled and you get something like:

"They come in by email, we check them against the PO, and if it's fine we pay it. Anything unusual goes to Sarah."

Every word is true and none of it is buildable. It leaves unanswered:

• What does "check against the PO" compare — quantity, price, both? Within what tolerance?
• What if there is no PO?
• What if the goods have not been received?
• What counts as "unusual"?
• What does Sarah do, and what happens if she is away?
• Who can approve, up to what amount?
• What if the supplier is new?

Nobody is being evasive. That is genuinely how processes live in people's heads: a confident summary plus a large amount of unexamined judgement that gets applied automatically and has never been articulated.

The description that works

Same process, described usably:

Invoices arrive by email to accounts@. Extract supplier, invoice number, date, net, tax, total and any PO reference. If a PO reference exists: match to the PO. Approve automatically where quantity matches the goods receipt and unit price is within 2% of the PO price. Where price is above tolerance, hold and notify the buyer who raised the PO. Where no goods receipt exists, hold until one is posted. If no PO reference exists: route to the department head named on the invoice for coding and approval. Above RM 10,000 also requires finance manager approval. If the supplier is not on the approved list: hold, and notify finance regardless of amount. Duplicate check: flag any invoice with the same supplier and invoice number as one processed in the last 12 months. If a hold is unresolved after 5 working days: escalate to the finance manager.

Longer, and it took someone forty minutes to write. But it can be built, and more importantly, writing it surfaces decisions nobody had made — that duplicate window, that escalation, what happens with an unapproved supplier.

That is the underrated benefit. The exercise finds the gaps.

The four things a description needs

The trigger. What starts it, and what arrives with it.

The decision points, with thresholds. Not "if it looks wrong" but the actual number. If nobody can state the tolerance, that is a decision waiting to be made, and making it is the valuable part.

The branches, including the ugly ones. What happens when the expected thing is absent. Most process failures live in branches nobody described because they felt like edge cases — and edge cases are the majority of the work.

The endings. Every path terminates somewhere: posted, rejected, escalated, waiting. A path with no ending becomes an item sitting in a queue forever.

Why this is an accountant's job

It could be given to a consultant or an operations analyst. It should not be, because the decisions are accounting decisions.

What tolerance is acceptable before a price variance matters. Whether an invoice without a goods receipt can be accrued. What segregation of duties requires. Which approvals are controls and which are habits.

Someone without accounting judgement making those calls produces a process that runs smoothly and controls nothing. That is a worse outcome than a slow manual process, because it looks fine.

How to get good at it

Write down a process you already own, then read it aloud. The vague parts are audible.

Attack every adjective. "Unusual", "significant", "urgent", "reasonable" — each hides a threshold nobody set.

Follow the unhappy paths. For each step, ask what happens if the input is missing, wrong, late, or duplicated. Follow each to an ending.

Ask who, not just what. "It gets approved" is passive and hides the control. By whom, up to what limit, and who deputises.

Test it on someone who does not know the process. If they can follow it without asking questions, it is buildable.

The strategic point

Finance teams carry workarounds that exist purely because changing the system was too expensive to justify. Someone reconciles a spreadsheet monthly because a report was never built. An approval happens over WhatsApp because the workflow could not be changed.

When the cost of a change falls far enough, those stop being permanent facts and become choices. The team that can describe what it wants gets its processes fixed. The team that cannot keeps the workarounds — not because the technology is unavailable, but because nobody can say precisely enough what to build.

Common questions

Why does describing a process matter for AI accounting?

Because when systems are built by describing what you need rather than through a development cycle, the description functions as the specification. A vague description produces automation that does not match how the process really works, and the vagueness usually hides decisions nobody has made — thresholds, branches for missing inputs, and what happens when something is unresolved.

What makes a process description good enough to automate?

It states the trigger and what arrives with it, every decision point with an actual threshold rather than a word like "significant", every branch including what happens when expected information is missing, and a definite ending for each path. A practical test is whether someone unfamiliar with the process could follow it without asking questions.

Should an accountant or a consultant write the process description?

An accountant, because the decisions embedded in it are accounting judgements — acceptable tolerance on a price variance, whether an invoice can be accrued without a goods receipt, what segregation of duties requires, which approvals are genuine controls. A process designed without that judgement can run smoothly while controlling nothing, which is more dangerous than a slow manual process because it appears sound.

What is the most common gap in a finance process description?

The unhappy paths — what happens when the purchase order is missing, the supplier is new, the goods receipt has not been posted, or an item has been sitting unresolved for a week. These feel like edge cases when describing the process but constitute most of the actual work, and a path with no defined ending becomes an item that sits in a queue indefinitely.

Related: how to describe a process so AI can build it · skills that matter when AI does the processing · documenting an automated process for review