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, consumed as orders are placed and restored when they are not.
3. Limit: how far does this person's own signature reach? A personal ceiling, per contact, sometimes per cost centre. Below it they act; above it they ask.
4. Approver: who signs when they have to ask? A named person, a role, or a chain of them by value.

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 value bands: 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. Its edge cases (what happens on a partial delivery, what happens when two buyers hit the last €500 of a budget in the same second) were analysed line by line before the model on these pages was designed.

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 will work in the Revenue Cloud

The planned model is split across two apps, because money and workflow have different owners and different failure modes.

Cost Centers answers two kinds of question and nothing else: which cost centres may this person use on this line and is there budget. It moves money with four operations, reserve, confirm, withdraw and commit, each of which writes a ledger entry.

Approval Workflows holds the rules and the requests. It 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 of three outcomes: the submit is prevented, an order is created directly, or a purchase request is created and routed. The buyer's browser does not get to choose which.

That single decision point is why the controls hold. There is no path to an order that skips it.

What exists today

None of the two apps above is on your tenant yet. Four of the questions in this article already have a real, if smaller, answer:

Budget control, spend visibility per cost centre, and routing to an approver are the parts that wait for the planned apps. Say so to the customer in those words.

Next

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