How procurement governance works

A purchasing department is not being difficult. It holds four separate controls in place at once, and every one of them has an auditor or a bank behind it. This article is about those four controls, before any of it becomes a screen.

The scene

A 300-person Maschinenbau company in Baden-Württemberg. The Einkaufsleiterin has eleven people who may order something: four in the workshop, three in maintenance, two in the Innendienst, a facility manager, and an apprentice who orders drill bits. Last year they placed about 2,400 purchase orders, average value €340, with a long tail up to €28,000 for a replacement spindle.

She will not let those eleven people loose in your shop with a Buy now button. She trusts them. What she cannot do is lose the ability to answer four questions:

• Did we stay inside the maintenance budget for 2027? (Her CFO asks in January.)
• Can one person alone commit €28,000? (Her insurer asks.)
• What did the Werkstatt spend on consumables last quarter? (Her controller asks monthly.)
• Who approved this, and when? (Her auditor asks once a year and expects a record, not a memory.)

Those four questions are the four controls. A shop that cannot answer them is a shop her company cannot adopt, whatever the price or the catalogue.

The four controls

They are separate controls. A workshop manager can be fully authorised to sign a €900 order and still be booking it against a cost centre that has €120 left. A budget can be healthy while the same person raises and approves everything, which is a segregation failure with a healthy-looking number on top. Conflating them is how procurement conversations go in circles.

The chain: cost centre → budget → limit → approver

Four things sit in a line, and each answers a different question. Getting the order right makes the whole subject tractable.

1. Cost centre: where does this cost belong? 4711 for the workshop, KST-2200 for maintenance, a project number, a vehicle. It is an accounting address. On its own it authorises nothing and blocks nothing.
2. Budget: how much may be booked to that address in this period? €50,000 on KST-2200 for the 2027 financial year, held the moment a request is submitted and given back when the request is declined or the order cancelled.
3. Limit: how far does this person reach on their own? A personal ceiling per contact. Below it they order; above it they ask.
4. Approver: who signs when they have to ask? A named person, a role, or a chain of them, one after the other.

Read it backwards and the failure modes show themselves. An approver with no limits underneath them is a rubber stamp. A limit with no budget behind it authorises spending money that is not there. A budget with no cost centre is a number attached to nothing.

Why "the boss approves everything" does not scale

Every company starts here, and it works for a while. Take the numbers above: 2,400 orders a year, one approver.

That is roughly ten approvals every working day, most of them for drill bits and cutting fluid. Three things happen, always in this order:

1. The approver stops reading. Approval becomes a keystroke, so the control still exists on paper and no longer exists in fact.
2. The approver goes on holiday and the workshop stops. Somebody hands out a password, which destroys the audit trail the control was for.
3. Buyers route around it. They phone your Innendienst, or they use the Handkasse, and your carefully built shop shows a fraction of the real spend.

The fix is not a better queue. It is thresholds: most orders should never reach a human at all. A workable shape for the company above is that around 85 % of orders clear automatically under a personal limit with budget available, 12 % need one signature, and the remaining 3 %, the spindle, need two. That is a system a purchasing department keeps using in year three.

Where this model came from: booking accounts

If the vocabulary here feels SAP-shaped, that is deliberate.

In SAP, a cost is never merely "spent". It is booked against an account assignment: a Kostenstelle (cost centre), an Innenauftrag (internal order), a PSP-Element for a project, or an asset. The account assignment is mandatory on the line, decided at the moment of ordering, and it is what makes the invoice postable without a human deciding where it goes. German controlling has worked this way for forty years, and every ERP your customers run copies it.

IntelliShop V8 carried this into commerce under exactly that name, booking accounts: a budget on the account, an approval rule above a threshold, and a head of procurement who released or refused. It ran in production for years, and the approval rules described in this guide keep its semantics: the same conditions, the same effects, the same precedence when several rules match.

Two decisions came out of that analysis, and they shape everything below:

• The account assignment belongs on the line, not the order. One delivery routinely covers three departments. Put the cost centre on the order and the customer's Kreditorenbuchhaltung splits every invoice by hand.
• The budget is a ledger, not a number. A field you decrement is wrong the first time an order is cancelled. Every movement has to be an entry that can be read back, reversed, and explained.

How this works in the Revenue Cloud

The model is split across two apps, because money and workflow have different owners and different failure modes. Both appear in the Cockpit's Procurement section.

The cost-centers app answers two kinds of question: which cost centres may this person use on this line, and is there budget, is the buyer under their limit. Every movement of money is an entry in a budget's ledger, and nothing else changes a balance.

The procurement app holds the rules and the requests, and calls cost-centers; cost-centers never calls back. When a cart is submitted, one server-side entry point evaluates the rules and produces exactly one outcome:

• Refused. A rule with the effect Prevent matched, a line books to a cost centre with no active budget, or the amounts are in a currency the cost centre does not hold. Nothing is created.
• Order. No rule asked for approval. The order is placed and the budget is booked against it at once.
• Purchase request. A rule asked for approval. The request is created, its budget is reserved, and one approval waits per rule that matched.

That single decision point is why the controls hold for every cart the shop submits through it. One path does not go through it: creating an order straight from an order list in the Cockpit places the order directly, with no rule read and no budget booked. For a customer with approval rules, send list orders through the cart and the normal checkout.

How the four controls map onto the two apps:

Three settings and fields need a clear word with the customer:

• The Approval gate is a tenant setting with two values, Booking account (the default: every cart is measured against the rules) and No approval (rules are not read; every cart becomes an order and its budget is still booked). Requests already waiting are decided as before either way.
• The approval limit on a contact (order_approval_limit in the customers app) is a stored value shown on the contact. The procurement app does not read it. A spending limit that the checkout respects is a personal limit in the cost-centers app, read by a rule with the condition Personal limit.
• Budgets roll over on their own. A recurring budget gets its successor every night after its period ends, carrying over what its carry-over setting allows. Nobody has to start the new period by hand.

Next

• Approval models — single approver, chains, parallel cost centres.
• Purchase requests vs. orders — why the order is created last.