Segregation of Duties & Security

Best Practice 7 min read Updated June 2026

Segregation of duties (SoD) is the principle that no single person should control a financial transaction from start to finish. It is one of the oldest and most important internal controls in accounting — and a core expectation of every major compliance framework. This article explains why it matters, and how REDA Financials AI helps you put it into practice and keep your books auditable.

Getting there. Segregation of duties is enforced through REDA’s five permission sets rather than a single screen — assign the v2 version of each, which is what version 1.610 onwards ships (see Migrating to the v2 permission sets); the roles and the separation below are identical either way: who can post, approve, or reconcile is decided by which set a user holds. You assign those sets in Salesforce (Setup → Permission Sets, or a user record’s Permission Set Assignments); the resulting controls then apply throughout REDA Financials AI (App Launcher — the grid icon at the top-left of any page).
Access you'll need. Assigning and reviewing permission sets is a Salesforce System Administrator task. The sets themselves — Accounts Payable v2, Accounts Receivable v2, Accounting Controller v2, Accounting Admin v2, and Read Only v2 — are what separate the duties, so plan them with your controller. See Permission Set Assignment.

Why segregation of duties matters

When one person can record a transaction, approve it, and reconcile it, errors go uncaught and fraud becomes easy to hide. Separating those responsibilities means a second pair of hands (and eyes) touches every transaction — which is exactly what auditors, regulators, and your own stakeholders expect.

It is woven into the global standards that govern financial reporting:

SOX (Sarbanes–Oxley), Section 404 requires management of public companies to maintain and assess internal controls over financial reporting — with SoD as a cornerstone.
The COSO Internal Control–Integrated Framework, the standard auditors use to evaluate controls, names separation of duties as a key control activity.
External audits under IFRS and US GAAP test whether incompatible duties — recording, authorising, reconciling, and custody of assets — are kept apart.
Internal audit and risk frameworks (and most insurers and lenders) treat weak SoD as a material control deficiency.

The four duties to keep apart Classic internal-control theory separates four responsibilities: authorisation (approving a transaction), recording (entering it in the books), custody (handling the cash or asset), and reconciliation (independently checking it). The more of these a single person holds, the higher the risk. REDA’s roles are designed to help you split them.

How REDA helps you enforce SoD

REDA Financials ships a set of role-based permission sets built around the natural separation of duties in an accounting team. You enforce SoD by assigning the right set to the right people — and, crucially, by not concentrating incompatible roles in one person. See Permission Set Assignment for the full list and how to assign them.

The separations that matter most:

Receivables apart from payables. Give Accounts Receivable and Accounts Payable to different people, so no one both bills customers and pays vendors.
Recording apart from reconciliation. Keep whoever records cash separate from whoever reconciles the bank, so cash can’t be misrecorded and then “reconciled” to hide it.
Preparation apart from review. Use the Read Only set for reviewers, auditors, directors, and the CFO — full visibility, no ability to change a thing.
Administration apart from daily operations. Reserve Accounting Admin for the people who configure the system, not those who post day-to-day transactions.

The Controller role is SoD by design The Accounting Controller set holds full control of the general ledger, journals, banking, budgets, and master data — but is deliberately read-only on every subledger document (invoices, bills, receipts, payments). The person who reviews and reconciles the books cannot create the AR and AP transactions that feed them.

Right-size for a small team Perfect separation isn’t always possible in a small finance team. Where one person must wear two hats, lean on REDA’s compensating controls — the audit trail, field history, and independent review using Read Only access — and document the exception. Auditors accept compensating controls when full separation is impractical.

Approval gates and the four-eyes check

Permission sets separate who can do what; approval gates separate recording from authorising on the documents where it matters most. Five document types — Purchase Orders, Purchase Invoices, Sales Invoices, Budgets, and Budget Entries — carry an Approval Status field that gates posting: the document must be Approved (or Not Required) before it can post to the ledger. Connect that field to native Salesforce Approval Processes that mirror your sign-off policy — by amount, by department, by entity — and the person who keys an invoice can no longer be the one who authorises it. REDA ships the gate; you design the approval chain. The walkthrough is in Approval Processes.

