Territory Codes & Full Codes

Q: Do I ever type the full code myself?

No. You only set the short territory code (and the parent, if it’s a child). REDA builds the full code from those — just the code for a top-level territory, or Parent-Child for a sub-territory — and keeps it up to date for you.

Q: Can I move an entity to a different territory and have everything re-stamp?

Not while the entity is active — the system blocks it: “Territory cannot be changed on an active entity. Deactivate the entity first to change territory; note that changing territory does not migrate existing periods or transactions.” Territory placement is a structural decision, so get it right when you create the entity.

Admin 7 min read Updated June 2026

A territory has two codes that work together — the short code you choose, and the full code the system builds from it. The full code is then copied onto every record so it can drive data access. This article explains how each is formed and how it propagates through the application. For the bigger picture, start with Understanding Territories.

Getting there. A territory’s code and full code are set on the territory itself — open the App Launcher (the grid icon at the top-left of any page) → REDA Financials Admin → the Territories tab.
Access you’ll need. Any REDA Financials permission set can view a territory’s codes; setting the territory code (and parent) requires the Accounting Admin v2 or Accounting Controller v2 permission set.

The territory code

The territory code is the short identifier you set when you create a territory — for example, US for the United States or CA for California. A few rules apply:

It can be up to 10 characters.
It cannot be changed once saved — because it ends up stamped on records throughout the application, changing it would break that link.
It cannot contain a dash (-), because the dash is reserved as the separator between a parent and a child in the full code.

The full code — how it’s built

The full code is generated automatically — you never type it. How it’s built depends on the territory’s level:

A top-level territory’s full code is simply its own code. United States → US.
A child territory’s full code is its parent’s code, a dash, then its own code. The parent’s code is prefixed onto the child. California (code CA) under United States (code US) → US-CA.

Putting it together for a simple US hierarchy:

Territory	Code	Parent	Full code
United States	`US`	—	`US`
California	`CA`	United States	`US-CA`
Texas	`TX`	United States	`US-TX`

This is why the code can’t contain a dash The dash is the join between a parent and child code. If a territory code itself contained a dash, the full code would be ambiguous — so REDA reserves it. It’s also why the full code is read-only: it’s always derived from the code and the parent, so there’s nothing to edit.

How the code reaches your records

The full code doesn’t just live on the territory — it is copied onto every major record in the application: entities, ledgers, invoices, bills, receipts, payments, journals, assets, bank accounts, and more. Each record carries a Territory Full Code field holding its territory’s full code.

The copy happens automatically, following the records’ structure:

A territory’s full code is stamped onto its entities and ledgers.
When you create a document (an invoice, a payment, a journal…), REDA reads the full code from the entity (or ledger) the document belongs to and copies it onto the document.
If a record’s entity or ledger is ever changed, its full code is re-stamped to stay correct.

For example: an entity assigned to the California territory carries the full code US-CA. Every sales invoice, purchase invoice, and payment for that entity is automatically stamped US-CA too — no one has to set it.

The Territory Full Code is system-maintained It is filled in for you and should never be edited by hand. It stays blank only when a record has no territory to inherit — for example, an entity without a territory assigned. It is a real stored value (not a live formula) on purpose — criteria-based sharing rules can only evaluate real fields, which is exactly what this code is for.

Which records carry the territory code

The Territory Full Code is stamped across every major part of the application — from master data to transactions to period-end and automation records. Here is the full list of where you’ll find it:

Area	Records that carry the Territory Full Code
Setup & master data	Entities, Ledgers, GL Accounts, Products, Bank Accounts, Customers & Vendors (the account record)
Sales & receivables	Sales Invoices (and Credit Memos), Cash Receipts
Purchasing & payables	Purchase Orders, Purchase Invoices (and Vendor Memos), Cash Disbursements, Cash Disbursement Batches, Expense Allocation Lists
General ledger	Journal Entries, Accounting Transactions (the posted ledger entries)
Assets	Fixed Assets, Asset Masters
Budgets	Budgets, Budget Entries
Banking	Bank Deposits, Bank Reconciliations
Automation & period-end	Recurring Templates, OCR Inbox documents, Aging Snapshots

That breadth is the point: because the code is on every top-level record, a single set of territory-based sharing rules can govern access to your entire financial dataset consistently.

What about line items and bank statements? You won’t see the Territory Full Code on detail records — such as invoice lines, journal lines, or bank statements and their lines — and that’s deliberate. These are child records of a parent that already carries the code: an invoice line belongs to its invoice, and a bank statement belongs to its bank account (which is stamped). Records like these are “controlled by parent”, so they inherit the parent’s territory-based access automatically. Stamping the parent covers its children too — so nothing is left unprotected.

Because a child’s full code begins with its parent’s code, the prefix structure makes hierarchical access natural. A sharing rule written against the parent code reaches the children automatically:

A rule that grants access where the territory full code starts with US covers US, US-CA, and US-TX — the whole United States hierarchy.
A rule that grants access where it equals US-CA covers California only.

So you can give a national team access to everything under a country with a single rule, while still being able to scope a regional team to just their sub-territory. For how this fits the overall data model, see Understanding Territories → Controlling who sees what.

Where to go next

Understanding Territories — the concepts behind territories.
Creating & Managing Territories — build your hierarchy.
Understanding Accounting Defaults — what territories drive.
Configuring Accounting Defaults — set defaults per territory.

Frequently asked questions

No. You only set the short territory code (and the parent, if it’s a child). REDA builds the full code from those — just the code for a top-level territory, or Parent-Child for a sub-territory — and keeps it up to date for you.

The dash is reserved to join a parent code and a child code in the full code (for example US-CA). Allowing a dash inside a code would make the full code ambiguous, so REDA blocks it.

The record’s entity (or ledger) doesn’t have a territory assigned — there is nothing to inherit. Assign the territory on the entity or ledger, and new and updated records are stamped automatically from then on.

No — it’s maintained by the system and should never be edited by hand. It always reflects the territory of the record’s entity or ledger, and is re-stamped automatically if that changes.

Not while the entity is active — the system blocks it: “Territory cannot be changed on an active entity. Deactivate the entity first to change territory; note that changing territory does not migrate existing periods or transactions.” Territory placement is a structural decision, so get it right when you create the entity.

Was this article helpful?