Multi-entity ledger, intercompany imbalance and unfinished security before a fourth entity goes live
Kestrel Mobility manufactures EV charging hardware and has three legal entities: Kestrel Canada (Toronto, Canadian dollars), Kestrel US (US dollars) and Kestrel GmbH (Frankfurt, euros). A Japanese entity opens in eight months with a fiscal year ending 31 March; the other three close on 31 December. Finance built one chart of accounts with 1,900 main accounts and twelve account structures, but the German tax team insists on its own statutory chart. The US entity sells finished units to Germany; today the two teams post manual intercompany journals at month end using different exchange rate types, and the group trial balance never nets to zero on the intercompany accounts. Purchase order numbers restarted at 1 after a data migration, so Canada and the US now share duplicate numbers. Security was never finished: 40 of 260 users hold the System administrator role 'temporarily'. The audit committee wants a remediation plan before the Japan go-live.
1. How would you decide between one shared chart of accounts for all four entities and a separate statutory chart for Germany?
Read the worked answer
Decide on evidence, not preference. A chart of accounts is assigned per legal entity's ledger, and several legal entities can share the same chart. Sharing gives you consistent main accounts, simpler consolidation and reporting, and fewer mappings; it also means any main account added for Germany is visible to everyone.
Ask the German tax team how many statutory-only accounts they actually need. If the answer is a small set, keep one shared chart and add a reserved number range for statutory-only accounts, then use separate account structures per legal entity to control which accounts each entity may post to. If the statutory chart is structurally different (different account classes, different reporting hierarchy, thousands of accounts), give Germany its own chart and maintain an explicit mapping to the group chart for consolidation.
The dimension design matters more than the chart choice. Decide which dimensions are mandatory per entity through account structures, and whether statutory reporting needs a dimension rather than main accounts. Also confirm the fiscal calendars: a legal entity with a 31 March year end needs its own fiscal calendar and period definitions, so Japan should not inherit the December calendar.
2. Intercompany balances do not net to zero at group level. Diagnose the likely causes and design a control that prevents recurrence.
Read the worked answer
The symptom points at process and setup, not at the trial balance. Likely causes:
- Rate type mismatch: the two teams use different exchange rate types (or the same type with a different rate date), so the due-to and due-from legs translate differently. Fix the rate type per intercompany relationship and post both legs in the same period from the same rate.
- Manual journals instead of intercompany accounting: hand-keyed entries route around the due-to/due-from accounts defined for the entity pair, so one side posts to the wrong account or is missed. Configure intercompany accounting for the US–Germany pair and generate the counter-entry, or use intercompany sales orders so the seller's invoice creates the buyer's payable.
- Timing: one entity posts in a period the other has closed.
Control: a monthly intercompany reconciliation using the intercompany accounting and due-to/due-from balances by partner, with an owner and a sign-off before consolidation. Post any residual difference to a designated intercompany suspense account, never to operating expense, and clear it before close. Track the suspense balance trend as the KPI.
3. What remediation do you propose for the duplicated purchase order numbers and the 40 System administrator users before the Japan go-live?
Read the worked answer
Number sequences. Check the scope of the purchase order number sequence in each legal entity's procurement parameters. A company-scoped sequence gives one series per legal entity; a shared sequence gives one series for all. After migration, the next number was left at a value below the migrated maximum, so new orders collided with history. Do not try to change the scope of a sequence already in use; instead set the next number above the highest migrated value with headroom, verify every legal entity, and add a pre-go-live checklist item that compares max used number against next number for every sequence. For Japan, define sequences before the first transaction, not after.
Security. System administrator is not a working role; it bypasses duty separation and cannot be audited meaningfully. Build roles from duties that match each job (AP clerk, purchasing agent, warehouse worker, controller), assign users to those roles, and keep a small break-glass admin group with named owners and periodic review. Use security diagnostics to test each role against the actual menus and duties a user needs, then run a segregation-of-duties review on create-vendor versus pay-vendor and on journal create versus approve. Target removal of the 40 temporary admins before the Japan user provisioning wave, not after.