Payment Approval with Segregation-of-Duties Automation: The Person Who Touched It Doesn't Clear It

A payment approval step only means something if the person approving genuinely could have said no — and that assumption quietly breaks the moment the same person who entered the payment, settled it, or uploaded its receipt is also the one clicking approve. Without an actual rule stopping that, "requires approval" becomes a formality that happens to be true on paper while doing nothing to catch a mistake or a bad-faith entry, because the one person checking the work is the same person who did it.

A single "approved" flag on a payment record cannot, by itself, express who is allowed to flip it — that requires knowing, at the moment of the decision, who created the payment, who marked it settled, who uploaded its supporting receipt, and who last touched it, and then comparing that history against the specific person clicking approve right now. Multi-approver thresholds face the same structural gap: without a server-side count of how many DISTINCT approvals have actually landed, a policy requiring two approvers is trivially satisfied by one person clicking twice, or by a race between two people that a naive read-then-write pattern would let both "win" inconsistently.

Every organization can activate one versioned payment policy at a time — flexible, controlled, or strict — and a new version never silently overwrites an old one; each payment approval permanently snapshots which policy version actually applied to it, so a later policy change can never rewrite what a historical decision meant. When segregation of duties is turned on, an approval decision is checked against the payment's own recorded creator, settler, receipt-uploader and last-modifier — whichever of those the policy names is blocked from approving that specific payment, verified server-side against the actual authenticated user, not trusted from whatever the browser sends.

A payment can require more than one approver before it actually clears; the decision function locks the specific approval row before touching it, so two simultaneous decisions on the same payment cannot both partially apply and leave an inconsistent state. An approver can also clear a payment "with reservation" instead of a flat approval, but only by supplying an actual written reason — a bare click is not accepted for that path. Every decision of any kind — approve, approve-with-reservation, reject, return, cancel — is written to a permanent, append-only history alongside who made it, the status it moved from and to, and any reason given; that history has no update or delete path available to anyone, so it cannot be cleaned up or rewritten after the fact.

A team activates a "controlled" policy requiring segregation of duties and two approvers for payments above a set threshold. An operations assistant registers a large vendor payment and uploads its receipt. When they open the approval screen, the approve action is blocked for them specifically — the policy recognizes they created the payment and uploaded its receipt — while a manager and the finance lead, neither of whom touched the original entry, each approve it independently; the payment only clears once both approvals have actually landed, and the full sequence — who approved, in what order, with what timestamp — remains on permanent record.

Approval stops being a formality that the same hands can both request and grant, and starts meaning that a genuinely different, policy-defined set of people has to sign off before a payment clears. A multi-approver requirement is enforced by an actual count of distinct decisions rather than trusted to habit, and a permanent, unmodifiable history means "who approved this and why" stays answerable long after the fact, not dependent on anyone's memory or an editable log.

A team that has not activated any payment policy sees none of this — the mechanism is deliberately a no-op until a policy is actually turned on, so a business relying on this page's protections needs to configure and activate one first. A team wanting segregation of duties enforced against roles or departments rather than the specific creator/settler/uploader/modifier of a given payment will find the current rule scoped to those four recorded actions on that exact payment, not a broader role-based separation.

A single "approved" checkbox trusts whoever has access to click it, with no structural check on whether they are the same person who created or handled the payment in the first place. Centriu Gauge instead checks the payment's own recorded history against the person deciding, right on the server, and requires an actual count of distinct approvers before anything clears — turning "requires approval" from a formality into a rule that a single person genuinely cannot satisfy alone when the policy says so.