Auditing Oracle ERP Financials
ERP systems are the central point for financial accounting. With this blog I intend to provide guidance regarding how those systems would be audited for statutory compliance (annually conducted for annual fiscal reporting). I will focus this on the German legislation (Grundsatz ordnungsmäßiger Buchführung — or GoBD) as an example. I do believe that many aspects of this blog will be similar across different countries. I believe so because compliance commonly means trustworthiness in the accounting data in the system which is an area that follows technical best practices not fiscal requirements.
Disclaimer: I write this is my own view as an ERP architect at Oracle and former IT auditor. Audits won’t be the same in every year. Certain aspects are subject to change (e.g., certifications may expire, new standards my come into existence) and other aspects are a matter of the auditor’s discretion. However, commonly audits will contain the aspect which I will outline in one form or another.
Intro
The first and most obvious thing: Oracle Cloud ERP is a Software-as-a-Service or cloud solution. This is important because the technical compliance requirements are the same as for any other (on premises) ERP software but the delivery and operations model changes which is relevant to the audit. An easy example is accessing the data center. Cloud customers commonly do not access cloud data centers and there is no reason to do so. Similarly, looking at operations, customers won’t have a technical admin within the company to maintain the system in day-to-day operations as well as the case of disaster. Oracle will take care of that. Also, there isn’t any way for a customer to gain full access to a database as this would present a risk to the cloud operations model. Therefore, monitoring of SYSDBA tables doesn’t make sense. As the compliance standard didn’t change for cloud, what has replaced all those functions? The answer is simple: certifications. Oracle will regularly undergo external audits to verify compliance with international and some local standards to deliver cloud solutions. Those certifications won’t replace the audit of a customer system, but it will make is simpler and shorter. No cloud provider can certify everything for a customer as customers in the end decide how they configure the system on the software level (like user access, accounting principles …). In the below I list the areas that are audited on top of certifications which Oracle provides.
Preparing an audit it is also important to understand what solutions a customer exactly runs. Like other ERP systems in the market, Oracle Cloud ERP is a modular software solution. The general ledger (which is subject to statutory audit) is contained in the Oracle Cloud ERP Financials solution. Payables and Receivables are subledgers and technically separate modules which come with the same offering so customers will usually use them alongside. Those sub ledger modules take care of things like tax calculation and cash transfers, so they are in scope for audit. Oracle is offering multiple other modules like Procurement or Projects which support processes. Those modules are usually not part of the audit as the actual transactions will flow through either payables or receivables into general ledger and are captured there before making their way into statutory financial reports. When integrating within an Enterprise, customers sometimes use EPM (Oracle Performance Management). This is a software which is tightly integrated with Oracle Financials. When EPM is used it may be in scope for an audit as this is where the ledges are consolidated. I won’t have this in scope in my blog. Oracle HCM is a great solution to manage employees and is tightly integrated with Financials. The actual access to ledger is however governed by Financials.
Areas of concern in an audit (Z1 and Z2)
1. Physical access (access to data centers as well as their safekeeping e.g., fire protection)
Oracle Cloud ERP runs on Oracle Cloud Infrastructure (OCI). OCI is Oracle’s IaaS (or infrastructure) offering while ERP is a SaaS (or software) product. Therefore, some of the compliance standards which apply to OCI will apply to ERP. Physical access is one of them. Standards which apply to operations may not or not fully apply to ERP. This is when for example there is a fault with the software which has nothing to do with infrastructure and therefore the same process cannot apply.
Oracle lists the available certifications on the public internet and breaks them down into the areas where they will apply. Oracle will send customers a copy of the certification documents when contacted with a valid reason (such as an audit) For statutory compliance in Germany and across Europe ISO27001 is the standard which is the most applicable. Specifically for Germany also C5 is important. Oracle Cloud ERP adheres to both.
2. Access Administration
This area will capture the main aspects of user management relevant to accounting. Access permissions in Oracle Financials are multi layered. The first concept to understand is that users have roles, which are a groupings of duty roles (e.g., single tasks) which again are groupings of privileges (e.g., DB accesses) Additionally there is another layer of security which is data access. In Oracle ERP a user can have a role which allows them to do a certain task (e.g. to do payments) but they still may not be able to do unless they also permitted to do this on a certain data set. In the scope of an audit access sets would be business units in subledgers and ledgers in general ledger (financials).
2.1 Audit of roles and data access permissions
Most notable for auditors would be all roles which do not begin with ORA_. ORA roles are seeded roles by Oracle and therefore fulfil the best practice of using Oracle Cloud ERP. There are also roles starting with AP_, AR_, GL_, FA_ those are roles on the module level. (all those roles start as their database table equivalents which can be found here) It isn’t advisable to use those as they also exist on a consolidated level as ORA roles and will make this task more complicated for auditors and internal reviewers. Yet, it presents no immediate risk.
Customers may have custom roles which as a best practice should follow a different naming convention. Often named after the company. Auditors are likely to question those roles and seek and explanation for their existence. The User and role access audit report provides the depth of drilling into the privileges which a custom role is comprised of to see if the custom roles fall into the category of being a superuser account or are otherwise able to outmanoeuvre compliant accounting practices.
To audit data accesses, it is advisable to focus on ledger (general ledger) and business unit (sub ledger) data access sets. To audit this correctly auditor will have to gain knowledge on which user should be entitled to access which ledger. In practice this is a task which will show multiple hundred if not thousands of lines in a report. Auditors may audit the full list, but it is rather likely that they will do either a random draw of users and will discuss their permissions or will only question users who have a lot of roles or superuser permissions on this basis. The advisable way for this part of the audit is to use the Authorize Additional Data Access sheet. This sheet can either show all data accesses or be filtered for users (in the case of a random draw or selection). Keep in mind that this sheet will require an additional addon to Microsoft Excel. Therefore, this is not a task which auditors can do on their own.
· Report: User role membership report: report of all users and their roles
· Report: User and role access audit report (for all roles): provides a detailed report on the roles in the system and their privileges. This report is especially needed if custom roles are used
· Report: Authorize Additional Data Access (ADF addon required): provides are full view of data access for all users or filtered for single users
2.2 Audit of user entrance and changes
To audit the entrance of new users to a system or changes in users’ statuses it may be required to see a full user history. On a single user level this is provided as a report. This isn’t a standard scheduled report. Therefore, companies who don’t administer teams in ERP will find it hard to pull it. In reality, demanding this report for every user will be difficult for larger enterprises. Therefore, this is another area where auditors may decide to do a random draw of users.
· Report: User history report: provides a full user profile incl. role and history of changes.
2.3 Audit of users leaving the company
Employees who left the company must be removed from the system in a timely fashion as a matter of compliance. A common approach to audit this is to pull a report of user activity and search for inactive users as those a likely to have left the company but might have been forgotten to be deactivated or be stripped of their permissions.
· Report: Inactive user report: this report will provide an overview of user activity. The auditor will define how long the time span of inactivity should be for this report. Common are 30 or 60 days.
3. Identification and Authentication
3.1 Audit of functional accounts (also known as generic privileged accounts or users)
Functional accounts are users that cannot be identified with a single person. One example are ‘firefighter accounts’ to quickly solve critical issues based on a wide permissions set (often called oracle_support, admin or similar). Another example are integration users which are used for example for imports. Generally speaking, there isn’t any limitation to if or how many functional users a customer can have. However, as a guideline be aware of the following:
- reduce the number of functional users wherever you can as those do present a security risk. Therefore, an auditor is likely to question if all functional accounts are strictly necessary.
- if you use functional accounts, monitor who owns the password to a functional user. An auditor is likely to ask you that.
- if you use functional accounts for integrations try to avoid using superuser permissions for those accounts. E.g., an interface to import journals doesn’t have to be a superuser but can be a general accounting manager or similar.
- as all activity of a functional user isn’t directly identifiable to a person it is strictly advisable to monitor all activity of those accounts (especially but not limited to if this account have admin permissions or similar)
Oracle enables you to set audit policies for those accounts. Follow this documentation to do so. Be aware that if your functional account is permitted to make changes to user accounts it could also disable this log. Therefore, don’t provide the FND_MANAGE_AUDIT_POLICIES_PRIV to any functional account. Should a functional account attempt to add this privilege to any other account this will be monitored. Auditors should inspect which users own this privilege which they can do with the help of the User and role access audit report. (see 2.1)
3.2 Audit of password compliance and complexity
Oracle Financials governs password complexity centrally on in the Security Console on the level of User Categories. The easiest way to audit compliance is by going onto the Security Console. There are best practices as to how complex a password is recommended to be which are not unique to Oracle. For GoBD the best resource to use is BSI Grundschutz. A full References provided by the German authorities on how an IT system should be secured. Other legislations are likely to have similar guidances.
3.3 Audit of frequent password changes
Frequent password changes are deemed to be a good security practice for users in enterprise systems. Therefore, this is often seen as a requirement to establish trust in the correct use an accounting system.
· Report: User Password Changes Audit Report: provides an overview of password changes. For an annual audit this would be required as a report for the period since the last audit for all users.
4. Monitoring of critical user activity
4.1 Audit of supplier creation and changes
Oracle financials uses suppliers and their supplier sites as the main source to capture critical information such as bank account data. To preserve integrity of statutory reporting, access to this information needs to be restricted and monitored. To maintain a four-eyes-principle, it is therefore a good-practice to establish approval workflows for registration and changes of suppliers. A Supplier registration is approved by supplier administrators or supplier managers depending on the status of the supplier. Auditors should pay close attention to how wide these roles are used within the organization.
Suppliers are also part of the Z3 extract which is part of an audit. (see 8)
4.2 Audit of impersonation use
Oracle provides a functionality for impersonation which means that users can temporally designate users to impersonate their profiles. By default, this functionality is automatically logged with the audit log for the business objects which are in audit scope. Auditors should check if this functionality hasn’t been disabled which is a profile option. There should be a start date but no end date (or one in the future).
5. Superusers
In Oracle Cloud ERP there are 2 seeded roles which need to be considered as widely privileged. This means that these roles provide such wide privileges that checks and balances are ineffective. This is great when installing the system or developing on it but during the day-to-day accounting operations the number of users with those privileges needs to be limited.
- Application Implementation Consultant: This role comes the closest to a typical admin type of role. Essentially the role is created to implement and configure the system. Therefore, this role has permission to do changes to a large majority of settings such as tax, payments, billing …
- IT Security Manager: this is the only role which gives permission to access the Security Console. On the Security Console roles and permission can be given and withdrawn. Therefore, technically anyone with this role could enable himself for admin permissions.
Using the User role membership report (see 2.1) auditors will identify users who possess those roles. It is common for auditors to demand a user history for those users.
As mentioned in 3.1, superuser permissions for functional accounts are seldom needed and open up security vulnerabilities. Therefore, try to limit those to standard seeded roles
6. Development
Development takes a special place during the audit. The overall assumption is when a system is running as advertised by the vendor and operated based on the vendor’s best practice, integrity can be assumed and the data can be trusted (hence the statutory reports haven’t been tempered with). This trust starts to vanish when a system is highly customized and components are added. Then auditors resort to development best-practices, development supervision as well as vendor recommendations to assure that integrity is still maintained.
In the cloud world certain aspects of the before stated need to be amended. The requirement towards a cloud system still remains the same but the operational integrity is already under the control of the vendor (or cloud operator but for Oracle Cloud ERP the vendor) where best practices can be assumed and usually are certified. A customer really is a tenant on a cloud without full permissions therefore customizing is also limited by design. As however customers still seek to differentiate themselves in the market by the means of software and processes how are they doing this? The answer is but providing secure and standardized APIs which customers can use to extend their systems. This is part of why many traditional vendors struggle to cloudify their software.
Summarizing: operational excellence is Oracle’s responsibility and is certified with ISO27001, for customizing auditors need to turn to how APIs are used to extend the solution (as opposed to changed), configuration changes (incl. the security posture on the software layer) remain the responsibility of a customer.
6.1 Versioning
As a mandatory requirement, auditors will be interested in which version of Oracle Cloud ERP is used to verify that the latest patches are used and therefore known security vulnerabilities are covered. This is the part of the audit where nobody can fail as Oracle patches the software and updates can only be postponed for a short time.
6.2 Migration of changed configurations to the production environment
Oracle Cloud ERP does not provide any way how configuration changes can be directly migrated from a test environment to a production environment. The suggested method is exporting and importing a configuration as a csv or zip. Auditors may ask how the integrity of the transported configuration is maintained. To approach this Oracle has a process on how to compare the existing and the imported configuration during the import. Following through this process as a suggested best practice will mitigate those risks. The only role which is permitted to import configurations is the Application Implementation Consultant which is a superuser type role and therefore should be trained personnel which the auditor may want to verify.
Oracle suggest that users have 3 environments named Production, Gold, Test. A two tier environment setup (Production, Test) is however accepted as well.
6.3 Configuration changes, logging
Configuration changes in Oracle Financials are changes on business objects. Those changes can be audited via logs if those are activated. Logging is not unlimited in size. Therefore, customers should focus on the objects most critical to them.
The underlying Fusion middleware stack can also be audited (SOA Suite, ODI …). For more information, see Audit Events for Oracle Applications Cloud Middleware (Doc ID 2114143.1) on My Oracle Support at where full list of middleware events is provided. The middleware is governed by Oracle not by the customers, still auditors may want to see those logs and customers should make sure that logging is activated.
6.4 Emergency changes
In traditional software emergency changes are usually patches which need to be rolled out quickly, often on exception approval, to solve an immediate problem. For example, if there is a malicious intrusion into the system of some other component resulted in a failure. This is audited because the integrity of the system is at risk. For a cloud solution such as Oracle ERP the process is different. Technical problems are escalated support requests raised by the customer to Oracle. Therefore, there is a historization of these events on support.oracle.com on the customer’s profile. To verify that this process is followed through correctly by the customer an auditor may ask to have a look or for a printout copy.
7. Accounting correctness
With regard to accounting there are certain aspects which auditors may want to see to ensure validity of the system
7.1 Audit gapless document sequencing
GoBD mandates a gapless ordering of documents to ensure completeness. This is an option with can be enforced on the ledger level in Oracle Cloud ERP.
· Report: Journals and Third-Party Report: This reports helps identifying if all journals are posted in a chronological order to identify gaps
7.2 Audit of sub ledger correctness
Unless only the general ledger module is used the transactions are happening in sub ledger modules. Most commonly in payables or receivables. The sub ledgers take care of the transactions and eventually transfer their balances to general ledger (GL) as journals. The journals then are booked onto balance sheet accounts. Transactions can be manually created and/or automatically loaded into the systems. The suggested process to do corrections to transactions is in sub ledgers before those are transferred to GL. However, it is also possible to transfer them first and correct the GL journal. When doing that the accounting in the ledger might become correct but the sub ledger will continue to hold incorrect information. Therefore, reconciliations between GL and the sub ledgers are likely to fail. Therefore, the suggested method is to never change or create GL journals for balance sheet accounts which are posted by a sub ledger application. Instead, it is advisable to do all corrections in the sub ledgers. Technically this can be enforced using Third-party controls on the general ledger accounts.
The best way to audit this is to export the value set for natural accounts to excel and look for the Third Party Control Account flag to be set for balance sheet accounts. As an additional audit task the balances of Third party control accounts can be viewed using the .
· Report: Export of the value set for natural accounts: provides the possibility to audit third-party control flags
· Report: Third-Party Control Account Balances Report: third-part account balances to verify functionality
It is to mention that this is more a best practice than a GoBD requirement. Therefore, it will unlikely be a mandatory party of a statutory audit. However, it is required for Z3 extracts when using SAFT (8.) and is therefore advisable.
7.3 Audit of interface tables and APIs
Oracle Financials uses FBDI to import files. The content of the files is loaded to interface tables which are then imported into the transactional database. If an import is not successful, then the interface table is purged and the user is prompted. Therefore, faulty data is not likely.
· Report: Import Payables Invoices Report: Reports if all imported invoices are accounted. The report is limited to payables.
API security is maintained in the security console in the API authentication area. Auditors may be interested in this aspect because security ensures integrity. It is however a side aspect of a statutory audit because any use of an integration will use a user account to do so and those are audited as outlined in 2. and 3. The standard setup is as below where Oracle is the trustee for API authentication and the identity cloud service is used for user federation. If any other API authentication provider, then it needs to be verified that the connection follows Oracle’s best practices which are documented here.
8. Z3 Extract (IDEA)
GoBD differentiates multiple methods of data access which should be made available for auditors. The above is a guideline for Z1 (unmittelbarer Datenzugriff) and Z2 (mittelbarer Datenzugriff) which are direct and assisted access to the system. Z3 (Datenträgerüberlassung) means the handover of the data or data device for auditing. In practice auditors commonly use the data analysis software IDEA to run statistical models on the data to identify malicious or suspicious accounting. It has become a de facto standard to extract data relevant to statutory audits in an IDEA format which is basically csv and a control file. Oracle Financials uses for it the Standard Audit File for Tax (SAF-T) interface to export the required files. SAF-T is a format standardized by the OECD have one single format for tax auditing. However not all OECD countries implemented this standard into law for this purpose. It is not a required standard in Germany for tax. It is however very useful for Z3. In fact, it can be used as is for IDEA when the control (or index) file is added to it. The File can be found on the Oracle Support portal.
Outro
I hope this guide has given a deeper insight into how to assure GoBD compliance with Oracle Cloud ERP Financials and has given a deeper insight into what to keep in mind. I also hope it has become clear what is different about running a cloud-based ERP system and that this aspect beneficial to compliance as it enforces standardization by design.
