Understanding Territories
A territory is how REDA Financials models where your business operates — a region governed by one set of regulations and standards. Most often that’s a country: the United States is one territory, the United Kingdom another. Territories are quietly one of the most important structures in the application, because they do four jobs at once: they stamp every record with a marker that can control who sees what, they carry your accounting defaults, they hold a set of business policies — and they own the fiscal calendar your entities post against.
Access you’ll need. Any REDA Financials permission set can view territories; creating and editing them requires the Accounting Admin v2 or Accounting Controller v2 permission set.
A two-level hierarchy
A territory can stand on its own, or it can have child territories beneath it — one extra level for regions within the parent. For example:
For example: the United States is a top-level (Level 1) territory, and California and Texas are child (Level 2) territories beneath it — useful when different states need their own data access or accounting defaults.
Every record is stamped with its territory
This is the mechanism that makes everything else work. As records
are created, REDA automatically stamps each one with its
territory’s code — invoices, bills, receipts,
payments, journals, assets, bank accounts, and more. The stamp is
the territory’s full code (for example,
US for a top-level territory, or US-CA for
a child), and it rides along on the record for its whole life.
You don’t set this by hand — the entity a document belongs to determines its territory, and REDA applies the stamp for you. The result is that every piece of financial data carries a reliable marker of which region it belongs to. How that code is built is covered in Territory Codes & Full Codes.
How territories control who sees what
Because every record carries its territory code, your Salesforce administrator can use it to control record-level access across the whole application. REDA Financials does not ship any sharing rules of its own — out of the box, record access follows your org’s normal Salesforce settings. What the application provides is the reliable stamp; the standard, secure pattern your administrator can build on it is:
- Set the organisation-wide sharing (the default access) for the REDA Financials objects to Private — so by default, users only see their own records.
- Open access back up with sharing rules, using the territory code as one of the criteria.
For example: a sharing rule can grant
your US finance team access to every record stamped US
(and its children), while your UK team sees only UK
records — cleanly separating each region’s data without
touching the records themselves.
Territories also carry your accounting defaults
Each territory can hold its own default GL accounts, ledger, and reporting framework. When you create an entity, REDA fills in its defaults from the most specific match — child territory, then parent territory, then the global defaults — so each region posts to locally appropriate accounts while sharing a sensible baseline. See Understanding Accounting Defaults for the full picture.
Territories own the fiscal calendar
Accounting periods belong to top-level territories, not to individual entities. For each top-level (Level 1) territory you generate 12 periods per fiscal year — on the Accounting Periods tab of the Financial Admin Console — and every entity in that territory, including entities in its child territories, posts against that shared calendar. Sub-territories don’t get their own periods; they inherit the parent’s.
If you try to create a period on a child territory, the system stops you: “Accounting periods can only be created on top-level territories. The selected territory has a parent — pick its parent territory instead. Sub-territories inherit their parent’s fiscal calendar.”
For example: Meridian Property Group runs a United States territory and an India territory. Its US entity follows the 12 periods generated on United States; its Indian entity follows the periods generated on India — which can start in April to match the Indian fiscal year, while the US calendar runs January to December. Each region keeps its own year-end without any per-entity period maintenance.
Every field on a territory, explained
A territory record has two kinds of fields: a few that set its identity and place in the hierarchy, and a set of business policies that control how the application behaves for everything in that territory.
Identity & hierarchy
| Field | What it means & controls |
|---|---|
| Name | The territory’s display name — for example, United States. |
| Territory Code | A short code (up to 10 characters) that identifies the
territory — for example, US. It is the
building block of the full code. It cannot contain a
dash (the dash is reserved to join parent and child)
and cannot be changed once saved. |
| Parent Territory | Links a child territory to its parent (for example, California under United States). Leave it blank for a top-level territory. It cannot be changed once saved, and a territory can’t be its own parent. |
| Level | Calculated automatically — 1 for a
top-level territory, 2 for a child. You
don’t set this; it follows from whether a parent is
set. |
| Full Code | Calculated automatically — and this is the value
stamped on every record. A top-level territory’s full
code is just its code (US); a child’s is
the parent code and child code joined by a dash
(US-CA). |
| Active | Whether the territory is in use. An inactive territory can’t be assigned to new entities or ledgers, but records that already reference it keep working. |
| Description | Free-text notes about the territory, for your own reference. |
Business policies
These switches set the regional defaults for how REDA behaves for every entity and document in the territory.
| Field | What it controls |
|---|---|
| Grouped Posting Enabled | How transactions post to the ledger for entities in this territory. Off (the default) — every source line writes its own accounting entry, giving a full line-level audit trail. On — lines that hit the same GL account are combined into summary entries (fewer rows, less detail). It’s set per territory because local audit-trail expectations differ. |
| Default Enforce Dimension Match | The starting value for new cash disbursements created in this territory. When on, a payment only auto-applies to invoices whose accounting dimensions match — a tighter control. It seeds the default; you can still change it on an individual payment. |
| Enable Aging Snapshots | Whether entities in this territory are eligible for period-end AR and AP aging snapshots. Each entity must also have aging enabled. Off by default. |
| OCR Auto-Create Threshold | The minimum AI confidence (0–100%, default 80%) for the OCR engine to auto-create a purchase invoice from a scanned document. Below the threshold, the document waits for manual review instead. |
| Generate Public URL for PDFs | How generated PDFs are shared. When on, a PDF gets a public link (anyone with the URL can view — convenient for emailing). When off, the file is attached privately and requires login. |
Not on the Territory Management tab. That tab lists territories and opens a modal that edits Accounting Defaults — it never touches these five.
Grouped Posting Enabled and Generate Public URL for PDFs are on the Territory record page. The other three — Default Enforce Dimension Match, Enable Aging Snapshots and OCR Auto-Create Threshold — are not on the shipped page layout at all (13 fields, none of them these), and not in the Territory Management component either. They exist on the object and they drive exactly the behaviour described above, but as delivered there is nowhere to set them.
An administrator has to add them to the layout first — Setup → Object Manager → Territory → Page Layouts. Verified against refin 1.610.0.
You set all of these on the Territory Management tab — see Creating & Managing Territories for the step-by-step.
Where territories are managed
Territories are created and maintained on the Territory Management tab of the Financial Admin Console. From there you build your hierarchy, set each territory’s code, and edit its accounting defaults via the per-territory Defaults button. For the step-by-step, see Creating & Managing Territories.
Where to go next
- Creating & Managing Territories — build your territory hierarchy.
- Territory Codes & Full Codes — how codes are constructed.
- Understanding Accounting Defaults — what territories drive.
- How Defaults Flow to Entities — trace defaults onto records.
Frequently asked questions
Yes — every entity belongs to a territory, so you need at least one. A single-country business just has one top-level territory that all its entities and records live under. You get the accounting-defaults and policy benefits even without using territory-based sharing.
Two — a parent and its direct children. A parent can have many child territories, but children can’t have their own sub-territories. For example, United States → California works; a third level does not.
Indirectly, and powerfully. REDA stamps every record with its territory code; your Salesforce administrator can then set the objects to Private and write sharing rules that grant access based on that code. So access follows the data’s territory, automatically. No sharing rules ship with the package — they are yours to define, whenever you’re ready.
No. A territory is a region (where you operate); an entity is a legal company (who owns the books). Entities live inside territories; accounting defaults are set per territory, and the fiscal calendar is set on the top-level territory and shared by every entity underneath it.
Because everyone in one region closes on the same calendar. Generating 12 periods once per top-level territory means every entity in that region — including entities in its sub-territories — posts against the same period boundaries, with no per-entity period maintenance and no risk of two companies in the same country disagreeing about when June ends.
Yes — the Name, Description, and Active flag stay editable for the life of the territory. What’s locked after the first save is the Territory Code and the Parent Territory, because the full code built from them is stamped across your records.
Was this article helpful?