---
title: "Setting up approval policies"
description: "Decide which payments, payouts, splits, direct debits and refunds need human sign-off in Qualy—who signs off, how many people it takes, and the conditions that decide when a policy applies."
lastModified: "2026-08-27"
lang: "en"
wordCount: 2403
url: https://qualyhq.com/training/approvals/setting-up-approval-policies
---
## Site navigation

- [For schools](/international-education/for-schools.md) — For international education schools
- [For agents](/international-education/for-education-agents.md) — For international education agents
- [Explore](/training.md) — Watch videos on how to use Qualy
- [About](/about.md) — Learn about Qualy's mission and values
- [Pricing](/pricing)
- [5-min demo](/demo.md)
- [Login](https://dashboard.qualyhq.com)

# Setting up approval policies

> Put the right money in front of the right people, and let the rest through.

## At a glance

- **Intended for:** Admins
- **Available in:** All plans
- **Reading time:** 6 minutes
- **Last updated:** 8th August 2026

## Quick summary

An approval policy answers three questions about one kind of item: what it applies to, who approves it, and under what conditions. Qualy ships five defaults—one each for transactions, payouts, payment splits, authorizations and refunds—covering your active admins and kept in step as people join and leave. Add your own policies above them for the movements that need different treatment: a second signature over a threshold, a named approver for one partnership, automatic approval for the routine. When an item is created, Qualy picks the first enabled policy whose conditions match, lowest priority number first.

## Overview

An **approval policy** is a rule that says: when an item of this kind shows up, and it looks like this, these people have to sign off before it moves.

Open the list from **Approvals** in the main menu, then the **Approval policies** button beside the heading. It is also listed under **Preferences** in your account settings, as **Approval policies**. Viewing the list needs the approvals view permission; creating and editing needs the approvals edit permission.

![The Approval policies list showing five default policies, each covering one item type at priority 1000 with the Any approver strategy](/images/training/approvals/setting-up-approval-policies/01-approval-policies-list.png)

You will already have five. Qualy seeds one default policy per item type as soon as your account has an admin who could approve, and keeps each one's approver list in step with your active admins. They sit at priority 1000, which leaves plenty of room to put your own rules above them.

The defaults are not a placeholder to be cleared out. Anything not matched by a policy flows through **ungated**—except refunds, which stop dead. Edit and layer rather than delete.

## Building a policy

**Create policy** opens one window with six parts, top to bottom.

![The Create policy window, with the Policy details fields above the Applies to cards for Transaction, Payout, Payment split, Authorization and Refund](/images/training/approvals/setting-up-approval-policies/02-create-policy-details-and-applies-to.png)

### Policy details

A **Name** your colleagues will recognise in a list, an optional **Description**, and a **Priority**. Lower numbers are evaluated first. The defaults are at 1000, so anything you want to take precedence needs a smaller number—start at 100 and leave gaps.

### Applies to

One policy governs one kind of item, and you pick it here:

- **Transaction** — incoming payments and charges.
- **Payout** — money paid out to partners and suppliers.
- **Payment split** — split allocations across parties.
- **Authorization** — direct debit mandates and the charges drawn against them.
- **Refund** — money returned to payers, including cross-currency refunds.

### Approval strategy

How many people it takes, and in what order.

![The five approval strategies as cards: Any approver, All approvers, Sequential, Round-robin and Auto-approve](/images/training/approvals/setting-up-approval-policies/03-approval-strategy-options.png)

- **Any approver** — approved as soon as any one approver says yes. The default everywhere.
- **All approvers** — every listed approver must approve before it passes. This is your two-signature rule.
- **Sequential** — approvers are asked one after another, in the order you set them.
- **Round-robin** — each request is auto-assigned to one approver in rotation, so the load spreads.
- **Auto-approve** — matching requests are approved automatically, no people needed.

### Approvers

Everyone eligible appears in the picker; tick the ones this policy asks. Under **Sequential** the order you tick them is the order they are asked, and the picker says so. Auto-approve hides this section entirely—it never reads it.

Approvers need the approvals action permission to decide. API-key identities count as real approvers and can be listed here; bot identities cannot.

### Conditions

Conditions narrow when the policy applies. Leave them all off and it matches everything of that item type. Tick more than one and they are **ANDed**—every condition must match.

![The Conditions checklist on a payout policy, with the Exchange rate movement section and Policy enabled toggle below it](/images/training/approvals/setting-up-approval-policies/04-conditions-and-exchange-rate-movement.png)

### Limit to a partnership

Applies the policy only to items belonging to one partnership. Useful when a single partner's money needs a named approver.

### Limit to teams

Applies only when the person who created the item belongs to one of the teams you pick.

### Match by recipient

**Supplier**, **Partnership** or **Self**—who the money is going to, expressed as a scenario rather than a specific account. Leave blank for any.

### Only entities flagged for manual review

Payouts and payment splits only. Matches just the items your payout settings or a partnership's **Require approval** toggle flagged, leaving operational holds alone. See the warning below before using it.

### Match by action

Authorizations only. **Authorization setup** is creating the mandate; **Charge** is drawing money against one that already exists. Gate them separately if setting up a mandate is routine but charging is not.

### Match by currency

Three modes: **Any currency**, **Same currency** (source and target match) or **Cross-currency (FX)**. Under FX you can list source and target currencies separately.

### Match by amount

A **Minimum** and **Maximum**, in the major unit—100 means $100.00. Either can be left blank for no limit. An item with no amount at all will never match a policy that gates on amount.

### Match by payment method

Limits the policy to specific methods. The default transaction policy uses this to gate manual external payments, partner-settled payments and balance offsets—the three that genuinely need a person—while leaving reconciled bank transfers to advance on their own.

### Exchange rate movement

Payout policies get one more setting. A cross-currency approval decides what the recipient gets; what you send is re-quoted before the money leaves, so it is given a margin rather than matched exactly. If the send amount rises by more than the tolerance after approval, the release is refused and approval is asked for again. Blank inherits the platform default of 5%; 0 asks again on any rise at all.

Each request stores the tolerance in force when it was raised, so tightening the policy tomorrow does not retroactively void decisions made today.

Do not express "only gate the flagged partners" by disabling the catch-all default and relying on a flagged-only policy. Items held for operational reasons carry no flag, so they would slip through with no approval at all. Put the flagged-only policy at a priority **below** 1000 and leave the default underneath it.

## Worked example: two signatures over $5,000

Say payouts under five thousand can go out on one approval, and anything larger needs the finance manager and a director together.

1. **Create policy**, name it *Large payouts—two signatures*, priority **100**.
2. **Applies to**: Payout.
3. **Strategy**: All approvers.
4. **Approvers**: the finance manager and the director.
5. **Conditions**: tick **Match by amount**, Minimum **5000**, leave Maximum blank.
6. Leave **Policy enabled** on, and **Create**.

Payouts of $5,000 and up now match this policy first and wait for both people. Everything below it falls through to *Default Payout Approval* at 1000 and needs one approver. Nothing else changed.

## Turning a policy off

Toggle **Policy enabled** off and it is skipped entirely when requests are evaluated—existing requests already raised under it are unaffected and still need deciding. Policies you created can be deleted outright; the five defaults cannot, which is deliberate.

Before you disable anything, work out what catches the items it was catching. A disabled policy does not mean "approve automatically"—it means the next matching policy decides, and if none does, the item moves without a request at all.

## Frequently asked questions

### Where did these five policies come from? I didn't create them.

Qualy seeds one default policy per item type—transaction, payout, payment split, authorization and refund—as soon as your account has an admin who could approve. Each one uses the Any approver strategy at priority 1000, and its approver list mirrors your current active admins: add an admin and they are added, remove one and they are removed. That sync stops the moment you set the approver list yourself, which hands the roster to you permanently. Editing any other field on the policy leaves the sync running.

### Two of my policies match the same payment. Which one wins?

Exactly one policy applies, and it is the first enabled one by ascending priority whose conditions all match. Lower numbers are evaluated first, so a policy at 10 beats one at 500, and both beat the defaults at 1000. Nothing stacks—a matched policy is the whole rule, so its strategy and its approver list are the only ones that apply. If two policies share a priority the order between them is not something you should rely on; give them distinct numbers.

### How do I make payouts over a threshold need two people?

Create a payout policy, choose the All approvers strategy, list the two people, then tick Match by amount and set a Minimum amount. Give it a priority below 1000 so it is evaluated before the default. Amounts are entered in the major unit—100 means $100.00. Payouts under the threshold fall through to the default policy and still need one approver; if you want them to pass without anyone, add a second policy for the same item type at a slightly higher priority with the Auto-approve strategy and an amount maximum.

### Can I turn approvals off completely?

For transactions, payouts and payment splits, yes—disable the default policy or replace it with an Auto-approve one, and matching items flow straight through. Refunds are the exception and it matters: a refund fails closed. If no policy matches a refund, the refund cannot proceed at all ("No approval policy or approvers are configured to authorize this refund"). Never leave refunds without a matching policy—if you do not want a human in that loop, give them an Auto-approve policy rather than deleting or disabling the default.

### Can someone approve a payment they created themselves?

Yes, unless you design the policy to stop it. Qualy does not enforce separation of duties—if a person is on the approver list, they can approve their own work. To require a second pair of eyes, use All approvers or Sequential with a roster that includes someone who does not raise payments. This is deliberate: the engine stays flexible and the rule is yours to write.

### What is the difference between a policy and the Require approval toggle on a partnership?

They answer different questions and both are needed. The Require approval toggle on a partnership, and the equivalent payout setting on your account, decide WHICH payouts are held for a human—they are governed by your partnership and settings permissions. The approval policy decides WHO signs off and HOW MANY of them, and is governed by the approvals permissions. If you want a policy that only governs the flagged ones, tick Only entities flagged for manual review on a payout or payment split policy.

### I added a new admin. Do I have to add them to every policy?

Not to the default policies—their approver lists track your active admin pool automatically, so a new super-admin can approve default-gated money straight away and a departing one loses the ability. Policies you created, and any default whose approvers you have edited by hand, are yours to maintain. If someone loses their role or is deactivated while a request is open, Qualy refuses their decision and hands the request to the current admins rather than letting a stale approver release money.

### I created a policy and it never matches anything. What did I get wrong?

Start with priority: if it sits at or above 1000 the default policy is evaluated first and takes every matching item. Then check the conditions, because they are ANDed—every ticked condition must match, so a policy with a currency, an amount range and a method matches only items satisfying all three. Amount conditions also fail closed: an item with no amount will never match a policy that gates on amount. Last, confirm the policy is enabled; disabled policies are skipped entirely.

### What does 'Only entities flagged for manual review' actually match?

It matches payouts and payment splits that a partnership or your payout settings flagged for manual review, and nothing else. Items held for operational reasons—a partial payment, an over-allocation, a gateway intervention, a batch—are not flagged and are not matched by it. That is the trap: unflagged does not mean "needs no approval". Layer a policy with this condition above the catch-all default rather than disabling the default, or the operationally-held items lose their sign-off entirely.

### What is the Exchange rate movement setting for?

It only appears on payout policies, and it governs cross-currency payouts. An FX approval is a decision about what the recipient gets; the amount leaving your balance is a quote that gets re-priced before the money moves, so it is given a margin rather than matched exactly. If the send amount rises by more than the tolerance after approval, Qualy refuses the release and asks for approval again. Leave it blank for the platform default of 5%; enter 0 to be asked again on any rise at all. The value in force when a request is raised is the one that judges it, so editing the policy later does not change decisions already made.

### Can an integration or API key approve payments?

Yes, if it holds an approver role. An API-key identity is a first-class approver: it can be listed on a policy, it can be auto-selected onto default policies, and it can clear the approvals its own integration triggers—useful when an accounting sync records payments that land in review. API keys are never emailed, because they act programmatically. Bot identities cannot approve at all. Be deliberate here: an account whose only admin is an API key can end up releasing money with no human in the loop.

### Can I delete a default policy?

No—default policies cannot be deleted, only disabled or edited. That is a guard rail, not a limitation: deleting one would leave a whole item type ungated with nothing saying so, and for refunds it would block refunds outright. If a default is not the rule you want, edit its strategy, approvers and conditions, or leave it in place at priority 1000 and put your own policy above it.

### Does auto-approval leave an audit trail?

Yes. An Auto-approve policy moves money without a human, so every auto-approval is recorded against the item—"auto-approved this request"—whether or not anyone was watching. The request itself exists and is visible in Approvals with its policy and strategy, exactly like one a person decided.

## Prefer doing this via the Qualy API?

Head over to our developer docs for everything you need—endpoints, examples, and simple how-tos.

[View API Docs](https://docs.qualyhq.com/docs)

## More on Qualy

**Industries**

- [For schools](/international-education/for-schools.md) — For international education schools
- [For agents](/international-education/for-education-agents.md) — For international education agents

**Support**

- [Training](/training.md)
- [System status](https://qualyhq.statuspage.io/) — Qualy system status
- [Product updates](https://changelog.qualyhq.com) — As we work on Qualy, here we spotlight what we’ve learned and updated across our products
- [Contact](/contact-us.md)

**Product**

- [Demo](/demo.md)
- [Enterprise](/enterprise.md)
- [Testimonials](/testimonials.md) — Learn what some customers have to say about Qualy
- [About](/about.md) — Learn about Qualy's mission and values
- [Blog](/blog) — International education payments blog by Qualy
- [Trust center](/trust.md)
- [API](/api.md) — Qualy API for international education payments
- [Zapier](/zapier.md) — Connect Qualy to 7,000+ apps with Zapier
- [NexPay](/nexpay.md) — Qualy + NexPay — automate everything around the payment

**Legal**

- [General terms](/terms-and-conditions.md)
- [Payer terms](/terms-for-payers.md)
- [Privacy policy](/privacy-policy.md)
- [BECS DDR](/becs-dd-service-agreement.md)