# Approval Workflows 101: Maker-Checker for Vendor Governance What maker-checker approval workflows are, why they matter for vendor governance, and how to implement them without slowing procurement to a crawl. Category: Platform Guides Published: July 28, 2026 Source: https://www.vendoreye.ae/blog/maker-checker-approval-workflows-vendor-governance Maker-checker is a term borrowed directly from the banking world, where it has long served as a foundational, well-understood control: the person who initiates a transaction (the maker) can't be the same person who approves it (the checker). It exists because a single person acting entirely alone, however well-intentioned and however experienced, is inherently a single point of failure — for honest, understandable mistakes just as much as for anything more deliberate. Vendor governance has exactly the same underlying structural need, and yet far fewer procurement teams apply the principle deliberately or consistently, often relying instead on informal habits that happen to work most of the time rather than a genuinely defined control that works reliably, every time, regardless of who's involved. ## Why Vendor Decisions Specifically Need This Vendor onboarding and approval decisions carry real consequences: who gets paid, whose documents were actually verified, whose screening results were actually reviewed rather than glanced at. A single person with unchecked authority to approve a vendor — create the record, upload the documents, mark it approved, all without independent review — creates risk regardless of that person's individual diligence, simply because there's no second perspective to catch an honest oversight, let alone anything more deliberate. This isn't a statement of distrust toward any individual; it's a recognition that even careful people miss things, and a second reviewer catches a meaningful share of what the first one misses. ## What Maker-Checker Looks Like in Vendor Governance ### Separating creation from approval The person who initiates a vendor record — whether that's a procurement officer adding a new supplier or an automated intake process capturing one from an email — shouldn't be the same person whose approval finalizes that vendor's status. A second, independent reviewer examines the submitted documents, screening results, and qualification data before the vendor moves to approved status. ### Separating scoring from awarding In sourcing events, the person scoring vendor bids and the person with final authority to award a contract can meaningfully be different roles, particularly for higher-value opportunities — reducing the risk that a single individual's preference, rather than the documented scoring criteria, drives the outcome. ### Separating document review from payment setup Banking detail changes are a specific, high-risk category worth their own maker-checker control: the person who receives and enters updated vendor banking details shouldn't be the same person who can approve those details as verified, given how directly this connects to payment fraud risk. ## Getting the Balance Right: Rigor Without Gridlock The most common objection to maker-checker controls is that they slow things down — and applied indiscriminately across every decision regardless of value or risk, they can. The practical answer isn't to abandon the principle but to apply it proportionally. Low-value, low-risk vendor approvals can reasonably move through a lighter review; high-value contracts, banking detail changes, and anything triggering a compliance flag warrant the full separation of duties. Tiering the control by risk, rather than either applying it universally or skipping it universally, is what keeps maker-checker genuinely useful rather than becoming bureaucratic friction that teams quietly route around under deadline pressure. ## What Happens Without This Control Organizations without maker-checker discipline in vendor governance don't usually notice the gap until something goes wrong — a vendor approved without adequate documentation, discovered only in a later audit; a banking detail change that turned out to be fraudulent, entered and acted on by the same compromised account without a second check. These incidents tend to be the moment organizations retroactively adopt maker-checker controls, when a small amount of proactive friction earlier would have prevented a much larger cost later. The pattern is familiar across most governance controls: the cost of having the control is visible and immediate (a bit more process, a bit more time); the cost of not having it is invisible until the specific moment it matters, at which point it's usually much larger than the friction it would have added all along. ## Building This Into Role Design, Not Just Policy A maker-checker policy that exists only as a written procedure, unsupported by the actual permissions in whatever system vendors are managed through, relies entirely on individual discipline to follow it — which tends to erode under time pressure exactly when the control matters most. A system where the roles are structurally enforced — where a "maker" role genuinely cannot also approve their own submissions, rather than simply being asked not to — removes the temptation and the possibility of the control quietly being skipped when someone's in a hurry. ## How This Works in Practice Vendoreye's role-based access control supports exactly this kind of separation: roles like Checker and Maker exist as defined permission sets, and vendor approval, bid scoring, and other governance actions can be configured to require a reviewer distinct from whoever initiated the request. This isn't a bolt-on compliance feature — it reflects how the underlying permission system is structured from the ground up, which is what makes the separation of duties actually enforceable rather than dependent on everyone remembering to follow an unenforced policy. ## A Worked Example Consider a mid-sized organization where a single procurement officer has, informally, become the person who both adds new vendors and marks them approved — not by any deliberate policy decision, but because they're efficient, trusted, and it's simply become the path of least resistance over time. This works fine for years, until that officer, under significant end-of-quarter pressure to get a time-sensitive vendor onboarded, approves a vendor whose beneficial ownership declaration was incomplete and whose insurance certificate had actually expired two weeks earlier — details that a second, independent reviewer, without the same time pressure and personal investment in getting this particular vendor through quickly, would very likely have caught. Nothing about this reflects poor character or carelessness; it reflects exactly the kind of pressure-induced oversight that maker-checker exists specifically to catch, precisely because a single person working under deadline pressure is a fundamentally less reliable check than two people, one of whom isn't under that same specific pressure. ## Common Objections and How to Answer Them "We're too small a team for this" is the most common objection, and it has a reasonable answer: maker-checker doesn't require an army of reviewers, it requires exactly two people with appropriately separated permissions — even in a three-person procurement function, this is achievable for the decisions that actually warrant it. "This will slow us down" is the second most common objection, and the honest answer is that it will, modestly, for the specific transactions where the control applies — which is precisely the point. A control that adds zero friction isn't actually controlling anything; the question worth asking isn't whether it adds friction, but whether the friction is proportionate to what it's protecting against, tiered so that low-risk decisions stay fast and high-risk ones get the additional scrutiny they warrant. ## Extending the Principle Beyond Vendor Approval Once maker-checker is established for vendor approval, the same logic extends naturally to other vendor governance decisions worth separating: who can mark an assessment as reviewed versus who submitted it on the vendor's behalf, who can award a bid versus who scored it, who can mark a document as verified versus who uploaded it. Organizations that adopt the principle deliberately, rather than applying it only to the single most obvious case, tend to find it becomes a general design pattern for the whole vendor governance process rather than an isolated control bolted onto one specific decision point. ## Auditing Whether Your Controls Are Actually Working Implementing maker-checker permissions is necessary but not sufficient — it's worth periodically checking whether the separation is functioning as intended in practice, not just in theory. A useful audit question: for a sample of recent vendor approvals, was the checker's review substantive (evidence of documents actually examined, screening results actually considered) or effectively a rubber stamp completed within seconds of the maker's submission? A structurally correct permission setup can still produce a checker role that adds no real scrutiny if the organizational culture doesn't support reviewers actually taking the review step seriously. ## Setting Realistic Expectations for Rollout Introducing maker-checker controls into a team that hasn't previously used them is a genuine change management exercise, not just a permissions configuration task. Staff accustomed to approving their own vendor additions may initially experience the new review step as a signal of distrust rather than a structural improvement, particularly if it's rolled out without clear communication about why. Framing the change around the control itself — this is standard practice, applied to everyone, protecting the whole team rather than singling anyone out — and pairing it with a realistic timeline for adjustment tends to produce a smoother transition than a policy announcement with no accompanying explanation of the reasoning behind it, delivered with no warning on a Monday morning. Maker-checker isn't about assuming bad intent — it's about building a system that catches honest mistakes before they become expensive ones, the same way it's done for centuries in every other function where a single unchecked decision carries real consequences. ## Frequently Asked Questions **What is maker-checker, in simple terms?** A control where the person who initiates an action — creating a vendor record, entering a banking detail change — cannot be the same person who approves or finalizes it, ensuring an independent second review before the action takes effect. **Does maker-checker need to apply to every vendor decision?** Not necessarily. Applying it proportionally — full separation of duties for high-value or high-risk decisions, lighter review for low-value, low-risk ones — keeps the control useful without creating unnecessary friction across every single approval. **Why is banking detail verification a particularly important place for this control?** Banking detail changes are a common vector for payment redirection fraud. Ensuring the person entering an updated bank detail isn't also the person approving it as verified closes a specific, high-consequence gap. **Can maker-checker be enforced through policy alone, without system support?** It can be written as policy, but policies unsupported by actual system permissions tend to erode under time pressure. Structural enforcement — where a maker role genuinely cannot approve their own submissions — is more reliable than relying on individual discipline.