In a prior blog on How to Secure Data Access to Procure to Pay Transactions in Oracle Cloud ERP, we highlighted the importance of Segregation of duties (SoD).
SoD is an administrative control used by organizations when more than one person is required to complete tasks in a business process. The aim of SoD is to prevent fraud, sabotage, theft, misuse of information, and other security violations.
This blog post focuses on the Order to Cash process. You separate Order to Cash (O2C) activities such as creating customers, processing invoices, and receipts, through SoD.
In addition, you determine how to restrict data access to selected lines of business transactions for certain O2C users. If you separate key processes and apply data access security, you mitigate risk of fraud and errors.
In Oracle Cloud ERP, the data access to O2C transactions is defined through user privileges and a security context.
Data Access Requirements
You assign a user one or more privileges through a custom role. The privileges roll up to duty roles, and you can create custom roles to ensure only the privileges and duty roles a user needs are assigned.
An example of a privilege is Generate Customer Statement.
A duty role represents a logical collection of privileges that grant access to tasks that a person performs as part of their job. For example, Bills Receivable Management. Only duty roles hold explicit entitlement to the data such as work areas, task flows, application pages, dashboards, reports, and menu items.
Security context controls the data access. You can assign one or more business units for a person to access and process O2C data.
A business unit is an Oracle Cloud enterprise structure that administers and secures subledger transactions such as invoices and payments. Business units can contain one or more business functions such as Billing and Revenue Management, Project Accounting, Customer Payments, and Collections Management. Business units should reflect stable real-world departments and not short-lived entities such as projects.
You can secure data access for a person to certain business units for a number of reasons:
- Regulatory needs
For example, the US government dictates that only US citizens can access information about government projects.
- Ease of use
For example, only transactions in a certain geographic region relevant to Receivables Shared Services personnel are presented to them.
- Minimum disclosure
For example, exposing only those transactions that an employee needs for their job and no more.
Carefully review and design your enterprise structure including business units early on in your project. Gain insight into Oracle Cloud ERP Enterprise Structures via My Oracle Support article Cloud ERP Enterprise Structures White Paper (Doc ID 2415848.1).
Assign Users with Appropriate Privileges
To address your SoD needs and minimize Oracle subscription impact, our recommendation is that you:
- analyze O2C data access security requirements of your O2C users in your enterprise
- identify the predefined duty roles and privileges in Oracle Fusion Applications that best address your data access requirements
- create custom roles and assign only relevant duty roles and privileges as appropriate to your different types of O2C users
- copy a predefined role and remove unwanted privileges, then save as a custom role
- de-provision a role when it is no longer needed
- check the release readiness documents for your product area for any updates to access definitions. If you find changes that are relevant, incorporate the same changes for the relevant privileges. This will remain an ongoing maintenance activity.
Illustration of Data Access Configuration
The diagram below shows an example of an employee assigned a custom Billing Specialist job role. For illustration simplicity, the user has Create Receivables Transaction and Generate Customer Statements privileges only. The user can, in this example, only create invoices for two business units. You configure the security context in the Manage Data Access for Users setup UI in Oracle Cloud ERP.

Business unit access privileges are aggregated across roles
A user is granted access to a business unit by virtue of a role. If the user has been granted access to multiple roles and business units, the business unit data access applies across all applications and features.
For example, a user is assigned:
- Custom role for a Billing Specialist with access to business unit A to create invoices
and
- Custom role for Accounts Receivable Manager with access to business unit B to process customer payments
The user will have access not only to create invoices but also to process customer payments for both business units. Such role assignments to create both invoices and process customer payments would typically be deemed a SoD issue for most enterprises and is not recommended.
You need to ensure that your O2C staff can access and process O2C data only for the business units and business functions to which they’re entitled.
Business functions in the O2C flow are illustrated in the table below.
Product Family |
Business Function |
Functional Area |
Dependencies |
SCM |
Order Fulfillment Orchestration |
Manage processing of sales orders. |
If Order Management is implemented, the Order Fulfillment and Billing & Revenue Management business units must be the same. |
Financials |
Billing and Revenue Management
|
Manage processing of customer invoices and credit memos in Receivables.
|
Sales Order-, Project Billing-, Subscription data, and AR Invoice data when processed in upstream BUs belonging to same Ledger data can be included in the same revenue contract in a Ledger in RM. |
Financials |
Customer Payments
|
Manage receipts of payment for customer invoices and customer refunds.
|
Localizations that report on both customer and supplier invoices are likely to assume that these business functions reside in the same business unit. Refunds (payment of customer credit memos in Payables) generates the payment request in the same business unit as the credit memo. |
Financials |
Collections Management
|
Manage advanced collections, including strategies to collect balances owed by customers. |
The Collections Management business function must be assigned to the same business unit as Billing & Revenue Management. |
Financials |
Bill Management*
|
External customers can view own bills, create, and manage disputes, and pay bills. |
The Bill Management business function must be assigned to the same business unit as Billing & Revenue Management. |
Financials |
Credit Management* |
Establish customer credit score and credit limit |
Enable customer credit checks during quote, order, and collections process to determine credit limit. |
Projects |
Project Accounting |
Manage project contracts (Enterprise contracts) and billing. |
If both Project Accounting and Project Billing are implemented, the Project Accounting and Customer Contract Management business functions must be assigned to a business unit with both Payables Invoicing and Billing & Revenue Management business functions. |
* These are not business functions that are assigned as part of the business unit setup but are included for completeness
A business unit may perform one or more business functions. Moreover, depending on the features of the applications, transactions may flow from one business unit to another.
Business unit security is central to most O2C transaction processes. The exception is Revenue Management. It combines sales cycle and billing data, for all business assigned to a ledger, to create one or more revenue contracts. Therefore, data access security for revenue contracts in Revenue Management applies at the ledger level.

Cross Business Unit O2C Processing
If you establish a shared service center (SSC) to process customer collections, you can request that customers transfer funds into the SSC bank account. SSC staff are assigned the appropriate duty roles, privileges, and security context. They can apply a cash receipt registered in the shared service center business unit to customer invoices that reside in another business units.
You can separate the receivables business function for customer invoices from the business function for bank facing customer payments. You can use the service provider relationship to centralize customer collections across multiple customer invoicing BUs. Thus, model centralized management of the cash resource coupled with de-centralized management of invoice process. Receivables and Subledger Accounting process all intercompany aspects automatically, as explained in related blog here: https://blogs.oracle.com/erp-ace/post/ease-journals-partition-and-reporting-with-correct-legal-entity-design
This is the example reflected in figure 3 below.

Be aware that Receivables Business Units cannot span multiple ledgers.
Control Access to Chart of Account (COA) values with Segment Value Security (SVS)
A blog post here explains how to secure access to data in General Ledger (GL), including Segment Value Security (SVS). However, it’s important to note that SVS applies to any Oracle Cloud applications that utilize the Chart of Accounts.
- SVS policies restrict access to COA segment values for data entry, inquiry, and reporting (i.e., full “read and write”).
- Super users define access control to detail- and parent segment values of the COA with SVS.
- SVS, once activated for a value set, prevents access to all values. That is, unless you are positively granted access via a custom job role.
- You assign SVS rules to roles that are, in turn, assigned to your users.
- SVS aggregates access privileges across roles.
Conclusion
Consider your segregation of duties (SoD) requirements carefully. Plan access requirements for all your Order to Cash staff to mitigate any SoD conflicts. This way you ensure your data access and security needs are addressed for your enterprise.