eProcureAI / Platform / Run procurement across entities
Use caseMulti entity structures are where procurement software usually breaks. One approval chain for everybody, one supplier list, one currency. Each entity needs its own rules and the group still needs one picture.
Enterprise capability. Multi entity and multi currency are not on the entry plans.
Software built for a single company can usually be stretched to cover several, and the stretching is where the problems start.
One approval chain has to serve entities with different sizes and risk appetites, so it ends up set for the largest and feels absurd in the smallest. One supplier list means a supplier approved for a specialised entity quietly becomes purchasable everywhere. One currency means either the subsidiaries or the group is always reading translated numbers.
The workaround is usually separate instances, which solves the local problem and destroys the group picture. Now consolidated reporting means asking four controllers for spreadsheets.
What multi entity actually requires is that each entity carries its own thresholds, budgets, numbering and supplier scope, while the group can still see across all of them without asking anybody.
That is a structural question rather than a reporting one, which is why bolting consolidated reporting onto a single company system rarely feels right.
Ordering in a supplier's currency and reporting in yours only works if the rate is captured when the commitment is made. Otherwise the committed position drifts with the exchange rate and nobody can explain the movement.
Set for the largest entity, which makes it disproportionate for the smallest and encourages workarounds there.
A supplier approved for one entity becomes purchasable across the group without anybody deciding that.
Order sequences that interleave across entities, which makes reconciliation and audit awkward.
Either subsidiaries or the group is always reading translated figures, and the committed position drifts.
Thresholds, approvers, budgets and numbering are set per entity, because a subsidiary in one market rarely buys like the parent.
One supplier record avoids duplication. Purchasability is scoped, so approval in one entity does not silently open the supplier to the whole group.
Order in the supplier's currency and report in yours, with the rate fixed at the moment of commitment so the committed position does not move with the market.
The split between these is what makes a multi entity deployment work rather than feel imposed.
| Element | Per entity | Across the group | Why |
|---|---|---|---|
| Approval thresholds | Yes | Reportable | A small entity should not inherit a large one's limits |
| Budgets and charge codes | Yes | Consolidated | Entity finance owns its own position |
| Order numbering | Yes | Reportable | Independent sequences keep reconciliation clean |
| Supplier purchasability | Scoped | Record shared | Avoids duplication without silent access |
| Reporting | Drill down | Consolidated | The group needs one picture without asking anybody |
Intercompany arrangements vary more than anything else here, so they are mapped during implementation against how your ledger already treats them.
Mapped during implementation against your ledger rather than invented for the software.
Delegated administration lets an entity change its own thresholds without a central request.
Some suppliers genuinely serve everybody. Deciding which is a five minute conversation worth having upfront.
How and when rates are set, which affects every committed figure the group sees.
The most variable part, and the one worth bringing an example of to the demo.
Usually spend, commitments and savings, with drill down into any single entity.
Multi entity works when it is structural, and feels imposed when it is reporting bolted onto a single company design.
Entities run themselves, the group looks across. Neither has to compromise for the other.
Applies the right entity's rules and rolls everything up without a collection exercise.
Including the intercompany arrangements. That is the part worth discussing with a real example.
Book your free demoRelated: All solutions and Access and Permissions