Multi-entity management: how it works and what to require
Proconomy multi-entity management applies a group procurement policy framework across every legal entity and plant, while allowing entity- and plant-specific thresholds, approvers, supplier requirements and buying routes. Role- and entity-based access gives each user the right context, and consolidated reporting removes the monthly group consolidation cycle.
What must be common. And what genuinely has to differ.
Twenty-four rules, sorted into the three categories that decide your policy framework.
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 documents for supplier onboarding
- 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-specific safety and access requirements
Group questions this answers
- Where the same material is bought at different prices
- Where policy is being applied inconsistently
- Which entities have the most exceptions
- Where supplier concentration crosses entities
- Which agreements are unused in which entity
- Where local practice has drifted from group rules
Group policy that cannot be switched off. Local configuration inside it.
Eight mechanisms, and the first one is what makes the framework binding.
| Mechanism | What it has to do |
|---|---|
| Group policy that cannot be switched off | Rules the group defines as mandatory are inherited and cannot be locally disabled — which is what makes the framework meaningful rather than advisory. |
| Entity configuration inside the framework | Thresholds, approvers, required documents, permitted routes and contracting entity configured per legal entity, within the group boundary. |
| Plant-level operational settings | Escalation timings, catalogue scope and local supplier lists set per site, where the difference is operational rather than governance. |
| Explicit approval scope | Supplier and category approval is scoped to entity, so clearance in one entity never silently becomes clearance in another. |
| Role and entity-based access | Every view and every action bounded by role and entity, so consolidated visibility does not mean uncontrolled visibility. |
| Shared supplier, separate authority | Two entities can transact with the same supplier under different approval, pricing and qualification positions. |
| Policy variance reporting | Where local practice diverges from group rules, visible as a measurement rather than discovered in an audit. |
| Consolidated group view | Work in progress, exceptions and spend across every entity, without consolidating the underlying systems first. |
A description of what the practice requires, not a feature list.
Same hierarchy. Different reasons entities differ.
What actually varies, by industry.
Automotive
Plant-level launch programmes with group-level commodity strategy, and tier concentration measured across entities.
Building materials
Regional supply is often correct. The point is seeing the delivered-cost spread and deciding deliberately rather than by default.
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. Configured live, in the session.
Two entities, two approval matrices, one platform.
- Configure two entities with genuinely different approval matrices for the same category, in the session.
- Try to buy in entity B from a supplier approved only in entity A. It should stop you.
- Ask what a group rule marked mandatory prevents a local administrator from doing.
- Confirm a plant user cannot see another plant's data from the same model.
- Ask how policy variance is measured, not just how policy is set.
Definitions. Asked and answered.
A practical rule: govern centrally what creates enterprise risk or leverage — competitive sourcing, supplier qualification, segregation of duties, audit retention. Configure locally what reflects operating reality — thresholds, approvers, delivery conditions and local supplier lists.
No. Local configuration operates inside the group framework. An entity-level exception to a group rule requires an authorised approval and is recorded.
The new entity is configured into the existing framework with its own thresholds, approvers and supplier requirements, and it appears in the group view from the point it goes live.
Within their access rights, yes. Group leaders can drill from consolidated views to entity, plant, supplier and transaction detail, while plant users see the context relevant to their operation.
Integration is scoped per connected system. Groups running several ERP instances are a common pattern; supported systems and objects are confirmed during scoping rather than claimed in advance.
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 requirements and operating reality. The difficulty is applying common rules without forcing identical processes.
A procurement policy framework defines which rules are mandatory group-wide, which may be configured locally, and who holds authority at each level. Encoded as executable rules rather than a document, it is applied as part of the work instead of depending on memory and retrospective sampling.
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. The durable approach standardises what creates enterprise risk and configures what reflects local reality.