Order to Cash workflow controls

What kind of sales orders need to be approved?

• Certain customers
• Certain values
• Certain users
• Certain business units or entities
• Certain product types

With access permissions and user types, only certain users can convert or approve a sales order.

Create a transaction definition for 'Sales Order Draft' that converts to an 'Approved Sales Order' transaction definition, where the convert is limited to certain users. Create a smart event to email a user when a new ‘Sales order Draft’ is created to notify them to approve.

• Create a sales order
• Convert a sales transaction

• How often to perform this review
• How old a sales order can be before it's considered a potential problem

Create a custom list view that's filtered by the appropriate transaction state:

1. Go to Order Entry > All > Other transaction activity and select View transactions.
2. Select Manage views and then select Create new view.
3. Select filters in Step 3 and make sure that State is set to the appropriate value, such as Draft or Pending.

See review control test.

The focus of the test should be on how missing sales orders are identified and followed up.

Depending on your process, you might have a few or a lot of open sales orders at any given time. Reviewing your open sales orders can address two risks:

• Sales orders that have been left open by accident and should be fulfilled
• Something has gone wrong and the sales order should have been closed or canceled.

• What are the valid reasons why sales orders might be open? Do you want to exclude those?
• How often to perform this review? How will you ensure that you're not reviewing the same open sales orders?
• What aging buckets should be used?

Create a custom list view that's filtered by the appropriate transaction state:

1. Go to Order Entry > All > Other transaction activity and select View transactions.
2. Select Manage views and then select Create new view.
3. Select filters in Step 3 and make sure that State is set to the appropriate value, such as Draft or Pending.

See review control test.

The focus of the test should be on how missing shipments or invoices are identified and followed up.

What kind of sales orders need to be approved?

• Certain customers
• Certain values
• Certain users
• Certain business units or entities
• Certain product types

With access permissions and user types, only certain users can convert or approve a sales order.

Create a transaction definition for 'Sales Order Draft' that converts to an 'Approved Sales Order' transaction definition, where the convert is limited to certain users. Create a smart event to email a user when a new ‘Sales order Draft’ is created to notify them to approve.

• Create a sales order
• Convert a sales transaction

Control type

Preventative

Objective types

Accuracy

Functional requirement

Sales orders can only contain pre-existing items with pre-existing prices

Control rationale

To enable controls over price overrides

Why it matters

This control is ensures sales people are not undermining the commerciality of the business through over-discounting. Consider the risk factors here. For example, what would drive a salesperson to adjust the price or try to create an inappropriate product?

Note that this is not strictly an accounting control (accounting controls focus on whether the sales is recorded at the correct price). If a salesperson offers an excessive discount, that's a commercial issue rather than an accounting issue. However, indirectly, if the sale price is below cost, then an auditor might raise a concern about the carrying value of inventory.

Factors to consider

• How you will ensure that this control is not circumvented?

• Are other limitations needed? For example, you might not want to allow all products to be selected by all people.

• Do you need pricing data to be adjustable upward?

• How is product and pricing data kept current?

Sage Intacct configuration

Configure Order Entry to enable standard price lists:

1. Go to Order Entry > Setup > Configuration.

2. Scroll to the Price and discounts subsection.
3. Select Price schedules.
4. Select Customer price lists, if applicable.

Configure sales order transaction definitions with the appropriate settings:

1. Go to Order Entry > Setup > More > Transaction definitions.

2. For each applicable sales order transaction definition:

   1. Select Edit next to the transaction definition.
   2. Scroll to the User overrides subsection in the Accounting section.
   3. Make sure that Line-item price is not selected.
   4. Select Track line-item discount or surcharge, if appropriate.

Sage Intacct Help page

• Price lists—Order Entry
• Transaction definitions—Order Entry

Evidence for control

Configuration page in Sage Intacct

How to test

See configuration test.

The test should focus on the elements of the validation that ensure the integrity of financial reporting.

What fields will be mandatory on a sales order and what fields can be left as optional?

Several fields are already required on sale orders. You can add custom fields. You can also use smart rules to require using fields that are critical to your business operations.

• Custom fields
• Smart rules

See configuration control test.

The test should focus on the fields that are relevant for the purposes of the control framework, for example, financial reporting.

