Creation and Management of Master Data

Objectives

After completing this lesson, you will be able to:
  • Describe organization hierarchies
  • Explain the procedure for creating and maintaining an organization hierarchy
  • Describe the risk catalog and how to create a risk in SAP Process Control
  • Describe central process hierarchies
  • Describe the accounts work set functionality and how to create an account group
  • Explain how to create a process hierarchy as business processes

Organization Hierarchies

This graphic is decorative placeholder for the example : CRG International, Inc.

You know CRG International from the previous Unit.

Lets see what the current status is:

The Organization Profile:

As the electronics market continues to evolve and expand, CRG International, Inc. is poised to further expand its business operations to meet the growing demand for electronic products in Europe and Asia. This rapid growth, however, brings a host of new challenges in managing and monitoring internal processes across multiple geographies and regulatory environments.

CRG International Inc. decided to implement SAP Process Control manage its expanding operations efficiently and effectively, minimizing risks and ensuring sustainable growth in the highly competitive electronics market.

Lets see how CRG International Inc. is building up the organization General Accounting in the Finance department.

SAP Process Control will be delivered with more roles, which will be shown in the demonstrations. For detailed information about other roles in SAP Process Control visit SAP Help Portal (Insert Link). Process Control Application Roles | SAP Help Portal.

The figure illustrates the persons, used in the example.

Roles in SAP Process Control that are defined by CRG International, Inc.:

Internal Control Manager – Ian Robb

Ian Robb is the Internal Control Manager. His role involves overseeing the implementation of robust corporate internal controls, including authorizations, reconciliations, employee performance reviews, asset security, segregation of duties, reliable financial reporting, and compliance with laws, regulations, and policies. It’s his responsiblity to create and maintain Master data such as create controls, regulations, process, and Sub Process and trigger workflows

Ian and his team encounter numerous challenges in monitoring millions of transactions annually across geographically diverse locations.

Managing such a big amount of data presents a significant technological challenge.

Internal controls act as the first line of defense against fraud and is crucial for the organization's sustainability.

A poorly maintained internal control system could result in material misstatements, in financial statements or non-compliance with obligations.

Control Owner – Brian Kenny

Brian Kenny is the control owner. He designs and documents controls to tackle specific risks, making sure they are comprehensive and well-detailed. Brian oversees the implementation of these controls, training staff and providing them with the necessary resources to execute their tasks accurately.

One of his regular task is to monitor and test the controls to ensure they are functioning correctly and identifies any deficiencies or areas for improvement. He maintains thorough records of all control activities and prepares detailed reports for management and auditors, demonstrating the effectiveness and compliance of the controls.

Control Performer – Mae Wong

Mae Wong as Control Step Performer, she diligently carries out tasks, documents outcomes, monitors control effectiveness, and reports findings to ensure compliance and integrity. She closely collaborate with control owner (Brian Kenny) fostering a collaborative approach for control execution.

Control Tester – Jenny Ma

Jenny Ma as control performer, she is responsible for evaluating the effectiveness of a control. Doing so, she focuses on assessing whether the controls designed and implemented by the organization are operating effectively. She documents the findings and provide clear insights into control deficiencies.

Issue Owner – Julia Armstrong

Julia Armstrong, as the issue owner, is responsible for managing and resolving specific issues identified within SAP Process Control. She Julia is assigned to issues that arise during the monitoring and auditing processes within SAP Process Control, making them responsible for understanding the nature and scope of each issue. She must investigate the root causes, coordinate with relevant stakeholders, an d ensure that appropriate corrective actions are implemented.

Ian Robb.

As CRG International, Inc. decided to implement SAP Process Control Ian Robb as Internal Control Manager starts to set up the master data step by step as shown in the master data flow chart.

The Procedure for Creating and Maintaining an Organization Hierarchy

Master Data creation approach in an order.

Do you remember the Master Data Flow Chart from "Explaining Master Data"?

Ian Robb will start by setting up the objects in SAP Process Control in the following order:

  1. Regulations
  2. Organizations hierarchy
  3. Risk Catalog
  4. Control Objectives
  5. Account Groups
  6. Business Processes
  7. Indirect Entity-Level Controls

He will continue to handle the master data assignments, once all the above objects have been created:

  1. Assign corporate and organization roles.
  2. Assign subprocesses to organizations.
  3. Assign local subprocess and local control roles.

Good to know: Workflow for Changing Master Data.

