Entities and master data in Oracle NetSuite

At station two you built a way of learning. This station builds the foundation everything after it rests on.

It is the heaviest station on this path and the highest-yielding. Four stations after it assume it is understood.

The entity — the unit everything stands on

An entity here is not an organisational folder; it is the unit a financial statement is produced from.

Three things belong to it alone: its base currency, its country and tax rules, and its place in the group’s tree.

The tree is not a cosmetic detail. It is what decides how the numbers roll up: an entity under an entity under the parent, and a consolidated statement readable at every level.

The decision taken once and paid for over years: how many entities?

The rule that settles it: an entity for every body that produces independent financial statements or files an independent tax return. Anything below that is not an entity; it is a classification.

Anybody creating an entity per branch buys permanent complexity with a passing report question.

The four classifications — the alternative to bloating the chart

The question that destroys most designs: “how do I read my profit by branch and by product and by project?”

The common wrong answer: multiply the chart of accounts. Every expense account gets a copy per branch, then a copy per product line, and then nobody can read it.

The right answer is that these are dimensions rather than accounts. The product provides them at four levels:

The classification	What it usually carries	When it is used
The subsidiary	The legal company	Independent statements or an independent return
The department	The organisational unit	Who bears the expense
The class	The product line or activity	What produced the profit
The location	The warehouse or the branch	Where the event happened

The essential decision: every dimension you want to read your numbers by must be filled on every transaction.

Anything left unfilled produces an unclassified line in your reports that swallows real numbers.

The remedy is not training people to be disciplined; the remedy is a default value on the user, item or customer record, and making it mandatory where it must be. Anything filled by hand every time is forgotten once.

Write this rule down: dimensions are designed before the first transaction, not after the first report. Correcting them a year later means reclassifying thousands of entries.

One record for one customer

Here is a structural peculiarity that surprises anybody arriving from another system.

A customer is one record in one database, even if they deal with five entities in five countries.

What changes is not the record; it is the entities they are permitted to deal with and the terms inside each one.

What stays one	What differs by entity
The customer’s identity and contact record	The currency and the terms
Their complete history with you	The accounts posted to
Their number in the system	The tax applied

The practical effect: you read your total exposure to one customer across the whole group from one place — a capability others build with export spreadsheets.

Its price is discipline in creating records. One duplicate created by two branches quietly destroys the whole capability — and its effect does not appear until an exposure report is asked for.

The three currencies in every amount

Every amount in a multi-currency group is read in three forms, and confusing them is the source of most of the wrong questions:

The transaction currency — the one the invoice was actually written in. The entity’s currency — the one its books are kept in. The consolidated presentation currency — the one the whole group is read in.

Between them sit exchange rates and differences that get calculated, and the differences are not all of one kind: a difference appearing at actual settlement, a difference appearing at revaluation during the close, and a difference appearing on translation to the consolidated presentation that never passes through the income statement at all.

The third is the one people who have never worked in a group get wrong. It returns in full at station seven.

Item data — two decisions before any field

Before filling in any item card, two answers:

1. What type is it? Stocked goods, a service, a non-inventory item, or a group. The type decides which accounts are asked of you at all.

2. What is its costing method? This decision is taken here and its effect is paid in every income statement after it, with the detail at station six.

The item carries its own accounts — the inventory account, the revenue account, and the cost of goods sold account. The user is not asked for an account at the point of sale; the item knows it.

Which means most account-routing errors in this product are not entry errors; they are an error on an item card written once and repeated a thousand times.

What you actually do at this station

• Draw an entity tree for an imagined group: a parent and two entities in two countries with two currencies, writing under each its currency and its country.
• Design the four classifications for that group, writing for each dimension the report question it exists to answer. Anything with no question is deleted.
• Write for each dimension where its default value comes from so it is never left empty.
• Take a customer dealing with two entities, and write what stays one and what differs.
• Write one invoice amount in all three currencies at a rate you assume, and name each form.
• Design three item cards of different types, and write the accounts each of them carries.

The three commonest errors

One: an entity per branch. It is taken for the convenience of a report, and paid for at every close for ever.

Two: designing the dimensions after the first report. The need is discovered after thousands of entries, and the correction becomes a project.

Three: duplicate customers across the entities. It goes unnoticed in daily operation, and it destroys the ability to read total exposure — one of the most valuable things bought in this product.

What the quality of this design does to the cost of implementation is set out in the Oracle NetSuite guide.

The acceptance test for this station

1. Explain when something is an entity and when it is a classification, with one rule.
2. Present your four-classification design, and the report question behind each dimension.
3. Explain what stays one and what differs in a customer record across two entities.
4. Name the three currencies and the three kinds of difference between them.
5. Explain why the item carries its own accounts, and what that does to the source of routing errors.

What comes next

The foundation is built. The next station moves money: the purchase cycle — three independent documents rather than one, and the three-way match that decides whether the invoice gets paid at all.