The arrangement almost nobody chose
Most groups running Oracle NetSuite and Oracle Fusion Cloud ERP at the same time never decided to. An acquisition closed, the acquired finance team kept its ledger, and eighteen months later the group has two general ledgers, two close calendars and two sets of accountants who each believe their numbers are the ones that count. The decision that determines whether the arrangement survives is which ledger actually counts, and most programmes answer it by default rather than on purpose.
The shape varies. A large group runs Fusion at the centre for statutory reporting and leaves NetSuite in the acquired subsidiaries, because pulling it out during an integration year costs more attention than anyone has spare. The reverse happens too, where a mid-market NetSuite business buys a division that arrives with Fusion in production and four years left on the services contract. Neither shape is wrong on its own.
What separates a sustainable version from an expensive one is a short list of decisions taken in the first six months. The choice between NetSuite and Fusion Cloud gets argued for weeks when a group is picking a platform, then nobody reopens the argument on the day an acquisition hands them both.
Whichever ledger consolidates inherits the calendar
Consolidation is a responsibility rather than a feature, and the system that carries it picks up obligations that have very little to do with software. The consolidating ledger owns the group close calendar, the currency translation rules, the elimination entries and the audit trail an external auditor follows when they sample intercompany balances. Whoever administers that system has joined the close, whether or not their job description mentions it.
NetSuite OneWorld does this inside one account, with subsidiaries in a hierarchy, consolidated rates maintained per period and eliminations posted against elimination subsidiaries. Fusion does it through ledger sets, reporting currencies and secondary ledgers, plus a separate consolidation product when the structure needs one. Both approaches work. The difference at group level is that one system holds the record the auditor tests and the other becomes a feeder.
Say the word feeder out loud in the steering meeting. The subsidiary ledger stops being the group's source of truth on the day the other ledger consolidates, and that finance team should hear it from an architect rather than during the first statutory audit. Reversing the choice later looks simple on a slide and is brutal in practice, since moving consolidation means restating comparatives and re-proving a full year of eliminations.
One chart of accounts, or a mapping layer with an owner
The chart of accounts decision has two honest answers. Force one global chart onto both systems, which is clean and slow and politically expensive, or maintain a mapping layer, which starts faster and becomes a permanent piece of infrastructure. Programmes get into trouble by picking the second while describing it to the board as the first, so nobody ever funds the owner the mapping needs.
The structures do not line up, which is why mapping is harder than the slide suggests. Fusion uses a segmented accounting flexfield with value sets and cross validation rules, so entity, cost centre and natural account all live inside one combination. NetSuite keeps a flatter account list and pushes the rest onto subsidiary, department, location, class and custom segments. A Fusion combination can map cleanly to a NetSuite account plus three classifications, or to something nobody can defend in an audit.
Where the reversibility sits deserves a blunt answer. A mapping layer can be retired later by converging the charts, at the cost of a conversion project. A global chart conversion is not meaningfully reversible, because you have restated history, retrained an accounting team and withdrawn account values that tax packs and bank templates already reference. Give the mapping table an owner and a change process, the discipline an ERP master data governance starter applies to vendor records, or it drifts within two quarters.
The two products disagree about what an entity is
Intercompany is where that disagreement surfaces. NetSuite models a subsidiary as one record in a hierarchy with its own base currency, and every transaction carries the subsidiary. Fusion separates legal entity, ledger and business unit, so two legal entities can post to a single primary ledger and be distinguished only by their balancing segment value. Both models are defensible. They are not the same model.
Eliminations break quietly on that gap. A rule that matches on an entity identifier assumes both systems agree on the list of entities. When the mapping runs many to one, the group level intercompany pair nets to zero while the entity level pair does not, and the residual lands in a clearing account that somebody empties with a manual journal every month. Nothing errors. The trial balance looks right until an auditor asks for the entity level detail behind one of those journals.
The fix is dull and it holds. Agree one durable identifier for every legal entity, store it on both sides in a field nobody can edit without a change request, and reconcile the two lists on a schedule instead of during close week. The case for durable business keys applies to legal entities harder than to any other record, because an entity identifier outlives the system that issued it and the person who invented the numbering.
The group close runs at the pace of the slower ledger
Two systems with different close timings produce one group close bounded by the later of the two. If the NetSuite subsidiaries lock payables on working day five and the group wants a consolidated trial balance on working day four, the group does not get day four. It gets day five, or it gets an estimate every month with a true up the month after, which an auditor will happily sample.
The honest consequence is that the subsidiary ledger's cut-off discipline stops being a subsidiary matter. Accrual policy, the cut-off for goods received but uninvoiced, and the treatment of late vendor invoices all become group rules enforced inside a system the group finance team does not administer. That needs a written agreement and a named person in the subsidiary, because no amount of configuration buys someone else's discipline.
Currency translation earns its own sentence. Two rate tables maintained by two teams produce two translated figures for the same entity, and the gap surfaces as a variance nobody can explain in the month it appears. Pick one rate source, publish it into the other system on a schedule and keep the copy auditable. The same instinct that settles who gets to define revenue settles this one: a single definition, a single owner, a single place it is maintained.
Whether this is temporary changes the design
The question most programmes avoid is whether the dual ledger state sits on the road to one ERP or stands as the permanent answer. The correct architecture genuinely differs. A transitional state deserves the thinnest bridge that survives eighteen months: summary level journal pushes, a mapping table maintained by hand, manual intercompany reconciliation and no investment at all in reporting on the departing side.
A permanent arrangement deserves the opposite. Shared vendor and customer master governance, automated intercompany matched on stable entity identifiers, one rate source, a documented mapping with a funded owner, and reporting that reads both ledgers without anyone exporting to a spreadsheet. Building all of that for a state you intend to exit within a year wastes real money. Building the eighteen month bridge for an arrangement that runs a decade buys ten years of manual close work nobody put in the business case.
A transitional state nobody ever ends becomes the most expensive version of both, carrying the manual overhead of the bridge and the deferred cost of the convergence, year after year, with no owner able to call it either way. Run a migration rehearsal early, since it is the cheapest way to learn whether the convergence everyone keeps promising is real. Then force an answer to one question at the next finance architecture meeting: if the group had to restate last quarter's consolidated revenue tomorrow, which system would you re-run to prove the new figure, and who signs it. If two systems come back, or two names, you already know which ledger counts and which one people only hope counts.
