Framework
The Reversibility Test
A framework for deciding which accounts payable decisions are safe to automate and which require a human checkpoint.
The principle is simple: if an error in this decision can be corrected before a payment is made, it is a reversible decision and can be automated safely. If an error triggers a payment to the wrong account, changes a vendor record, or creates an obligation that is difficult to unwind, it is an irreversible decision and requires a human checkpoint - regardless of how mature the automation is.
Why this boundary matters
Most AP automation content treats automation as a spectrum: the further along you go, the better. The Reversibility Test rejects that framing. It draws a hard line between decisions where automation reduces cost and error, and decisions where automation removes a control that was doing real protective work.
The failure mode is not automation that works badly. It is automation that works correctly on a fraudulent input. An AI system that extracts bank details from an email and updates a vendor record without human review is functioning as designed - the problem is that the design removed a checkpoint that caught fraud.
Payment redirection fraud cost Australians AU$166.8 million in 2025 according to the ACCC - up 9.3% from the prior year. The majority of these losses occurred not because automation failed, but because human review was bypassed at the irreversible-decision boundary.
Reversible decisions - safe to automate
These decisions are appropriate for full automation with exception handling. Errors are detectable and correctable before any financial transaction occurs. Human attention should be reserved for the exceptions that automation cannot resolve, not applied to every instance.
Invoice data extraction
Extraction errors are caught during human review before the invoice reaches the ledger. A wrong total or misread supplier name is corrected in seconds. No financial transaction has occurred.
Line-item account coding
A line item coded to the wrong account can be corrected with a journal entry or credit note. The error is visible at reconciliation and has no immediate financial consequence.
GST classification
An incorrect GST code surfaces as a reconciliation discrepancy before BAS lodgement. Caught before lodgement, it is a correction. Missed after lodgement, it is an amendment - still reversible, though with more effort.
Duplicate detection
A false positive (flagging a legitimate invoice as a duplicate) causes a brief processing delay. A false negative (missing a duplicate) results in a second invoice reaching the approval queue - where a human can catch it. Neither outcome is irreversible.
PO matching flags
A matching exception raises a question: does this invoice match the approved order? The question routes to a person. No payment has been made. The mismatch is investigated, resolved, or escalated - all reversible.
Approval routing
Routing an invoice to the wrong approver causes a delay. The invoice returns to the queue. It has not been paid. Routing errors are annoying, not consequential.
Irreversible decisions - require a human checkpoint
These decisions cannot be safely automated without a human verification step. The cost of an error - a misdirected payment, a fraudulent vendor record, an unauthorised transaction - is not correctable after the fact in the way a coding error is. Automation assists the process; it does not replace the checkpoint.
Payment authorisation
Why it cannot be automated
Once a payment is sent to a supplier's bank account, recovering it is difficult and not guaranteed. Payment redirection fraud exploits this: attackers substitute a fraudulent bank account, the payment is made to the wrong account, and the funds are withdrawn before the error is discovered. The ACCC reported AU$166.8 million in payment redirection losses in Australia in 2025.
Required control: Human sign-off above defined thresholds. Automated routing is appropriate; automated authorisation is not.
Vendor bank detail updates
Why it cannot be automated
If a supplier's bank account changes and the system updates the vendor record without verification, all future payments go to the new account. If the update was fraudulent - a common business email compromise tactic - those payments go to an attacker. Bank detail changes are the primary mechanism of invoice fraud in Australia.
Required control: Any change to a supplier's bank account details triggers a manual verification step before the updated record is saved and used for payment.
New supplier first payment
Why it cannot be automated
A new supplier has no historical behaviour to compare against. ABN verification confirms the entity exists; it does not confirm the bank account belongs to that entity. The first payment to any new supplier is the highest-risk payment in the AP process.
Required control: New supplier approval requires a human to confirm the payment destination before the first payment runs, regardless of how clean the invoice looks.
Approval threshold overrides
Why it cannot be automated
Overriding an approval threshold - processing a payment above the authorised limit without the required sign-off - removes the delegation-of-authority control. If the override becomes a pattern (e.g. when approvers are unavailable), the threshold policy becomes effectively unenforced.
Required control: Threshold overrides require explicit escalation to a higher-authority approver. The system should not allow threshold bypass; it should route to the next approver in the hierarchy.
Applying the test to any AP decision
When evaluating whether to automate a specific step in your AP workflow, run through these questions. A single "irreversible" answer should be treated as a flag that the decision requires a human checkpoint.
If this decision is wrong, can it be corrected before a payment is made?
Does this decision change where money goes, or change a vendor record that affects future payments?
Is the error detectable during normal review before any financial transaction occurs?
Does getting this decision wrong require a journal entry, credit note, or external party to resolve?
Is this a one-time setup or a first-time action with a supplier or account?
How Pulsify implements the Reversibility Test
Pulsify's AP workflow is designed around this boundary. Reversible decisions are handled by the automation engine. Irreversible decisions are flagged for a person to check.
Invoice extraction & coding
AI handles extraction and line-item coding for all invoices. Each bill shows Ready, Check or Needs fix, so a reviewer knows where to look.
GST classification
GST treatment is applied at line level from supplier history. GST charged by an ABN not registered for GST is flagged.
Duplicate detection
Checked at intake. A possible duplicate is flagged and the approver has to confirm before approving.
Vendor bank detail changes
Bank details on an invoice are compared with the supplier record in Xero or MYOB. A mismatch is flagged for the approver.
Payment authorisation
Approval workflows route each bill to the right human approver by supplier, amount, account or job. Pulsify never pays suppliers. You pay from Xero or MYOB.
New supplier first payment
A supplier not found in Xero or MYOB is flagged on the bill for the approver to check.
Related frameworks and guides
The AP Controls Stack
Five layers every AP workflow must cover
AP Automation Glossary
15 AP automation terms defined
What gets automated in AP - 2026
Detailed analysis of the automation boundary
AP fraud prevention with PO matching
How PO controls stop fraud at intake
Vendor bank detail validation
How Pulsify checks supplier bank details
Invoice approval workflows
How approval routing enforces policy
AP automation with the right boundaries built in
Pulsify automates the reversible decisions and flags the irreversible ones. Start a 30-day free trial with your Xero or MYOB account.