Research
Segregation of Duties for Outsourced Finance Coordinators
How to split initiation, approval, recording, custody, and reconciliation in a small offshore finance lane without losing speed.
On this page
Key stats
Segregation of duties separates authorization, record keeping, custody of assets, and reconciliation so that no single person can complete a material transaction without an independent check.
Methodology
This note draws on the GAO Standards for Internal Control and the NIST Cybersecurity Framework to examine a Philippines-based finance support lane. It maps a transaction lifecycle, identifies the duties that should be separated, and describes compensating controls for small teams. The analysis is a control-design reference, not an audit opinion or a statement of legal compliance. The test is whether a second person could reconstruct and challenge a material decision from the record.
Evidence summary
Start with the transaction lifecycle rather than the org chart. A vendor payment moves through request, approval, vendor master maintenance, payment execution, recording, and reconciliation. Each step is a duty, and the risk is not only who performs it but who can change the underlying record. A coordinator who can add a vendor and approve an invoice has effectively combined two duties even if a different person clicks the final pay button.
The strongest split is between initiation and approval. The person who prepares a payment request should not be the person who authorizes it, and the approver should see the source document rather than a summary. In a small team, the client owner can approve while the coordinator prepares. That is a real separation as long as the approver checks the evidence and does not simply forward the request back with a one-word reply.
Vendor master data deserves its own control. A change to bank details, tax information, or legal name is a high-risk event because it redirects money or changes the record future payments depend on. Require an independent call-back or a second document, a named approver, and a log of the old and new values. Do not let the same person who requests the change also verify it, even if the workload is tight.
Recording and reconciliation should be separated from execution where possible. The person who runs the payment file should not be the only person who reconciles the bank statement. If the team cannot separate the roles, the client should review the reconciliation and sign it. An independent review of the match between the payment record and the bank line catches a duplicate, a wrong amount, or a payment to an unexpected recipient.
Small teams need compensating controls, not pretend separation. Options include a second reviewer on a sample, a mandatory vacation or rotation, a system-enforced approval limit, and a monthly review of access rights. The control should be written down with the person who performs it and the evidence it leaves. A control that exists only in a conversation disappears when the person who remembers it is on leave.
Test the design with an adverse case. Ask what would happen if a coordinator received a convincing email asking to change a vendor’s bank account on a Friday afternoon. Trace the path: who would verify the request, which document would be required, who could approve, and what would appear in the log. If the answer depends on the coordinator’s judgment alone, the control is not yet designed. Fix the path before the real request arrives.
Access rights are part of the control. A coordinator who cannot see the payment file cannot execute a payment, even if the process says approval is required. Review who can create a vendor, who can edit a bank field, who can release a payment, and who can export the ledger. Remove rights that are not used in the current lane, and record the review, because the design is only as strong as the permissions behind it.
The client side of the control needs a named person, not a general mailbox. An approval sent to a shared address may sit unread while the coordinator waits, and the resulting delay encourages shortcuts. Name the approver, the deputy, and the response window in the account plan. If the client cannot meet the window, agree on a lower-risk fallback such as holding the payment until the next cycle.
Reporting should show the control working, not just the volume processed. Track approvals by tier, same-person exceptions, master-data changes, and reconciliation differences. A clean report with no exceptions may mean the control is effective or that nobody is recording the exceptions. Sample a few transactions behind the numbers to tell the difference, because the report is a prompt for review rather than a certificate.
Monitoring is a duty too. Someone should review the approval queue, the failed-payment report, and the reconciliation exceptions each day, even when the volume is low. A quiet day is a good time to check a sample rather than assume the control is idle. Record the review, the reviewer, and any item that needed escalation. The routine is what keeps a control alive between audits, and a sample of five items is usually enough to show whether the quiet is genuine.
Transaction lifecycle
Map request, approval, master-data change, execution, recording, and reconciliation for each finance lane. Assign a role to each step and mark where the same person appears twice. The map is more useful than a policy statement because it shows the actual path a transaction takes.
Initiation and approval
Keep preparation and authorization in different hands, and require the approver to see the source evidence. A summary can hide a missing invoice, a changed bank detail, or a duplicate request. The approval record should name the approver, the date, and the document reviewed.
Master-data changes
Treat vendor bank, tax, and legal-name changes as high-risk events. Require independent verification, a second document or call-back, and a log of the old and new values. The person who requests the change should not be the only person who verifies it.
Compensating controls
When the team is too small for full separation, use a client review, a sample check, rotation, or a system limit. Write each control with an owner and the evidence it leaves. A control that depends on memory is not a control, and a control nobody tests is only a hope.
Adverse-case test
Walk a fraudulent or mistaken request through the lane and see where it is caught. The test should cover a changed bank account, a duplicate invoice, an after-hours request, and an approver who is unavailable. Record the gaps and fix the path before the next live transaction.
Access and permissions
Map who can create, edit, approve, release, and export for each finance system. Remove rights outside the current lane and record the review. A process that assumes separation while the same account can do every step is not a control. Test the permissions with a real user, not only a matrix.
Reporting and sampling
Report approvals by tier, same-person exceptions, master-data changes, and reconciliation differences. Then sample the transactions behind the report. A clean summary can hide an unrecorded exception, and a long exception list can show that the control is finally visible. Use the sample to correct one rule or one permission each cycle.
FAQs
Can a two-person finance team separate duties?
Not completely, but it can separate preparation from approval and add a client review or sample check. The key is to document the compensating control and the evidence it leaves, rather than claiming a separation that does not exist.
Who should approve a vendor bank change?
A person independent of the request, with access to the source evidence and the authority to accept the change. A second document or a call-back to a known contact reduces the risk of a fraudulent redirect.
How often should access be reviewed?
At onboarding, at any role change, and on a regular schedule that fits the risk. A quarterly review is common for finance access, but the important part is that the review is recorded and that removed access is verified.
What if the client cannot review every payment?
Use a risk-based sample and a lower approval threshold for the rest. The client should still own the policy and the exception decision, while the coordinator prepares the evidence. A written sample plan is stronger than an informal promise to check when time allows.