Build the entity map before the product map
A parent company, subsidiary, branch and shared-service operation may sit inside one organisation chart while having different accounts, employees, accounting records and decision rights. Treating the group as one undifferentiated customer can hide the very details that determine whether a card programme is workable.
Create one record for every entity intended to participate. Capture where it operates, who owns its finance decisions, which populations need cards, how expenditure is recorded and which systems are involved. This is a discovery inventory, not a conclusion about legal or regulatory treatment; the relevant advisers and programme partners should confirm those questions for each market.
- Legal name, registration location and relationship to the group
- Operating and reporting currencies
- Banking, treasury and accounting ownership
- Cardholder populations and their relationship to the entity
- Local finance systems, cost structures and approval processes
- Named stakeholders for finance, operations, technology and review
Separate global policy from local configuration
A scalable programme usually needs a small set of group-wide principles and a controlled set of local variables. Global principles might define who can sponsor a programme, which evidence is required for spending and how access is reviewed. Local configuration may cover limits, currencies, approval paths, cost centres or support hours.
Make the distinction explicit in a policy matrix. For every rule, state whether it is fixed across the group, selected from an approved range or owned locally. This prevents local differences from becoming undocumented exceptions while giving operating teams room to account for genuine variations.
- Global: programme purpose, minimum evidence and oversight expectations
- Configurable: limits, card types, permitted use cases and approval tiers
- Local: entity coding, named approvers, support routing and reporting calendar
- Exception: who may approve a departure, for how long and with what record
Design funding and reconciliation together
Funding should not be designed in isolation from accounting. A central source may simplify treasury visibility but create allocation and intercompany questions. Separate local sources may align more closely with entity ownership but increase the number of balances, processes and reconciliations. The appropriate structure depends on the organisation and the available programme arrangements.
For each entity, walk one transaction from the source of funds through authorisation, settlement, accounting entry and period close. Record currencies, timing, identifiers and exception paths. Finance should be able to identify which entity incurred the cost, who used the card, what the purchase represented and how the record will be matched without relying on manual interpretation.
- Who provides and monitors available funds for each entity?
- How are transactions assigned to entity, cost centre, project and account?
- Which exchange-rate or fee information is required in the ledger?
- What identifier connects a transaction, receipt, approval and accounting entry?
- Who investigates unmatched, reversed, duplicated or disputed items?
Create ownership that survives organisational boundaries
Multi-entity programmes fail quietly when responsibility sits between group and local teams. The group may assume a local administrator is reviewing activity while the local team assumes central finance owns it. A responsibility matrix should therefore cover decisions and recurring operational work, not just project milestones.
Use role-based access and separate sensitive duties where the organisation requires independent approval or review. Avoid giving every entity the same administrative rights for convenience. Access should match the work performed, have a clear owner and be removed or reassigned when people or responsibilities change.
- Programme sponsorship and policy ownership
- Funding requests and balance monitoring
- Card ordering, activation, control changes and closure
- Approval of exceptions and higher-risk actions
- Transaction review, reconciliation and audit support
- Cardholder help, escalation and provider coordination
Roll out in waves with explicit readiness gates
A pilot should test a representative operating model rather than simply use the easiest entity. Select a bounded population with real spend, accountable local owners and manageable dependencies. If later entities have materially different funding, systems or use cases, include those differences in the rollout plan rather than assuming the first configuration will transfer unchanged.
Define readiness and exit criteria before cards are distributed. Review the pilot using both operating evidence and cardholder experience, then decide what must change before the next wave. A phased rollout is valuable only when each wave produces decisions for the one that follows.
- Entity data and programme responsibilities have been reviewed
- Funding, approval, support and reconciliation processes have named owners
- Required configuration and data exchanges have been tested
- Cardholders and administrators have role-specific guidance
- Exceptions can be logged, resolved and used to refine the design
- The sponsor has agreed the evidence required to approve the next wave
This article explains programme-design considerations and is not financial, legal, tax or regulatory advice. Availability and final responsibilities depend on the approved programme and its documentation.