Article

Compliance reports in Business Central: catch critical changes that bypassed internal control

A procedure only works if someone notices when it's skipped. How to move from ERP reviews at audit time to continuous internal control oversight.

June 11, 2026 - A Way How Product Team

Compliance reports in Business Central: catch critical changes that bypassed internal control

In May 2026, a company in Huesca paid the same payroll twice: once to a fraudster and once to the legitimate employee. The scam started with a routine email requesting a bank account change, forged documentation, and a payment processed as if nothing were wrong (Hoy AragΓ³n). Days earlier, in Tenerife, another business transferred payment for cooking courses to a different account after attackers intercepted the thread between company and supplier (El DΓ­a).

These are not isolated stories. Spain's Guardia Civil and INCIBE have been warning for months about a wave of Business Email Compromise: impersonation, urgency, and β€” almost always β€” a sensitive data point that ends up changed somewhere in an operational system.

The uncomfortable question for Business Central users is not just "how do we prevent fraud?" It is this: would we know tomorrow if someone changed a critical data point outside the procedure we thought we had under control?

A scenario that repeats more often than you'd think

Picture the Tenerife company from the case above β€” the one that paid for cooking courses into a fake account after its email thread with a supplier was intercepted β€” running Business Central. After the scare, Finance designs a procedure for supplier bank account changes, trains the team, and communicates the rule: no new IBAN goes live without validation and approval.

On paper, the control exists.

Months later, during a pre-ISO certification review, the compliance lead tries to prove that procedure is actually followed. They cross-check sensitive changes from the quarter against recorded approvals. The result is uncomfortable:

  • Eleven changes to supplier bank details.
  • Four with clear evidence of oversight.
  • Seven with no control reference at all.

None of those seven would necessarily mean confirmed fraud. But they would reveal something worse for day-to-day operations: the procedure would not be used consistently. Changes made "quickly", "because the supplier asked by phone", or "because the colleague on leave left it pending".

One of those seven cases could coincide with a payment Treasury has to reconstruct weeks later because the supplier claims they were never paid β€” exactly the BEC pattern where the double hit is not just diverted money, but the obligation to pay the legitimate creditor again. Maybe no new financial loss; but hours of work, tension between teams, and a question no auditor lets slide: who authorised this, and on what basis?

At that point it stops being distant cybersecurity and becomes operational internal control.

Recording changes is not the same as overseeing them

Business Central keeps a record of who changed what, and when. That is essential. In practice, though:

  • The log grows every day and no one reviews it systematically.
  • A legitimate change and one made on the sly look the same in the list.
  • Audit arrives months later, when rebuilding context costs three times as much.
  • Having a defined procedure does not guarantee it was followed in every real case.

The gap is not technological. It is continuous oversight: knowing in time which sensitive actions happened without the intended control path.

Many organisations discover that gap too late: when preparing for certification, when a supplier complaint arrives, or when someone asks about a specific payment and the email hunt begins.

What continuous audit adds (beyond the change log)

What is missing is not another static report or more spreadsheets running parallel to the ERP. What is missing is a straight answer to a simple question: did this critical action go through the control we designed?

That is what compliance reports in AWH GRC provide: a periodic view of sensitive ERP actions and which ones ended up without the expected oversight. They do not replace Business Central's native change log; they complement it with a reading oriented to internal control.

In business terms, the value is concrete:

  • Early detection of deviations, not just reconstruction after the fact.
  • Less reliance on team memory or chasing scattered emails.
  • Operational evidence when Finance, Compliance, or audit ask what happened in a given period.
  • Closing the loop between designing a procedure and confirming it is actually applied.

Among the situations worth watching are those that keep appearing in recent BEC fraud β€” such as changes to supplier bank details β€” but also in perfectly avoidable operational errors.

What that company would do to close the loop

The answer would not be "more generic phishing training". It would be turning oversight into an operational habit.

1. Review exceptions regularly, not only at audit time

Compliance and Finance would agree on fifteen minutes each week to review sensitive actions that occurred without the expected control. The rule would be simple: every exception is investigated or justified. Nothing gets filed "for later".

2. Separate one-off cases from design failures

Of the seven unsupervised changes in the quarter, three might have a reasonable explanation (genuine urgency, new supplier in onboarding). Four would not.

At that point the conversation stops being "someone broke the rule" and becomes "our control is not operational enough". The response would not be a reprimand email, but strengthening the link between sensitive change and mandatory approval β€” the same approach we cover in our article on supplier bank account changes.

3. Keep evidence where the work happens

When a critical action does follow the intended procedure, the evidence should live in the same operational context β€” not spread across Teams, email, and individual memory.

It would stop being a conversation like "we trust that Marta reviewed it". It would become something Finance or Compliance can check without rebuilding the case by hand.

Three questions to tell if this sounds familiar

Before assuming "we've already got this covered", it helps to answer honestly:

  1. Do you know how many sensitive actions occurred in Business Central last month?
  2. Can you identify which ones did not follow the intended procedure?
  3. Does someone review that regularly, or only when an audit is approaching?

If any answer is no, the problem is not a lack of external regulation. It is a lack of continuous audit inside the ERP.

Compliance reports do not add bureaucracy for its own sake. They turn a question every CFO should be able to ask β€” what happened to our critical data yesterday, and was it overseen? β€” into something the team can look at, discuss, and fix in time.

Because in internal control, the worst scenario is not losing two million on a fraudulent transfer. It is discovering months later that the system flagged it β€” and no one was watching.

Want to implement this in your organization?

We help teams move from manual controls to structured, traceable governance inside Business Central.