Compliance as an investment: Why an audit-proof Business Central operation pays off

In this first article, we deliberately focus on your business perspective: Why it is worthwhile for you to view the establishment of a structured, audit-proof ERP operation as a sustainable investment—and not just as a necessary response to specific audit requests.

Many companies find IT and ERP-related audits to be particularly time-consuming and difficult to plan. Especially in companies subject to audit, where Business Central is used as an accounting system and as the information nerve center for finance and supply chain, supporting audits often ties up considerable internal resources.

In this article, we will explain the topic from our perspective: What costs arise from unstructured, "non-audit-proof" ERP operations—and what effects you can achieve by investing in clear processes, documented verification methods, and (partially) automated workflows. The focus is on the combination of risk reduction, predictability, and noticeable relief for your teams involved.

In many companies subject to auditing, the ERP system is now the information nerve center of the business: finance, key parts of the supply chain, and often customer-centric processes (e.g., e-commerce, logistics) run on Business Central or similar systems.

At the same time, the topic of ERP compliance is often perceived as a "chore" in everyday life. For many organizations, the annual or multi-year IT operational audit is one thing above all else:

• time-consuming,
• difficult to plan,
• associated with uncertainty and, in some cases, noticeable nervousness.

A typical situation is one in which questions pile up before an exam, such as:

• "What exactly did we deliver last time?"
• "Where can we get the current organizational chart?"
• "Who can draw this conclusion—and in what form does the examiner need it?"

Added to this are unclear responsibilities:

• "Who is responsible for the list of leavers/movers?"
• "Why haven't last year's findings been implemented yet?"

In our view, this conflict of interests means that audits are perceived less as a technically useful means of reassuring companies about their own processes and more as a disruption to day-to-day business involving a high level of ad hoc effort.

The core message of this article is therefore:
ERP compliance consists of many small and, frankly, often "annoying" tasks. Taken together, however, these tasks enable audit-proof ERP operations that reduce risks and increase the reliability of business processes – far beyond the question of whether the final audit report includes findings or not.

When we talk about "audit-proof" operations in the ERP environment, we do not mean a perfect, fully automated governance construct. From our point of view, it is more about the following characteristics:

• Defined processes instead of ad hoc responses
  Repeatable procedures for providing evidence, for authorization checks, for changes, and for dealing with findings.
• Transparency instead of individual heroics
  It is clearly documented that
  • what the requirements are,
  • how evidence is provided,
  • where these are stored and
  • who is responsible for what.
• Risk reduction beyond audit limits
  An audit-proof operation not only reduces the risk of findings. It also ensures that the ERP environment runs according to defined processes, making it more stable, traceable, and less prone to errors.

In contrast, there is a company that "somehow works," but lacks key elements: clear responsibilities, defined verification processes, documented methods. The result is not necessarily a negative audit opinion, but very often a high, recurring workload and permanently increased uncertainty.

In many companies, we see a similar pattern before the structured support of IT audits:

• A key person (often from internal IT) is heavily involved in supporting the audit over a period of several weeks.
• A significant portion of the time is spent not on technical discussions of the content, but on searching and clarifying issues:
  • Who is the right contact person for a specific topic?
  • Where can I find the relevant information?
  • In what form and from which systems should evidence be obtained?
• Findings from previous years are addressed "incidentally" without a structured action plan.

In our view, this generates three cost blocks:

Cost block 1: Direct expenses during the audit

• Highly committed capacities over several weeks,
• high need for coordination,
• many queries and clarifications with the examiners.

Cost block 2: Opportunity costs

• Projects, upgrades, or process improvements are postponed.
• Finance and IT teams are tied up in a phase where they should actually have other priorities.

Cost block 3: Qualitative risks

• Uncertainty in finance, IT, and management: "We don't know for sure whether what we're doing is enough."
• ERP processes tend to be person-driven rather than process-driven, which in itself poses a risk to stability and scalability.

We believe that "not investing" in a structured, audit-proof ERP operation is not a neutral decision in this context. It is an implicit decision in favor of recurring ad hoc expenses, increased uncertainty, and the creation of processes that cannot be easily reproduced.

An audit-proof operation does not consist of a single project, but rather a set of interlocking building blocks. Typically, these include:

• Access Management & Permissions
  Clarity about who is allowed to do what, how privileged access is handled, and how leavers/movers are mapped.
• Change Management & Traceability
  Proof of which changes were made to the system, when, and how, including approvals and responsibilities.
• IT operations, monitoring, and backup
  Comprehensive documentation of backup concepts, recovery tests, and operational monitoring.
• Documentation of verification methods
  Not only that proof is provided, but how it is generated:
  • Where does the data come from?
  • Which script is used?
  • What filtering is applied?
• Central storage and repeatable audit processes
  Evidence is not buried in a "final v2 latest audit folder," but is stored in such a way that it can serve as a reference and blueprint in subsequent years.

An important detail: the sum of these activities initially represents an expense. However, it creates a structure that will make it possible to conduct audit rounds much more efficiently in the future. This is precisely where the investment character lies.

To illustrate this, here is an anonymized example from our practice.

initial situation

• Company subject to audit, Business Central as an accounting-relevant system and at the same time the backbone of central processes in finance and supply chain.
• For several years, IT audits were conducted exclusively by internal IT and specialist departments.
• The tests regularly involved a high level of manual effort:
  • A key person in internal IT was heavily involved for several weeks.
  • considerable time required to find contact persons,
  • Coordination of verification formats and the type of verification provided.
