An approval policy is a rule: when this happens, these people must sign it off first. Good policies let you prove control to an auditor. Bad ones slow the team down and get worked around.
Here is how to set them up so they do the first without the second.
What you can gate
Xace can require approval on payments, batch payments, creating, editing and deleting payees, and FX trades. Every account starts with default policies. Your own custom policies override them.
How a policy is built
Each policy has five parts:
- When it applies. For payments, an amount range: greater than or equal to X, less than Y.
- Who approves. One or more named approvers. Add a second option to create an alternative path, so a request does not stall when someone is away.
- In what order. Any order, or a fixed sequence such as controller first, CFO last.
- How long it stays open. No expiry, or a set window.
- Scope. Limit it to certain users or roles, and choose whether it covers payments created through the API.
Roles sit underneath. Owner and Supervisor need no approval on their own payments. Standard users follow a four-eyes flow. Creators raise payments but cannot approve. Approvers do the reverse. Each role has its own payment and approval limits.
A baseline that works
For a finance team of four to eight. Adjust the amounts to your volumes.
- Under £10,000 - one approver, any order. Alternative: any Supervisor.
- £10,000 to £100,000 - two approvers, any order. Alternative: CFO alone.
- £100,000 and up - two approvers, in order, CFO last. No alternative. 48-hour expiry.
- Batch payments - two approvers, whatever the total.
- Payee creation and edits - one approver, always. This is the rule that stops invoice fraud.
- Payee deletion - one approver.
- FX trades - one approver above a modest amount, none below it.
Five gaps to avoid
- Gating payments but not payees. Changing a supplier's IBAN and then paying the "same" supplier is the classic attack. Rule 5 is not optional.
- No alternative approver. One named person with no OR path means every holiday is a bottleneck.
- Forgetting the API. If the scope toggle is off, programmatic payouts skip the policy entirely.
- Tiers with a gap. £0 to £10,000 and £10,001 to £100,000 leaves £10,000.50 uncovered. Use greater-than-or-equal on the bottom and less-than on the top.
- Expiry that is too short. Requests that expire get resubmitted, and resubmissions get rubber-stamped.
Review it quarterly
Every approval, rejection and override is logged against the user and entity. Once a quarter, look for policies that never fire and policies that fire all the time. The first are set too high, the second too low.
