Most Australian SMBs have an informal understanding of who approves what. The financial controller handles invoices up to a certain amount, the director sees anything large, and the owner signs off on anything unusual. Everyone broadly knows the rules, and the system works — until it doesn’t.
The problem is not that people are dishonest. It is that informal rules are not controls. They depend on the right people being available, remembering the policy, and having the time to apply it correctly under volume pressure. A delegation of authority (DoA) is what turns that informal understanding into a documented, enforceable policy.
This guide is specifically for 10-to-50-person private Australian businesses that do not yet have a formal DoA policy, or have one that exists only as a PDF that nobody reads. The goal is a policy that works when your financial controller is on leave, when invoices are arriving faster than normal, and when an unfamiliar supplier submits a payment request.
What a delegation of authority actually is — and what it is not
A delegation of authority defines who can approve what expenditure, up to what value, and under what conditions. It is a governing policy about financial authority in your business.
It is distinct from an approval matrix, which is the table that captures those rules in a structured format. The DoA is the decision about who holds authority. The approval matrix documents those decisions. Both need to exist before any software can enforce them.
What a DoA is not:
- It is not an IT configuration. Software enforces the policy, but the policy must exist independently of the software. If the system goes down, the policy still applies.
- It is not a job description. Authority limits define what someone can approve, not what their role involves generally.
- It is not a once-and-done document. The policy needs to be reviewed when staff change, when revenue grows, and at minimum annually.
The distinction that matters most: most Australian SMBs have neither a written DoA policy nor an enforced one. A PDF that was written three years ago and shared once via email is not an enforced policy. It is a statement of intent that most staff have forgotten, if they ever read it.
Why “everyone knows who approves what” is not a control
The informal approval system in most SMBs works most of the time, which is why it persists. The failure cases are not obvious until they happen.
Consider what occurs when:
- The financial controller goes on leave for two weeks and a new supplier invoice for AU$34,000 arrives — who approves it, and at what threshold?
- An employee processes a legitimate-looking invoice from a supplier they do not recognise — does the process flag it, or does it move to payment?
- A supplier’s bank account details change on an invoice that otherwise looks normal — who notices, and what does the process require them to do?
In an informal system, each of these scenarios depends on the person processing the invoice making the right judgment call under time pressure. Sometimes they will. Sometimes they will not. Neither outcome is traceable to a policy that was or was not followed, because the policy was never written down.
The ACCC’s National Anti-Scam Centre reported AU$152.6 million in payment redirection fraud losses in 2024 — a 66% increase from the prior year. The mechanism in most cases is simple: an invoice that looks legitimate but contains changed bank details. The approval process passes it through because no one’s role includes checking that specific thing. A DoA with a category-based trigger for bank detail changes would have caught it before payment.
Step 1: Define roles, not names
The first design decision in any DoA is to build it around roles rather than the names of current staff. The policy should survive a personnel change without requiring a complete rebuild.
For a typical 20-person Australian business, the relevant AP approval roles are:
| Role | Position in approval hierarchy |
|---|---|
| AP officer / bookkeeper | Invoice entry and coding; no independent approval authority |
| Operations manager / team lead | Approves routine operational invoices within threshold |
| Financial controller | Approves above operations manager threshold; reviews exceptions |
| CFO or finance director | Approves above financial controller threshold |
| Managing director / owner | Final authority for high-value and category-triggered items |
Map your current staff to these roles separately, and keep that mapping in a staff register that is updated when people join or leave. The DoA document references roles; the staff register records who holds each role.
This matters because a policy that says “Sarah approves invoices up to AU$15,000” becomes useless the moment Sarah leaves. A policy that says “the financial controller approves invoices up to AU$15,000” survives the transition.
Step 2: Set dollar thresholds that reflect your actual risk profile
Threshold values should be calibrated to your business’s financial reality — specifically, at what invoice value does an approval error represent material risk?
A practical starting point for a 20-person Australian business processing mixed operational and capital invoices:
| Threshold | Approval required | Notes |
|---|---|---|
| Under AU$2,000 | AP officer | Routine suppliers only; recurring invoices pre-approved by category |
| AU$2,001 to AU$10,000 | Operations manager or financial controller | Standard operating invoices |
| AU$10,001 to AU$50,000 | Financial controller + director sign-off | All invoices in this range require two approvers |
| AU$50,001 to AU$150,000 | Director | Must be accompanied by supporting documentation |
| Above AU$150,000 | Board resolution or two-director approval | No single-director sign-off above this threshold |
These are starting points. A wholesale distributor whose regular stock invoices run to AU$80,000 needs different thresholds than a professional services firm whose largest regular invoice is AU$8,000. The test is: at which value does a single approval error create meaningful financial exposure for your business?
Do not set thresholds at round numbers simply because they feel clean. Set them at the values that reflect your actual invoice distribution and risk tolerance.
Step 3: Add category-based triggers — these matter more than dollar thresholds
Dollar thresholds catch large invoices. Category-based triggers catch risky invoices, regardless of value.
The following categories should trigger escalated approval in almost every Australian SMB context:
New supplier invoices. Any invoice from a supplier that has not previously been paid requires a separate validation step before entering the normal approval workflow. This is the highest-risk category for fraud and error.
Bank detail changes. If a supplier invoice presents bank details that differ from what was recorded in the last payment, that change must be flagged and verified before the invoice proceeds. Verbal or email confirmation from the supplier is not sufficient — the verification should follow a documented process and be recorded.
Capital expenditure. Any invoice categorised as capex — equipment, fit-out, vehicles, significant IT — should require director approval regardless of amount. The materiality threshold for capex is typically lower than the materiality threshold for operational invoices.
Unbudgeted spend. Invoices for items not included in the approved operating budget require a documented explanation and escalated sign-off before payment.
Variations to existing contracts. An invoice for more than the contract value, or for a scope variation not formally approved in writing, requires a separate approval step that references the original contract.
These category triggers are what most DoA policies in Australian SMBs are missing. A policy with thresholds but no category triggers is an incomplete control.
Step 4: Handle absence — because gaps in coverage are when fraud happens
The DoA must address what happens when the primary approver for a given threshold is unavailable. Absence coverage is not optional.
For each approval role, document:
- Named delegate. Who holds approval authority when the primary approver is unavailable?
- Authority limit for the delegate. Does the delegate hold the same authority as the primary, or a reduced limit?
- Activation process. Is the delegation automatic when the primary is out of office, or does it require a formal notification step?
- Duration. How long does the delegation apply? Is it tied to specific dates, or open-ended?
A practical example: the financial controller is the primary approver for invoices between AU$10,000 and AU$50,000. When they are on annual leave, the operations manager holds delegated authority for invoices up to AU$15,000 only. Invoices above that threshold are held in a queue for the financial controller’s return, unless the director specifically authorises them to proceed.
The key design principle: the delegate’s authority should be limited, not unlimited. Granting full authority to a delegate “so the queue doesn’t back up” defeats the purpose of having a threshold structure in the first place.
Step 5: Write the policy — a formal document, not a Slack message
The DoA policy needs to exist as a formal written document. This is not a formality. It is the evidence that a control environment existed if the policy is ever tested by an external auditor, a bank, an insurer, or following an incident.
The document should include:
- The effective date and the version number
- The approval roles and their authority limits (by dollar threshold and by category)
- The category-based triggers that override dollar thresholds
- The absence and delegation rules for each role
- The review schedule (at minimum, annual)
- Sign-off by the managing director or board
The document should be stored in a location accessible to the finance team and retrievable on request. It is not confidential — the existence of clear approval rules is a governance positive, not a risk. It should not exist only in the accounting system or only in an email thread.
Why PDFs don’t work under pressure
Here is the problem with a policy that exists only as a document: people do not read documents when they are processing invoices under time pressure at month-end.
The financial controller is clearing a queue of forty invoices on the last day of the month. An invoice arrives from a supplier whose bank details have changed. The PDF policy says she needs to verify the change through a separate process. She knows this in principle. She is also aware that the supplier’s payment is overdue and the supplier has been chasing. She approves the invoice and plans to follow up on the bank detail change later.
This is not a failure of character. It is a failure of process design. A policy enforced by documents requires people to remember and apply it correctly every time. A policy enforced by software does not.
When the AP system is configured to flag changed bank details as a mandatory exception before the invoice can proceed — routing it to a separate review queue and preventing approval until the check is complete — the outcome is not dependent on the financial controller’s memory or her workload on that particular day.
Step 6: Configure the software to enforce the policy
Once the DoA policy is written, it needs to be translated into software routing rules. This is where the policy becomes a control.
Xero and MYOB do not enforce delegation of authority thresholds natively. Both record who approved a bill. Neither prevents someone from approving a bill above their authority limit. A financial controller in Xero with approval access can approve any bill value regardless of their documented authority limit.
Enforcing a DoA requires a dedicated AP approval workflow layer that:
- Routes invoices to the correct approver based on the dollar amount and invoice category
- Blocks approvals above the approver’s configured authority limit
- Escalates automatically when a threshold is exceeded
- Triggers separate exception workflows for category-based items (new suppliers, bank detail changes, capex)
- Records the authority rule that applied to each approval in the audit trail
The configuration in the software should mirror the written policy exactly. If the policy says financial controllers approve up to AU$25,000 and directors approve above that, the software should enforce that boundary — not rely on the financial controller choosing not to approve above their limit.
Pulsify’s approval workflow layer is configured to enforce the DoA structure, including dollar-tier routing, category triggers, and absence delegation. The validation and exception review layer handles bank detail changes and new supplier flags before invoices reach the approval queue, so the main approval workflow is working with verified data rather than trusting the invoice at face value.
What this looks like in practice: a 20-person distribution business in Brisbane
A Brisbane-based wholesale distributor processes approximately 120 invoices per month. Before implementing a DoA policy, the informal process was: the bookkeeper entered invoices, the financial controller approved most of them, and the owner signed off on anything that looked large or unusual.
The problem: “unusual” was subjective. The financial controller approved invoices she was comfortable with, which sometimes included items above the threshold the owner thought she had. There was no documented policy, so there was nothing to enforce.
After implementing a DoA:
- The bookkeeper enters and codes invoices but cannot approve any amount
- The financial controller can approve invoices up to AU$20,000 for operational suppliers
- The owner/director approves anything above AU$20,000, all capex items, and all new suppliers
- A category trigger flags any invoice where the supplier’s bank details differ from the last payment — these route to the owner for verbal verification with the supplier before the invoice can proceed
- When the financial controller is on leave, the operations manager holds delegated authority up to AU$8,000 only; everything above that is held in a queue
This structure was then configured in their AP system, so the routing happens automatically. The financial controller does not have to remember not to approve a AU$22,000 invoice — the system routes it to the director before she can approve it.
Month-end processing time dropped because exceptions were being caught earlier. The owner had greater confidence in what was being paid, not because the team was more careful, but because the process was more structured.
FAQ
What is a delegation of authority? A delegation of authority is a formal policy that defines who in a business can approve expenditure, at what dollar amounts, and under what conditions. In AP, it governs which roles can approve supplier invoices at different value thresholds and what additional approval is required for high-risk categories such as new suppliers, bank detail changes, and capital expenditure.
How do dollar thresholds work in a delegation of authority? Each role in the business is assigned a maximum invoice value they can approve independently. Invoices below that threshold proceed to that role for approval. Invoices above it are escalated automatically to the next authority level. Category-based triggers override these thresholds — a new supplier invoice may require director sign-off even if it is below the financial controller’s normal limit.
What software enforces a delegation of authority for Australian SMBs? Xero and MYOB do not enforce DoA thresholds natively. Both record approvals but do not block approvals above an approver’s configured limit. Enforcing a DoA requires a dedicated AP automation layer configured with the specific routing rules, thresholds, and category triggers defined in the written policy.
How often should a delegation of authority policy be reviewed? At minimum annually. Also when a key approver joins or leaves, when business structure changes, when revenue grows significantly, and after any AP incident or near-miss. The software configuration should be updated at the same time as the written policy — misalignment between the two creates a governance gap.
What is the difference between a delegation of authority and an approval matrix? The delegation of authority is the governing policy — the decision about who holds what authority and under what conditions. The approval matrix is the structured table that documents those decisions by role, threshold, and category. The DoA must exist as a policy before the approval matrix can meaningfully capture it, and the approval matrix must exist before a workflow tool can be configured to enforce the rules.
Sources: ACCC National Anti-Scam Centre — Targeting Scams Report 2024 · ATO record-keeping requirements for business · ASIC financial reporting and audit obligations · Australian Small Business and Family Enterprise Ombudsman — governance resources