New: what governed autonomous procurement actually means
Explainer

Multi-plant & multi-entity procurement: how it works and what to require

In short

This is for groups where procurement runs across several plants, legal entities or acquired businesses. Proconomy applies one group policy framework everywhere, configures entity- and plant-specific thresholds, approvers and requirements, and gives central teams a live operating view without a monthly consolidation cycle.

See Multi-plant & multi-entity procurement

Three categories decide everything. The rest is detail.

What must be common, what differs by entity, and what differs by plant.

Must be common

  • Competitive sourcing above a value threshold
  • Supplier qualification before first purchase
  • Segregation of duties on award and approval
  • Audit retention and evidence standards
  • Sanctions and prohibited-supplier screening
  • Delegation of authority principles

Differs by legal entity

  • Approval thresholds and named approvers
  • Required onboarding documents
  • Tax, currency and statutory requirements
  • Permitted buying routes
  • Contracting entity and jurisdiction
  • Data residency and retention obligations

Differs by plant

  • Escalation timings against shift patterns
  • Local supplier panels and catalogues
  • Delivery points and logistics constraints
  • Emergency purchase handling
  • Local language and working hours
  • Site access and safety requirements

Questions the group can finally answer

  • Where the same material costs different amounts
  • Where policy is applied inconsistently
  • Which entities generate the most exceptions
  • Where supplier concentration crosses entities
  • Which agreements are unused, and where
  • Where local practice has drifted from group rules

Group policy that cannot be switched off. Local configuration inside it.

Six mechanisms, and the first is what makes the framework binding.

MechanismWhat it has to do
Group policy that cannot be switched offRules marked mandatory are inherited and cannot be locally disabled, which is what makes the framework binding rather than advisory.
Entity configuration inside the frameworkThresholds, approvers, documents, permitted routes and contracting entity set per legal entity, within the group boundary.
Plant-level operational settingsEscalation timings, catalogue scope and local supplier lists per site, where the difference is operational rather than governance.
Explicit approval scopeSupplier and category approval is scoped to entity. Clearance in one never silently becomes clearance in another.
Shared supplier, separate authorityTwo entities can transact with the same supplier under different approval, pricing and qualification positions.
Policy variance as a measurementWhere local practice diverges from group rules, visible continuously rather than discovered in an audit sample.

A description of what the practice requires, not a feature list.

What drives the differences, by sector

Automotive

Plant-level launch programmes under group commodity strategy, with tier concentration measured across entities.

Building materials

Regional supply is frequently correct. The point is seeing the delivered-cost spread and deciding deliberately.

Industrial equipment

Project entities and service entities operating under materially different approval logic.

Medical devices

Entity-specific regulatory scope, where approval for one market genuinely cannot transfer to another.

Five questions. Run on your own workflow.

Each takes minutes and none can be prepared for.

  1. Ask them to run one of your workflows in the session, on your policy and your thresholds.
  2. Ask what happens when reality varies from the happy path — that is where most of your work lives.
  3. Ask which decisions return to a person, and confirm those checkpoints cannot be configured away.
  4. Ask what the system did without a person overnight, and see the record.
  5. Ask what they would advise you not to do first.

Definitions. Asked and answered.

Yes. Thresholds, approvers, required documents and permitted buying routes are configured per entity, and often per plant. Group rules define only what must be common.

Proconomy connects to each system, reads approved context and writes approved outcomes back to the right one. ERP consolidation is not a prerequisite for procurement standardisation.

The entity is configured into the existing framework with its own thresholds, approvers and supplier requirements, and it appears in the group operating view from go-live rather than after an integration programme.

Yes. Approval scope is explicit — a supplier approved for one entity and category does not automatically become available elsewhere, which is what makes shared records safe.

Role- and entity-based access controls both directions. Group leaders see consolidated activity and can drill within their rights; plant teams retain the operating autonomy the entity grants them.

Multi-entity procurement is the governance of purchasing across several legal entities, plants or business units that share group policy but differ in approval authority, statutory obligations and operating reality. The difficulty is applying common rules without forcing identical processes.

Because plants differ in ways that matter operationally — shift patterns, delivery points, local supplier availability, statutory requirements — and a process that ignores those differences gets worked around rather than followed.

By separating the rules that create enterprise risk, which are set centrally and cannot be disabled, from the settings that reflect local operating reality, which are configured per entity and plant inside that boundary.

See it on your own workflow. Not a prepared scenario.

Reference material explains the model. A demonstration on one of your own processes is what settles the internal argument.

Someone from client success replies, not a sales sequence. If we are not a fit we will say so on the first call.