- ERP AUDIT & COMPLIANCE – Part 2 –
- 1. Context: Why discuss compliance in the ERP environment?
- 2. What Is Compliance? Definition, Origin, Objectives
- 3. Where do compliance requirements come from?
- 4. What does this mean specifically in an ERP environment?
- 5. Common Misconceptions in Small and Medium-Sized Businesses
- 6. Assessment and Outlook: What’s Next?
ERP AUDIT & COMPLIANCE – Part 2 –
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.

What does compliance actually mean in the ERP context?
In the first post of this series, we focused on the business perspective: why a structured, audit-ready ERP operation is a worthwhile investment. This post addresses the conceptual and substantive foundations: What do we actually mean when we talk about “compliance in the ERP environment”—and why is this perspective relevant for companies using Business Central? In addition, we address what we consider to be some key misconceptions regarding ERP compliance in small and medium-sized businesses and present our perspective on the matter.
1. Context: Why discuss compliance in the ERP environment?
Compliance is not a new issue. At the very least since the accounting scandals of the early 2000s, lawmakers, regulatory authorities, and auditing organizations have tightened the rules for proper financial reporting and backed them up with significant penalties.
At the same time, ERP systems have evolved: what were once isolated accounting silos have become integrated platforms that support finance, the supply chain, and often key components of the business model. In many companies, Business Central serves as the central nervous system—both for financial reporting and for operational processes.
Against this backdrop, we believe a sober assessment is necessary:
- Compliance is not just a "legal side issue."
- ERP systems are not just "digital filing cabinets."
- The combination of these two factors determines
– how reliable the financial reporting is,
– how smoothly processes run, and
– how relaxed or stressful audits are.
Nevertheless, we still encounter two extremes in small and medium-sized businesses: either the topic of compliance is perceived as an abstract “corporate world”—or it is reduced to individual, visible aspects such as GoBD procedural documentation. In our view, both perspectives fall short.
2. What Is Compliance? Definition, Origin, Objectives
In a business context, we generally define compliance as adherence to rules: compliance with laws, regulatory requirements, and self-imposed rules. It is not just a matter of avoiding penalties, but also of mitigating risks for your company, its governing bodies, and its stakeholders.
Historically, the term has gained prominence primarily in the context of accounting scandals. The response from lawmakers was correspondingly strong:
- stricter accounting and reporting requirements,
- greater emphasis on management responsibilities,
- Expansion of enforcement mechanisms (ranging from fines to personal liability).
In our view, the objectives can be broadly summarized as follows:
- Protecting the Integrity of Financial Reporting
– Stakeholders should be able to rely on financial figures and reports. - Risk mitigation
– financial risks (fines, damages),
– legal risks (liability of corporate officers),
– reputational risks (loss of trust in the market and among the public). - Transparency and Traceability
– Processes and decisions should be traceable and verifiable in retrospect.
Compliance is therefore not an end in itself, but rather a framework within which companies operate if they wish to remain trustworthy and capable of acting in the long term.
3. Where do compliance requirements come from?
Compliance requirements arise from various sources. For companies with ERP systems—and especially those using Business Central as their financial reporting system—three areas are particularly relevant:
Level 1: International and supranational regulations
Depending on your company’s structure and market environment, international or supranational regulations may apply, for example:
- EU regulations (e.g., in the areas of financial markets, data protection, and sustainability reporting),
- In some cases, regulations such as the U.S. Sarbanes-Oxley Act (SOX) may also apply if the company is part of a corporate group.
These regulations often have an indirect impact on national laws and testing standards, thereby raising the bar for processes and systems.
Level 2: National Laws and Standards
For companies in Germany that use Business Central as their accounting system, the national framework is particularly relevant, including:
- German Commercial Code (HGB) and Generally Accepted Accounting Principles (GoB),
- GoBD (Principles for the Proper Maintenance and Retention of Books, Records, and Documents in Electronic Form, as well as for Data Access),
- Stock Corporation Act (e.g., duties of care of the board of directors, requirements for internal control systems and risk management),
- other legal regulations that apply depending on the industry and legal form.
To interpret these requirements, auditors refer to auditing standards, such as:
- IDW RS FAIT 1 on the proper conduct of accounting when using information technology,
- Additional IDW standards regarding the scope and depth of the audit.
Level 3: Voluntary or self-imposed frameworks
In addition to legally binding regulations, there are a number of standards to which companies can voluntarily adhere, e.g.:
- German Corporate Governance Code,
- ISO 27001 (Information Security Management),
- ISO 20000 or ITIL (IT Service Management),
- COBIT (IT governance),
- COSO (Framework for Risk Management and Internal Control).
These frameworks are not binding in and of themselves, but they can:
- The expectations of auditors and parent companies shape,
- serve as the basis for certifications and proof of trust,
- have a significant impact on the design of processes, roles, and controls in the ERP environment.
4. What does this mean specifically in an ERP environment?
4.1 Levels of Impact of Compliance Requirements
These requirements must not be limited to static documentation. They have a concrete impact on processes, data, and systems—and thus directly on your ERP system.
From our perspective, three levels can be distinguished:
Level 1: Processes
- Mapping of business processes in Business Central (e.g., Purchase Order → Goods Receipt → Invoice → Payment),
- Approval workflows, dual-control principle, approvals,
- Roles and responsibilities (e.g., separation of the roles of the person who enters transactions and the person who approves them).
Level 2: Data
- Completeness (all relevant business transactions are recorded),
- Accuracy (data is plausible and factually correct),
- Traceability (changes are documented in a traceable manner; no "invisible" corrections).
Level 3: Systems and Technical Environment
- Business Central itself (setup, permissions, logging),
- Database, operating system, Active Directory / Entra ID,
- Supporting systems (Shop, Loyalty, DMS, Reporting),
- Monitoring, Backup, Recovery.
4.2 Our working definition of ERP compliance
From our perspective, “compliance in the ERP environment” does not refer solely to adherence to legal requirements. It specifically refers to the requirements that auditors typically place on systems used for financial reporting.
In the context of Business Central, this goes beyond GoBD requirements and also covers topics from the IDW standard RS FAIT 1. Specifically, audits regularly request procedural documentation and evidence related to areas such as IT operations, access management, and backup management—that is, controls that safeguard the ERP system and its environment from both a technical and organizational perspective.
In our experience, these are precisely the aspects that are often underestimated or even completely overlooked when first exploring “ERP compliance.”
We therefore define ERP compliance as the aspect of corporate compliance that deals with:
- accounting-related and
- other processes and data relevant to the audit
focuses on the ERP system (e.g., Business Central) and its environment—including the technical and organizational controls designed to safeguard these processes.
5. Common Misconceptions in Small and Medium-Sized Businesses
In our discussions with small and medium-sized businesses, we repeatedly encounter similar assumptions when it comes to compliance in the ERP environment. In our view, some of these assumptions are misguided and lead to a false sense of security.
5.1 “ERP compliance = GoBD procedural documentation—that’s all there is to it.”
Many companies initially equate “ERP compliance” almost entirely with GoBD procedural documentation. This is important and useful: it addresses the description of processes, systems, and responsibilities.
In contrast, auditors typically go a step further. They expect not only documentation, but also robust controls and evidence in areas such as:
- Permissions and Access Management,
- Change Management (changes to systems and processes),
- IT Operations and Backup Management.
Anyone who reduces ERP compliance to procedural documentation therefore often has an incomplete picture. In our view, it makes sense to consider documentation and controls together.
5.2 “If Business Central is running smoothly and the auditor hasn’t said anything so far, we’re in the clear.”
In our view, the assumption that a lack of or minimal number of findings in past audits is a reliable indicator of a “fully developed” compliance framework is a one-dimensional perspective.
Audits are risk-based and rely on sampling. In addition, company size, system architecture, and audit focus change over the years. An ERP environment that passes an audit today without significant issues may reveal vulnerabilities in the future—especially when it comes to issues such as:
- Access Management,
- IT operations (e.g., monitoring, backup),
- Process Documentation in the IT Environment
have so far been considered only in isolated cases.
The question here is not so much whether “everything has gone well so far,” but rather whether the control system is appropriate for the company’s current and future situation.
5.3 “ERP compliance is an IT issue—they’ll take care of it.”
In practice, ERP compliance is often “delegated” to the IT department. Since technical controls and documentation are handled there, it follows that the issue of ERP compliance often ends up there as well.
In our view, this perspective falls short. Relevant questions always concern the interplay between:
- departments (e.g., Finance),
- IT / ERP Operations,
- Management (CFO, Executive Management),
- if necessary, internal audit.
Ultimately, responsibility for content—particularly with regard to accounting-related processes and controls—lies with management or the CFO. IT can support this responsibility, but cannot bear it alone.
An ERP compliance setup that is treated solely as an “IT issue” runs the risk of failing to adequately address business requirements, responsibilities, and operational priorities.
6. Assessment and Outlook: What’s Next?
In summary:
- Compliance refers to a company's adherence to laws, regulations, and self-imposed standards.
- These rules have a direct impact on processes, data, and systems, and thus directly affect the ERP environment.
- ERP compliance is the aspect of corporate compliance that deals with accounting and audit-related processes in the ERP system (e.g., Business Central) and its peripheral systems—including the technical and organizational controls that safeguard these processes.
- In our view, it is not advisable to reduce ERP compliance to procedural documentation or to “delegate” it solely to IT.
In the first post of this series, we explained why it makes good business sense to invest in an audit-ready ERP system. In the following posts, we will further elaborate on this framework:
- We explain what GoB, GoBD, and the IDW standard RS FAIT 1 mean for IT-supported accounting in Business Central environments.
- We present a tiered model that distinguishes between:
– companies without ERP,
– companies with ERP,
– companies with ERP and outsourced processes.
This explains why, as IT penetration and outsourcing increase, so do the requirements for structure, controls, and documentation in the ERP environment.
If you feel that the terms “compliance,” “ERP compliance,” and “audit readiness” are interpreted differently within your company or have only been addressed on an ad hoc basis so far, a brief, structured overview may be helpful. Through a joint discussion, we can work with you to clarify which requirements are actually relevant to your Business Central environment, where you are already well-positioned, and where we believe further action is needed.
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