- ERP AUDIT & COMPLIANCE – Part 3 –
- 1. GoB, GoBD, and IDW RS FAIT 1: Three Perspectives on the Same Issue
- 2. How do compliance objectives translate into requirements for ERP and IT?
- 3. Compliance doesn't stop at the surface of Business Central
- 4. Clear requirements make audits easier to plan
- Our conclusion
ERP AUDIT & COMPLIANCE – Part 3 –
This post is part of our series on “ERP Audit & Compliance.” In each article, we explore what we believe constitutes audit-ready Business Central operations for small and medium-sized businesses—from a functional, technical, and organizational perspective.
Be sure to read 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?
GoB, GoBD, and IDW RS FAIT 1: What Does This Mean for ERP Systems in Practice?
In the first article of this series, we explained why a structured, audit-ready ERP operation can be viewed as an investment. The second article defined the concept of ERP compliance and focused on the accounting and audit-related processes associated with Business Central.
The Principles of Proper Accounting (GoB) and the GoBD are particularly familiar to finance managers in companies. However, during annual financial statement and IT audits, attention is regularly directed toward topics that are initially considered more IT-related: user permissions, logging, changes to applications and configurations, interfaces, and the reliable operation of the ERP system.
For IT managers, it is not always immediately apparent how these requirements relate to the familiar accounting principles. Why, for example, does the auditor ask about privileged user accounts, change processes, patch management, or service monitoring when the initial focus is on the proper conduct of accounting?
The answer lies in the dependence of financial reporting on the IT systems used. As soon as business transactions are recorded, processed, and prepared for financial reporting in Business Central, the reliability of financial reporting no longer depends exclusively on technically correct accounting rules. It also depends on whether the ERP system is set up, modified, and operated in a controlled manner.
IDW RS FAIT 1 addresses this connection and clarifies what the principles of proper accounting entail when using information technology. The requirements that auditors impose regarding access permissions, changes, interfaces, or system operations are thus not separate from GoB and GoBD. Rather, they serve to ensure that these standards’ fundamental objectives are met even in IT-supported accounting.
For the purposes of further discussion, we have deliberately chosen a simplified and schematic presentation. Our goal is not to provide a comprehensive legal or auditing analysis of GoB, GoBD, and IDW RS FAIT 1. Rather, we aim to illustrate the fundamental relationships and derive clear requirements for ERP systems and their operation. Naturally, this overview cannot replace a thorough assessment of a specific individual case.
Would you like a structured assessment of your current situation? We’d be happy to discuss this with you briefly and work with you to identify the specific requirements for your Business Central system.
Email us or give us a call.
1. GoB, GoBD, and IDW RS FAIT 1: Three Perspectives on the Same Issue
The GoB provide the overarching framework for proper accounting. Key requirements include, among other things, the complete, accurate, timely, and orderly recording of business transactions. Furthermore, a record must not be altered in such a way that its original content can no longer be determined. For electronically maintained records, it must also be ensured that the data is available during the retention period and can be read within a reasonable amount of time.
The GoBD specify these principles for electronic books, records, and documents, as well as for data access by tax authorities. In doing so, they do not focus solely on financial accounting itself. Rather, the focus is on the entire process in which tax- or accounting-related information is generated, processed, transmitted, stored, and retained. The GoBD were most recently amended by a BMF letter dated July 14, 2025.
DW RS FAIT 1 is titled “Principles of Proper Accounting When Using Information Technology.” The statement describes, from the perspective of the auditing profession, the significance of the GoB for IT-supported accounting systems. It does not, therefore, create a collection of technical requirements detached from accounting. Rather, it examines the organizational and technical conditions under which an IT-supported accounting process can meet the requirements for proper accounting.
GoB, GoBD, and IDW RS FAIT 1 do not form a rigid legal hierarchy. For practical classification purposes, however, their relationship can be described in simplified terms as follows:
The GoB define the fundamental compliance objectives. The GoBD specify these objectives for electronic records and procedures. IDW RS FAIT 1 describes the organizational and technical requirements that must be taken into account in IT-supported accounting.
2. How do compliance objectives translate into requirements for ERP and IT?
The requirements cannot always be mapped to a single technical measure in a clear one-to-one relationship. An authorization scheme, logging, or interface control can simultaneously support multiple objectives of proper accounting.
For practical guidance, however, a schematic breakdown is still helpful:
| Compliance Objective | Typical Questions Asked by an Auditor | Implications for the ERP System and IT Operations |
|---|---|---|
| Traceability and Verifiability | Can a knowledgeable third party understand how a business transaction arose, was processed, and was recorded? | There must be a continuous link between the document, the business transaction, and the entry. The source of the entry, the processing steps, and any corrections must remain traceable. Interfaces, automated processing, and key procedures must be documented in a traceable manner. |
| Completeness and Accuracy | How can we ensure that all relevant transactions are processed completely, only once, and with the correct values? | Technical validations, controlled posting rules, and reconciliations are required. For interfaces and background processing, it must be possible to detect and handle missing, duplicate, or erroneous transactions. |
| Timely Recording and Organization | How can we prevent business transactions from being posted late, in the wrong period, or without a clear assignment? | Posting periods, posting dates, and closing processes must be monitored. Document numbers, accounts, dimensions, and other classification criteria help ensure clear assignment and facilitate future retrieval. |
| Protection Against Unauthorized Changes | Can journal entries, master data, or accounting-related settings be changed retroactively without anyone noticing? | Posted transactions must not be simply overwritten. Corrections must be traceable. Changes to relevant master data, system settings, and control parameters must be limited and, where necessary, logged. Direct database accesses must be addressed separately. |
| Safety and Reliability of the Process | How is the system protected against unauthorized access, data loss, or operational disruptions? | Appropriate access and authorization controls, controls over privileged access, data backup, recovery procedures, monitoring, and regulated operational and change management processes are required. |
| Documentation of the Procedure | Is there a clear description of how the accounting-related process actually works and is monitored? | The documentation must explain the interaction between processes, the ERP system, interfaces, authorizations, controls, and operations, and must be updated whenever relevant changes occur. Product documentation provided solely by the manufacturer is generally not sufficient. |
The assignment complies with the requirements specified in the GoBD regarding traceability and verifiability, completeness, accuracy, timeliness, orderliness, and immutability. The GoBD also takes into account the internal control system, data security, change logging, and procedural documentation.
This classification reveals an important distinction: authorizations, logging, monitoring, and data backup are not independent objectives of accounting. They are technical and organizational measures used to ensure compliance with the overarching regulatory objectives.
An authorization concept, for example, is intended to prevent unauthorized persons from altering journal entries or accounting-related settings. Logging supports traceability and protection against undetectable changes. Interface controls serve, in particular, to ensure complete and accurate processing. Backup and recovery procedures are designed to ensure that the information required for financial reporting remains available.
As a result, even typical audit questions regarding IT can be traced back to the fundamental requirements of GoB and GoBD. IDW RS FAIT 1 establishes the connection to IT-supported accounting: It examines not only whether Business Central is fundamentally capable of posting entries correctly, but also whether it is used within a controlled and reliable process.
3. Compliance doesn't stop at the surface of Business Central
Business Central is a central component of the accounting process. In our view, however, it is not appropriate to reduce ERP compliance solely to authorization rules, approval workflows, or the activation of a change log. Business Central provides the necessary functions for access control and for tracking selected changes; however, their effectiveness depends on how they are specifically configured and integrated into the control system.
Particularly in on-premises installations, Business Central is part of a broader technical system landscape. This includes, for example, identity management, Business Central Services, the underlying hosts, SQL Server, and the processes used to modify, monitor, and back up these components. Three control areas illustrate this relationship.
Privileged Access Across All System Levels
A sophisticated role- and permission-based model within Business Central is an important foundation. However, it falls short if, at the same time, there is extensive access to the underlying infrastructure.
In addition to privileged permissions within Business Central, administrative access to hosts, Business Central services, and SQL Server, as well as the permissions of technical users, must therefore be taken into account. If accounting-related data or system settings can be modified at any of these levels, that level must also be included in the authorization and control framework.
The key question is therefore not solely, “Who has which permissions in Business Central?” but rather, more broadly, “Who can influence the ERP process at which technical level?”
Controlled Changes and Patch Management
Changes are not limited to business applications or individual extensions. Changes to the technical platform can also affect the reliability, security, and availability of the ERP system.
A controlled change management process should therefore take into account, for example, deployments, configuration changes, updates, and security-related patches for the system components in use. In this context, it is essential to establish a transparent process for how changes are evaluated, tested, approved, and deployed to the production environment.
Logging selected changes within Business Central remains important. However, it is only one component of a more comprehensive process used to control changes to the application, configuration, and technical platform.
Monitoring and Recoverability
An ERP system may be technically accessible even though an accounting-related process is no longer running properly. For example, background processing, job queues, or interfaces may fail without this condition being immediately detected by host monitoring alone. Business Central provides status, error, and log information for job queues, as well as additional monitoring capabilities.
For this reason, monitoring should take place at multiple levels: Are hosts and central infrastructure components accessible? Are the required services running? Are background processing tasks and interfaces executing successfully? Are the business-required processing results being produced?
Data backup and recovery are also essential. A successfully logged backup initially only proves that a backup operation was performed. Whether the data can actually be restored completely and within a reasonable time frame, however, can only be reliably assessed through documented restore tests.
These examples show that compliance arises only from the interplay of the application, the technical platform, operational processes, and verifiable controls.
4. Clear requirements make audits easier to plan
If the interrelationships described above are only identified during an audit, this regularly results in a significant amount of work related to reconciliation and documentation. IT, finance, and ERP managers, as well as external service providers, must then quickly determine which systems and processes are relevant to financial reporting, what controls are in place, and how their effectiveness can be demonstrated.
In contrast, audits can be prepared in a more structured manner if the requirements of GoB and GoBD have already been translated into concrete technical and organizational measures. These include clearly defined responsibilities, documented authorization and change processes, appropriate monitoring, and traceable evidence of controls performed.
The more clearly these requirements are implemented and documented, the less need there is to reconstruct relationships retroactively during the audit. While this does not necessarily reduce the scope of each audit, we believe it improves predictability and limits the internal effort required for last-minute inquiries and follow-up work.
This brings us full circle to the investment logic we outlined earlier: A controlled and transparently documented ERP operation entails ongoing effort. However, it prevents the need to create required structures and supporting documentation only under the time pressure of an audit.
Our conclusion
GoB, GoBD, and IDW RS FAIT 1 examine the compliance of financial reporting from different perspectives. For IT managers, the interrelationship between these standards is particularly crucial: Auditors’ requirements regarding user permissions, system changes, monitoring, and data backup are not separate from the technical requirements of financial reporting. Rather, they are intended to ensure that the fundamental compliance objectives are also achieved within an IT-supported system and process landscape.
Business Central can provide important functions and technical foundations for this purpose. However, the compliance of the entire process cannot be ensured by a single system setting or by a blanket evaluation of a software product. What matters is the interplay of business configuration, controlled access permissions, traceable changes, a reliably operated technical platform, and documented organizational controls.
From an IT perspective, this means consciously expanding the scope of consideration beyond the user interface of the ERP application. Who has access to hosts, databases, services, or technical users; how security-related patches are applied; and whether faulty background processing is detected in a timely manner—these factors can be just as relevant to the reliability of financial reporting as an authorization set within Business Central.
The more clearly your company has understood these interrelationships, defined responsibilities, and embedded appropriate documentation into its day-to-day operations, the less the necessary structures will need to be reconstructed during an audit. An audit-ready ERP operation is therefore not achieved through one-off measures taken before the audit, but through a continuously monitored and transparently documented process.
In the next part of our blog series, we’ll take a look at the three levels of ERP compliance:
—ranging from companies without an ERP system, through the use of Microsoft Dynamics 365 Business Central, to outsourced processes such as hosting or external operations. We’ll highlight the typical risks and audit requirements associated with each level and explain how these impact the effort and benefits of a compliance strategy.
Do you have questions about your current situation? If so, please feel free to contact us—we’ll work with you to assess 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