Depending on your process, you might have a few or a lot of open sales orders at any given time. Reviewing your open sales orders can address two risks:

• Sales orders that have been left open by accident and should be fulfilled
• Something has gone wrong and the sales order should have been closed or canceled.

• What are the valid reasons why sales orders might be open? Do you want to exclude those?
• How often to perform this review? How will you ensure that you're not reviewing the same open sales orders?
• What aging buckets should be used?

Create a custom list view that's filtered by the appropriate transaction state:

1. Go to Order Entry > All > Other transaction activity and select View transactions.
2. Select Manage views and then select Create new view.
3. Select filters in Step 3 and make sure that State is set to the appropriate value, such as Draft or Pending.

See review control test.

The focus of the test should be on how missing shipments or invoices are identified and followed up.

This control is not likely to be a financial reporting control, although it is part of demonstrating completeness of revenue. This control helps to ensure that all orders are shipped and billed. Ensuring that you fulfill orders on time is an important part of your shipment process.

The key to ensuring this works well is to make it part of a process of follow up that can be repeated, weekly or daily, without duplication. How will you ensure that the check doesn't cover the same items again and again, while using the most up-to-date information.

• Do you have any terms with customers that result in financial penalties for a certain number of days overdue?
• What is the follow-up and resolution process for overdue shipments?

See review control test.

The focus of the test should be on how shipments outside the threshold of acceptable delivery times are identified and followed up.

This control can address the following risks:

• The risk that the fulfillment process is not working well, which can lead to problems with customers.
• The risk that Invoices are incorrect, which can lead to incorrect revenue recognition. The accuracy of invoices depends on how they are created.

• What is an acceptable variance on fulfillment quantity?
• How often will do the review?
• What actions will you take if you find differences?
• How will you differentiate the orders that have problems with the orders where the variance is acceptable? A variance might be acceptable if the customer will accept the variance or a future shipment will complete the sales order.
• Also see Review of closed sales orders with quantity variance.

Use the Order Entry standard reports, which show a variety of information. Go to Order Entry > All > Reports.

You can also create custom reports to get more information, if needed.

• Order Entry reports
• Custom Report Writer Wizard—CRWZ

See review control test.

The focus of the test should be on how fulfillment with inappropriate variances are identified and followed up.

This control can address the following risks:

• The risk that the dispatch process is not working well, which can lead to problems with customers.
• The risk that Invoices are incorrect, which can lead to incorrect revenue recognition. The accuracy of invoices depends on how they are created.
• The fraud risk that a person has incorrectly recorded shipments to customers to conceal theft or collusion with a customer (for example, to provide them with additional goods free of charge).

The difference between this control and Review of fulfillment quantity variance is that this control is for closed orders, which means that the invoice is likely to be issued with no further shipments.

• What is an acceptable variance on dispatch quantity?
• How often will you do the review?
• What actions will you take if you find differences?
• How will you differentiate the orders that have problems with the orders where the variance is acceptable? A variance might be acceptable if the customer will accept the variance or a future shipment will complete the sales order.
• Also see Review of fulfillment quantity variance.

• Order Entry reports
• Custom Report Writer Wizard—CRWZ

See review control test.

The focus of the test should be on how shipments with inappropriate variances are identified and followed up.

This control is not likely to be a financial reporting control, although it is part of demonstrating completeness of revenue. This control helps to ensure that all orders are shipped and billed. Ensuring that you fulfill orders on time is an important part of your shipment process.

The key to ensuring this works well is to make it part of a process of follow up that can be repeated, weekly or daily, without duplication. How will you ensure that the check doesn't cover the same items again and again, while using the most up-to-date information.

• Do you have any terms with customers that result in financial penalties for a certain number of days overdue?
• What is the follow-up and resolution process for overdue shipments?

See review control test.

The focus of the test should be on how shipments outside the threshold of acceptable delivery times are identified and followed up.

Designing the process without the need for a lot of invoice changes is the best way to prevent inappropriate or erroneous changes to invoices. However, when changes are necessary, you might want to check them to ensure they are appropriate.

Also see Automated population of invoices based on shipper quantity and sales order price.

• What will the likely volume of changes be? So, how often will this control need to be run?
• How will you identify the difference between valid changes and inappropriate changes?

