The cost invoice: who describes it, who approves it, who is accountable

Almost every company above twenty people has a written procedure for approving invoices. And almost every one of them simultaneously has invoices circulating by e-mail, because nobody follows the procedure.

The reason is not ill will. It is that a typical procedure describes accountability rather than a path. It says who is responsible for what, but not where a particular invoice is on Thursday at three o'clock and whose move it is now. Until that is visible, people use the only tool that shows it, which is an e-mail thread.

Five roles around a single invoice

The first misconception is that somebody approves an invoice. In reality it passes through five roles, which in a small company two people may cover and in a larger one five different departments.

1. The registrar. Enters the invoice into the workflow, or makes sure the integration does it automatically. Accountable for nothing going missing on the way in.

2. The person who describes the cost. They know what the cost covers, because they ordered the service or received the delivery. This is the only person who can say whether the invoice is justified.

3. The approver. Takes on the decision to pay. They do not need the technical detail; they need to trust the description and see the amount.

4. The budget controller. Looks not at the single invoice but at what is left in the budget line. In many companies this role formally does not exist, and it shows in December.

5. The bookkeeper. Receives the complete set and enters it into the accounting systems. Their problem is not the invoice but the information missing around it.

It is worth writing these roles out even if the same person performs three of them. The mere fact that they are named resolves most of the situations where an invoice sits still because everyone assumes it is waiting on somebody else.

Three blockages that stop most invoices

When you look at the invoices stuck inside a company, it is nearly always one of three things.

• An invoice with no owner. It arrived from a supplier nobody recognises, or relates to an order from six months ago. It sits there because nobody feels obliged to touch it.

• Approval with no amount threshold. With no thresholds, everything goes to the board, and the board has a hundred invoices a month and looks at them once a fortnight.

• No link to the order. There is no quick way to check whether the rate and quantity match what was agreed, so the approver either phones somebody or signs blind.

An approval matrix without forty exceptions

Amount thresholds are the simplest instrument you can introduce, and the one most often ruined by excess ambition.

A good matrix fits on a single page and has three thresholds, four at most. Up to a certain amount the department head approves. Above it the finance director joins. Above the next boundary, the board. Add one or two cost categories with their own path regardless of amount, usually legal services, marketing or IT purchases.

A bad matrix appears when every department adds its own special case during a workshop. An hour later there are forty of them, nobody remembers them, and the system that mirrors them becomes unmaintainable. Better to start with three thresholds and no exceptions, then add the ones that actually occur over the first quarter.

Thresholds are worth keeping in a dictionary rather than buried in the process configuration. In Opero, changing a limit is then editing a value in a table rather than raising a request with your software vendor, and that is the difference between a matrix that lives alongside the company and one that stays frozen at go-live.

Exceptions worth anticipating from the start

Three situations overturn any workflow designed purely for the ideal case. They need no elaboration, they simply need to exist.

• A disputed invoice. Somebody has to be able to hold it and record why, and the case needs a deadline of its own, or it hangs indefinitely.

• A credit note. It has to land in the same case as the original invoice. Handling credit notes separately is the simplest way to pay twice.

• An invoice ahead of delivery. Advance payments have no acceptance protocol, so the formal check has to route them differently rather than block them.

What it looks like once organised

The difference between a procedure and a working flow comes down to four things.

• Stages instead of descriptive statuses. You can see where the invoice is now and whose move it is.

• A task with a deadline instead of a request in an e-mail. The approver sees their own list, not a thread that has slid to the bottom of an inbox.

• A role instead of a name. A manager's holiday does not stop a payment, because cover follows from the configuration rather than from somebody remembering to arrange it.

• One place with the history. Invoice, description, attachments, the full set of approvals and the dates all sit together, so a year later you can reconstruct who decided and on what basis.

The measure of success is not the number of automations but the fact that nobody asks by e-mail what stage an invoice is at. If such questions are still circulating after a month, the workflow is badly designed or too long.

Where to start

Take last month's invoices and count two numbers: how many of them had no unambiguous owner, and how many waited for approval longer than five working days. Those two numbers describe your workflow better than any procedure, and they double as the baseline you will come back to in three months.

The rest is a matter of arranging stages and thresholds, which is simpler than it sounds, provided it is done by one person with the authority to decide rather than by a workshop where everybody adds their own exception.