As the structures, processes, controls, and responsibilities (roles) within an organization are always developing, it is essential to consistently update the master data. Within SAP Process Control, any changes to master data require approval through a workflow.

Why is this necessary? Implementing an approval workflow allows organizations to maintain a standardized and controlled method for managing changes to master data, reducing the chance of errors and non-compliance, and enhancing the overall quality and reliability of data.

Set up Regulations

The Master Data flow starts: Set up Regulations.
The graphic displays the regulation hierarchy.

Explanation: The regulation hierarchy helps to organize and manage the various regulations that a company needs to comply with. Additionally it helps to ensure that all relevant regulations are being monitored and managed effectively, reducing the risk of non-compliance and potential legal issues.

The regulation hierarchy in SAP Process Control is structured as follows:

1. Regulation Group: This is the highest level of the hierarchy and represents a category of related regulations. For example, a regulation group could be "Financial Regulations" or "Data Security Regulations."

2. Regulation: This is the next level down in the hierarchy and represents a specific regulation that falls within a regulation group. For example, a regulation within the "Financial Regulations" group could be "Sarbanes-Oxley Act" or "IFRS Reporting Standards."

3. Regulation Requirement: This is the lowest level of the hierarchy and represents the specific requirements or controls that need to be implemented to comply with a regulation. For example, a regulation requirement within the "Sarbanes-Oxley Act" regulation could be "Segregation of Duties Control" or "Financial Reporting Control."

Demonstration: Set up Regulations

Ian Robb as internal control manager begins building a regulation hierarchy to ensure clear traceability and accountability. By establishing this hierarchy, it becomes easier to trace specific regulations back to their source, ensuring that all compliance activities align with the correct regulatory requirements. This also clarifies who is responsible for each regulation and its associated controls, promoting transparency and accountability throughout the organization.

Important to know: Regulations can be configured to depend on specific timeframes. This feature is crucial because regulations and policies often have specific effective and expiration dates, and the system needs to enforce these time-bound rules. This ensures that the correct regulations are applied to the appropriate activities within the designated time frame.

Demonstration: Ian creates a Regulation Requirement in Financial Regulation (FIN) as Accounting Standards because these standards often serve as regulatory requirements that companies must adhere to for legal and financial compliance.

Lets set up the Regulation Requirement "Accounting Standards" in the set up.

Excurse: Policies

Excurse: Policies, built

What are Policies and why they are important?

A policy is a set of principles, rules, and guidelines that are formulated or adopted by an organization to reach its long-term goals.

Policies are designed to influence major decisions and actions, and all activities take place within the boundaries set by them. They are used in Process Control and Risk Management.

A policy contains a written description of an organization's position on important subjects and its response to specific situations.

Policies support managerial decision-making, to help the company achieve its objectives. They are an element of a complete governance process. This process involves an analysis of regulations, best practices, and corporate business objectives, after which they are codified into policies affecting the business actions of all employees.

Policies need to be created, reviewed, approved, and distributed; there is an ongoing process of policy acknowledgment, self-assessment, and updates.

CRG Example

Ian Robb sets up the Segregation of Duties (SoD) Policy for CRG International Inc.

Why is this important: Because Segregation of Duties (SoD) Policy aims to prevent errors and reduce the risk of fraud by ensuring that no single individual has control over all critical aspects of any financial transaction.

The next step in the Master Data Flow is to set up the organization hierarchy.

Key functions explained in a nutshell:

  • Valid From and Valid To dates

    Compliance is reported within specified time frames, so it is critical to enter the correct Valid From date.

  • Shared Services Provider

    Selecting Yes enables you to share the subprocesses and controls of the shared services organization (with related control objectives and risks) with organizations that rely on the services and controls of the shared services provider and therefore inherit the results of the conducted control. The shared service receiver is not allowed to change any data within the control.

  • Org-Level System Parameters are:
    • Part of the auto-testing controls, only valid for legacy testing.
    • Assigned with connectors.
    • Used to schedule automatic control testing.
    • Links Process Control to other systems, such as SAP, PeopleSoft, or other non-SAP systems to access their controls.
    • Checks control criteria in other systems and adds their results with the PC control, and reports the total data.
    • Can be scheduled to run at specific times.

Demonstration: Setting up Organization Hierarchy

CRG Example:

CRG International, Inc. decided to structure the organizational hierarchy based on functional units as FinanceGeneral Accounting or OperationsSales & Marketing.