See review control test.

The focus of the test should be on how inappropriate changes to invoices are identified and followed up.

Manual invoices are often used to bypass the main route, which is to dispatch quantities and sales order prices to automatically populate the invoices. Therefore, use this control to enforce the manual invoice policy.

Also use this control in conjunction with Restricted access to create manual invoices.

• What will be the likely volume of manual invoices? So, how often will this control need to be run?
• How will you identify the difference between appropriate manual invoices and ones that should not have been raised?

See review control test.

The focus of the test should be on how inappropriate manual invoices are identified and followed up.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

You can use this control in conjunction with Manual invoice listing review.

Are there any specific people who need to be prevented from having this access for segregation of duties reasons?

Create a 'Manual Invoice' transaction definition that has restricted access to certain users.

1. Go to Order Entry > Setup > More, and select Transaction definitions.
2. Select Edit next to applicable transaction definition.
3. Select the Security configuration tab and scroll to the User and group permissions section.
4.  Select Enable permissions for specific users or groups.
5. Use the fields and table that appear to restrict access to certain users or groups.

Designing the process without the need for a lot of invoice changes is the best way to prevent inappropriate or erroneous changes to invoices. However, when changes are necessary, you might want to check them to ensure they are appropriate.

Also see Automated population of invoices based on shipper quantity and sales order price.

• What will the likely volume of changes be? So, how often will this control need to be run?
• How will you identify the difference between valid changes and inappropriate changes?

See review control test.

The focus of the test should be on how inappropriate changes to invoices are identified and followed up.

Manual invoices are often used to bypass the main route, which is to dispatch quantities and sales order prices to automatically populate the invoices. Therefore, use this control to enforce the manual invoice policy.

Also use this control in conjunction with Restricted access to create manual invoices.

• What will be the likely volume of manual invoices? So, how often will this control need to be run?
• How will you identify the difference between appropriate manual invoices and ones that should not have been raised?

See review control test.

The focus of the test should be on how inappropriate manual invoices are identified and followed up.

Where companies operate in markets where local tax rules are complex or rapidly changing, maintaining those tax rules in a core finance system can be hard to do and prone to error. In these cases it might be worthwhile to use local tax engines to calculate taxes and duties.

Are you subject to complex or rapidly changing tax regimes (such as US state & local tax)

There are several options for configuration of automated tax calculations, posting, and reporting. Each organization should review the options relevant to the compliance requirements.

Sales tax, VAT, and GST

Will usually be held in documentation for the tax engine. Users should not have access to manually maintain tax rates maintained by tax engines (as this would allow them to override).

See configuration test (for configuration of tax rates) and access control test (where access should be restricted).

A tax control account reconciliation is important to make sure that the tax balance is correct and/or the tax submission is correct. The former is done by checking the tax balance to any expectations (practicality will prevent a review of all tax transactions), while the latter is done by checking the tax balance to the tax submission, where this is done based on data outside the system.

• What are the thresholds for reconciling items? What will you do if there's for example, a single dollar difference?

• Control account reconciliation is often part of the wider process of balance sheet reconciliations - applying a consistent approach to all reconciliations should be considered.

Configurations will vary per tax solution.

Sales tax, VAT, and GST

Reconciliation documentation, including reconciling items and follow-up.

See reconciliation control test.

This control is not likely to be a financial reporting control, although it is part of demonstrating completeness of revenue. This control helps to ensure that all orders are shipped and billed. Ensuring that you fulfill orders on time is an important part of your shipment process.

The key to ensuring this works well is to make it part of a process of follow up that can be repeated, weekly or daily, without duplication. How will you ensure that the check doesn't cover the same items again and again, while using the most up-to-date information.

• Do you have any terms with customers that result in financial penalties for a certain number of days overdue?
• What is the follow-up and resolution process for overdue shipments?

See review control test.

The focus of the test should be on how shipments outside the threshold of acceptable delivery times are identified and followed up.

Suggested matches, if used, are not a guarantee of the matches being correct. Think about the process of matching and ensure that this control is one contributing factor to ensure accurate matching.

How to define tolerance thresholds that are in line with your company's policy?

Sage Intacct configuration is set as a default to make automatic payment suggestions, matching customer payments to open invoices.

