Documenting an automated process so someone else can review it

Every automated finance process has an implicit owner: the person who set it up. They know why the tolerance is 2%, which exceptions matter, and what the odd workaround in the middle is for.

None of it is written down, because it was obvious while they were doing it.

Then they leave, and the process continues running exactly as configured, with nobody able to say whether it should. That is the most common way automated finance functions degrade — not failure, but the slow loss of the knowledge required to question them.

The one page that prevents it

Per automated process. Not a project document — a page that stays current.

What it does. Two sentences, plain language. "Supplier invoices arriving at accounts@ are extracted, matched to purchase orders and posted where price and quantity are within tolerance."

When it started. A date. Necessary because the audit period may contain both the old process and the new.

What posts without a person. The specific criteria and the threshold. "Confidence above 0.9 and amount below RM 10,000 and a matched purchase order exists."

What routes to a person, and to whom. Each exception type and its destination. Price-above-tolerance to the buyer, not to finance.

Hard limits. What the system cannot do regardless of confidence. Approved supplier list, amount ceilings, accounts it may never post to.

Who owns it. A name.

The review cycle. When the thresholds get reconsidered, and by whom.

Change history. Every configuration change with date, reason and author.

Eight items. Half an hour to write, and it answers most of what an auditor asks about automated processing.

The two nobody writes down

Why the threshold is what it is.

"Tolerance 2%" is a fact. "Tolerance 2% because our main suppliers' agreed price lists allow a 2% variance for exchange movement" is a reason, and only the second can be reviewed. Without it, a successor either leaves the number untouched forever or changes it on no basis — both bad.

What the workaround is for.

Most real processes contain something odd: a supplier excluded from matching, a category always routed to a person, a rule that looks wrong. Each exists for a reason that was obvious at the time and is invisible afterwards.

Write the reason next to the oddity. It is the single highest-value sentence in the document, because it is the thing a successor will otherwise either preserve superstitiously or remove destructively.

What "current" requires

A document that describes the process as implemented eighteen months ago is worse than none, because it will be believed.

The mechanism that works: the change is not complete until the page is updated. Attach it to the act of changing configuration rather than to a review cycle, because review cycles get skipped and changes do not.

If that discipline is unrealistic, the fallback is a quarterly check by the process owner, accepting that it will sometimes be a few weeks stale.

What an auditor needs that this covers

Almost all of it. The typical questions map directly:

| Question | Where it is answered | |---|---| | What posts without review? | The criteria and threshold | | Why that threshold? | The reason, if you wrote it | | Who is accountable? | The owner | | What changed during the year? | The change history | | What stops it doing something wrong? | The hard limits | | Who handles exceptions? | The routing |

The one it does not cover is "how do you know it is working", which needs your sampling file — a separate record. See sampling automated transactions.

The test

Give the page to someone in finance who does not run that process and ask them to explain, from the document alone:

• What would happen to an invoice from a new supplier for RM 40,000
• Why the tolerance is set where it is
• What they would check if the exception queue doubled

If they cannot answer all three, the document is a description rather than something a successor could work from — and the gap it reveals is usually the reasoning, not the mechanics.

Common questions

What should be documented about an automated accounting process?

What it does in plain language, the date it started, the specific criteria and threshold for posting without human review, which exception types route to which people, the hard limits the system cannot exceed, a named owner, the review cycle for thresholds, and a change history with dates and reasons. That covers most of what an auditor asks and takes about half an hour per process.

What is most often left out?

The reasoning. Documents record that a tolerance is 2% without recording why, and they record unusual workarounds without recording what those workarounds are for. Both omissions matter when the person who configured the process leaves, because a successor will either preserve settings they do not understand or change them on no basis.

How do you keep process documentation current?

Tie the update to the act of changing configuration rather than to a periodic review, since changes always happen and review cycles often get skipped. A stale document is worse than none because it will be believed, so if that discipline is not realistic the fallback is a quarterly check by the named owner with the acceptance that it may be slightly out of date.

How do I know the documentation is good enough?

Give it to someone in finance who does not run that process and ask them to explain from the document alone what would happen to a large invoice from a new supplier, why the threshold is set where it is, and what they would investigate if the exception queue doubled. Inability to answer usually reveals missing reasoning rather than missing mechanics.

Related: who is accountable for an automated entry · why accountants should learn to describe processes · when the only person who understood it resigns