Station 3 of 10
Enterprise structures and master data in Oracle Fusion
What you leave this station with
A written design for a two-entity, two-currency group, a chart of accounts with every segment justified, and a clear list of what cannot change after the first journal.
Station two built a way of learning. This station builds the foundation the remaining seven stand on.
It is the heaviest station here, for one reason: most of the decisions on this page cannot be undone. The system will let you rename a supplier a thousand times. It will not let you add a segment to the chart of accounts once a journal has posted against it.
The three layers that get conflated
Single-company systems have one layer, called “the company”. There are three here, and none of them does another’s job.
| Layer | What it is | What hangs off it |
|---|---|---|
| Legal entity | The registered person in the eyes of the state | Commercial registration, tax number, statutory reporting |
| Ledger | The accounting container itself | Journals, balances, the close, the financial statements |
| Business unit | The operating unit that transacts | Purchasing, payables, receivables, sales orders |
Three relationships between them, understood once, save ten pages:
- A single legal entity’s books may sit in a ledger shared with others, provided the four pillars agree.
- One business unit may serve more than one entity, and many units may sit under one ledger.
- The unit that buys is not necessarily the entity that pays. That sentence is exactly why the product looks over-engineered to somebody arriving from a single-company system, and exactly why it exists.
A worked case settles it. A Saudi group with a company in Riyadh and another in Dubai. Two entities, always. Two ledgers, because the currencies differ. Possibly one procurement unit buying for both from a single centre.
The four pillars of a ledger
Every ledger is defined by four things, and they are the most commonly asked question in both interviews and exams.
| Pillar | What it settles | Changeable after the first journal? |
|---|---|---|
| Chart of accounts | The structure of an account and its segments | No |
| Accounting calendar | The year, the periods, how many | No |
| Currency | The ledger’s functional currency | No |
| Accounting method | The rules that generate the journal | Partly, and at a cost |
Read that last column twice. Three of four decisions are final. A project that settles them in one rushed meeting pays for it three years later, when management asks for a report that cannot be produced because the segment that would carry it was never created.
The calendar is the concrete example. A company picks twelve periods, then two years on management asks for a thirteenth adjusting period. Thirteen periods is a decision taken at definition, not after.
The chart of accounts: three decisions with no way back
The chart here is not a list of numbers. It is a structure of segments, each with its own value list, and a journal posts to a full combination rather than to an account number.
The typical Gulf group lands between five and seven segments: company (the balancing one), natural account, cost centre, product or line, region, and one or two spares.
Decision one: how many segments. More is tempting because it looks free at design time, and the cost is paid every day afterwards: each extra segment is a mandatory field on every journal, every invoice and every import. The working rule is that no segment is added unless a real report is being asked for today that cannot be produced without it. Not “we might need it”.
Decision two: which segment balances. The balancing segment is the one every journal must balance at, and the one the per-entity financial statements are built on. Choosing it is not a preference: it is the segment you want to be able to issue a standalone balance sheet for.
Decision three: value lengths and structure. Four digits on the natural account or six? And who may create a new value? This is a governance question rather than a numbering one, and neglecting it ends with three accounts for the same expense created by three people in three months.
Add to the three a set of cross-validation rules — a rule that blocks a combination with no meaning, a manufacturing cost centre against a services company. Skip them at the start and a year later half your reporting needs manual cleaning.
The four master data objects
| Object | What to understand before creating one |
|---|---|
| Suppliers | A supplier is one party with many sites and payment accounts — a new address is not a new supplier |
| Customers | A customer is a trading party with its own addresses and accounts, and one record serves the whole group |
| Items | An item is defined centrally then enabled in the organisations that use it, never duplicated into them |
| Units of measure | The class and its conversions are set before the first purchase, not after the first wrong count |
The commonest failure in a group is the same across all four: duplication. One supplier created three times because three business units buy from it. The consequence shows up a year later, when someone asks for total group spend with that supplier and gets three numbers instead of one — which is precisely the number the system was bought to produce.
The rule: one party, one record, however many units deal with it.
What this structural depth costs — what is actually being paid for — is in the Oracle Fusion Cloud ERP guide.
This station’s exercise
Design a two-entity group on paper, before any screen.
- A Riyadh company in riyals and a Dubai subsidiary in dirhams. How many ledgers, and why?
- Write out the chart of accounts segments with names and lengths, and justify each one with a specific report asked for today. Delete any segment with no report behind it.
- Pick the balancing segment and explain why it and not another.
- Write one cross-validation rule that blocks a meaningless combination in your group.
- Write one supplier that sells to both entities, and explain what is created once and what is created per entity.
What you actually do in this station
- Read the enterprise structures chapter in order, not by search.
- Do the exercise in writing — five pages, not five thoughts.
- Show your design to an accountant working in a group and ask one question: which report does your management ask for that you cannot produce today? The answer reveals the segment missing from your design.
- Write the list of what cannot change after the first journal and keep it in front of you. Every project after this one will need it.
- Revisit ERP modules to connect the three layers to what sits above them.
The three commonest mistakes
One: copying a chart of accounts from a previous project. A chart is a reflection of one company’s structure and reporting, and copying imports somebody else’s reports along with it.
Two: too many segments. Seven “just in case” means seven mandatory fields on every transaction forever, three of them filled with a default that means nothing.
Three: conflating entity, ledger and business unit. It surfaces at the first consolidated report, when nobody can say at which level the number was produced.
The acceptance test for this station
- Define the three layers and what hangs off each.
- Name the four pillars and which cannot change after the first journal.
- Show your chart of accounts with a report behind every segment.
- Explain the balancing segment and its effect on per-entity statements.
- Explain why a supplier is created once for the group, and what is created per entity.
What comes next
The structure is built. The next four stations run transactions through it, starting with procure to pay — requisition to supplier payment, three-way matching, and where invoices actually stall.