Ian as Internal Control Manager, will establish the organization unit "General Accounting" in SAP Process Control. Prior to implementation, he worked with the organizations management to determine that "General Accounting" will not function as a shared service provider within the organizational hierarchy. The reasoning behind this decision is that the subprocesses, risks, and controls are specific to the finance department and may not overlap with other operations areas. By implementing this approach, "General Accounting" can concentrate on managing financial activities with a more focused and specialized approach, while ensuring accuracy and compliance within the organization.

The Risk Catalog

The next step in Master Data Flow is the creation of the Risk Catalog.

Demo: Setting up Risk Catalog

CRG International Inc.

Ian understands that the Risk Catalog serves as the backbone of CRG International, Inc.’s risk management framework, providing a unified platform for cataloging risks across the enterprise. As Ian delved into the intricacies of the Risk Catalog, he discovered its dual role as a harmonized data structure shared by both SAP Process Control and SAP Risk Management applications. This integration not only streamlines communication between departments but also ensures consistency and accuracy in risk reporting.

Undeterred, Ian set out to populate the Risk Catalog with relevant risk categories and templates, laying the groundwork for effective risk identification and mitigation. He is setting up a Risk Template called "Purchase Approval Limit Non-Compliance," recognizing it as a critical risk area for the company. With meticulous attention to detail, he outlines the risk's description, impacts, and mitigation measures, ensuring that each field captures the essence of CRG International's risk profile.

When classifying the risk type, he chooses "Operational" because he understands that non-compliance with purchase approval limits directly impacts CRG International's day-to-day operations, from procurement processes to resource allocation. Corporate risks, in contrast, affect the broader strategic objectives, reputation, and long-term sustainability of the company, often having implications at the highest levels of decision-making and impacting stakeholders such as shareholders, customers, and employees.

Central Process Hierarchies

The next step in Master Data Flow is the set up of Control Objectives.

CRG International, Inc.

Ian Robb is in the process of setting up a Control Objective within the company's risk management framework. Recognizing the importance of Control Objectives in Process Control, Ian is keen to establish clear objectives associated directly with relevant subprocesses.

Understanding that SAP does not provide a predefined catalog of control objectives, Ian plans to leverage Continuous Control Monitoring data sources and business rules to align with specific control objectives. He knows that like Risk Categories and Risk Templates, Control Objectives can be created manually or uploaded using an MDUG master data template.

With this in mind, Ian aims to establish "Accounts Payable Adjustments" as a Control Objective. This objective is crucial for ensuring the accuracy, compliance, and integrity of accounts payable processes within the organization. By formalizing this objective, Ian intends to enhance the effectiveness of financial management and internal controls.

His Control Objective, "Accounts Payable Adjustments are Valid," reflects his commitment to ensuring that any adjustments made to accounts payable are legitimate and in accordance with established protocols. With meticulous attention to detail, Ian outlines the objective's description, associated subprocesses, and measures for validation.

In doing so, Ian takes a proactive approach to strengthen the company's financial management practices, safeguarding against errors, discrepancies, and potential risks in the accounts payable process.

Demo: Setting up Control Objective

CRG International, Inc.

Ian is in the process of setting up a Control Objective within the company's risk management framework. Recognizing the importance of Control Objectives in Process Control, Ian is keen to establish clear objectives associated directly with relevant subprocesses.

Understanding that SAP does not provide a predefined catalog of control objectives, Ian plans to leverage Continuous Control Monitoring data sources and business rules to align with specific control objectives. He knows that like Risk Categories and Risk Templates, Control Objectives can be created manually or uploaded using an MDUG master data template.

With this in mind, Ian aims to establish "Accounts Payable Adjustments are valid" as a Control Objective. This objective is crucial for ensuring the accuracy, compliance, and integrity of accounts payable processes within the organization.

The next step in the Master Data Flow is the set up Account Groups.

The Accounts work set allows you to document and manage account groups and their relevant compliance data. Account maintenance allows you to:

  • Create account groups that are relevant to your compliance initiatives.
  • Designate account groups as significant for compliance tracking and reporting. Document the reason for designating an account group as significant.
  • Define financial assertions relevant to your account groups.

Once maintained, account groups can be assigned to other master data objects and inherited at the Organization level.

In different work sets and by separate activities, significant accounts and assertions are assigned to:

  • Subprocesses: Representing which accounts/assertions should be covered by the controls within the subprocess.
  • Controls: Representing which accounts/assertions are actually covered by the controls.
  • Risks: If the company manages by risk

