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 explains the rules themselves, before the settings.
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. This is common, and it is usually not about the shop.
Inside a company of any size, a purchase is not a decision one person makes. It 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 department, the machine, the project, the vehicle that will carry it in the accounts.
- Purchasing checks it against the framework agreement they negotiated.
- Finance settles it on agreed terms, on one invoice, not per order.
A shop that lets anyone with a login click Buy now does not fit anywhere in that. It removes the controller from the process, and the controller is the person who decides whether the shop gets used. When a German Mittelstand buyer says "we cannot use your shop", this is what they usually mean.
The three mechanisms
Procurement governance is three separate ideas that get talked about as one. Keeping them apart makes the whole subject much easier.
| Mechanism | The question it answers | Where it lives |
|---|---|---|
| Authority | May this person commit the company to this amount? | On the person |
| Allocation | 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 have authority up to €2,000 but book against a cost centre with nothing left in it. A company can have generous payment terms and still route every order over €500 through a manager. Confusing the three is how governance conversations go round in circles.
Authority: who may commit what
The B2B version of "add to cart" is two buttons:
- Place the order. The buyer commits the company. Done.
- Submit for approval. The buyer produces a request that somebody else has to sign.
Which one a person gets is their role. How far their signature goes is an
amount. A workshop manager with a €1,000 ceiling orders consumables all day
without asking anybody, and the one order for a €4,000 machine tool goes up a
level. That is the entire mechanism, and it maps onto exactly two fields:
role and order_approval_limit.
Allocation: cost centres
A cost centre (Kostenstelle) is the accounting bucket a cost is charged to:
4711 for the workshop, KST-2200 for maintenance, a vehicle number, a project
code. It is not a permission and it does not stop anything by itself. Its job is
that the invoice can be split correctly when it arrives.
Two things follow, and both surprise people:
- The cost centre belongs on the line. One delivery routinely covers three departments. If the cost centre is a property of the whole order, the customer's accounts payable team splits the invoice by hand, which is exactly the manual work they were promised they would lose.
- The valid values are the customer's. Their chart of cost centres comes out of their ERP. Your job is to carry the value faithfully through to the order and the invoice.
A budget is the next step up: a cost centre with an amount and a period, plus a ledger of what has been consumed against it. Budgets are where governance gets hard, because a budget has to be decremented when an order is placed, restored when it is cancelled, and reconciled when a partial delivery is invoiced.
Terms: how the money moves
Nothing above touches payment. In B2B the money moves on agreed terms (net 30, net 60, direct debit) against an invoice, often a collected monthly one, and under a credit limit. Covered separately in Credit control in B2B.
Punchout: when the governance is not yours at all
There is a fourth possibility to know about before you build anything. Large buyers run their own procurement system (SAP Ariba, Coupa, Onventis), and their approval workflow, cost centres and budgets live there. In that world your shop is opened inside their system, the buyer fills a cart, and the cart is handed back to their system as a requisition. Every approval then happens on their side and you never see it.
That is punchout, and for a large customer it is often the right answer instead of reproducing their rules in your shop. Ask which one the customer wants before building either.
How this works in the Revenue Cloud
Be clear about what is available today, because these three mechanisms are at different stages.
Authority is modelled. contacts.role distinguishes a requester (may
submit for approval) from a buyer (may place directly) and an approver (may
sign off), and contacts.order_approval_limit carries the amount ceiling. The
underlying permission keys are orders.create, orders.request and
orders.approve, and you can see and re-map them on CRM › Roles.
The routing step is not finished. The model says who may approve and up to what amount; the Orders app can create an order that has not been placed, but there is no approval queue in the Cockpit yet that an approver works through. Treat approval today as a design you configure now and switch on later, and read Approval rules for what to do in the meantime.
Allocation is carried, not managed. An order line has a cost_center field
and it survives from an order list through to the order position, where the
Cockpit shows it on the line. There is no cost-centre master data and no budget
ledger yet. See Cost centres and budgets
for how to work with what exists.
Next
- Credit control in B2B — payment terms, credit limits and delivery blocks.
- Contacts and roles — set the role and the approval limit on a person.