Resources · Guide

AP approval workflows that scale

An approval process that works at fifty invoices a month can fail quietly at five hundred. This guide walks through the three ways to route an approval — amount bands, cost centers and projects — why separation of duties is really a permissions question, and why the audit trail earns its keep at close.

The starting point

Where approval processes come from

Nobody sits down and designs their first approval process. It accretes. The controller signs everything because the controller has always signed everything. The office manager knows that anything from the electrician goes to facilities, and forwards the PDF. At low volume, with everyone in one office, this genuinely works.

Then the volume grows. Approvers go remote, a second entity appears, the controller becomes the queue every invoice waits in, and the real logic of the process — who signs what, and why — lives in one or two people's heads. The week one of them is on vacation, invoices stop moving. Scaling an approval process means one thing first: the rules have to come out of people's heads and into a form that runs the same way every time. The question is what the rules should say.

Dimension one

Routing by amount bands

Amount is the oldest routing dimension and the easiest to write down. Routine invoices take a short path — one approver, often the requester's manager. Larger invoices climb: a second signature past the next threshold, the largest reaching the CFO. Every finance policy manual has a version of this table.

Amount bands have two real virtues. They are easy to explain — anyone can read a total off the invoice and know its path. And they cap exposure: nothing large moves on a single signature. But amount answers only one question: how many eyes an invoice deserves. It says nothing about whose eyes. A modest invoice coded against the wrong budget slides under every band and gets approved by someone with no reason to catch the error. That is the gap the next two dimensions exist to close.

Dimension two

Routing by cost center

In most companies, spending authority is budget ownership. The marketing lead answers for the marketing budget, so the marketing lead should see the invoices that hit it. Cost-center routing sends each invoice to the person who owns the budget the spend actually lands in — which sounds obvious and has one demanding prerequisite: the lines have to be coded first.

Routing cannot read a budget off the vendor's name. It reads the coding — the GL account and cost center assigned to each line — which means coding stops being clerical paperwork done at the end and becomes the input the whole approval process depends on. The earlier the coding happens, ideally during invoice capture and OCR, the earlier routing can act on it — and software can carry a good share of that work, as covered in how invoice OCR learns your vendors.

The payoff is sharper than convenience. The budget owner does not just approve their own spend — they see spend arriving against their budget that they never ordered. That is the review most likely to catch a miscoded line or a vendor billing the wrong department, and amount-based routing never produces it.

Dimension three

Routing by project

Projects cut across the org chart. An office fit-out, a system implementation, a construction job — each draws invoices from many vendors and lands them across several cost centers, while a single person is accountable for the whole budget: the project owner. Routing by project sends those invoices to that person, wherever the lines sit departmentally. Projects are also time-bounded, and the routing should be too — once the project closes, an invoice that still names it deserves a harder look, not a quieter path.

Putting it together

In practice, you combine all three

The three dimensions are not competitors. A workable pattern: amount decides how many approvals an invoice needs; cost center and project decide whose approvals those are. A routine invoice goes to its budget owner and stops there. A large one goes to its budget owner and then climbs the amount bands.

The part that fails silently is precedence. Sooner or later an invoice matches two rules at once — it belongs to a project and it hits a cost center with its own approver. The process needs a deterministic answer to which rule wins, written down before the case arrives. "Send it to both and hope" is not an answer; it is how an invoice stalls in two queues while each approver assumes the other has it.

Control design

Separation of duties is a permissions question

The classic AP control says the person who records an invoice must not be the person who approves it. One pair of hands entering data and approving payment is how fraud goes unnoticed — and how honest errors certify themselves.

Written in a policy binder, that rule is a hope. It becomes a control only when the system's permissions enforce it: recording and approving are separate rights, held by different roles, and the approve action simply does not exist for the person who coded the lines. That is why separation of duties is really a question about role-based access control — not "what did we tell people to do," but "what is each account able to do." If every user is an administrator, there is no separation of duties, whatever the policy document says.

The role model has to answer the awkward cases too. Who may edit an invoice after its approval has started — and does an edit reset the approvals already given? It should: an approver signed off on a specific amount and coding, not on whatever the record says now. What happens when an approver leaves the company — does the chain reroute to someone with authority, or does it stall, or worse, silently skip a step? Each of these is a permissions decision, and each surfaces only at volume, when nobody notices a single invoice slipping through.

The paper trail

Why the audit trail matters at close

During the month, approval feels like workflow — the point is to keep invoices moving. At month-end close, and again in audit season, it becomes evidence. The question is never merely whether an invoice was approved. It is who approved it, when, under what authority — and what they were looking at when they decided: the coding on the lines, the result of the match against the purchase order and goods receipt (the subject of what three-way matching checks), and any warnings showing at the time.

A trail that can answer those questions has two properties. It is written at the moment of the decision, not reconstructed afterward. And it resists editing — a record altered after the fact should show as altered. The alternative is familiar to anyone who has closed the books on an email-driven process: inbox archaeology, piecing together who said yes from forwarded threads, months later, for an auditor who would much rather have seen a record.

One note on tooling

Where software fits

Everything above is process design, not a product requirement — amount bands, budget-owner routing and enforced separation of duties can be built into most serious systems, given enough will. For what it is worth, this is the shape Onivo AP takes: each line is coded to a GL account, cost center and project, approvals route by amount, cost center and project, and every decision is written to a tamper-evident audit trail. The mechanics are on the invoice approval workflow automation page, and how the trail is protected is covered under security.

FAQ

Approval workflows, answered

What are the three ways to route an invoice approval?

By amount bands, cost centers, and projects. They are not competitors: a workable pattern is that amount decides how many approvals an invoice needs, while cost center and project decide whose approvals those are. A routine invoice goes to its budget owner and stops there; a large one goes to its budget owner and then climbs the amount bands.

Why is separation of duties really a permissions question?

Written in a policy binder, the rule that the person who records an invoice must not approve it is a hope. It becomes a control only when the system's permissions enforce it — recording and approving are separate rights held by different roles, and the approve action simply does not exist for the person who coded the lines.

Why does the audit trail matter at month-end close?

At close, and again in audit season, approval stops being workflow and becomes evidence. The question is never merely whether an invoice was approved — it is who approved it, when, under what authority, and what they were looking at when they decided. A trail that can answer those questions is written at the moment of the decision and resists editing: a record altered after the fact should show as altered.