• The biggest pain points were:
  • Change logs (traceability of changes in the system),
  • Access/permissions (privileged access, user lists, roles),
  • Consistent backup documentation (proof that backups not only exist but can also be restored).
• There were no concrete, "red" findings. What dominated was a diffuse uncertainty and the feeling of starting from scratch before every exam.

trigger

The trigger for bringing in external support was not so much an acute audit risk as the very high internal costs involved in supporting the audits. The aim was to relieve the burden on internal resources and at the same time achieve a structured, repeatable audit process.

In the example described, we proceeded in several steps:

Step 1: Joint workshop with IT managers and auditors
In an initial workshop, the scope and requirements were specified in detail together with the customer's IT managers and the auditors:

• What topics are the focus of the current round of examinations?
• What evidence is expected—in what form and from which systems?
• Where are there ambiguities on both sides?

This ensured early on that everyone involved was speaking the same language and reduced misunderstandings.

Step 2: Converting detailed requirements into structured tickets
All requirements were not kept in a general list, but were converted into individual work items. Each requirement received:

• its own ticket context,
• a clear description,
• responsible persons and
• a status.

This contrasts with a one-dimensional approach, in which audit requirements are treated as "package 2, 5, 17." The granularity allowed communication and processing to be much more targeted.

Step 3: Central documentation of requirements and verification methods
The following was documented for each requirement:

• how the evidence is provided (e.g., BC report, SQL query, PowerShell script),
• which database is used as a basis,
• which filters or restrictions are applied.

In our view, this documentation was the decisive lever that prevented us from falling back into the same search pattern in subsequent years.

Step 4: Central storage of evidence and focus on repeatability
All evidence generated was stored in a structured manner in a central repository. The aim was not only to pass the current audit, but also to create a reference base for subsequent years.

Where possible, verification was (partially) automated, for example using PowerShell scripts. This made it possible to reproduce exports or evaluations in subsequent audits with significantly less manual effort.

Step 5: Regular coordination with auditors and IT managers
During and after the audit, open issues were clarified in dialogue with auditors and customer IT. On this basis, it was possible to:

• Uncertainties addressed early on,
• the detection methods have been refined and
• established "language rules" are reinforced.

The effects of this structured approach can be divided into several dimensions.

01 – Reduced effort in follow-up audits

Prior to the changeover, a central customer resource was heavily involved in providing evidence over several weeks—primarily driven by search, coordination, and clarification efforts.

After introducing the structured verification architecture, the effort required in subsequent years was significantly reduced. Many verifications were:

• described methodically,
• technically feasible,
• and organizationally anchored.

The initial, time-consuming survey thus became an investment that resulted in a noticeable reduction in workload in subsequent audits.

02 – Clearer process, fewer queries

Over time, the number of queries from auditors decreased. Established communication channels and clear verification methods resulted in an audit process that became more predictable for both sides.

Recurring patterns in the requirements in terms of language and content could be used instead of treating each exam round as an individual case.

03 – Reduced uncertainty and more orderly ERP processes

In terms of quality, the attitude within the company changed noticeably before and during the audit:

• Uncertainty ("Do we have everything? Do we understand the requirements?") has decreased.
• A certain calmness has set in, even though the focus of the examiners' attention can naturally vary from year to year.
• ERP-related processes run in a more orderly and rule-based manner because controls and verifications are no longer seen as an additional layer on top, but as an integral part of operations.

From our point of view, this is an essential part of the "return": an audit-proof operation not only has an impact on the audit, but also on the daily management and stability of the ERP landscape.

We believe that structured, audit-proof ERP operations are particularly useful where the following criteria apply:

• Business Central or a comparable ERP is an accounting-relevant system and part of the core process.
• The company is subject to audit and is in regular contact with auditors.
• ERP processes have become more complex due to growth, internationalization, or the system landscape (multiple peripheral systems, service providers, integrations).

In these scenarios, we believe that the recurring costs and risks of "non-audit-proof" operations are higher than the initial investment in structure, documentation, and (partial) automation.

Getting started with BC operations that are ready for audits does not have to be a large-scale project. We believe a step-by-step approach makes more sense:

Step 1: Brief review of the last rounds of examinations

• Which topics came up repeatedly?
• Where was the effort particularly high?
• Where is the greatest uncertainty?

Step 2:Focus on 2–3 core areas. These are often :

• Access/Permissions,
• Change records,
• Backup documentation.

Step 3: Document the verification methods instead of just the verifications
Don't just "save export XY as PDF," but clearly describe how this export is generated.

Step 4: Gradual (partial) automation where appropriate
For example, using scripts or standardized reports that can be reused annually.

In the medium term, this will result in an audit-proof ERP operation that not only meets regulatory requirements but also reduces the burden on the organization, increases transparency, and reduces risks.

If you find yourself in the situation described above—high costs, uncertainty, recurring stress before IT audits—this type of investment approach may be a sensible next step. It is crucial that you do not view this issue solely as a mandatory task, but rather as an opportunity to make your company's ERP nervous system more stable, transparent, and future-proof.

In the next articles in our series, we will show you how topics such as authorizations, change management, monitoring, and backup can be implemented in an audit-proof Business Central operation.

If you have any questions about your current situation, please feel free to contact us—we will work with you to organize your setup and develop a pragmatic approach.