Designing an IFC framework for a mid-market company

Most mid-market companies discover their Internal Financial Controls (IFC) problem the same way: a statutory auditor asks for the RCM in week two of fieldwork, a spreadsheet nobody has touched in eighteen months gets emailed across, and then everyone spends the next three weeks pretending it was always current. The Companies Act 2013 is not ambiguous on this — section 143(3)(i) requires the auditor to report on the adequacy and operating effectiveness of IFC over financial reporting. For every company the Act applies to, this is a real statutory obligation, not a box to tick once and file away.

What follows is how I think about building an IFC framework that actually holds up — for a mid-market company or a newly acquired entity — without copying a 300-line Big-4 template that nobody in the organisation can operate.

The statutory baseline: what IFC actually requires

The relevant provision is section 143(3)(i) of the Companies Act 2013, read with the guidance note issued by the ICAI. The auditor must opine on whether the company has, in all material respects, adequate internal financial controls over financial reporting, and whether those controls were operating effectively as at the balance sheet date.

"Adequate" means the controls are designed to prevent or detect material misstatements in the financial statements. "Operating effectively" means the controls were actually functioning as designed during the period — not just documented as existing. This distinction between design effectiveness and operating effectiveness is where most mid-market frameworks quietly fail.

The scope is financial reporting — IFCoFR — which means the focus is on controls over the numbers that flow into the financial statements, not operational controls broadly. That scoping boundary is your friend: it keeps the framework focused and manageable.

The mid-market trap: two failure modes

Mid-market finance teams tend to fall into one of two traps when it comes to IFC.

The first is ignoring it until audit time. The thinking is that the company is small enough for the auditor to rely on observation, and a formal framework feels like enterprise overhead. This works until it doesn't — and when the auditor qualifies IFC adequacy, it becomes a board-level issue that takes far more time to fix under pressure than it would have taken to build proactively.

The second trap is the opposite: downloading a Big-4 RCM template — typically 250 to 350 control lines covering every sub-process of a global enterprise — and trying to apply it wholesale. The result is a document that lists controls nobody performs, owners who don't recognise the controls attributed to them, and evidence that has never been collected. This framework is, if anything, worse than none, because it creates a paper audit trail that diverges from operational reality.

The right design is neither. It starts from the actual transaction flows of this company, builds controls around the risks that are real and material, and encodes those controls in the ERP wherever possible so that evidence is a by-product of normal operations.

Start from process risks, not COSO theory

COSO is a useful conceptual framework. It is not a useful starting point for building an RCM for a company with a 15-person finance team. Start instead by walking the actual transaction cycles and asking, at each step: what can go wrong here that would cause a material misstatement?

The core transaction cycles to cover for most manufacturing or trading mid-market companies are:

• Procure-to-Pay (P2P) — from purchase requisition through vendor invoice to payment and GL posting
• Order-to-Cash (O2C) — from sales order through dispatch, invoicing, collections and AR ageing
• Inventory — receipts, issues, adjustments, physical count and valuation
• Fixed Assets — additions, disposals, depreciation, impairment and the FAR-to-GL reconciliation
• Payroll — master data changes, payroll computation, statutory deductions, disbursement and GL posting
• Financial Close & Reporting — journal entries, accruals, account reconciliations, consolidation adjustments and the eventual trial balance

For each cycle, map the sub-processes, then identify the specific risk at the financial-statement assertion level — completeness, existence/occurrence, accuracy, cut-off, valuation, rights and obligations, presentation and disclosure. An assertion-level risk statement is precise enough to design a control against. "Something could go wrong in procurement" is not.

Building the Risk Control Matrix

The RCM is the working document of the IFC framework. Every control that matters should live in it; every control in it should matter. Here is the column structure I use:

A few design principles that keep the RCM operational:

• One risk, one primary control. Secondary controls can exist, but every risk should have a clearly designated key control. If the same risk has four controls listed, nobody knows which one actually matters and all four get tested half-heartedly.
• The evidence column is mandatory and specific. "Manager reviews" is not evidence. "Purchase order approval email stored in Business Central purchase order header, approval workflow log" is evidence. If you cannot describe the evidence at design time, the control is not designed.
• Preventive over detective, automated over manual. A three-way match configured in the ERP that will not allow a vendor invoice to post without a matched GRN is stronger — and cheaper to operate — than a human reviewing a weekly exception report. Design controls in that priority order.
• Keep the RCM to 60–80 key controls. A mid-market company with clean transaction processing should not need more. If your RCM has 200 lines, you have listed activities, not controls.

Entity-level, process-level, and IT general controls

The IFC framework has three layers, and they interact. Understanding which layer a control belongs to determines how you test it and what failure in that layer implies.

Entity-level controls (ELCs) are the governance and tone-at-the-top controls — the board-approved delegation of authority matrix, the code of conduct, the financial close and reporting calendar, the audit committee oversight of financial reporting. ELCs are not sexy, but a deficiency at this layer has a pervasive impact: it can undermine the entire framework below it. Document them separately from the RCM and assess them first.

Process-level controls are the transaction controls in the RCM — the three-way match, the payment authorisation workflow, the payroll approval, the monthly bank reconciliation. These are specific to a process and to an assertion. A deficiency here affects only the financial statement areas covered by that process.

IT general controls (ITGCs) are the controls over the IT environment that underpins automated process controls. If your ERP is Microsoft Dynamics 365 Business Central — or any other system — the automated controls it enforces (approval workflows, posting restrictions, access limitations) are only as reliable as the ITGC environment around them. The four ITGC domains that matter for IFCoFR purposes are:

