ERP AUDIT & COMPLIANCE
This article is part of our series on the topic of "ERP Audit & Compliance." In each article, we highlight what we believe constitutes audit-proof operation of Business Central in medium-sized businesses—from a professional, technical, and organizational perspective.
Be sure to check out the other articles in this series:
Part 1 Compliance as an Investment: Why an Audit-Ready Business Central Operation Pays Off
Part 2: What Does Compliance Actually Mean in the ERP Context?
Part 3 GoB, GoBD, and IDW RS FAIT 1: What Does This Mean for ERP Systems in Practice?
Part 04 – Three Levels of ERP Compliance: How IT and Outsourcing Broaden the Scope of Consideration
In the previous installment of our series, we examined the GoB, the GoBD, and IDW RS FAIT 1, and used them to identify the requirements for IT-supported accounting. Among other things, it became clear that when assessing compliance, one cannot focus exclusively on the technical processing of a business transaction; rather, with the use of information technology, the IT systems employed and their operation also become part of the assessment.
Against this backdrop, an important question arises from our perspective: Does ERP compliance actually begin only with the use of information technology? In our view, the answer to this question is a clear “no,” because the fundamental requirements for proper financial reporting exist first and foremost regardless of whether a company processes its business transactions manually or with the support of information technology. The use of IT does not change these fundamental requirements; rather, the scope of consideration expands to include additional requirements for the IT systems used and their operation. If accounting-related processes or functions are subsequently outsourced to external service providers, this scope expands once again—now extending beyond the company’s own boundaries.
To help you understand these interrelationships, we use a three-level model of ERP compliance below. It is important to note that these three levels are explicitly not intended as a maturity model: A company at Level 3 does not automatically meet higher compliance requirements or is “more compliant” than a company at Level 2. Rather, the levels build upon one another, with the requirements of a previous level generally remaining in place while each level adds an additional layer of consideration.
We believe it is important to clarify one conceptual distinction: We do not equate an ERP system with ERP software or information technology. In our view, an ERP system encompasses the entire system for planning, controlling, and integrating operational resources and processes; thus, in addition to technical components, it specifically includes processes, roles, organizational regulations, and the relationships between the stakeholders involved. Microsoft Dynamics 365 Business Central, by contrast, is ERP software and therefore a technical component of such an ERP system.
Level 1
Proper accounting without IT support
Let’s begin by deliberately considering a reference case that is somewhat theoretical today, in which a company handles its accounting entirely without the support of information technology: For example, business transactions are documented on paper, receipts are physically filed, approvals are verified by signatures, and the necessary records are maintained manually. Whether such a scenario is still realistic for a company like yours today is not, for the purposes of our discussion, a decisive factor at this stage. Rather, the reference case makes it clear that the fundamental requirements for proper accounting already exist before information technology is implemented.
Even in a purely manual process, a company must ensure, among other things, that business transactions are recorded completely and accurately, that supporting documents can be assigned to the corresponding transactions, and that the processing and any changes made remain traceable. The controls required for this are, by their very nature, primarily organizational in nature and may include, for example, defined responsibilities and segregation of duties, manual approvals, the dual-control principle, or regular reconciliations between supporting documents and records.
Let’s consider, for example, an incoming invoice that is received as part of a purely paper-based process and initially forwarded to the person responsible for the subject matter. This person confirms the factual accuracy, after which another person, for example, authorizes payment, with both processing steps documented by corresponding signatures on the document. The actual control objective, however, is not to produce two signatures on a paper document, but to ensure that the invoice has been substantively reviewed and approved by an authorized person before further processing, and that this process can be traced retrospectively.
This example clearly illustrates the basic logic of the first stage: The requirements for compliance arise from accounting and the underlying business process—not from the information technology used. Thus , this first stage forms the foundation for further considerations.
Level 2
Accounting is IT-supported
In the second step, we integrate information technology into accounting without compromising the fundamental requirements established in Step 1. Business transactions must still be recorded completely and accurately, processed in a traceable manner, and approved in accordance with defined responsibilities; however, the way these requirements are implemented and monitored has changed.
Let’s stick with our example of an incoming invoice: The invoice is now, for example, received electronically, automatically imported into a document management system, and then processed in Microsoft Dynamics 365 Business Central, while the substantive review and approval no longer take place via signatures on a paper document but through an electronic workflow. The underlying control objective has not changed for the time being, as it is still necessary to ensure that the invoice is reviewed for accuracy and approved by an authorized person. In contrast, the specific implementation of the control has changed significantly.
Whether the control mechanism functions no longer depends exclusively on organizational regulations and the individuals involved, but also on whether the information technology used actually supports the intended rules and does not, for example, undermine them through an inappropriate configuration. For example, an electronic approval process fulfills its control function only if the permissions within the ERP software in use are set up accordingly. If a user can create, approve, and subsequently modify a business transaction on their own without sufficient traceability, even an approval process that is fundamentally well-defined is of only limited use.
Against this backdrop, the scope of compliance considerations expands to include requirements for IT-supported accounting. This is precisely where IDW RS FAIT 1, among other standards, comes into play, as it specifies the principles of proper accounting for the use of information technology.
In the previous article in this series, we contextualized IDW RS FAIT 1 alongside GoB and GoBD. If you haven’t read that article yet, we recommend starting with “GoB, GoBD & IDW RS FAIT 1: What Does This Mean for ERP Systems in Practice?”
For a Business Central environment, this means that the following aspects, for example, may become relevant:
- the setup and regular review of permissions,
- identity and access management,
- document management systems and other supporting or ancillary systems,
- interfaces between Business Central and other applications,
- changes to the ERP software and its deployment,
- database and technical infrastructure,
- data backup and recovery, as well as
- monitoring of ongoing operations.
Which of these components are actually relevant to accounting in your company depends on your specific system and process landscape; therefore, in our view, it would not be appropriate to consider only the ERP software in a blanket manner. At the same time, this point once again highlights why we distinguish between an ERP system and ERP software: Business Central can be an essential technical component of an ERP system, but the compliance of a business process arises from the interplay of business processes, organizational regulations, the people involved, and the IT systems used for this purpose.
In summary, for the second stage, it can be stated that the requirements from Stage 1 remain in place and are supplemented by an additional level of requirements through IT support: The information technology used must also support proper processing and be monitored accordingly.
Level 3
Accounting-related processes and functions are outsourced
So far, we have assumed that the processes and IT systems relevant to financial reporting are organized and operated entirely within the company in question. In practice, however, these tasks are often distributed among multiple service providers. The infrastructure for Business Central may be provided by an external hosting or cloud provider; custom extensions to the ERP software may be developed by an ERP service provider; or parts of application management, DevOps, or IT operations may be outsourced. In addition, external service providers may also directly perform specialized tasks within the ERP system.
By involving external service providers, we reach the third level of our model; however, it should be noted here as well that the requirements from the previous levels remain in effect. The underlying business transaction must still be processed properly, and the information technology used must still be appropriately configured and operated. What is new, however, is that certain processes or functions relevant to this proper processing are now performed outside the organization.
Let’s apply this once again to our example: The incoming invoice is processed electronically and approved within Business Central via a workflow; however, the underlying ERP software is operated on infrastructure provided by an external service provider, and changes to the application are additionally developed and deployed by an ERP partner. Consequently, proper processing no longer depends exclusively on processes, people, and IT systems within the company itself, but can also be directly or indirectly influenced by services provided by external organizations. The scope of consideration thus extends beyond the company’s own boundaries.
Against this backdrop, the three levels can be summarized as follows:
In our view, the cumulative perspective is crucial here, because IT support does not replace the fundamental requirements for compliance, just as outsourcing services does not render the requirements for a company’s own processes and IT systems obsolete. Rather, an additional layer is added in each case.
This raises a particularly important question regarding the third level: If an external service provider takes over processes or functions that affect your company’s accounting-related procedures, that service provider must inevitably become part of the compliance framework. Conversely, outsourcing a task does not mean that your company can absolve itself of the associated responsibility.
However, we have deliberately chosen not to delve into how these responsibilities are specifically distributed among companies, ERP service providers, hosting or cloud providers, and other parties involved—or how compliance with them can be demonstrated—at this point, as this very issue will be the subject of the next article in our series.
Three levels—but not three different compliance systems
At this point, we believe it is important to make one further distinction: The model presented here does not describe three independent compliance systems, but rather three levels of analysis within a single, interconnected system. The substantive and organizational controls from Level 1 remain relevant even when Business Central is used, while technical controls from Level 2 remain necessary when individual technical services are outsourced to a service provider.
As a result, the following logic emerges:
Proper accounting
+ IT-supported accounting
+outsourced accounting-related processes and functions
In our view, this perspective helps in particular to avoid two misunderstandings. First, ERP compliance does not begin with the implementation of ERP software, as the fundamental requirements already arise from the underlying business processes and the requirements for proper accounting. Second, compliance does not “shift” to the service provider as soon as a technical or business function is outsourced; rather, outsourcing creates an additional relationship that must be incorporated into your company’s compliance framework.
However, this does not automatically mean that every additional step must lead to a proportionally increasing compliance burden. On the other hand, IT support in particular offers the opportunity to systematically map, standardize, and partially automate controls, as well as to provide evidence regularly and reproducibly through appropriate processes, rather than having to manually gather it only in the context of a specific audit. We have already examined the business perspective on this relationship in more detail in the first article of our series “Compliance as an Investment.”
Our conclusion
In our view, the three levels of ERP compliance help to systematically define the scope of an audit-ready ERP operation by first taking as their starting point the technical and organizational requirements for proper financial reporting and then showing how this scope is gradually expanded through the use of information technology and the outsourcing of accounting-related processes or functions.
The starting point always remains the requirements for proper financial reporting, which exist regardless of whether information technology is used. If financial reporting is IT-supported, additional requirements apply to the IT systems used and their operation; if, in addition, accounting-related processes or functions are outsourced, the scope of consideration extends once again beyond the organization itself. The additional levels do not replace the previous requirements but rather supplement them.
Against this backdrop, two relatively simple questions can be helpful in assessing your own company: Which parts of your accounting are currently processed using IT, and at what points are external service providers involved in these processes or the IT systems required for them? The answers to these questions already provide a good initial indication of how far the scope of compliance must extend within your company.
The second question, in particular, leads directly to another set of issues, because as soon as accounting-related processes or functions are outsourced, the question inevitably arises: Who actually bears what responsibility in the event of an audit? We will address precisely this question in the next installment of our series.
We would be happy to assist you in structuring your accounting-related ERP and system landscape, clarifying responsibilities, and deriving a compliance framework appropriate for your company.
In the next part of our blog series, we will address the question of who actually bears responsibility in the event of an audit when IT processes are outsourced. We’ll examine the interplay between your company, ERP service providers, hosting or cloud providers, and auditors, and discuss the significance of IDW PS 951 and ISAE 3402. We’ll also explain why outsourcing processes or receiving audit reports from a service provider does not automatically relieve your company of its responsibilities.
Please feel free to contact us. We'll work with you to organize your setup and develop a practical plan to get started.
Stay up to date and subscribe to our PROTAKT blog!
About the author
DR. SVEN ODERMATT · EXECUTIVE BOARD
Board member and Team Lead Technicals – my playing field: Development, DevOps, and IT Ops.
I have been responsible for the implementation and operation of organization-wide application systems since 2002. I have been at home in the NAV/Business Central environment since 2017 – with a focus on reliable ERP operations and agile development processes that really work in everyday life.
Space for your comments