In a ten-person company, "who approves this payment" has one answer, and everyone knows it. The owner does, on a phone, between two other things, usually by replying "ok" to a message with a screenshot in it.
That is not a failure of discipline. It is the rational response to having eleven jobs. It also works fine — right up until the day a real invoice arrives from a real supplier with one field changed, and "ok" moves 14,000 lei to an account nobody has ever paid before.
This is about the smallest amount of process that prevents that, without turning a five-person finance function into a committee.
The one principle worth importing
Large organisations call it segregation of duties. Stripped of the audit vocabulary, it is a single sentence:
The person who sets up a payment should not be the only person who releases it.
Not because anyone is suspected. Because a single pair of eyes is a single point of failure, and every mechanism of loss — fraud, a typo, a duplicate, an invoice for something never delivered — is caught by a second person looking at the same thing with a different question in mind.
The mistake companies make is not rejecting this principle. It is applying it uniformly, so that a 90-lei domain renewal needs the same ceremony as a 90,000-lei equipment purchase, at which point everybody routes around the whole system and you are back where you started, but with a false sense of control.
Thresholds are what make it survivable
The fix is to make the ceremony proportional. Pick two numbers:
- A no-approval floor. Below it, whoever runs payments just pays. Recurring utilities, small subscriptions, the courier. The control here is the monthly review, not a per-item gate.
- A two-signature ceiling. Above it, two named people must approve. In a small company this is usually the owner plus whoever keeps the books.
Between the two, one approval from someone other than the preparer.
The exact figures matter less than that they exist and are written down. A reasonable starting point is to set the floor where an error would be annoying but survivable, and the ceiling where a loss would actually hurt. Most small Romanian companies land somewhere around a few hundred lei and a few tens of thousands, and then adjust once they see how often the ceiling actually fires.
The four roles, and what each is for
Whatever tool you use, the same four roles keep reappearing, because they map to genuinely different needs:
| Role | Can | Exists because |
|---|---|---|
| Owner | Everything, including who else has access | Someone has to be able to remove a departing employee's access on the day they leave |
| Admin | Set up suppliers, prepare payments, manage the day-to-day | The person doing the work should not need the owner for routine setup |
| Approver | Approve or reject what an admin prepared; cannot change it | The second pair of eyes only works if it cannot quietly edit what it is checking |
| Viewer | See everything, change nothing | Accountants, auditors, an investor, a co-founder who wants visibility without another way for money to leave |
The important row is approver. An approval right that also carries an edit right is not a control — if the same person can change the IBAN and then approve the change, the second pair of eyes has been handed a pen.
The viewer row matters more than it looks, too. Most access sprawl in small companies happens because the only way to show your accountant something was to give them a login that can also pay.
The specific attack this stops
It is worth naming the threat, because "fraud" is too abstract to design against.
The common one is invoice redirection. An attacker gets into the email of a supplier, or spoofs it convincingly, and sends a genuine-looking invoice — often a real, previously-sent invoice — with the bank account changed. Sometimes it is accompanied by a note explaining that the company has changed banks. It arrives during a busy week, from a supplier you really do owe money to, for an amount you really do expect.
Three cheap controls defeat it, and none of them require software:
- Pay from the invoice the tax system delivered, not from the one in your inbox. For Romanian B2B invoices this is now the default anyway — see paying invoices from e-Factura. An emailed PDF is a notification.
- Flag first-time and changed bank accounts. A new IBAN for an existing supplier is the single highest-signal event in accounts payable. It should stop the payment and be verified by voice, on a number you already had, not one from the email.
- Have the approver check the account number, not just the amount. Approvals fail as a control when the approver only ever looks at the total, because the total is the one field the attacker did not need to change.
The audit trail is for you, not the auditor
Whatever you use, it should be able to answer, months later: who approved this, when, and what did they see at the time?
This is usually justified with the word "compliance", but the honest reason is more practical. When something does go wrong, the alternative to a trail is a reconstruction from memory and a WhatsApp thread, at exactly the moment when relationships are strained and nobody's recollection is neutral. A timestamped record is a kindness to your future self and to the colleague who would otherwise be under vague suspicion.
Where to start if you have none of this
Do these in order. The first two take an afternoon.
- Write down who can move money today. Include every bank login, card and mandate. Most companies find at least one entry that surprises them.
- Remove the access that no longer belongs to anyone — the former employee, the accountant you stopped working with two years ago.
- Set the two thresholds. Tell everyone.
- Name one approver who is not the person preparing payments. In a very small company this can be the owner; the point is that it is not the same person twice.
- Make the check explicit. "Confirm the IBAN matches the supplier's record" is a sentence in a checklist, not an assumption.
How OpenPay handles it
OpenPay has exactly those four roles — owner, admin, approver and viewer — so you invite people with the access they actually need, and approval is required before money moves. The payment itself is then confirmed at your bank with multi-factor authentication, which is the second, independent gate described in how open banking works: OpenPay cannot move money on its own, regardless of who is logged in.