See configuration control test.

The three-way match functionality should be tested, along with any threshold for acceptance and blocking of invoices above the threshold.

Suggested matches, if used, are not a guarantee of the matches being correct. Think about the process of matching and ensure that this control is one contributing factor to ensure accurate matching.

How to define tolerance thresholds that are in line with your company's policy?

Sage Intacct configuration is set as a default to make automatic payment suggestions, matching customer payments to open invoices.

A review of unallocated cash will likely be performed very frequently as users try to resolve receipts that aren't very clear or that come from unexpected places. These daily or weekly reviews do not necessarily need to be formalized because they are operational in nature.

At month end, however, you can do an unallocated cash review to ensure the month-end receivables position is accurate and not overstated.

• Consider the whole allocation process. What are the reasons for unallocated cash, and how will this control identify the ones that are problems?
• At what point in the process will this control be run?

See review control test.

The test should focus on how problematic unallocated cash items are reviewed and followed up.

The production of a report is a process and not a control. If the accrual is automatically calculated based on terms in the system, then it's a control. Otherwise, a manual calculation, which might dependent on a report, that leads to a journal posting is needed. However, review of the system-based report and checking against contracts can be used as an IT dependent manual control over this difficult area.

See review control test.

The test should be carefully designed to ensure the control objective is met and is not just a general check that some kind of review happened.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

This control is primarily for fraud control, but also prevents the inappropriate use of returns instead of adjusting invoices.

Use this control in conjunction with Review of customer returns.

• Who needs to be restricted to prevent fraud?
• Are other restrictions needed, such as by entity?

Create a 'Returns' transaction definition that has restricted access to certain users.

1. Go to Order Entry > Setup > More, and select Transaction definitions.
2. Select Edit next to applicable transaction definition.
3. Select the Security configuration tab and scroll to the User and group permissions section.
4.  Select Enable permissions for specific users or groups.
5. Use the fields and table that appears to restrict access to certain users or groups.

This control can address the following risks:

• Deliveries are incorrect. This operational consideration ensures that the fulfillment process is working and that the quality is appropriate.
• Returns are inappropriate. Appropriate returns ensure that no one is accidentally crediting customers too much or fraudulently entering returns.

Design this review to identify follow-up items for both risks. Be careful of the danger of it becoming a generalized review where it is not easy to evidence how the control addresses the risks.

• Given the likely volume and value of customer returns, ensure that this control focuses on the right areas to identify problematic returns, rather than it simply being an operational review of customer return volumes.
• To address completeness, an overall comparison of return levels to expected returns would need to be carried out.

See review control test.

The test should focus on how inappropriate returns are identified and followed up.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

Use this control in conjunction with Credit note approval workflow and Credit note listing review.

• Who needs to be restricted to prevent fraud?
• Are other restrictions needed, for example, by entity?

You can create transaction definitions (for example, Customer Refund) that have restricted access to certain users.

1. Go to Order Entry > Setup > More, and select Transaction definitions.
2. Select Edit next to applicable transaction definition.
3. Select the Security configuration tab and scroll to the User and group permissions section.
4.  Select Enable permissions for specific users or groups.
5. Use the fields and table that appears to restrict access to certain users or groups.

This control is a review of all credit notes to ensure that they’re valid. This should be a relatively small list. However, if it's unmanageable or inefficient to check all of them, think about the criteria that you want to apply to find problematic credit notes, such as value, user who created it, customer.

• How will you identify what constitutes an error, misstatement or fraud?
• How will you ensure that this review is done consistently each time it is performed?
• You might want to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization and monitoring of the reviews?
• How will you ensure that the person signing off is not responsible for raising credit notes? Consider either a secondary check or ensuring that the reviewer does not have access to raise credit notes.

See review control test.

The test should focus on how inappropriate credit notes are identified and followed up.

The production of a report is a process and not a control. If the accrual is automatically calculated based on terms in the system, then it's a control. Otherwise, a manual calculation, which might dependent on a report, that leads to a journal posting is needed. However, review of the system-based report and checking against contracts can be used as an IT dependent manual control over this difficult area.

See review control test.

The test should be carefully designed to ensure the control objective is met and is not just a general check that some kind of review happened.

