Most accounts payable problems are not software problems. They are control design problems that software then makes faster.
A business that cannot say who is allowed to approve a fifty thousand dollar invoice, or how a supplier’s bank details get changed, does not have a tooling gap. It has a framework gap. Automating on top of that just moves the errors through more quickly.
This guide sets out a practical accounts payable framework: the control layers that matter, how to set approval thresholds, and where automation genuinely belongs. It is written for Australian finance teams, so it assumes GST, ABN validation and the local payment rails.
What an accounts payable framework actually is
The framework is the documented answer to five questions:
- Who can commit the business to spend, and up to what value?
- What evidence is required before an invoice is paid?
- Who checks that evidence, and who is barred from checking it?
- How do supplier details, especially bank details, get created and changed?
- What happens when something does not match?
Everything else, including which software you buy, follows from those answers. A framework is not a flowchart of the AP process. It is the set of rules that decide what the flowchart is allowed to do.
The distinction matters because the two most expensive AP failures, payment fraud and duplicate payment, are both control failures rather than process failures. The process ran perfectly. It just ran on a bad instruction.
The five control layers
1. Delegation of authority
A delegation of authority sets who approves what, by value and by category. It is the backbone of the framework and the thing most often left implicit.
A workable structure for an Australian mid-market business:
- Up to $1,000: budget holder approval only
- $1,000 to $25,000: budget holder plus finance manager
- $25,000 to $100,000: adds CFO or financial controller
- Above $100,000: adds director or board sign-off
- Any capital item: separate approval path regardless of value
Two rules make it work. Every band must be documented with named roles rather than named people, so it survives someone leaving. And each additional approver must be reviewing something the previous one could not see, otherwise you have added delay and called it control.
2. Segregation of duties
No one person should be able to take a payment from end to end. In practice this means the person who onboards a supplier or changes bank details must not also approve invoices or release the payment run.
This is the control most often broken in small teams, usually for understandable reasons: there are three people in finance and someone is on leave. If you genuinely cannot segregate, compensate with detection. A weekly report of all supplier bank detail changes, reviewed by someone outside AP, catches most of what segregation would have prevented.
3. Matching and verification
Three-way matching, purchase order to goods receipt to invoice, is the standard control for goods. It answers three separate questions: did we agree to buy this, did we receive it, and does the invoice match what we agreed.
Services rarely fit that model. For services, substitute a documented milestone or timesheet approval by the person who received the work. The control is the same in principle: someone independent of the supplier confirms the thing was delivered before it is paid.
Non-PO spend needs its own path. Trying to force utilities, rates and subscriptions through a PO process produces workarounds, and workarounds are where controls go to die.
4. Supplier and bank detail integrity
This is where the money actually goes missing. Payment redirection fraud works by changing a legitimate supplier’s bank details, usually via a convincing email from a compromised or spoofed account.
The control is unglamorous and it works: any bank detail change is verified by phoning the supplier on a number already held on file, never a number in the email requesting the change. The verification is logged with the name of the person called and the date.
New supplier onboarding follows the same logic. Validate the ABN, confirm GST registration status, and confirm bank details independently before the first payment rather than in the payment run.
5. Exception handling
A framework that only describes the happy path is not finished. Decide in advance what happens when an invoice arrives without a PO, when the price differs from the order, when a supplier chases an invoice nobody can find, and when a duplicate is suspected.
Each exception needs an owner and a deadline. Exceptions with neither become the aged payables balance that nobody can explain at year end.
Setting thresholds that people follow
Thresholds fail when they are set from theory. Set them from your own data.
Pull twelve months of invoices and look at the distribution. If eighty per cent of invoices are under $2,000 and account for twelve per cent of spend, a $1,000 first threshold means your senior people spend their time on the twelve per cent. Moving the first band to $2,500 typically removes half the approval load and almost none of the risk.
Then check the other tail. If a handful of invoices account for most of the value, those deserve more scrutiny than a single approval, regardless of how well you know the supplier.
The measure of a good threshold is not how much it catches. It is how much genuine review each approver is able to give. An approver reviewing four hundred invoices a month is rubber-stamping, and a rubber stamp is worse than no control because it creates a record suggesting review took place.
Where automation belongs, and where it does not
Automation belongs on the checks. It does not belong on the approval.
The checks are mechanical, repetitive, and exactly the kind of work people do badly at volume: does this ABN exist and is it registered for GST, does the GST calculation reconcile, have we seen this invoice number from this supplier before, does the total match the purchase order, are the bank details the ones we hold on file, is this coding consistent with how we coded the last twelve invoices from this supplier.
Run those on every invoice and the exceptions surface before anyone opens the file. That is a genuine control improvement, because sampling becomes unnecessary when the whole population is checked.
The approval is a judgement, and judgement should stay with a person. So should anything irreversible. dexIQ is built on exactly that line: a human approves every action by default, and the system never takes an irreversible step such as releasing a payment or changing bank details on its own. As confidence builds you can switch on autopilot for predictable, low-risk work, bounded by limits you set.
That boundary is the whole point. Automation that approves its own payments has not improved your framework. It has removed it.
Making the framework survive contact with reality
Three things separate a framework that works from a document nobody reads.
Put it where the work happens. A policy in a shared drive is a policy nobody consults. The thresholds should be enforced in the system that routes the invoice, so the correct path is the default rather than something to remember.
Review the exceptions, not the approvals. Approved invoices that matched are not interesting. Spend the review time on what did not match, what was overridden, and who overrode it.
Re-test annually. Thresholds drift out of date as the business grows. So do delegations, especially after a restructure. An annual walkthrough of five real invoices, tracing each from arrival to payment, will find more than a policy review will.
Where to start
If you are building this from nothing, the order that produces the most control for the least effort:
- Document the delegation of authority and get it signed off
- Fix supplier bank detail verification, because that is where the fraud is
- Separate supplier maintenance from payment release
- Define the non-PO path so it stops being a workaround
- Automate the checks, once you know what the rules are
The last step is deliberately last. Automating an undocumented process encodes whatever it currently does, including the parts that are wrong.
If you want to see what the checks look like running on every invoice, with a person still approving, talk to our team or read how AP inbox management handles the arrival end of the process.