Start with the financial risk and the existing workflow

Map how a transaction moves from request to approval, recording and payment. Identify where errors or unauthorised changes could occur. Focus first on material risks and recurring failures rather than producing a large policy manual with no practical owner.

Review purchasing, supplier changes, payments, payroll changes, journals and reconciliations as relevant to the business. Understand the actual system permissions and staffing constraints before designing an approval that nobody can perform.

What does a useful financial control look like?

A control needs an objective, a named operator, a frequency and evidence of completion. Separate preparation and review where feasible. In a small team, an appropriate additional management review may address a gap, but its limitations should be understood.

  • Define approval limits and the transactions they cover.
  • Document who can change payment or master data.
  • Agree reconciliation deadlines and review evidence.
  • Record exceptions, follow-up owners and escalation routes.

A policy describes the rule. A procedure explains the steps. A record shows whether the control actually operated. Each serves a different purpose.

Example: changes to supplier bank details

A proposed process could require an authorised person to verify a change through a previously established supplier contact, retain evidence and obtain a separate approval before the payment details are updated. The reviewer should be able to see the original request and verification record.

This is an illustrative design to adapt to your systems and risks. An email requesting a change is not, by itself, independent verification. No individual control eliminates all fraud risk.

Implement, pilot and review the controls

Agree priorities and responsible owners. Walk through selected transactions with the people doing the work, document the procedure and pilot it in the real workflow. Check that the required evidence is easy to retain and that holiday cover is addressed.

Review operation after rollout, log exceptions and revise unclear steps. Software can support an approval but does not decide who should have authority. Configuration changes and access grants should follow your authorised system administration process.

What a controls implementation project can deliver

  • A prioritised risk and control register.
  • Documented approval and review responsibilities.
  • Practical procedure notes and evidence templates.
  • An implementation tracker and handover session.
  • A defined follow-up review where included in scope.

This is implementation support, not independent assurance or a certification. Connect oversight to governance processes and preparation evidence to audit readiness. Start with the process causing concern; scope and fees depend on the systems, risks and required involvement.

Your questions, answered.

Do controls require a large finance team?

No. Controls should reflect the business and available staff. Where duties cannot be separated, additional review can be considered and its limitations documented.

Can you implement controls in existing systems?

The work starts with your current workflow and system capabilities. A system replacement is not assumed, and configuration responsibilities are agreed separately.

Does this provide independent assurance?

No. Designing or helping operate controls is different from independently assessing them. Any assurance engagement needs a separate scope and appropriate independence.