Seven traps in contract permissions across group subsidiaries

Group legal wants to see in-flight contracts across every entity. Each entity would rather its commercial terms stayed out of sight of its sibling companies. These two wishes conflict, and most projects dodge the conflict at design time by settling on isolation by default with access on request, which simply hands the decision to a stream of individual approvals later.

A workable split separates visibility into two layers: metadata (entity, counterparty, value band, status, expiry) visible to group legal by default, with the document and clause detail isolated per entity and released on request. Group reporting and risk scanning remain possible while commercially sensitive text stays put. Where the split cannot be made, the ruling on which side wins belongs at project kickoff rather than in an argument after go-live.

Entities running their own collaboration tenants, or part of the group on a modern suite and part still on an older OA system, is the norm rather than the exception. The consequence is that one person holds two accounts across two directory trees, and once both are synced into the contract system you get identical names that are different people and identical people holding different identifiers.

Left unresolved, every permission rule after this is built on sand: granting by department misses people, granting by person duplicates them. The order of work is to fix a single source of people data first, usually the HR system rather than any one collaboration tenant, have the contract system read people from there, and leave the tenants responsible only for sign-in and task delivery.

A group usually has one delegation of authority policy stating which approval level a given contract value requires. Implemented as a single global threshold, it ignores that entities can differ in scale by one or two orders of magnitude: a value that is routine at headquarters may require board sign-off at a newly incorporated subsidiary.

Thresholds should be configurable per entity with a group-level fallback. Currency is the companion oversight: contracts at overseas entities are denominated in foreign currency, so threshold evaluation requires conversion, and the rule must state which day's rate applies. Without that, approval levels drift as exchange rates move.

Intra-group service agreements, lending and shared procurement put both parties inside the same system. Under a conventional permission model the originator sees the full text and so does the counterparty, so both legal teams negotiate in a single interface. It feels efficient, and the problem appears at audit: there is no way to demonstrate that the two sides decided independently.

Related-party transactions need their own handling: separated views, independent approval chains and separately recorded decisions. None of this exists at single-entity scale, so it rarely reaches the requirements list, and it is usually added after internal or external audit raises it.

Domestic and overseas entities fall under different rules, and some contract data cannot cross a border in one direction or the other. A single shared deployment makes the strictest requirement binding on the entire group, which is expensive. Fully separate deployments make the group view impossible to assemble.

The middle path keeps documents resident per instance while centralising metadata: files stay in their own compliant storage, and non-sensitive structured fields such as entity, value band, status and expiry roll up to group level. What to establish during evaluation is whether the product supports that split natively or whether it requires customisation. Where inference must also stay in-region, confirm where the model runs; the current status of private LLM deployment is as marked on the product pages.

This one is not a permission problem, but it wastes all the permission work above it. When entities define contract types, risk levels and statuses for themselves, the group cannot aggregate: one company's framework agreement means procurement, another's means sales, and two entities marking something high risk are applying different standards.

Few fields actually need harmonising before go-live, typically contract type, state machine, risk level, entity and currency. Everything else can stay local. Harmonising costs one meeting at kickoff; after two years of operation it costs a data cleansing project.

Holding roles at several entities is common inside a group: someone heads legal at entity A while also being named at entity B. When that person transfers or leaves, HR typically processes only the primary employment relationship. The secondary role stays in the system, and the contract permissions stay with it.

The permission model has to express one person holding different roles at different entities, and revocation has to run entity by entity rather than as a single switch. A periodic review, exporting currently effective grants and reconciling them against the HR active roster, is the reliable control. There is no shortcut, and this is both the most common source of incidents in group structures and the item most often left out.

A self-check you can run today

Export every account that can currently open contract text at any entity in the group, group the list by entity, and confirm each one is still required. Most companies find more entries than expected the first time they do this, particularly after an acquisition or an entity reorganisation.