Choosing which account money moves through

Your organisation holds its own bank accounts. Every payment you send leaves one of them, and every collection you pull lands in one of them.

Which account a payment uses is decided by rules you configure, not by whoever raises the payment.

The rules are a list, and the order matters

You write an ordered list of rules for each operating entity. A payment goes through the list from the top, and the first rule that fits carries it.

A rule can name five things. Anything you leave blank matches everything, which is how the last rule catches whatever the rules above it declined.

Put the specific rules above the general ones. A rule that fits everything, sitting at the top, will carry everything.

A worked example

Woodgrove Bank will not accept receipts from gambling-sector customers into its main clearing account. Two rules handle that:

1. Collections, from counterparties whose sector is Gambling → the high-risk collections account.
2. Collections → the main collections account.

Every gambling-sector collection takes the first rule. Everything else falls to the second. Adding the exception is one row, not a change to how collections work.

Routing by what a payment is for

The purpose term is the kind of payment — an interest payment, a maturity, an instalment collection. It is the same idea that decides how fast a payment goes, so one answer serves both.

That is what lets an organisation pay interest out of one account and everything else out of another, without anyone choosing per payment.

A purpose belongs to an account type. If a rule names an account type, you can only choose purposes that account type actually produces — choosing one it never produces would be a rule that never carries anything.

Why you choose values instead of typing them

When a rule routes by a counterparty property, you choose both the property and the value from a list.

That is deliberate. A typed-in value that does not exactly match what is stored would match no counterparty at all — and it would not look wrong. The rule would sit in the list, appear correct, and quietly route nothing. Choosing from the list makes that impossible.

For the same reason, you can only route on properties whose values are a fixed list. A free-text property has nothing to choose from, so it cannot be routed on.

What happens if no rule fits

The payment is still raised and still appears in your queues. It cannot be sent until a rule covers it, and the error names what was missing.

The usual cause is a new product or a new currency that no rule mentions yet. Adding a rule releases the payment — nothing needs to be captured again.

The account is recorded when the payment is raised

The account a payment will use is worked out and recorded when the payment is raised, not when it goes out.

If the rules change between those two moments — someone edits a rule, or the counterparty’s details change — the account is worked out again at send, and any change is recorded. You see that the account moved, when, and what it moved to.

An auditor reading the payment later sees both the original choice and the change, rather than one value with no explanation.

Changing the rules

Rules are edited on the operating entity’s Banking panel.

1. Open the operating entity.
2. Select Banking.
3. Select Add rule, or use the arrows to move an existing rule up or down.

Two things are checked when you save:

• The account belongs to this operating entity, and is held in the rule’s currency. You cannot route your organisation’s money into somebody else’s account.
• Every property and purpose you named exists. A rule naming something that does not exist would never carry a payment, so it is refused rather than saved.

Re-routing your organisation’s money is the kind of change that needs a second pair of eyes, so it goes for approval before it takes effect.