This control can address the following risks:

• Deliveries are incorrect. This operational consideration ensures that the fulfillment process is working and that the quality is appropriate.
• Returns are inappropriate. Appropriate returns ensure that no one is accidentally crediting customers too much or fraudulently entering returns.

Design this review to identify follow-up items for both risks. Be careful of the danger of it becoming a generalized review where it is not easy to evidence how the control addresses the risks.

• Given the likely volume and value of customer returns, ensure that this control focuses on the right areas to identify problematic returns, rather than it simply being an operational review of customer return volumes.
• To address completeness, an overall comparison of return levels to expected returns would need to be carried out.

See review control test.

The test should focus on how inappropriate returns are identified and followed up.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

Use this control in conjunction with Credit note approval workflow and Credit note listing review.

• Who needs to be restricted to prevent fraud?
• Are other restrictions needed, for example, by entity?

You can create transaction definitions (for example, Customer Refund) that have restricted access to certain users.

1. Go to Order Entry > Setup > More, and select Transaction definitions.
2. Select Edit next to applicable transaction definition.
3. Select the Security configuration tab and scroll to the User and group permissions section.
4.  Select Enable permissions for specific users or groups.
5. Use the fields and table that appears to restrict access to certain users or groups.

This control is a review of all credit notes to ensure that they’re valid. This should be a relatively small list. However, if it's unmanageable or inefficient to check all of them, think about the criteria that you want to apply to find problematic credit notes, such as value, user who created it, customer.

• How will you identify what constitutes an error, misstatement or fraud?
• How will you ensure that this review is done consistently each time it is performed?
• You might want to split this out by entity or amount. How will you ensure that everyone does this consistently? Will there be central organization and monitoring of the reviews?
• How will you ensure that the person signing off is not responsible for raising credit notes? Consider either a secondary check or ensuring that the reviewer does not have access to raise credit notes.

See review control test.

The test should focus on how inappropriate credit notes are identified and followed up.

This control can address the following risks:

• Deliveries are incorrect. This operational consideration ensures that the fulfillment process is working and that the quality is appropriate.
• Returns are inappropriate. Appropriate returns ensure that no one is accidentally crediting customers too much or fraudulently entering returns.

Design this review to identify follow-up items for both risks. Be careful of the danger of it becoming a generalized review where it is not easy to evidence how the control addresses the risks.

• Given the likely volume and value of customer returns, ensure that this control focuses on the right areas to identify problematic returns, rather than it simply being an operational review of customer return volumes.
• To address completeness, an overall comparison of return levels to expected returns would need to be carried out.

See review control test.

The test should focus on how inappropriate returns are identified and followed up.

The Customer Aging report provides this functionality. You can run the report on invoice date or due date.

Set up custom aging periods on the Configure Accounts Receivable page, set up Accounts Receivable terms, and assign the terms to customers. Sage Intacct will automate the calculated terms and age of outstanding invoices.

• Configure Accounts Receivable: Aging
• Terms—Accounts Receivable
• Run Customer Aging reports

See configuration control test.

The test should ensure that the age of the invoice is calculated correctly.

• How can credit limit checks be circumvented?
• What will prevent these circumventions from being used?

You can add a credit limit to a customer by editing the customer record:

1. Go to Accounts Receivable > All > Customers.

2. Find the customer that you want to set a credit limit for.
3. Select Edit at the end of the row.
4. Select the Additional information tab.
5. In the Credit limit text box, enter the amount of credit you are willing to extend to the customer.
6. Select Save.

1. Go to Accounts Receivable > All > Customers.

2. Find the customer that you want to set a credit limit for.
3. Select Edit.
4. Select the Additional information tab.
5. In the Credit limit text box, enter the amount of credit you are willing to extend to the customer.
6. Select Save.

You can determine what happens when a credit limit is exceeded on the Configure Accounts Receivable page:

1. Go to Accounts Receivable > Setup > Configuration.
2. Scroll down to the Thresholds section.
3. Select the appropriate option for If customer is on hold, such as blocking the transaction from being created.

See configuration control test.

The test should focus on checking that the block is applied automatically when the credit limit is exceeded.

• How will you evidence that the changes are appropriate?
• What supporting evidence will be examined?

