Most businesses buy AP software and then figure out how to use it. Demos show the interface, the integration with Xero or MYOB, and the approval queue view. The business signs up, configures the basic settings, and discovers six months later that the tool is enforcing a process they didn’t actually intend to design.
The accounts payable system - the rules, structures, and controls that govern how invoices move from receipt to payment - needs to be designed before software is selected. Software enforces whatever rules you give it. If the rules haven’t been clearly defined, the software implements whatever the implementation consultant guesses you want, or whatever matches the default settings.
Five decisions determine whether any AP software will work. None of them are software decisions.
Decision 1: How Many Approval Tiers Do You Need?
An approval tier is a level in the authorisation chain. Each tier is triggered by either a dollar threshold or a category rule. The question isn’t “who currently approves invoices” - it’s “who should be required to approve invoices at different value levels, and what triggers an escalation to the next level?”
Most Australian SMBs need two to three tiers. A first-line approver handles routine invoices within a defined value threshold - this might be a project manager, department head, or operations manager. Above a second threshold, a financial controller or CFO approval is required. Above a third threshold, a director or board approval is needed. Capital expenditure, new suppliers, and invoices with anomalies might trigger escalation regardless of amount.
Document this as roles, not names. “Project Manager: up to AU$5,000” rather than “Sarah: up to AU$5,000.” When Sarah leaves, the system should route to whoever holds the project manager role, not fail silently because the named approver is no longer in the business.
The other thing to decide here is coverage: what happens when the designated approver is unavailable? Who is the backup? The answer needs to be in the system, not in an email thread from when the primary approver went on leave last Christmas.
Decision 2: Delegation of Authority Limits by Role and Category
Once the tiers are defined, each role needs explicit limits. This is the delegation of authority (DoA) - the formal statement of what each role can approve independently. It needs to be a table, not a conversation.
| Role | Standard invoice limit | Capital expenditure | New suppliers | Changed bank details |
|---|---|---|---|---|
| Project Manager | AU$5,000 | Not authorised | Not authorised | Not authorised |
| Financial Controller | AU$25,000 | AU$10,000 | Authorised to approve | Escalate to CFO |
| CFO | AU$100,000 | AU$50,000 | Authorised to approve | Authorised to approve |
| Director | Unlimited | Unlimited | Unlimited | Unlimited |
Category-specific rules matter because they override value thresholds in the right circumstances. A project manager approving an AU$3,000 invoice for routine site materials is different from the same person approving an AU$3,000 invoice from a supplier they’ve never worked with before. The category rule triggers a different approval path even though the amount is within their standard limit.
If this table doesn’t exist before you configure your AP software, you’ll configure it based on what feels right at the time, and you’ll find out what’s wrong about six months later when someone approves something they shouldn’t have.
Decision 3: How New Vendors Are Onboarded
Vendor onboarding is where most Australian SMB AP systems have no process at all. A new supplier is set up when the first invoice arrives: name entered, bank details from the invoice saved, and the invoice gets processed like any other.
This is the highest-risk point in the AP cycle. New suppliers have no payment history to compare against. Changed bank details on a first invoice are indistinguishable from legitimate details. A ghost vendor - a fraudulent entity created to receive fraudulent payments - gets created at this point if there’s no verification step.
Decide what happens before a new supplier can receive a payment:
- ABN verified against the ATO’s ABR and matched against the supplier name on the invoice
- Bank details confirmed by phone to the supplier’s main contact number - not the number on the invoice, a number from prior correspondence or from a separate source
- The supplier record formally approved, ideally by someone other than the person who entered it
This doesn’t take long. The phone confirmation is the most time-consuming step and it takes five minutes. But it needs to be a mandatory process, not a step that happens when someone thinks of it.
For the validation and exception review layer to catch anomalies on new suppliers, the onboarding process needs to create a clean baseline record. If the first record is set up from an unverified invoice, the baseline is wrong and subsequent checks compare against fraudulent data.
Decision 4: The Exception Escalation Path
An exception is anything that doesn’t match expectations: a changed bank account number, an invoice without a matching purchase order, a potential duplicate, an amount that exceeds the approver’s limit, or a supplier whose ABN has become inactive.
What happens to an exception determines whether your controls are real or nominal. The two failure modes are:
Exceptions that sit in the standard approval queue with a flag, waiting for the regular approver to deal with them. Under volume, these get approved because the path of least resistance is to approve and move on. The flag doesn’t make the invoice any harder to approve - it just adds a note.
Exceptions that have no defined resolution path, so they’re approved or rejected based on whoever has access at the time and whatever seems reasonable in the moment.
For each exception type, define: who reviews it, what they need to do to resolve it, and how long they have before it escalates further. A changed bank detail exception should route to the CFO, not the standard approver, with a requirement for a callback verification and a 24-hour resolution window. A no-PO-match exception should route to the project manager who raised the original PO, not to the AP officer who can’t resolve the mismatch independently.
This decision feeds directly into how the AP system is configured. If you haven’t mapped exception types to resolution owners before implementation, the system will have a generic “exceptions” bucket that nobody knows how to process correctly.
Decision 5: Separate Payment Approval From Payment Execution
This is the segregation of duties decision, and it’s the one most often skipped because it requires changing who does what.
The person who approves an invoice and the person who executes the payment should not be the same individual. For any significant payment - set your own threshold, but most businesses start at AU$5,000 - a second person should see it before funds leave the account.
In a small finance team, this is often operationally awkward. The bookkeeper approves and pays. The financial controller approves and pays. But the control doesn’t require a full-time second AP officer. It requires:
- A rule that invoices above a threshold require a second approver before the payment run
- Or a rule that the payment run summary goes to a reviewer (the business owner, the CFO) for explicit release before the bank transfer is processed
- Or a second signatory requirement on the banking platform itself, separate from the AP tool
Which of these fits your business depends on your size and structure. But the decision needs to be made before software is selected, because different tools enforce this differently - some via approval chain configuration, some via payment run release controls, and some not at all.
For a practical guide to configuring these controls in your accounting setup, the AP automation page covers how Pulsify’s workflow layer enforces each of these decisions once they’re defined.
Why This Order Matters
The consistent failure mode in AP software implementations is buying the tool first and designing the process second. The tool gets configured to match how things currently work, which means it automates the existing process - including the gaps in the existing process.
A business that doesn’t have a defined vendor onboarding process configures the AP tool without a vendor onboarding step. A business without a documented DoA configures approval routing that roughly matches current practice but doesn’t enforce the limits anyone agreed to. A business where one person controls approval and payment configures the tool to route invoices through that person without a second checkpoint.
None of this is the software’s fault. The tool enforces the rules it’s given. The rules need to exist, and be deliberately designed, before the configuration starts.
Work through these five decisions with the relevant stakeholders - typically the financial controller, CFO, and business owner - before evaluating any software. The software evaluation then becomes about whether each tool can enforce the decisions you’ve made, rather than whether the tool has the right demo environment.
Sources: ATO - ABN Lookup · ACCC National Anti-Scam Centre - Targeting Scams Report 2024 · ATO - Record-keeping requirements for business
Further reading: Best AP Automation Software Australia 2026 · Accounts Payable Software Australia: Buyer’s Guide · The Final Decisive Comparison of Invoice Processing Automation Software