How Defaults Flow to Entities
Your accounting defaults don’t do anything until they reach an entity — that’s where the accounts are actually used for posting. This article explains exactly how a new entity gets its default accounts: which defaults are chosen, how they’re copied, and what that means in practice. For what the defaults are, see Understanding Accounting Defaults.
Access you’ll need. Any REDA Financials permission set can view the defaults that flow to entities; setting or changing them requires the Accounting Admin v2 or Accounting Controller v2 permission set.
It happens once — at creation
Defaults flow to an entity at the moment the entity is created. REDA looks up the right defaults, copies the accounts onto the new entity, and from then on the entity owns its own accounts. This is a one-time copy, not a live link — changing a default later does not reach back and update entities that already exist.
Which defaults are chosen
REDA picks the most specific defaults record for the entity’s territory, walking up the hierarchy until it finds one:
- The entity’s own territory — if that territory has a defaults record, it wins.
- The parent territory — if the child has no record, REDA uses the parent’s.
- The global defaults — the catch-all used when neither the territory nor its parent has a record.
For example: a new entity in California (a child of United States) uses California’s defaults record if one exists; if not, the United States record; if neither exists, the global defaults.
If no record exists at any level — no territory record, no parent record, no global record — the entity is created with its default accounts empty, and you set them on the entity before it can post.
A worked example: Meridian Property Group has a global defaults record (created by seeding) and one territory defaults record, on Brazil, where local rules call for different control accounts. When Meridian creates its Brazilian entity, the Brazil record is chosen; when it creates its US, UK, and Indian entities — whose territories have no defaults record of their own — the global record is chosen. Four entities, one place to maintain the baseline, one deliberate regional exception.
The chosen record is used as a whole
How the accounts are copied
Once the right record is chosen, REDA copies each default account onto the new entity — but only into fields the entity doesn’t already have. In other words:
- Any account you set yourself on the new entity is preserved.
- Every account you left blank is filled from the chosen defaults record.
So you can override an individual account on a specific entity at creation time, and REDA fills in the rest from the defaults.
The entity is the tier that actually posts
It’s worth being precise about what transactions read. When a purchase invoice posts, it credits the entity’s Default AP Account; when a receipt is left unapplied, it credits the entity’s Default Unapplied Cash account. The global and territory records exist only to fill those entity fields at creation — after that, the entity is the single source of truth for its own postings, and anything you change on the entity takes effect immediately for its future transactions.
The entity also carries defaults that were never part of the global or territory set — the Default Bank Account, realized and unrealized FX accounts, withholding-tax payable and receivable accounts, dimension clearing, and sales and purchase discount accounts. Those are configured directly on each entity as the matching features come into use; no defaults record supplies them.
After creation
Once an entity exists, its accounts are its own. Changing a global or territory default afterward affects only new entities created from that point on — existing entities keep the accounts they were given. To change an existing entity’s accounts, edit them on the entity directly. This is why it’s worth getting your defaults right before you create your entities.
Where to go next
- Understanding Accounting Defaults — the concepts behind defaults.
- Configuring Accounting Defaults — set the defaults up.
- Understanding Territories — where defaults originate.
- Territory Codes & Full Codes — how codes are built.
Frequently asked questions
No. Defaults are copied onto an entity when it’s created, and the entity then owns its accounts. Updating a default changes what future entities inherit; existing entities keep theirs. Edit an existing entity’s accounts on the entity itself.
No — that’s the key thing to know. REDA uses the single most-specific record in full; it doesn’t blend accounts across territory levels. If a territory has its own record, fill in every account you want it to set. The global defaults only apply when a territory (and its parent) have no record at all.
Yes. Set that account on the entity yourself when you create it — REDA preserves any account you’ve already filled in and only copies the defaults into the fields you left blank.
Then the entity is created without default accounts, and you’ll need to set them on the entity before it can post. This is why seeding (which creates your global defaults) and a review of those defaults should come before you create entities.
The deepest one that exists: its own child territory’s record if there is one; otherwise the parent territory’s; otherwise the global record. The walk stops at the first match — a child-territory record completely replaces the parent’s and the global one for that entity.
No. Only active records participate in resolution. An inactive record is invisible to entity creation — which is exactly what makes it safe to stage future configurations as inactive records and activate them when ready.
Was this article helpful?