Take either or both of the following actions:

• Set up a smart event to send an email to reviewer when changes are made to a customer credit limit.
• Run the Audit History report, filtered by appropriate object data areas.

• Smart events
• Use an Audit History report

See review control test.

The test should focus on how inappropriate changes to credit limits are identified and followed up.

• What sanctions and jurisdictions impact the organization?
• What instructions have been provided from the legal or commercial risk teams or general counsel?

See review control test.

The test should focus on how the checks were carried out and what evidence was inspected.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

In particular, this is important to prevent fraud through the creation of fictitious customers against which fictitious sales could be recorded

Use this control in conjunction with Review of customer master data changes.

• Who needs to be restricted to prevent fraud?
• Are other restrictions needed, such as by entity?

The control is to identify fictitious customers, which primarily new customer creations. However, it's also possible to change existing customer into a fictitious customer by making a large number of changes.

Use this control in conjunction with Restricted access to create customers or change customer master data.

• Which fields will be defined as potentially risky?
• How much checking back to the original information will be performed?
• Will you use a sample-based approach?

Take either or both of the following actions:

• Set up a smart event to send an email to reviewer when changes are made to a customer credit limit.
• Run the Audit History report, filtered by appropriate object data areas.

• Smart events
• Use an Audit History report

See review control test.

The test should focus on how inappropriate changes to customer records are identified and followed up.

• Custom fields
• Smart rules

See configuration control test.

The test should focus on the fields that are relevant for the purposes of the control framework, for example, financial reporting.

• How will you differentiate between valid and invalid price overrides?
• How often does a manual price override occur, and therefore, how often will you need to review this?

See review control test.

The focus of the test should be on how inappropriate changes to sales order pricing are identified and followed up.

• How often are product prices changed? Is this on a specific basis (for example, annual price review) or more frequently?
• Are there certain people who would not be expected to change prices?

Use this control in conjunction with Restricted access to pricing master data.

See review control test.

The focus of the test should be on how inappropriate changes to sales order pricing are identified and followed up.

Give normal considerations as for all restricted access controls, with access minimized and excluded from those who should not have it.

You can use this control in conjunction with Product price change review.

• Who needs to be prevented from having access?
• Is there a process in place to change master pricing data? Having such a process helps avoid a proliferation of access from people who have a justifiable need to get a price changed, and therefore request access to do it themselves.

• What is the business' overdue invoices policy?
• Who will perform this review? Ideally, it should be someone with collections responsibility.

See configuration control test.

The test should focus on how problematic invoices and customers are identified and followed up.

Revenue adjustments are a potentially major fraud risk. Design this control to enforce the manual journal policy and to detect fraudulent entries.

Like all review controls, the review should not just be a scan, or a "sense check", as this will be insufficient evidence of review. Identify a combination of thresholds and variables to detect risky entries, and document the conclusion. More detailed investigation can always be done if the control operator wants to.

• When will this review be performed? Will it be done pre- or post-close, or less frequently?
• The nature of the adjustments that are expected will drive the design of this control. If there are many small adjustments, make sure that they are not ignored if they could aggregate to a large impact.

See review control test.

The test should focus on how inappropriate revenue adjustments are identified and followed up.

In a segregation of duties control, the ideal scenario is that no one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring. However, because of the risk of fraud, check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

• Assign permissions to users
• Example Permissions report for all users—CRW

In a segregation of duties control, the ideal scenario is that no one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring. However, because of the risk of fraud, check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

• Assign permissions to users
• Example Permissions report for all users—CRW

This control is important to prevent fraud. It's important to remember that segregation of duties is easily violated if access changes regularly.

In a segregation of duties control, the ideal scenario is that no one has access to do both of the activities. Even in this case, the control should ideally be operated to ensure this is true on an ongoing basis, because it is easy for someone to be given access inadvertently (or change roles and retain old access). Preventative controls within the access provisioning process should stop this occurring. However, because of the risk of fraud, check segregation of duties conflicts regularly.

In the case of conflicts, simple approval of the conflict is not normally sufficient. The 'mitigating controls' should be identified, for example, a review of activity logs to ensure the conflict is not abused.

• Assign permissions to users
• Example Permissions report for all users—CRW