
An accounts payable approval matrix is the set of rules that decides who signs off on each bill. Most templates sort bills by dollar amount alone, which works until a business tracks its costs by job, project or entity.
For those businesses, the matrix has to look at how each bill is coded, not just its total. MakersHub is set up around how your business already works, and our team configures it with you.
Charley Howe, our co-founder and President, wrote about this the week MakersHub shipped its rebuilt approval workflow. Here is his post:
In businesses that track costs by job, project, entity or class, approving a bill often has little to do with the dollar amount. Instead it depends primarily where the cost is going.
For example, a foundation contractor we work with routes bills by the letter in the middle of the job number. S is shoring, R is rigid inclusions, D is drilling. Each letter goes to a different group of project managers, then the CFO, then the COO. A different construction company sends every bill to its outside bookkeeper for coding first, sends anything over $10,000 to the owners, unless it is from one of their three primary suppliers, in which case the ops team approves up to $15,000, because those invoices routinely run between $10,000 to $13,000. A property manager with a dozen entities needs a bill for one building's roof to reach a different person than the same vendor's bill for another building.
These procedures sound idiosyncratic, but they're what control looks like when cost allocation really matters.
They're also very hard for software companies to support for a few reasons. The deciding fact usually isn't printed on the invoice. It shows up only after someone codes the bill to a job or entity. The conditions stack on top of each other: vendor and amount and project, all at once. And several rules can apply to the same bill, where one adds an approver while another replaces the whole chain. Most approval tools are built around "over $X goes to Y," so the rest of the logic lives in a controller's head and an AP clerk's notes.
This week, we shipped our rebuilt approval workflow at MakersHub. A rule can combine as many conditions as the business needs. It can look at anything we read or derive on the bill, including the project, the entity, the customer, specific characters in an invoice number, etc. Rules can stack, adding an approver without bumping anyone else off the bill, or they can override. The owner who says, "I don't care who else sees it, if it's over $10,000 I want to see it."
Each piece is simple: the vendor is X, the project contains -D-, the amount is over 15,000. What matters is that simple pieces can be put together into whatever the business already does.
Every company already has an approval chain, and nobody wants to change it. Our job is to build that configurability into the platform.
His examples come from businesses MakersHub works with. The rest of this article explains what an approval matrix is, why the dollar-band version falls short for job-costed businesses, how to write yours down, and when a simple threshold is all you need.
An approval matrix, also called a delegation of authority or schedule of authority, is a written map of who can approve which spending. In accounts payable it answers one question for every incoming bill: whose sign-off does this need before it can be paid?
The idea comes straight from internal control. The U.S. Government Accountability Office publishes the Standards for Internal Control in the Federal Government, known as the Green Book, which many auditors use as a reference model. Among its control activities: transactions are authorized and executed only by people acting within the scope of their authority. It also expects those policies to be written down. An approval matrix is how a finance team does both for its bills.
The version in most templates looks like this:
| Bill amount | Approver |
|---|---|
| Under $1,000 | Department or site manager |
| $1,000 to $10,000 | Controller |
| Over $10,000 | Owner or CFO |
That works when every dollar flows through one budget. It starts to break when the same $4,000 bill means different things depending on which job, property or company it is charged to.
A dollar threshold measures how much is at risk. It says nothing about who can tell whether the bill is right. In a business that tracks costs by job or entity, the person who can verify a bill is the person who owns the cost: the project manager running that job, the property manager for that building, the controller for that company.
In all three of Charley's examples, the amount is rarely the deciding question. Even the company that does draw a $10,000 line carves out its main suppliers, because a dollar rule alone would send the owners a stack of routine bills.
Cost allocation means charging every expense to the job, project, entity or class it belongs to, and it changes how approvals work. Once costs are allocated, approval has to follow the allocation, or the wrong person ends up signing off. A bill that reaches someone who cannot judge it gets approved anyway, which looks like a control on paper and does very little in practice.
Vendors print what they care about: their own invoice number, an amount, maybe a PO number. They rarely print your job number, your entity or your cost code. Those get attached during coding, the step where each line of a bill is assigned to an account, job, project or class in your books.
That changes the order of the work. If routing depends on coding, routing cannot happen when the bill arrives. It has to wait until the bill is coded:
Software that routes at intake, before coding, can only see what the vendor printed. That is why so many tools stop at the dollar amount. It is the one fact every invoice reliably carries. MakersHub captures the vendor, totals, line items, GL codes, projects, customers and jobs before a bill routes, so the rules can see the coding. With line-level automated coding fills that in before anyone has to type it. You set your coding rules once, and MakersHub applies them everywhere.
Real approval policies are rarely one rule per bill. Conditions combine, and more than one rule can match the same bill. Charley's post names the two ways that plays out:
Here are the rules from Charley's post, written the way a rules engine has to hold them. Each one is a set of conditions that must all be true, plus what happens when they are:
| Business | Conditions (all must be true) | What happens | Type |
|---|---|---|---|
| Foundation contractor | Job number contains -D- | Drilling project managers, then CFO, then COO | Base chain |
| Construction company | Every bill | Outside bookkeeper codes it first | Coding step |
| Construction company | Amount over $10,000 | Owners approve | Base chain |
| Construction company | Vendor is one of three primary suppliers, and amount up to $15,000 | Ops team approves instead of the owners | Override |
| Property manager | Bill is coded to a specific building's entity | That building's approver signs off | Base chain |
| Owner rule | Amount over $10,000 | Owner added, nobody removed | Stacking |
Written out, none of these is hard. The work is in the combinations, and in deciding which rule wins when two of them match. That part rarely gets written down.
In people. As Charley puts it, whatever the software can't hold lives in a controller's head and an AP clerk's notes. The AP clerk knows that the big supplier goes to ops, not the owners. The controller remembers which building belongs to which entity. The system routes on the dollar amount, and someone quietly reroutes the bill by hand.
That works until the person who knows goes on vacation, leaves, or forgets a rule. It also leaves a control that works in practice but is invisible on paper, the hardest kind to audit. The Association of Certified Fraud Examiners' 2026 Report to the Nations studied 2,402 occupational fraud cases across 143 countries. More than half of all cases involved either a lack of internal controls or an override of existing controls. The same study found that controls such as management review were associated with stronger outcomes.
“Prevention is so valuable in combatting any type of fraud, and within workplaces, fraud prevention must be a collaborative effort across employee levels”
John Warren, J.D., CFE, Chief Executive Officer, Association of Certified Fraud Examiners, in the 2026 Report to the Nations releaseAn approval matrix that the software actually enforces is that collaboration written down. The project manager checks the work, the controller checks the coding, the owner sees the large bills, and the system makes sure each of them gets the right ones.
The quickest way to document your real matrix is to work from last month's bills rather than from memory.
Enterprise ERP systems have supported conditions like these for years, usually through a configuration project. Oracle's documentation for invoice approval rules, for example, includes conditions on the cost center segment of an invoice's distribution, set up in a rules spreadsheet. The idea is not new. Most smaller businesses have just had no way to set up rules like these without hiring a consultant.
The rebuilt approval workflow described in Charley's post holds a matrix like the one above as written: any combination of conditions, on anything MakersHub reads or derives from the bill, with each rule set to stack or override.
Steps run in sequence when order matters or in parallel when it doesn't. Bills can route to a group instead of one person, and approvers can delegate when they are away, so bills don't stall while someone is away. Approvers use MakersHub without training. They approve from email in one click, and see only the bills that are theirs. Our accounts payable approval software page walks through the routing options in more detail.
Approval and payment stay separate. Bill approval confirms a bill is right. Payment authorization, a separate step held by different people, decides when and how the money leaves. MakersHub is SOC 2 Type II certified, with Positive Pay protection on check payments and encrypted collection of vendor bank details. SOC 2 Type II means an independent auditor tested those security controls over a period of months, not on a single day. With Positive Pay, your bank compares every check presented for payment to the checks you actually wrote, and holds any that don't match.
Locke Buildings, a Portland pole-building contractor, moved its approvals into MakersHub to get bills in front of the right project managers. It now processes 500+ bills a month digitally and saves 40+ hours a month, without changing how it approves. The details are in the Locke Buildings approvals customer story.
“We had a system that worked, but it was slow, manual, and tied to the office.”
Trina Brockway, Office Manager, Locke BuildingsCharley ends on the same idea: nobody wants to change their approval chain. MakersHub is transparent about where every bill sits and who is holding it, so the chain you already run becomes one everyone can see.
Not every business needs conditional rules. If you run one company, don't track costs by job or project, and have two or three people who approve everything, a dollar threshold is clear and easy to audit. Adding conditions you don't need only makes the rules harder to read.
The signs you have outgrown it are practical ones: someone regularly reroutes bills by hand, approvers receive bills they cannot judge, the owner keeps seeing routine supplier bills, or the real rules exist only in one person's head. Any one of those means the matrix you run is already conditional, and the software just isn't holding it.
If you are comparing tools, our comparison of accounts payable approval software covers how eight platforms handle sign-offs, and our guide to configurable AP software looks at routing beyond dollar amounts. Construction teams can start with our AP approval software guide for construction and trades.
An accounts payable approval matrix is a written set of rules that decides who must approve each bill before it is paid, often called a delegation of authority or schedule of authority. Most start with dollar thresholds, and businesses that track costs by job or entity add conditions for the job, project, entity or vendor. MakersHub holds the whole matrix as rules that run on every bill, so the matrix does not live in someone's head.
Dollar amount measures how much is at risk, but in job-costed businesses the right approver usually depends on where the cost is going. A dollar threshold works on its own for a single company with a handful of approvers. MakersHub lets amount sit alongside job, project, entity, vendor and other conditions in the same rule.
Yes, as long as routing runs after the bill is coded, because job numbers, entities and cost codes are usually added during coding rather than printed by the vendor. MakersHub captures and codes the bill, including its line items, before any approval rule runs, so rules can use the coding.
A stacking rule adds an approver to a bill without removing anyone already on it, while an override rule replaces the whole approval chain when it matches. Most real policies need both, along with a clear order for which rule wins. MakersHub supports both kinds in its rebuilt approval workflow.
Assign delegates ahead of time, and route to groups rather than single people where you can. MakersHub supports user groups and delegation, and approvers can approve from email in one click from any device, so a bill does not wait for someone to get back to a desk.
No. Bill approval confirms that a bill is valid and coded correctly, while payment authorization decides whether, when and how money is released. MakersHub keeps the two steps separate by design, with different roles for each and both recorded in the audit trail.
Not if the software can hold the rules you already use. Most teams start by documenting who approves what today and why, then set those rules up as they are. MakersHub is set up around how your business already works, and our team configures it with you.
The approval rules you run today took years to get right. We built MakersHub to hold them exactly as they are. If yours live in a spreadsheet, a sticky note or someone's memory, show us and we'll map them. Get started with MakersHub.
Sources: Association of Certified Fraud Examiners, Occupational Fraud 2026: A Report to the Nations, key findings and press release, May 2026; U.S. Government Accountability Office, Standards for Internal Control in the Federal Government (GAO-25-107721), May 2025; Oracle Fusion Cloud Financials documentation, invoice approval rules; MakersHub published customer stories.
See how MakersHub helps organizations that track spend by project, location, program or entity get every line of every bill coded and approved before it's paid.