Paying out on a standing order

A standing order is a repeating payment out of an account, on a schedule you set. Each time the schedule falls due, the platform sends money from the account to a nominated bank account.

It lives on the Standing Orders tab under Payments.

Not the same thing as a debit order

The two look alike on screen and do opposite jobs. Getting them the wrong way round is the usual reason a payment is chased in the wrong place.

	Standing order	Debit order
Who instructs it	The customer tells you to pay	The customer permits you to collect
Which way money moves	Out of the account	Into the account
Whose bank account is touched	The one you pay	The one you collect from
Does it need a mandate	No	Yes, where the collection scheme authenticates

You are pushing money on the customer’s instruction. Nobody’s bank has to authorise a push, so a standing order needs no mandate and cannot be disputed the way a collection can. See collecting money from a customer’s bank account for the other side, and payments on an account for the whole group of tabs.

What a standing order holds

Three things, and nothing else.

It holds	What it means
Amount	A fixed amount, or the account’s full available balance
Schedule	How often it falls due, when it starts, and whether it ends
Destination	The bank account the money is paid to

Everything about how the payment travels — which rail, how fast, what it costs — is decided when each payment is raised, not when you set the standing order up. See how a payment picks its rail.

Setting one up

Open the account and select Payments, then Standing Orders.
Select Schedule.
Enter the Amount.
Choose the External Account to pay.
Set the schedule: frequency, start date, and whether it ends after a number of payments, on a date, or not at all.
Choose a business-day convention, and the calendars it reads.
Save.

The schedule must use a business-day convention. Without one a payment could fall due on a day the banks are shut. The conventions and the calendar behind them are covered in business day conventions; the platform’s position on them is the Business day conventions row in the standards register.

The dialog previews the dates the schedule will fire, so you can see the effect of the convention before you save. You can also add or remove an individual date on that preview.

The minimum amount

Your organisation sets a minimum standing-order amount for each currency. Anything below it is refused when you save, and the message names the minimum.

Where the minimum for the currency is 50.00, a standing order for 10.00 is refused.

A standing order cannot start in the past. The start date must be today or later.

Who you are allowed to pay

The destination must either belong to the account’s own owner, or be an approved beneficiary in scope for the account. Anything else is refused, and the message says which of the two is missing. See approved beneficiaries.

The same check runs again if you later repoint the standing order, so a destination cannot be changed into one you were never allowed to pay.

Paying the full balance

Some accounts exist only to pass money on — a dealer’s or a conveyancer’s disbursement account, for example. On those, the Payout amount choice appears, and you can set the standing order to pay the full balance instead of a fixed amount.

A full-balance standing order carries no amount of its own. Each occurrence pays whatever is available on the day.

A day with nothing on the account is skipped. No empty payment goes out, and the standing order simply waits for its next date.

The minimum amount does not apply to a full-balance standing order, because there is no amount to check when you set it up.

When each payment is raised

A payment is raised before the day it lands, not on it. The rail needs notice, so the platform works backwards from the day the money should arrive and raises the payment on the right day for that rail’s lead.

flowchart TD
    A["The schedule falls due<br/>on a date"] --> B["Work back by the rail's lead"]
    B --> C["End of day:<br/>the payment is raised"]
    C --> D{"Is the money there?"}
    D -- "Yes" --> E["The payment is sent,<br/>and lands on the due date"]
    D -- "No" --> F["Nothing is sent.<br/>The attempt is recorded"]

Raising happens as part of end of day. Nothing is raised during the working day, so a standing order you set up this morning does not pay until the run.

A standing order due on 17 January, over a rail that needs two days’ notice, is raised on 15 January and clears on 17 January. The account is dated on the clearing date, not the raise date — see value dating.

Each occurrence is raised once. A run repeated for the same day raises no second payment.

A full-balance payment is quoted more slowly

A fixed amount can be matched to a rail exactly, because the platform knows what it is paying. A full-balance payment does not know its amount until the day it runs, so it is quoted on the slowest rail that could carry it.

Take Woodgrove Bank, with a fast payout rail that clears the same day and a slower one that takes three days.

The standing order pays	Clears
A fixed 500.00	Same day, on the fast rail
The full balance	Three days later, on the slow rail

Quoting the slower date is deliberate. Money that arrives sooner than promised is a pleasant surprise; money that arrives later than promised is a complaint.

When there is not enough money

The account decides whether it can afford the payment. Each product carries its own rule — typically that the available balance must cover the amount.

If it cannot, nothing goes out.

No payment is raised, and no transaction is posted. The account is untouched.
The attempt is recorded against the standing order, with the date and the amount it tried to pay.
That occurrence is not tried again. There is no retry the next day, and no catch-up when money arrives.
The standing order stays active. The tab moves on to the next scheduled date, and the next occurrence is attempted normally.

That last point is the one to watch. A missed payment leaves nothing on the account and nothing on the payments-out list, because no payment was ever sent. An account that keeps falling short looks quiet rather than delinquent. If a customer says a standing order did not pay, check the balance on the due date rather than the payment lists — see reading the transaction list.

Other reasons a payment does not go out

Reason	Where it stops	What to do
The customer’s compliance clearance is frozen	Nothing is raised at all	A freeze stops outbound money only. See counterparty clearance
The beneficiary’s approval was withdrawn after the payment was raised	The payment is raised, then refused before it is sent	Approve the beneficiary again, or cancel the payment
The standing order was cancelled before the run	Nothing is raised at all	Nothing further is raised from it

The first two are reported as failures against the end-of-day run, on the run’s own detail, with the reason. One failed payment does not stop the rest of the run.

Changing one

While a standing order is active, use the actions menu on its row.

Action	What changes	What does not
Adjust amount	The amount every future payment pays	Payments already raised
Reschedule	The whole schedule, from a new start date	Payments already raised
Change external account	Where future payments are sent	Payments already sent

Adjusting a 500.00 standing order to 750.00 takes effect on its next occurrence. The new amount is checked against the minimum, exactly as it was when you set it up.

A rescheduled standing order takes its new start date as its next due date. Like the original, the new start date cannot be in the past.

Stopping one

Select Cancel on the row. The standing order ends, and no further payments are raised from it. The row stays on the tab showing Cancelled, so the history of what the account used to pay is not lost.

Cancelling is final. A cancelled standing order cannot be restarted, amended, or rescheduled — set up a new one instead.

Cancelling does not recall a payment already sent. If the money has gone, it has gone; see taking money out for what can and cannot be undone.

What your organisation configures

Which products carry the tab. Each product names the tabs its accounts show, so an account that never pays out has no Standing Orders tab.
Whether the capability is licensed at all. Without the licence the tab does not appear, whatever the product asks for. See switching features on and off.
The minimum amount for each currency. A settings row per currency, edited as a draft and published.
Which products pay by full balance, and which pay a fixed amount only.
The rule each product applies before it pays — typically that the balance must cover the amount, with the message the clerk sees when it does not.
The payout rails, their order, and their lead times. These decide how many days before the due date a payment is raised. See how a payment picks its rail.
The business-day calendars a schedule may read.
The approved-beneficiary directory, and whether an entry is payable across the whole organisation or only within one operating entity.