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 records which policy version applied to it. The approval request itself is created after the payment is settled, from the policy in force, and whatever it leaves open goes into the period-close check rather than holding the payment back. When segregation of duties is turned on, an approval decision is checked against the payment's recorded creator, settler, receipt-uploader and last-modifier stored on the approval request — whichever of those the policy names cannot approve it through the decision routine, which reads the authenticated user on the server.

An approval request can require more than one approver before it is marked approved; the decision function locks the specific approval row before touching it, so two simultaneous decisions on the same request 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 the approval history alongside who made it, the status it moved from and to, and any reason given; users can only add entries to that history, not edit or delete them.

A team activates a "controlled" policy requiring segregation of duties and two approvers for payments above a set threshold. An operations assistant settles a large vendor payment and uploads its receipt, and the policy raises an approval request for it. When the assistant opens the approval screen, the decision routine refuses their approval — the request records them as the one who settled the payment and uploaded the receipt — while a manager and the finance lead, neither of whom touched the original entry, each approve it independently. The request is only marked approved once both decisions have landed, each one written to the approval history with who decided and when, and until then it stays open in the period-close check.

Approval stops being a formality that the same hands can both request and grant, and starts meaning that a policy-defined set of people other than the ones recorded on the request has to sign off before the approval request is closed, with anything still open carried into the period-close check. A multi-approver requirement is counted by the decision routine rather than trusted to habit, and the approval history keeps "who approved this and why" answerable later, 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 participants against the person deciding, inside a server routine, and counts distinct approvers before the approval request is closed — turning "requires approval" on that screen from a formality into a rule the recorded participants cannot satisfy alone.