• Access management — who can access what in the system, on what basis, and how is that access reviewed and revoked when roles change
• Segregation of duties (SoD) — whether the system prevents the same user from both creating a vendor and approving payments to that vendor; whether the person who processes payroll is different from the person who approves it
• Change management — how changes to the ERP configuration, chart of accounts, approval thresholds, or posting rules are requested, approved, tested, and deployed
• Backup and availability — whether the system and its data are recoverable, which matters for the reliability of audit evidence stored in the system

If the ITGCs are deficient — say, a single superuser can approve and post their own transactions, or ERP configuration changes go live without an approval trail — then automated controls in the ERP cannot be relied upon as key controls, and you fall back to manual compensating controls, which are more expensive to test and less reliable.

Designing controls into the ERP so evidence is a by-product

The most efficient IFC design philosophy is: encode the control in the system, and the evidence writes itself. In Dynamics 365 Business Central, this looks like:

• Approval workflows — purchase orders above a threshold require sign-off from a designated approver before the PO is released; the approval log is embedded in the purchase order header with timestamp and user ID
• Three-way match — vendor invoices cannot be posted without a matched purchase order and a GRN; mismatches generate a tolerance exception that must be explicitly resolved
• Posting restrictions by period — periods are locked at close; no back-dating of transactions is possible once the period is closed, which eliminates one of the most common sources of cut-off error
• Access and role-based permissions — user roles are configured so that, for example, the accounts payable clerk can create invoices but cannot post payments, and cannot modify vendor master data
• Audit log / change log — Business Central's change log can be configured to capture changes to any field on any table; for sensitive master data (vendor bank accounts, customer credit limits, payroll data) this log is the primary evidence for an access management control
• Payment approval limits — payments above defined thresholds require dual approval in the system; the payment journal cannot be posted without the second approver's action being recorded

When controls are configured this way, the control is performing continuously, and the evidence is a system-generated by-product of ordinary transactions. You are not asking anyone to remember to sign a checklist. You are not reconstructing approvals from email at year-end. The ERP is generating timestamped, user-attributed evidence with every transaction.

A control you cannot evidence isn't a control — it's an intention. Automate the control into the system, and the evidence becomes free.

Testing: design effectiveness vs operating effectiveness

Testing the IFC framework is a two-stage process, and many mid-market implementations collapse the two stages into one, which means they only ever confirm that controls are documented, not that they worked.

Design effectiveness testing asks: is this control, as described, capable of preventing or detecting the risk it is assigned to? This is evaluated through walkthroughs — taking one or two real transactions end-to-end and confirming that each control step occurred as documented. A walkthrough confirms the plumbing is connected; it does not tell you whether water flowed through it all year.

Operating effectiveness testing asks: did this control operate as designed throughout the period? This requires sampling. For a key control that operates daily, an appropriate sample under IFCoFR standards is typically 25 items. For a monthly control, it may be the entire population. For a quarterly control, you test all occurrences. The key discipline is that sample selection must be independent — not the items the control owner helpfully pulls for you.

The most important practical discipline is continuous evidence. Finance teams that try to reconstruct IFC evidence in March for a March year-end audit are doing it wrong. Every month's close checklist, every quarterly access review, every approval log export should be saved at the time it occurs — not recreated. In Business Central, this means periodic exports of approval logs and change logs to a controlled folder, timestamped. Nothing more sophisticated than that, but it must be regular.

Prioritising by risk and materiality

Not every account balance and every transaction class warrants the same depth of controls. An IFC framework should be explicitly risk-stratified. The criteria I use to prioritise:

• Materiality threshold — controls over balances and transactions that are individually or in aggregate material to the financial statements are key controls; everything below materiality is lower priority
• Complexity and subjectivity — estimates and judgements (provisioning for doubtful debts, inventory NRV write-downs, depreciation useful lives) carry higher inherent risk and warrant detective controls and management review procedures
• Volume and repetition — high-volume transaction streams (vendor invoices, customer receipts) have lower per-transaction risk but aggregate to material amounts; automated controls are appropriate here
• History of error or adjustment — any area where the external audit has historically passed adjustments or raised differences is a red flag for control weakness; those areas deserve more, not less, attention

A focused 70-control RCM that covers the six transaction cycles, is genuinely operated and evidenced, and is reviewed by the CFO quarterly will satisfy the statutory requirement more robustly than a 250-control document that exists in a SharePoint folder nobody visits.

The annual IFC review cycle

IFC is not a one-time design exercise. Controls need to be reviewed when processes change — a new ERP module goes live, a new business line is added, a significant accounting policy changes. The practical cadence I recommend for a mid-market company:

1. Quarterly: Control owners confirm their controls operated as designed and evidence is filed. Access management reviews completed — user listings compared to active employee and contractor lists, exceptions resolved.
2. Half-yearly: CFO-level review of RCM — any process changes that require new or modified controls, any controls that have become obsolete, any emerging risk areas.
3. Annually (pre-audit): Full walkthrough testing of all key controls, operating effectiveness sample testing completed and documented, ITGC access log reviews completed. This package is what gets presented to the statutory auditor.

What good IFC actually looks like

When an IFC framework is working well, the finance team does not feel like it is doing "IFC work" separately from normal operations. The approvals happen in the ERP because that is how transactions are processed. The access reviews happen because the HR system triggers a notification when someone leaves. The monthly reconciliations are on the close checklist that runs every month anyway. The evidence is in the system because the transactions are in the system.

The statutory auditor's IFCoFR report is then a confirmation of what you already know, not a discovery exercise. That is the goal: a framework so embedded in operational process design that its outputs are a natural consequence of running the business properly, not an additional compliance workload imposed on top of it.

Good IFC is, mostly, good process design encoded in the system — and a discipline of never letting the evidence lag behind the reality.