Post-Acquisition Ledger Design: One Chart of Accounts or Three?

Recommendation: leave MXMF on its local chart for now and consolidate by mapping.

• A shared chart of accounts is a container of main accounts; each legal entity's ledger points at a chart and activates only the accounts it needs through account structures. Sharing the chart does not by itself create statutory alignment, so the migration buys less than the team assumes.
• The mapping work does not disappear. A statutory trial balance in a local chart has to be mapped to group accounts for consolidation either way, so the mapping is a cost you pay regardless.
• Volume: ~40 vouchers a month is ~480 a year. Against that, relocation costs (history mapping, opening balances, local auditor sign-off, retraining, cutover) are large, and the cutover risk lands in the same window as go-live.
• Statutory risk is concentrated in a chart the local auditors already trust. Rewriting it in a go-live window buys no reporting benefit.

Do instead: build a consolidation account group mapping every MXMF main account to its USMF equivalent and run Consolidate online monthly into a dedicated consolidation legal entity. Revisit migration only if MXMF volume grows materially or the group mandates a single system of record, and then do it as a phased project with a parallel run.

Four things, in order:

1. Make Department a real dimension in MXMF: create the financial dimension, attach it to MXMF's account structures, and make it required on the accounts that carry it so new postings cannot bypass it.
2. Align the values: dimension values are maintained per legal entity by default. Either create the identical value set in USMF, DEMF and MXMF, or use shared financial dimensions so a value is maintained once. If the strings differ (Cardio vs Cardiology), consolidation silently produces two departments.
3. Backfill history: map the free-text strings to dimension values and correct open transactions. Closed periods usually need an adjustment entry or a dimension transfer rather than an edit.
4. Control the transfer in consolidation: the consolidation account group can force a dimension value on the consolidated line. If Department is forced there, you lose transaction granularity and every MXMF line lands in one department. Leave the Department field blank on the consolidation accounts so the source transaction's value flows through.

Test: run one month in a sandbox and prove two reconciliations - the sum of departments equals the consolidated total, and the MXMF side ties to its own trial balance.

• Budget control configuration is scoped to one legal entity. Budget models, budget codes, budget cycles, budget control configuration, budget groups and control rules are all set up in USMF's company context. Nothing propagates.
• DEMF and MXMF postings, purchase requisitions and purchase orders are never checked against budget. That is a deliberate control gap and should be written down and accepted, not discovered later.
• Calendars: each legal entity has its own fiscal calendar on its ledger, and USMF's budget cycle must line up with USMF's calendar. Do not assume the German or Mexican calendars match.
• Consolidation does not carry budget data. Budget register entries and budget control balances are not consolidated into the consolidation entity, so the consolidated pack shows actuals only. Budget-versus-actual across the group has to be assembled outside the consolidation entity or by loading group budget data separately.
• If MXMF later needs control, that is a fresh configuration exercise - separate budget model, cycle and rules - not a switch.