Supplier bill approvals for a small team: a threshold, two signatures and an audit trail

A supplier bill in a company of eight usually travels like this: it lands in someone's inbox, the same someone types the amount into the bank, and the same someone marks it paid in whatever the books are. Nothing about that is dishonest. It is a chain with one decision in it, and a chain with one decision has no place where a wrong amount, a changed IBAN or a second copy of the same invoice gets a second look.

The fix is not a bigger team. It is three small changes to the chain: a number above which a second person looks, a rule that the second person is never the first one, and a record of who did what, kept somewhere the first person cannot edit.

Control one: a threshold

A threshold is the amount above which a bill needs more than one person. Below it, one person pays and the record shows who. Above it, the payment waits for a signature.

Where to put it is a judgement about your own numbers: high enough that the everyday bills do not queue, low enough that a mistake above it would hurt. A useful way to pick it is to list last quarter's supplier payments largest first and find the point where "I would want to know before this leaves" starts. Write the number down with a date; it is a policy, not a setting.

What a threshold has to survive, in practice:

• Slicing. Ten payments of 900 against a 1,000 threshold must not walk past it. In Orla the threshold is measured against everything already settled on that bill plus the payment being recorded, so the second slice meets it, and a separate 24-hour aggregate adds up payments to the same contact and bills of the same supplier, whichever screen moved the money.
• Bands with a gap. One rule stops at 1,000 and the next starts at 2,000, and a bill for 1,500 falls in the hole. Orla refuses that payment and names the two rules it fell between, rather than letting it out unsigned.
• The muted rule. A rule switched off must not mean "no rule". In Orla a rule that is turned off still blocks a payment it would have matched; turning signatures off means deleting the rule, and switching one off asks you to confirm exactly that.
• The person, not the payment. On the Scale plan a rule can name a person and become their monthly allowance instead of a per-payment threshold: what they have already sent this calendar month on their own authority, plus the payment in hand, is what the number is measured against.

One rule with a threshold, a signature count and the address-book switch is on every plan. Several rules, bands, named approvers and allowances are on Scale and Enterprise.

Control two: the second signature

The second signature only works if it cannot be the first person's. That sounds obvious, and it is the part most spreadsheet policies miss: "two people approve" turns into one person approving twice under two logins on a Friday evening.

In Orla whoever proposes a payment cannot sign it; a quorum only counts other people. A rule can name who may sign, and if it asks for more signatures than there are eligible signers, the Payments page warns with the numbers ("needs 2, has 1") before anything waits on it. The owner can always reject a payment, and the proposer can withdraw one, so a payment never sits forever waiting on somebody who left.

The signer has to know what they are signing. The notification names the contact, the amount and the rail the send will use: the network and a shortened address for a wallet, the last digits of the account for a bank payee. A signature given from Telegram, Slack or a lock screen is for the payment that will leave, and permissions are checked again when the button is pressed, not when it was drawn.

Then the bank asks again. A payment approved in Orla and paid from a connected Revolut Business or Airwallex account arrives in the bank as a draft that someone on the team sends there; in Mercury it is a request into the bank's own approval queue. Two systems, two questions, and Orla holds no permission to send on its own from either.

Control three: only the address book

A common shape of supplier fraud in a small company is not a fake supplier. It is a real supplier's email, compromised, sending a real-looking invoice with new bank details. The control is that bank details never come from the document. They come from the supplier's card, entered as fields, and changed only there.

In Orla a bill forwarded by email becomes a draft with the amount and the due date read off the file, and payment details are never taken from the email: where to pay comes from the contact card. A bill entered by hand for a name nobody has in the address book is flagged as an unverified sender. The same supplier and invoice number entered twice is refused, and one bill keeps one file, because the file is what a payment gets approved against.

"Address-book only" then closes the last gap: any destination that is not a trusted contact needs signatures, whatever the amount. Only an owner or admin can mark a contact trusted, and editing a trusted contact's rails drops the trust until it is confirmed again, because trust belongs to the exact details that were checked.

The audit trail

An audit trail is not a log file. It is the answer to four questions about any payment, answerable a year later by somebody who was not there: who proposed it, who signed it, when it left, and what changed on the way.

What Orla keeps, and where:

• On the payment. The signatures with names, the refusal reason typed by whoever refused, the bank's reference or the chain's transaction id, and a note when the amount that left differed from the amount approved.
• In the Payments export. A CSV of exactly what the filters show: date, payee, amount, category, status, batch, who created, approved and rejected it, transaction hash, account, chain and destination.
• In the activity log. Every governance entry with who did it, what it touched and the change, exportable as a CSV for a period. A range holding more than 10,000 entries is refused rather than trimmed, because a silently short file is one somebody signs off on believing it covers the whole period.
• In the month's archive. The payments of the month with who proposed and who signed travel to the accountant inside the same archive as the journal, so the trail leaves the building with the numbers. The accountant reads all of it from their own seat, which comes with Pro and above and never takes one of yours, and one who keeps several clients' books can join the partner program. What else the month needs before it goes is the month-end close checklist.

The point of the trail is that the system keeps it, not the person it is about. That is what turns "we have a policy" into "here is the period, and here is who signed".

A policy you can copy

Fill the brackets from your own numbers. Keep it to one page and date it.

1. Every supplier is a contact with bank details entered as fields. Details change only on the card, by [owner or admin], after a call to a number we already had.
2. Bills arrive by email to the space's address or are entered by hand. Nobody pays from an attachment.
3. A bill up to [threshold] is paid by [role] and recorded with their name.
4. A bill above [threshold] needs [1 or 2] signatures from [named people], and the person who entered or proposed it does not sign.
5. Any payee not on the trusted list needs signatures regardless of amount.
6. A supplier whose bank details changed this month is confirmed again before the first payment to them.
7. On the first of the month the Payments CSV and the activity log for the month are exported and filed with the archive.

What it costs in time

A second signature is a notification and a press. The proposer waits for one person, not a meeting. The bills below the threshold do not queue at all. What you give up is the ability to pay a large bill alone at 11pm, which is the point. How the same rule runs over contractor payouts, on a bank and on a chain, is in the guide to paying contractors.