Note:

Control objectives and account groups are both important concepts in SAP Process Control, but they are different in nature.
  • Control objectives are high-level goals that an organization sets to ensure compliance with regulations, policies, and best practices. These objectives define what the organization wants to achieve in terms of internal controls, risk management, and compliance. Control objectives help to guide the design and implementation of control activities within the organization.
  • Account groups, on the other hand, are a grouping mechanism in SAP Process Control that is used to categorize and manage accounts or business processes in the system. Account groups help to define the attributes and settings for various types of accounts, such as general ledger accounts, vendor accounts, customer accounts, and so on. They provide a way to organize and manage accounts based on their characteristics and usage within the system.

In summary, control objectives are strategic goals related to internal controls and compliance, while account groups are a technical grouping mechanism used to manage accounts within SAP Process Control.

Both are important for effective risk management and compliance within an organization.

Demo: Creating a Account Group

CRG Example:

Ian is looking to create a new Account Group within the "Balance Sheet Acts" and has chosen to name it "Accounts Payable." This decision is based on a variety of reasons:

1. Organizational Clarity: The creation of a separate account group for accounts payable enhances clarity and organization within the balance sheet, making it easier for users to differentiate accounts related to accounts payable from other balance sheet accounts.

2. Financial Reporting: Having a dedicated account group for accounts payable allows for more precise and detailed financial reporting, enabling better tracking and analysis of payables for a clearer understanding of the organization's financial position and performance.

3. Control and Management: Establishing a distinct account group for accounts payable facilitates better control and management of payables, providing focused monitoring, analysis, and management of liabilities owed to creditors for more efficient cash flow management.

4. Analysis and Decision-Making: Separating accounts payable into its own account group enables easier analysis and decision-making related to payables.

5. Compliance and Auditing: The dedicated account group for accounts payable strengthens compliance with accounting standards and aids in auditing processes, ensuring that payables are accurately accounted for and reported in accordance with regulatory requirements and internal policies.

The Accounts Work Set Functionality

The next step in setting up the Master Data Flow is to set up Business Processes.

But before we continue with the Education lets understand what Business Process, Subprocess and Control is:

Business Process
This are the activities that the organization carries out to run the business. A Business Process Hierarchy, which includes Business Process, Subprocess, and Control, is a structured representation of an organization's business processes. This hierarchy supports in organizing and managing various business processes within the system, facilitating risk assessment, compliance monitoring, and governance, risk management, and compliance (GRC) initiatives.
Subprocesses
Subprocesses represent the logical subdivisions of activities within the broader process defined earlier. For instance, in the Procure to Pay process, subprocesses might include Purchase Requisition, Purchase Order, and Goods Receipt. It includes the definition of relevant attributes such as regulations, control objectives, accounts, and risks.
Controls
After defining the subprocesses, the next step is to establish controls. Each control can be specified by its level of evidence, which determines the extent of testing required. Control risk indicates the potential impact on the organization in the event of control failure. Additionally, controls can be categorized by their level of automation—automated, manual, or semi-automated. These aspects will be explained in more detail in the Unit Identifying the Key Capability: Perform and Monitor.

Following is the list of steps for creating a Business Process hierarchy:

  1. Create a process.
  2. Create a subprocess.
  3. Create controls at the subprocess level.

GRC Example

Ian understands the importance of maintaining accurate and up-to-date financial records.

He is adding the manual control "Vendor statement reconciled to Accounts Payable" to the Subprocess "Account Payable Invoicing" to ensure that all vendor statements are accurately reconciled to the accounts payable ledger.

Ian outlines the following steps to effectively execute this manual control. He adds following steps as performance plan:

Gather vendor statements: involves collecting all financial statements and invoices from vendors to ensure that these documents are up-to-date and accurately reflect the transactions.

Compare with vendor balance details: This step involves carefully cross-referencing the vendor balance details to ensure there are no errors or discrepancies in the recorded data.

To address potential risks and strengthen the control, Ian identifies and incorporates specific risks.He adds "Multiple processing of invoices" and "invalid transaction are recorded" as risk to avoid duplicate invoicing processing and to ensure that only legitimate and accurate transactions are recorded.

In the Unit Identifying the Key Capabilitiy: Perform and Monitor, it will be explained in more detail which control types are possible in SAP Process Control (Automated / Manual/ Semi-Automated)

