What counts as an intercompany expense
An intercompany expense is any cost that involves more than one legal entity in the same group — one entity pays, another (or several) receives the benefit. In an employee expense workflow they arrive in a handful of recurring shapes:
- Cross-entity work. An employee of entity A travels to support entity B — a project, an audit, a rollout. Entity A reimburses its employee; the cost economically belongs to entity B.
- Shared purchases. One person buys something the group consumes together: a team event across entities, a tool licensed group-wide, a booth at a fair where three entities exhibit.
- Group-role spend. People with group-level roles — a CFO who oversees five entities, a recruiter hiring for three — generate expenses that no single entity should carry in full.
- Convenience payments. The person with the corporate relationship or the local bank account pays, regardless of whose cost it is. Practical in the moment, misallocated by construction.
The unifying property: the entity that reimburses the employee and the entity that should bear the cost are not the same, so the reimbursement creates an intercompany balance — a receivable in one company, a payable in the other — that exists whether or not anyone has written it down yet.
Why waiting until reconciliation makes everything weaker
Cross-entity costs found at month end instead of at submission carry three compounding penalties.
The evidence has decayed. The strongest statement of why a cost was shared is the one made by the person who incurred it, at the time they incurred it. A rationale reconstructed weeks later by someone in finance is an inference, not a record — and it reads as one to an auditor.
The balances are related-party balances. Transactions between group companies are related-party transactions, and IAS 24 exists precisely because of them: its objective is to ensure financial statements draw attention to the possibility that an entity’s position and results have been affected by related parties and by transactions and outstanding balances with them, and it requires disclosure of the nature of the relationship and information about those transactions and balances. An intercompany balance nobody documented at source is a disclosure item assembled from guesswork.
The charge may need to survive a tax examination. When the entities sit in different jurisdictions, the intercompany charge that moves the cost is a controlled transaction. In the United States, section 482 authorizes the IRS to adjust the income, deductions, credits, or allowances of commonly controlled taxpayers to prevent tax evasion or to clearly reflect income, and the regulations generally require intercompany prices to yield results consistent with what uncontrolled parties would have realized in the same transaction under the same circumstances — the arm’s-length standard. Most tax authorities apply an equivalent principle. A recharge backed by a contemporaneous business purpose and allocation rationale is defensible; a lump “management fee” invented at close is the kind that gets examined.
None of this requires expense software to compute transfer prices — it requires the workflow to preserve, at source, the facts the accountants and advisers will need: who spent, for whose benefit, why, and on what basis it was split.
Capture the allocation before the approval, not after
The single highest-leverage change is to move the allocation question from reconciliation to submission. Three facts have to be on the claim before it is approved:
The employing entity
Which entity owns the employee and will reimburse them. This is fixed by the employment relationship and determines whose bank account pays and whose books record the reimbursement.
The benefiting entity or entities
Where the cost economically belongs. For a single-beneficiary claim this is one field; for shared costs it is a split with percentages. The submitter is the person most likely to know, and submission is the moment they still remember.
The approver with authority over the benefiting budget
Approval by the submitter’s own manager establishes that the spend was legitimate; it does not establish that another entity agrees to bear it. A cross-entity claim needs a decision from someone accountable for the receiving side — the budget owner in the benefiting entity, or a group-level owner with authority over both.
Route on the benefiting entity, not just the employing one. A workflow that only ever routes to the submitter’s manager will approve cross-entity costs all day without anyone on the receiving side ever seeing them — every one a small surprise scheduled for month end.
Keep the allocation rationale on the claim
The claim itself is the best container for the allocation evidence, because it is the record everyone can already find — attached to the receipt, the amounts, and the approval history. A separate month-end allocation spreadsheet divorces the rationale from the evidence and ages badly. What finance needs on the claim:
| Field | Why finance needs it |
|---|---|
| Employing entity | Determines who reimburses the employee and where the payable to the employee sits |
| Benefiting entity or entities | Shows where the cost belongs and which intercompany balance the claim creates |
| Allocation basis and percentages | Explains how a shared cost was split — headcount, usage, project share — so the split is a method, not a negotiation |
| Business purpose | The contemporaneous statement of why the cost served the benefiting entity — the sentence the recharge documentation will quote |
| Cost center or project | Lets the receiving entity book the cost where its own reporting needs it |
| Approver identity and role | Proves someone with authority over the benefiting budget accepted the cost, and when |
| Currency and rate applied | Cross-entity usually means cross-currency; the recharge must use a stated, dated rate |
| Supporting documents | Receipt, and for recurring arrangements the agreement the recharge sits under |
Two of these deserve emphasis. The allocation basis turns a percentage from an assertion into a method — “40/60 by project headcount” can be checked next quarter; “40/60” cannot. And the business purpose is the field with the longest useful life: it feeds the entity’s own audit file, the related-party disclosure, and the transfer-pricing documentation, all from one sentence written while the facts were fresh.
Clara keeps this evidence in the workflow: each entity’s claims, approvals, and documents stay inside that entity’s boundary, and a claim carries its attachments and approval history with it — so the allocation record is wherever the claim is, not in a parallel spreadsheet. For what the surrounding trail must capture field by field, see expense audit trails.
The settlement leg: from reimbursement to recharge
Reimbursing the employee closes the loop with the person; it does not close the loop between the entities. The full sequence has four stages, and skipping the middle two is where groups accumulate their unexplained balances:
Reimburse the employee
The employing entity pays its own employee under its own policy, in the reimbursement run it was going to execute anyway.
Recognize the intercompany balance
The employing entity records a receivable from the benefiting entity; the benefiting entity records the cost and a payable. This is bookkeeping, but it only happens if the claim carries the benefiting-entity field that triggers it.
Issue the recharge
On a schedule — monthly is typical — the accumulated cross-entity costs are invoiced between entities, with the claims as line-item support. Cross-border recharges need the arm’s-length framing above and, in many jurisdictions, attention to VAT or equivalent tax treatment on the recharge itself.
Settle and reconcile
The balance is paid or netted, and both sides confirm the same number. Intercompany balances that never settle are the classic aging item a group auditor asks about first.
Currency spans the whole sequence: the employee may spend in one currency, the employing entity reimburses in another, and the recharge lands in a third. Fixing the conversion moment early is what keeps the three amounts reconcilable — in Clara the FX rate is locked at submission, so the recharge documentation can point at a stated rate on a stated date. The rate-documentation mechanics are covered in foreign currency expenses.
Compensating controls when the same people run several entities
Cross-entity expense flows concentrate risk in a specific way: the people most likely to handle them — group finance, shared-services accountants, multi-entity administrators — are exactly the people whose access spans entities. One person may administer the workflow in entity A, approve in entity B, and prepare payments in both.
The role design that contains this is entity-scoped: a person’s role is granted per entity, so the same individual can be an administrator in one entity and only a submitter in another, and visibility follows membership rather than seniority. Clara scopes roles and visibility per entity in exactly this way. But scoping alone does not resolve every conflict — small teams will still have individuals with broad access — so compensating controls carry the rest:
- Cross-entity claims always get a second pair of eyes. Whatever the amount, a claim allocating cost to another entity should not be approvable solely by someone acting for the paying side.
- A periodic report of cross-entity activity, reviewed by someone who does not process it — group controller or CFO — looking for allocations that concentrate in one preparer, one counterparty, or one round percentage.
- Periodic access review of who holds which role in which entity, against what their job actually requires now, not when they were granted it.
- No self-settlement. The person who prepares the recharge should not be the only approver of its payment on either side.
The general duty-splitting framework — which conflicts matter most and a matrix to test your own — is covered in segregation of duties in expenses, and the entity-boundary design that makes these controls enforceable is the subject of multi-entity expense management.