ApprovalMax and similar approval workflow tools give finance teams the technical infrastructure to enforce financial controls. Whether those controls are actually in place depends on how the tool is configured, and whether the configuration reflects genuine governance principles rather than a digital version of the existing manual process. The financial control principles that matter in AP are not complicated. Applying them consistently in a workflow tool is where most implementations fall short.
What financial control looks like: principles versus common practice
Financial control principle | What it means | Common gap in approval workflow implementation |
|---|---|---|
Segregation of duties | Different people initiate, approve, and pay | Invoice creator can also approve, or approver can also publish to ledger |
Documented approval limits | Defined values per role | Thresholds exist in policy but are not enforced by the workflow |
Independent supplier verification | Bank details confirmed against an independent source | Approval step proceeds without checking changed bank details |
Duplicate prevention | Same invoice cannot be paid twice | Duplicate check is manual or post-payment |
Exception escalation | Unusual invoices follow a separate, higher-scrutiny path | Exceptions are noted but proceed through standard routing |
Audit trail completeness | Approval record includes supplier data, not just the decision | Audit trail records who approved but not what was verified |
Time-bound approvals | Invoices are approved within defined periods | Invoices sit in queues without escalation |
Why financial control principles exist
Financial controls in AP are designed to protect against two types of failure: intentional fraud and unintentional error. Both occur in Australian SMBs at meaningful rates. The Reserve Bank of Australia identifies cash flow management - including payment errors - as one of the primary operational challenges for small businesses. Ardent Partners research found that manual AP processes produce errors in 5-10% of invoices. Intentional fraud via payment redirection cost Australian businesses $152.6 million in 2024 according to the National Anti-Scam Centre.
The financial control principles in AP address both failure types. They are not bureaucratic overhead - they are the structural conditions under which AP becomes reliably safe to operate at scale.
Principle 1: segregation of duties must be real, not nominal
Segregation of duties means the person who creates the financial transaction and the person who authorises it are different individuals. In AP, this means:
The person who enters a bill into the accounting system should not also approve it
The person who approves a bill should not also execute the payment
An administrator with full system access should not be the sole approver for any bill category
In practice, financial controls around segregation of duties are frequently nominal rather than real. A finance team member with Xero Adviser access can create, approve, and publish a bill without any additional sign-off. In ApprovalMax, the routing rules may require a second approver - but if that second approver holds full accounting system access, the approval adds process without genuinely adding control.
A financial controller at a Townsville healthcare provider configured ApprovalMax’s approval rules to require two sign-offs for any invoice above $5,000. What was not addressed: the second approver held Xero Adviser access and could approve the invoice in Xero directly, bypassing ApprovalMax entirely. The control existed on paper. It did not exist in practice.
What good looks like: Each approval stage is held by a different person with clearly bounded system access. No one individual holds the ability to complete the full invoice-to-payment sequence without a second actor. This is documented in the authority matrix and reflected in the user permission configuration.
Principle 2: approval limits must be enforced, not documented
Most Australian SMBs have some form of delegation of authority that specifies which roles can approve which invoice values. In the majority of cases, this authority matrix exists as a policy document. The workflow tool is not configured to enforce it - approvers are expected to know the limits and comply.
This creates a compliance risk that is invisible until it materialises. When an operations manager approves a $45,000 invoice that their documented authority limits to $10,000, the approval is recorded in the system as valid. There is no flag, no escalation, and no audit evidence that the limit was breached.
What good looks like: Approval routing in the workflow tool is configured to match the authority matrix exactly. Invoices above a threshold cannot be approved by a role below that threshold - the system routes them to the correct approver automatically. Value-based routing is configured in ApprovalMax’s matrix rules, not left to the approver’s judgement.
Principle 3: supplier verification is a pre-approval control, not an assumption
Most approval workflows verify the approval decision - who approved, when, and for how much. What they rarely verify is whether the underlying invoice is from who it appears to be.
Payment redirection fraud in Australia works by sending an invoice that appears legitimate - correct supplier name, familiar format, plausible amount - but with altered bank details. The approval workflow routes it to the approver, who confirms the amount looks right and the supplier name is familiar. The payment goes to the attacker.
Supplier verification at the approval step means the approver is presented with the supplier’s current bank details and a comparison against the last verified payment record. If they differ, the invoice is flagged before approval, not after payment.
What good looks like: The platform compares incoming invoice bank details against historical records at the receipt stage. Any change triggers an exception flag that routes to a senior reviewer before the invoice enters the standard approval queue. This is a pre-approval control, not a post-payment reconciliation.
Platforms that handle the extraction and approval steps separately - Dext for capture, ApprovalMax for approval - rarely share this supplier history comparison between tools, because the historical data lives in the extraction tool while the approval decision is made in the workflow tool. This is the context-loss gap that matters most for fraud prevention.
Principle 4: duplicate prevention belongs at intake, not at reconciliation
Most AP processes have some form of duplicate detection. The most common form is a finance team member noticing that an invoice reference number looks familiar. The second most common is a supplier statement reconciliation that reveals a double payment after the fact.
Neither of these is a control. The first is a memory-based check that degrades under volume. The second is a correction mechanism, not a preventive one.
What good looks like: Duplicate detection runs automatically when an invoice arrives, comparing incoming reference numbers, supplier names, and amounts against existing bills in the accounting system. Matches above a defined threshold are flagged before the invoice enters the approval queue. In a well-configured AP workflow, a duplicate submitted 60 days after the original is caught at receipt, not discovered during the quarterly payment review.
Principle 5: exceptions require a separate, higher-scrutiny path
Standard approval routing routes invoices to the appropriate approver based on value and supplier type. Exceptions - invoices that don’t match purchase orders, invoices from new or infrequent suppliers, invoices with changed payment details - require a different path.
The most common implementation failure is routing exceptions through the same workflow as standard invoices, with a flag visible to the approver. This places the burden of exception assessment on the approver who may lack the information or authority to resolve it. An invoice flagged as ‘supplier bank details differ from last payment’ should not proceed to a standard approver - it should stop and escalate to a senior reviewer before approval is possible.
What good looks like: Exceptions are held at the intake stage and routed to a dedicated exception reviewer - not to the standard approval path with a flag. The exception is resolved before the invoice proceeds. Unresolved exceptions do not accumulate in the standard approval queue where they may be approved under volume pressure.
Principle 6: the audit trail must capture supplier data, not just approval events
The minimum audit trail - who approved, when - satisfies basic record-keeping requirements. An audit-ready trail captures the full context of the approval decision: the supplier’s bank details at the time of approval, the invoice amount and reference, the approver’s role and authority level, and any exception flags that were present at the time.
This depth matters when a disputed invoice requires evidence of what information was available to the approver. ‘J Smith approved on 15 March 2026’ does not establish that J Smith had authority to approve, that the supplier’s bank details matched historical records, or that the invoice was not a duplicate of a previously paid bill. A complete audit trail shows all of this from the system record.
What good looks like: The audit trail records the approval decision plus the supplier data visible at point of approval, the approver’s role and defined authority limit, and any exception flags that were active at the time. This record is tamper-resistant - it cannot be edited after the fact.
Practical implications for ApprovalMax users and evaluators
For finance teams using ApprovalMax or evaluating it:
ApprovalMax addresses principles 2 (approval limits enforcement via matrix rules), 6 (audit trail for approval events), and 7 (time-bound approval escalation) reasonably well when configured correctly. The configuration step is where most implementations fall short - the matrix rules need to reflect the actual authority matrix, not a simplified version.
ApprovalMax does not natively address principle 3 (supplier bank detail verification at intake) or principle 4 (duplicate detection before approval). These require either a separate tool - Dext for extraction, with supplier history checked manually - or a platform that handles validation before the approval step.
For construction and industrial businesses where supplier bank detail verification is the highest-priority control, the gap in the Dext-plus-ApprovalMax combination is the gap that matters most. An integrated platform that handles validation, exception routing, and approval in a single workflow closes the gap without requiring coordination between separate tools.
Pulsify’s approval workflows are configured to enforce all six principles above - with validation and exception review handling the pre-approval supplier verification that separate extraction tools cannot provide.
Checklist: does your approval workflow follow these principles?
Is segregation of duties real (not just nominal) - can the invoice creator bypass the approval step?
Are approval limits enforced by the workflow configuration, not just by policy?
Does the workflow verify supplier bank details against historical records before routing?
Does duplicate detection run at intake, not post-payment?
Do exceptions follow a separate, higher-scrutiny path rather than the standard approval queue?
Does the audit trail capture supplier data at approval, not just the approval event?
Are overdue approvals escalated automatically, or do they wait indefinitely in the queue?
FAQ
What are the core financial controls in accounts payable?
The core AP financial controls are: segregation of duties (different people initiate, approve, and pay), documented and enforced approval limits by value and role, independent supplier verification before payment, duplicate invoice prevention at intake, exception escalation for anomalous invoices, and a complete audit trail. These controls protect against both fraud and unintentional error.
Does ApprovalMax enforce all financial control principles?
ApprovalMax enforces approval routing with conditional logic and maintains an audit trail for approval decisions. It does not natively verify supplier bank details before routing, detect duplicates at intake, or handle the exception pre-clearance step. These functions require either a separate tool integrated with ApprovalMax or a platform that combines validation and approval in a single workflow.
What is segregation of duties in accounts payable?
Segregation of duties means the AP functions of invoice entry, approval, and payment are performed by different individuals. The goal is to ensure no single person can complete the full sequence of creating, approving, and paying an invoice without a second actor involved at each stage. In accounting software, segregation requires that user permissions are configured to match this principle, not just that a policy document states it.
Why do approval limits need to be enforced by the workflow, not just by policy?
A policy document specifying approval limits relies on the approver knowing the limit and choosing to comply. Under volume pressure, limits are commonly exceeded without flagging. Workflow enforcement means the system routes the invoice to the correct approver based on value automatically - an operations manager cannot approve a director-level invoice because the workflow does not present it to them. The control is in the system, not in the individual’s memory.
What should an AP audit trail include beyond who approved what?
Beyond the basic approval event (who, when, decision), an audit-ready AP trail should include: the supplier’s bank details at the point of approval, the approver’s role and their defined approval authority limit, any exception flags that were active at the time of approval, and a record of any escalation steps. This context is what distinguishes an evidence-ready audit trail from a basic processing log.