The Process Hierarchy as Business Processes

The next step in Master Data Flow is to set up Indirect Entity-Level Controls.

An Indirect Entity-Level control is an internal control designed to assist an organization and ensure that management directives and policies that pertain to the entity as a whole are carried out effectively.

A direct entity level control is designed to detect and/or prevent, on a timely basis, any misstatement resulting from an error or fraud and related to a significant account or disclosure that could result in a material misrepresentation on the financial statements.

Indirect entity-level controls are a class of controls that relate to general management practices and overall corporate governance and have an indirect effect on the chances of detecting and/or preventing the occurrence of a misstatement. Each indirect entity-level control may be associated with one the five COSO components:

  • Monitoring
  • Control environment
  • Control activity
  • Information and Communication
  • Risk assessment

Indirect Entity-Level controls are a critical component of corporate governance, but are not related directly to specific risks at the financial statement assertion level. They do, however, play an important role in the overall effectiveness of the control environment.

You can create an Indirect Entity-Level control group and an entity level control as sub control.

For example:

In CRG International Inc., the entity level control group is responsible for managing control activities and ensuring segregation of duties to safeguard assets and uphold operational integrity.

Consider their procurement process - segregation of duties is diligently maintained by assigning different roles to initiate purchase requisitions, approve purchases, and reconcile invoices. For instance, a purchase officer could initiate requisitions, a manager might approve the purchases, and a finance executive might be in charge of reconciling the invoices.

In addition, automated controls are in place to monitor inventory levels regularly and flag any discrepancies for further review. These controls could trigger alerts if the inventory falls below a certain level or if there's a sudden, unexplained change in the inventory quantity.

Performance evaluations are conducted routinely to assess the effectiveness of these control activities and pinpoint any potential areas for improvement.

The entity-level control group for this scenario could be termed as "Control Activities", encompassing a sub-control addressing segregation of duties. This could be considered an "Indirect Entity-Level Control".

When creating an Indirect Entity-Level Control in their system, CRG International can assign specific regulations, define a validity period for the control, specify the frequency of the operations (which is a customizable field), decide if the control requires testing, and even upload relevant attachments if needed.

This structured and meticulous approach helps CRG International to maintain effective controls, ensuring smooth business operations and compliance with relevant regulations.

The next step is to do the assignments.

After setting up all necessary master data objects we will perform the master data assignments.

  1. Assign corporate and organization roles.
  2. Assign subprocesses to organizations.
  3. Assign local subprocess and local control roles.

Assigning Corporate and Organization Roles

The next step is to assign corporate and organization roles.

You can use this function to assign users to roles for corporate and organization objects. You typically perform this task during initial setup, when organizations or roles (corporate or organization) are added, or when multiple users are assigned to roles.

This step essential for defining user responsibilities, setting permissions, ensuring segregation of duties, facilitating accountability, and enhancing security within the system. It plays a critical role in effectively managing internal control processes and compliance initiatives within organizations.

Mass Role Reassignment

With Mass Role Assignment, you don't need to remove roles, replace role assignees or replicate role assignment one by one. You can select multiple users to remove some or all roles assigned to them, or replace them with new assignees, or copy their role assignment to other users.

CRG Example:

Ian Robb as internal control manager is assigned to his role at the beginning of creation CRG International, Inc. hierarchy.

Ian assign following Roles for the organization "General Accounting":

  • Control Owner - Brian Kenny
  • Control Performer - Mae Wong
  • Control Tester - Jenny Ma
The next step is to assign subprocesses to organizations.

Demo: Assigning an Subprocess

CGR Example:

Ian goes to the General Accounting Organization and adds the "AP Invoicing" subprocess. He is prompted to choose between using it as a shared service provider and allowing local changes. Ian decides to not use it as a shared service and chooses No for allowing local changes.

This allows for the subprocess to be tailored to the specific needs of the General Accounting Organization and ensures that any changes are made in a controlled and standardized manner, aligning with the organization's policies and regulations.

The next step is to assign local subprocesses/local controls to roles.

Assigning local subprocess or local control roles to an organization refers to the process of granting specific responsibilities and permissions to individuals or teams within an organization to manage and control specific processes or activities.

These roles may include defining and monitoring internal controls, compliance activities, risk management, and other related tasks at a local level. By assigning these roles, organizations can ensure that the right people have the necessary authority and access to effectively carry out their responsibilities within the SAP Process Control system.

Log in to track your progress & complete quizzes