Expense management across every entity

Why a single-entity workflow breaks at the second entity

A single-entity expense workflow can afford a set of silent assumptions: one policy, one functional currency, one approval chain, one chart of accounts, one audit file. None of those assumptions survives the second legal entity.

• Policy stops being singular. A meal threshold that is defensible in one market is trivial or prohibitive in another. Per-diem rules, receipt requirements, and non-reimbursable categories all acquire entity-specific variants — and a workflow with nowhere to put the variant forces someone to enforce it by hand.
• The approver is now ambiguous. “Route to the manager” is a complete rule in one entity. Across several, the correct approver depends on which entity carries the cost, and an approver in the wrong entity may have no legal or budgetary authority over the claim at all.
• The books diverge. Each entity keeps records in its own functional currency and answers to its own tax authority. An expense recorded against the wrong entity is not a cosmetic error; it misstates two sets of books at once and creates an intercompany balance that someone has to find, document, and settle.
• The audit surface multiplies. One entity means one auditor asking questions. Several mean overlapping audits, each entitled to a complete, self-contained evidence trail for its entity only — including proof that what they are shown excludes everyone else’s records.

The common workaround — running a separate instance of the same tool per entity — solves the control problem by destroying the visibility problem’s solution. Nobody can answer “what did we spend last month, everywhere?” without a manual consolidation exercise, and every group-level question turns into an export-and-merge project.

What entity-level control actually means

“Multi-entity support” on a feature list can mean anything from a genuine control boundary to a label on a report. The test is whether the entity dimension changes what the system permits, not just what it displays. Entity-level control holds when four things are true:

• Visibility follows membership. Users see the entities they belong to and nothing else. An employee submitting in one entity should not be able to browse another entity’s claims, approvers, or bank details — and an auditor reviewing one entity’s file should not need anyone to manually crop out the rest of the group.
• Approval authority is entity-scoped. An approver’s rights exist within an entity, not globally. Someone who administers one entity and merely submits expenses in another should hold both roles simultaneously without either leaking into the other.
• Policy varies where it should, within group bounds. Local finance sets thresholds that reflect their market; group finance keeps a floor below which no entity can drift. Both need to see which rule was in force when a claim was decided.
• Consolidation preserves source records. Group-level reporting aggregates across entities without erasing which entity each record belongs to, what currency it was incurred in, or what evidence was attached. A consolidated number that cannot be drilled back to entity-level source records is a number an auditor will not accept.

Clara is built around this model: each entity keeps its own membership, roles, approval configuration, and records, while people who work across several entities switch between them under one account — group visibility without flattening the boundaries between books.

The entity dimension at every workflow stage

Entity-level control is not one feature but a property each stage of the workflow either preserves or loses. The stages fail differently.

1. 1

   Submission — bind the claim to an entity

   The claim must carry its entity from the moment it exists, because everything downstream — policy, approver, currency treatment, audit file — reads that field. A submitter who works in one entity should never have to choose; one who works in several should choose explicitly, at submission, not have finance reassign it after the fact.

2. 2

   Approval — route within the entity

   The approval chain evaluated for a claim is the chain of the entity that owns it. This is what keeps an approval legally meaningful: the person approving has authority over that entity’s budget, and the record shows a decision made inside the right boundary.

3. 3

   Payment preparation — group by entity, then by currency and account

   Reimbursements are paid by a specific legal entity from a specific bank account. A payment run that mixes entities produces transfers from the wrong company — which is not an expense error but an accounting event that has to be unwound. Clara produces a payment-ready reimbursement report grouped this way, and the finance team of each entity executes the transfers through its own bank; Clara does not execute transfers itself.

4. 4

   Close and audit — keep entity files separable

   At period close, each entity needs its expense records complete, in its functional currency, with evidence attached and the approval history intact. The group needs the same records aggregated. If producing either view requires manual surgery on the other, the entity dimension was lost somewhere upstream.

Entities, currencies, and approvals move together

The multi-entity problem is rarely just an entity problem. The second entity is usually in a second country, which brings a second currency, a second tax regime, and employees whose claims cross all three. Three design decisions keep the combination manageable.

Denominate each entity’s thresholds in its own currency

A group-wide threshold expressed in one currency drifts against every other entity’s costs as exchange rates move. Set thresholds per entity, in the currency in which that entity actually spends, with a group-level floor to prevent silent divergence.

Fix the exchange rate at a defined moment

When a claim in one currency routes by a converted amount, the moment of conversion must be defined, or the amount that determined the routing and the amount in the books will disagree. In Clara the FX rate is locked at submission, so the converted amount that routed the claim is the same amount visible on it afterwards. The mechanics of documenting rate choices are covered in foreign currency expenses and multi-currency expense management.

Design approval chains per entity, not per org chart

The reporting line and the approval line are different graphs. A regional manager may sit above five entities in the org chart while holding formal authority in only two. Approval design that follows the entity keeps every decision inside a boundary an auditor recognizes — the fuller treatment is in automated expense approvals and spend controls.

Because employees can sit anywhere the group operates, the workflow has to accept a claim from any country, in any currency, under whichever entity carries that employee — the constraint that makes the entity dimension unavoidable rather than optional.

Group visibility without flattening entity records

Consolidation is where multi-entity expense management earns its keep — and where flattening does its damage. IFRS 10 requires a parent that controls one or more entities to present consolidated financial statements: the assets, liabilities, equity, income, expenses and cash flows of parent and subsidiaries presented as those of a single economic entity. IAS 21 adds that each entity’s functional currency is the currency of its primary economic environment — which means a group view is always a translated view, and the translation must be reconstructable.

For the expense workflow, two practical consequences follow:

• The group view is derived, never primary. Entity records in the entity’s functional currency are the source of truth; the consolidated view translates and aggregates them. A system that stores only the group-currency figure has thrown away the number the entity’s own books and auditors need.
• Cross-entity claims create intercompany balances. When an employee of one entity incurs a cost that belongs to another, the reimbursement and the cost sit in different companies until an intercompany charge moves it. Left unfound, these become the reconciling items that stall a group close — the identification and settlement workflow is covered in intercompany expenses.

The operating model that follows: give group finance a consolidated reporting view, keep every entity’s file self-contained underneath it, and make the link between the two a drill-down rather than a spreadsheet.

A buyer’s checklist for multi-entity expense software

Feature lists converge; behavior under multi-entity load does not. These are the questions that separate a control boundary from a report label.

Run the checklist against real scenarios from your own group — the employee who works across two entities, the claim in a currency neither entity uses, the auditor who wants one entity’s file — rather than against the vendor’s demo structure.