How procurement governance works
Every company that buys anything has rules about who may spend what. Your shop either reproduces those rules or the company cannot use it. This article sets out the idea from the customer side; the Procurement guide covers the setup in full.
The reason a buyer will not use your shop
You have built a shop, put the customer's contract prices in it, and their purchasing department still sends orders by email. Usually that is not about the shop. Inside a company of any size a purchase goes through some version of this:
- Somebody notices a shelf is empty and requests the goods.
- Somebody with authority approves the spend.
- The cost is booked against a cost centre: the workshop, the machine, the project.
- Finance settles it on agreed terms, on one invoice.
A shop where anyone with a login can press Buy now removes the controller from that process, and the controller decides whether the shop gets used. When a Mittelstand buyer says "we cannot use your shop", this is usually what they mean.
Three mechanisms, kept apart
| Mechanism | The question it answers | Where it lives |
|---|---|---|
| Authority | May this person commit the company to this amount? | On the person, and in the approval rules |
| Allocation | Which cost centre, and which budget, does this cost belong to? | On the order line |
| Terms | When and how does the company pay? | On the company |
They are independent. A buyer can be allowed to order up to €2,000 and still book against a cost centre with nothing left on it. A company can have generous payment terms and route every order over €500 through a manager. Mixing the three is how governance conversations go round in circles.
How this works in the Revenue Cloud
Authority and allocation are handled by two apps that appear together under Procurement in the Cockpit:
| Cockpit screen | What it holds |
|---|---|
| Cost centres › Cost centres | The customer's cost centres as master data, each with a code, a currency and an accountable contact |
| Cost centres › Budgets | Amounts per cost centre and period, with a ledger of every reservation, rollover and return |
| Cost centres › Personal limits | One spending limit per contact |
| Approval rules | The customer's policy: a condition, an effect, an approver |
| Purchase requests | Spend that is waiting for approval, and its history |
At checkout the cart is measured against the approval rules, and one of three things happens:
- No rule applies. The cart becomes an order straight away, and its cost centre lines are booked on their budgets.
- A rule asks for approval. The cart becomes a purchase request. Its budget is reserved at once, so the next buyer sees what is really left. The approvers decide on the request, layer by layer, and the order is created only when the last one has approved.
- A rule prevents it. The submission is refused and nothing is created. A rule on the condition Available budget with the effect Prevent is how an empty budget stops an order.
Who may approve follows from the person's role: an approver or an admin may, a buyer or requester may not, even when a rule names them. A requester holds no permission to place an order, which is what a rule on Contact missing permission catches. Approvers decide their step as contacts, signed in to the shop. In the Cockpit an administrator can Super-approve a whole purchase request or Cancel it, but not decide a single step.
Whether checkout runs through these rules at all is a tenant setting, the approval gate. It is on by default. Switched to No approval, every submitted cart becomes an order and its budget is still booked.
Terms stay with the company: payment terms and credit limit on the organization. See Credit control in B2B.
Punchout: when the governance is not yours at all
Large buyers often run their own procurement system (SAP Ariba, Coupa, Onventis), and their approval workflow, cost centres and budgets live there. Your shop is then opened inside their system, the buyer fills a cart, and the cart goes back to their system as a requisition. Every approval happens on their side. That is punchout, and for a large customer it is often the better answer than rebuilding their rules in your shop. Ask which one the customer wants before building either.
Next
- Approval rules — the customer conversation before you write the first rule.
- Cost centres and budgets — what to collect from the customer.
- Approval models — chains, layers and parallel approval in detail.