Our Finance System Is Failing and the Auditor Is Asking Questions: The System-Side Plan

Which part of an audit finding belongs to finance, and which part belongs to the system?

Most control findings arrive as one sentence in a management letter, but they contain two different pieces of work. One is the conversation with the auditor: how the finding is answered, what the remediation timeline is, which controls will be designed, who performs them and what evidence will prove they work. That belongs to the finance leadership, internal audit if you have it, and the audit firm. Frameworks such as the COSO Internal Control guidance are where that conversation usually starts, and Solzet gives no audit or accounting advice on it.

The other piece is the system: why the ERP allowed the thing the auditor found. A journal could be posted without review because no approval workflow exists. A prior month could be changed because posting dates were never restricted. Nobody can say who changed a vendor's bank account because nothing was logged. That half is configuration, security, integration and code, and it is the half an ERP team can fix.

What system causes usually sit behind control findings?

The findings differ by auditor and by company, but the system causes behind them repeat. Most finance systems that draw findings have two or three of these at once, and each one has a specific technical fix once it is named.

• Manual journals posted directly to the general ledger with no review step and no approval limit.
• Purchase orders, vendor invoices and payments released without an approval workflow, or with one that can be bypassed.
• No audit trail of changes to master data such as vendor bank accounts, customer credit limits or posting setup.
• Postings allowed into months that finance considers closed, because posting dates were never restricted per user.
• Shared logins and broad administrator roles, so one person can create a vendor, post the invoice and pay it.
• Integrations from CRM, payroll, banking or e-commerce that fail silently, leaving gaps or duplicates nobody reconciles.
• Customisations that post outside the standard posting routines, so the normal controls never see those entries.

What does an ERP assessment cover when the auditor is already involved?

The assessment starts from the findings themselves, not from a generic checklist. Each finding is traced to its system cause, and each cause is given a fix, an owner and a priority. The review covers configuration, security roles and user assignments, approval setup, posting date and period settings, logging, journal and posting patterns, integrations and their error handling, and any custom code that touches posting. The deliverable is a findings report with priorities and a stabilisation plan, written so that your finance team can share the system part with the auditor.

The assessment method is the one in our Dynamics 365 health check and technical audit, applied to the finance controls the auditor is asking about. Where an integration to finance is a black box nobody can explain, our guide to untangling a black-box integration before quarter-end close covers how to reconstruct it safely. Where records the auditor wants were never captured, reconstructing records when the evidence was never captured covers what can honestly be rebuilt and how to label it.

• Finding-to-cause map: every audit finding linked to the setting, role, integration or code that allowed it.
• Priority list: which fixes close the most serious findings first, and which depend on each other.
• Stabilisation plan: the configuration, security and integration changes, in order, with test steps.
• Platform view: whether the current ERP can enforce the controls, or whether a move is the cleaner route.

Should you stabilise the current ERP or move to Business Central or Finance and Operations?

Stabilising is often the right first step, because an audit cycle rarely leaves time for a new ERP. Many control gaps are settings that were never switched on. A move becomes the better route when the current system cannot enforce the control at all, when nobody can maintain it, or when the findings are only the visible part of a system the business has outgrown. Business Central suits small and mid-sized organisations; Finance and Operations suits larger, multi-entity organisations with deep supply chain, production or multi-country finance needs. The assessment gives the evidence for that decision instead of an opinion.

Which Business Central controls close the common findings?

Business Central has native controls for each of the common system causes. One detail matters for audits: in Business Central, accounting periods do not control posting dates. Posting dates are controlled by the Allow Posting From and Allow Posting To fields on the General Ledger Setup and User Setup pages, as Microsoft documents in Working with accounting periods and fiscal years. A company that closed its fiscal year but never restricted posting dates can still post into it.

Which Finance and Operations controls close the same findings?

Finance and Operations covers the same causes with its own tools, and adds a formal segregation of duties feature. Segregation of duties rules pair two duties that one person should not hold, and Microsoft notes that creating a rule does not check existing assignments: compliance has to be verified after each rule change. Ledger fiscal periods have statuses that control which periods accept postings, and the period close is set up so that finance, not individual users, decides when a month stops accepting entries.

What can the system side not do for you?

Be clear about this from the start, with your board and with your auditor. A system fix makes a control possible and provable; it does not decide whether the control is sufficient, and it does not close the finding. That judgement belongs to the audit firm. The system side also cannot invent evidence for past periods: if approvals were never recorded last year, configuring workflows now protects next year, not last year.

• Solzet does not communicate with the auditor on your behalf or advise on how to answer findings.
• Solzet does not judge materiality, severity or whether a deficiency is significant.
• Configuring a control does not mean the control is performed; people still review, approve and reconcile.
• Missing historical evidence can be reconstructed and labelled honestly, never backfilled as if it had been captured at the time.

How does Solzet work alongside your finance team and the auditor?

Solzet's own senior consultants run the assessment and the stabilisation work, with your finance lead as the owner of the controls. We document every change so that it can be shown to the auditor: what was configured, why, how it was tested and where the log evidence sits. Where the stabilisation plan leads to a move, we implement Business Central or Finance and Operations, including Dynamics 365 Finance, and design the controls into it from the first configuration.

When sales data reaches finance from a CRM, the same team covers that side too: Dynamics 365 Customer Engagement, Power Platform, or a custom-built CRM for organisations that would rather not carry Microsoft licensing, with the integration to the ERP designed by one team.