Data Security & Sharing

Admin 7 min read Updated July 2026

Financial data earns the strictest handling in any system, and REDA Financials layers its protections: role-based permissions decide what kind of records you touch, territory sharing decides whose, and the platform enforces both on everything you open, enter and change. The automation that runs after you save — posting, matching, allocation — deliberately reads configuration and related records in system context, so an entry posts completely and correctly whoever saved it. That is not a way around your permissions: you had to be allowed to save the document in the first place, and the ledger it writes is locked to everyone (see below).

The layers

Layer	Question it answers	Managed via
Permission sets	What can this person do — enter AR? pay vendors? close books? read only?	The five REDA permission sets — see Permission Set Assignment
User licences	May this person write to the books at all?	User-Level Licensing
Territory sharing	Whose records can they see — India’s? Brazil’s? all?	Territory Management (+ the enabling setting)
System-managed records	Can anyone edit the ledger directly?	Nobody can — see below

The five permission sets at a glance

The first layer — what kind of records can this person touch — is delivered by five ready-made, role-shaped permission sets:

Permission set	What it grants	Typical role
Accounting Admin	Full access to every object, field and feature — including entity, GL, tax, territory, period and settings setup.	The administrator who configures and maintains the application.
Accounting Controller	Full access to the General Ledger, Journal Entries, Banking, Reconciliation, Budgets, Assets, Aging and master data; read access to Receivables and Payables.	Financial controllers and accounting managers who own the books.
Accounts Receivable	Full access to Sales Invoices, Credit Memos, Cash Receipts and their applications; read access elsewhere.	AR clerks and managers.
Accounts Payable	Full access to Purchase Invoices, Vendor Memos, Cash Disbursements, Purchase Orders, the OCR Inbox and Expense Allocations; read access elsewhere.	AP clerks and managers.
Read Only	Read-only access to everything; no create, edit or delete anywhere.	CFOs, directors, external auditors, compliance reviewers.

Sets stack: access is cumulative, so a small team's one-person AR-and-AP desk can hold both sets. Add only what the role truly requires.

Permission set ≠ licence. A permission set controls what a user can access; the REDA Financials AI licence controls whether they can post accounting transactions at all. Most working users need both — and removing one never removes the other. See User-Level Licensing.

Territory sharing — the "whose records" layer

Permissions say a user may work with, say, sales invoices; territory sharing says which sales invoices. When territory-based sharing is switched on (a REDA Setup setting), users see the financial records of their own territories, while group-level roles see across all of them. The tree itself — countries at Level 1, optional sub-regions at Level 2 — is drawn on the Territory Management tab.

With the setting off, territories still drive accounting defaults and fiscal calendars — they just stop filtering visibility. That makes the rollout order friendly: build the tree first, turn on sharing when the organisation is ready.

A worked example — one company, four countries

Meridian Properties Group runs entities in the United States, United Kingdom, India and Brazil, with territory sharing on. Here's how the layers combine for four of its people:

Person	Permission set(s)	Territory	Net effect
AR clerk, India	Accounts Receivable	India	Creates and applies Indian invoices and receipts; reads the rest of India's books; never sees Brazil's records at all.
AP clerk, Brazil	Accounts Payable	Brazil	Full payables workbench for Brazil — bills, disbursements, the OCR Inbox — and nothing outside it.
Group controller	Accounting Controller	Group-level (sees across)	Owns ledgers, banking and close in every country; reads AR and AP everywhere but enters neither.
External auditor	Read Only	Group-level	Sees everything, changes nothing — and the Audit Log records the Login and Export events of the visit.

Notice that no combination lets anyone edit the ledger itself — the fourth layer applies to all of them equally.

Enforcement you don’t see (and can’t bypass)

The app obeys your permissions. REDA Financials’ own code runs its data access in user mode — a user without rights to a record gets no more through the app’s screens and actions than they would raw. No privileged back doors.
The ledger is write-protected for everyone. Accounting Transactions — the immutable ledger entries behind every posting — accept no direct edits from any user, any permission set, ever. Only the posting process itself writes them; the strongest guarantee your audit trail has.
Documents lock when posted. Posted records refuse edits except through the sanctioned paths (reopen, void) — which themselves unwind and rewrite the ledger properly.

The ledger's write-protection is your audit anchor. Because Accounting Transactions accept no direct edits from anyone — not even Accounting Admin — every ledger figure traces to a posted document and a logged event. That single guarantee underpins the answer to most auditor questions about data integrity.

Segregation of duties, practically

The permission sets are designed to be combined deliberately: the person who enters vendor bills (AP) needn’t be the person who approves budgets (Controller); executives read everything and change nothing (Read Only). Keep assignments role-shaped and review them periodically — the Segregation of Duties guide offers patterns.

Review access on a calendar, not on demand. A quarterly pass over permission set assignments, licence assignments and territory membership catches the drift that role changes leave behind — and the Audit Log's Login and Export views tell you whether dormant access is actually being used.

Common mistakes to avoid

Mistake	Why it hurts	Do this instead
Giving everyone Accounting Admin "to keep things simple"	Every control the other layers provide collapses into one over-powered role	Match the five sets to real jobs; stack two sets only where one person genuinely holds two roles
Confusing a permission set with a licence	A user with the right set but no licence can't post; a licensed user with no set can't even see the tabs — both look like "it's broken"	Check both, in that order, whenever access misbehaves
Handing auditors a working role instead of Read Only	The people inspecting the books can now change them — the exact thing audit frameworks prohibit	Read Only exists precisely for reviewers: full visibility, zero write access
Expecting territory sharing to work before the tree does	Sharing filters by territory membership — an unbuilt or misshapen tree filters wrongly	Build and verify the territory hierarchy first, then enable the setting
Trying to "correct" a posted figure by editing records directly	Posted documents are locked and the ledger accepts no direct edits — and any workaround attempt is visible in the Audit Log	Use the sanctioned paths: reopen or void, which unwind and rewrite the ledger properly

Frequently asked questions

No — Accounting Transactions accept no direct edits from any user or permission set, ever. Only the posting process writes them. Corrections flow through reopen or void on the source document, which rewrite the ledger properly.

No. REDA Financials runs its data access in user mode — the app's screens and actions grant a user nothing beyond their own rights. There are no privileged back doors.

Yes — sets stack and access is cumulative. It's the sanctioned way to cover a combined role in a small team. Just add only what the role truly requires, and prefer separate people for AR and AP where headcount allows.

Visibility narrows: users see the financial records of their own territories, while group roles keep the cross-territory view. Defaults and calendars behaved territorially all along — the switch only adds the access filter.

Usually the licence layer or a posted-record lock. Check the user holds a REDA Financials AI licence if posting is blocked, and remember posted documents refuse edits by design. If neither applies, re-check the permission set actually grants write on that module.

Show the layered model (this article), the role-shaped assignments, the ledger's write-protection, and the Audit Log — always-on, auto-numbered, covering postings, period closes, logins and exports. Together they answer the who-could-do-what and who-did-what questions.

Where to go next

Audit Logging — the who-did-what record.
Field History Tracking — field-level change history.
Permission Set Assignment — the role model.

Was this article helpful?