What the work produces
We document selected processes, walk through evidence and distinguish design gaps from failures in operation. Recommendations identify an owner, practical action and evidence that the control can produce.
Agree the process boundaries first: for example, supplier setup through payment, sales through collection, payroll changes, inventory movements or period-end journals. The output can include a process map, identified risks and controls, evidence observations and a prioritised action register.
Each finding explains the expected control, what was observed, the supporting evidence and the practical consequence. A missing record is distinguished from evidence that an unauthorised transaction occurred; the report should not treat these as identical conclusions.
Inputs to organise
- Process descriptions
- approval matrices
- system access lists
- sample transactions
- reconciliation logs
- exception reports
- prior incidents.
Identify process owners and the people who perform or check each step. Provide actual examples of ordinary and exceptional transactions, including overrides and rejected items where available. Explain recent system or staffing changes that may make an older procedure description inaccurate.
Use appropriately restricted access to records and permission reports. A process review does not require casually sharing passwords or granting unrestricted production access; agree the evidence-access method with the system owner.
What good records help you see
If the same person can create a supplier and approve its payment, a policy document alone may not address the risk. Review actual permissions and compensating checks.
- Walk through a transaction from initiation to recording and settlement.
- Identify who performs, approves and checks each step, including exceptions.
- Compare the stated process with the available approval and system evidence.
- Discuss gaps with the process owner and distinguish an absent control from a control that was not performed.
- Agree a practical action, accountable owner and evidence expected when the action is implemented.
Example: a small team cannot fully separate supplier setup from payment preparation. The review can examine whether an independent approval and change review operates in practice. The recommendation should describe what the check covers and the record it produces, rather than adding an approval box that nobody uses.
Agree the boundaries
This is a scoped process review, not a forensic investigation or blanket assurance that fraud cannot occur.
Confirm the covered entities, periods, systems, deliverables and fees before work starts.
Specify whether the work covers control design, selected operating evidence, implementation support or a later follow-up. Document any sampling and access limitations. Management decides and implements remediation; a recommendation being accepted does not establish that the changed control is operating.
The handover retains open actions, dependencies and any residual concerns. Where a change requires configuration or migration work, scope it through finance systems implementation rather than treating it as completed within the review.
Kosha.Services · Updated 2 October 2026