Two related controls round out the picture:

Journal entries are controlled by role, not approval. A journal entry has no approval field — the control is that only users whose permission set grants journal rights can create and post one. Keep that right to the people who should have it.
Bank reconciliation has a hard-coded four-eyes check. The user who approves a completed reconciliation must be a different user from the one who completed it — the system refuses otherwise: “The approver cannot be the same user who completed the reconciliation. Segregation of duties requires a different user to approve.” Once approved, a reconciliation is locked for good.

Built-in controls that protect your books

Segregation of duties works best on top of a platform that records everything and lets nobody quietly rewrite history. REDA Financials is built with enterprise-grade controls baked in:

An immutable ledger. Accounting entries are system-generated from their source documents and cannot be edited directly by anyone — no role grants write access to the ledger. Every entry is traceable back to the transaction that created it.
A complete audit trail. A centralized audit log records financial operations and system events — who did what, when, from which IP address, including the before-and-after of changed fields.
Field history tracking. Changes to critical fields are tracked on financial records, giving you a permanent history for SOX and audit purposes.
Permission-aware everywhere. The application respects each user’s permissions on every read and write, so people only see and touch what their role allows.
Period locks. Once an accounting period is closed, it is protected from further posting — preserving the integrity of reported results.

An enterprise-grade, compliant platform

REDA Financials AI is built for organisations that take compliance seriously. Beyond the in-app controls above, REDA operates a formal information security management system and runs entirely on Salesforce’s trusted infrastructure:

ISO 27001 and SOC 2 Type II — REDA’s security programme is built to these standards for managing the confidentiality, integrity, and availability of your data.
Data privacy — data handling and deletion practices aligned with GDPR and CCPA.
Your data stays in your org. REDA Financials is Salesforce-native — your accounting data lives in your Salesforce environment, under your controls, not in a separate third-party system.
Trusted infrastructure. It runs on the Salesforce platform, whose data centres carry SOC 1/2, ISO 27001, and FedRAMP attestations.

Need our compliance documentation? For ISO 27001 or SOC 2 reports, data-processing terms, or a security questionnaire for your procurement team, contact support@reda.one and we will share the relevant documentation.

Putting it into practice

Map roles to people

Decide who does AR, AP, the ledger, administration, and review — then assign the matching permission sets, keeping incompatible duties apart.

Document any exceptions

Where one person must hold two roles, note the compensating controls (audit trail, field history, independent review) for your auditors.

Bake it into go-live

Confirm your SoD setup as part of the Go-Live Checklist before you start transacting.

Where to go next

Permission Set Assignment — the mechanism that enforces SoD.
License Assignment — who can post at all.
Compliance & Standards — the standards SoD supports.
Audit Logging — the evidence trail behind controls.
Approval Processes — add review gates to transactions.

Frequently asked questions

Mostly, REDA gives you the building blocks — role-based permission sets designed around separated duties, and approval gates on key documents — and you implement SoD by assigning and wiring them appropriately. This is deliberate: the right separation depends on your team and policies. One check is enforced unconditionally: a bank reconciliation cannot be approved by the person who completed it. And the platform backs everything up with an immutable ledger, a full audit trail, and field history so any activity is traceable.

Separate what you can — at minimum, keep receivables, payables, and bank reconciliation in different hands where possible — and rely on compensating controls for the rest: independent review using Read Only access, the audit trail, and field history. Document the exceptions. Auditors accept compensating controls when full separation isn’t practical.

No. The ledger is immutable — entries are system-generated from their source documents and cannot be edited directly by any role. Corrections happen through proper reversing or adjusting transactions, which are themselves recorded and traceable.

A centralized audit log records financial operations and system events — who performed the action, what record it affected, when, from which IP address, and the before-and-after of any changed fields — alongside Salesforce field history on critical fields for SOX-style traceability.

Yes. REDA runs a formal information security programme aligned with ISO 27001 and SOC 2 Type II, follows GDPR/CCPA data practices, and runs natively on the Salesforce platform — so your data stays in your own org on trusted, certified infrastructure. Contact support@reda.one for compliance documentation.

Was this article helpful?