A construction draw is due, the church is waiting on funds, and the loan officer is working from a spreadsheet that was updated by someone else. At the same time, an ACH file is ready for release and a vendor has sent new banking instructions. Under that pressure, a “quick approval” can become a payment error, an audit exception, or a fraud event.
A maker checker approval process gives CEFs a practical way to prevent one person from creating and releasing a high-risk transaction alone. The maker prepares the entry and evidence. The checker independently validates it. A reviewer handles exceptions and higher-risk decisions. When the workflow is configured around actual loan draws, escrow releases, investor notes, and cash operations, it protects both the organization's funds and its ministry mission.
Why Most Approval Workflows Fail Before They Begin
A loan officer at a community development financial fund once pushed a $145,000 contractor disbursement without a second person reviewing the release. The wiring instructions had been changed in a phishing email two days earlier. The bank recovered most of the funds, but the controller still had to record the weakness in the next SOC report.
That failure wasn't caused by a missing policy. It happened because the system allowed a single actor to move a high-risk payment from preparation to release. The maker-checker model exists to make that exposure structurally impossible, especially when a transaction involves payments, beneficiary changes, or other sensitive financial instructions. Industry guidance describes the model as a two-person workflow in which one person initiates a transaction and another independently reviews and authorizes it, with both actions recorded for auditability (maker-checker control guidance).
Practical rule: An approval that happens after release is documentation, not prevention.
The three gaps that repeat
Weak implementations tend to fail in familiar ways:
- Shared access: A maker and checker use a shared mailbox or common login, so the audit trail can't prove independent action.
- Unreachable thresholds: Approval limits are set so high that ordinary loan draws, ACH releases, and vendor changes rarely enter the control.
- Off-system exceptions: A manager gives verbal approval for a deadline-sensitive payment, but nobody records the decision back in the ledger.
These aren't unusual edge cases. They occur when a policy is designed separately from daily operations. A CEF may have a strong written segregation-of-duties policy while still allowing the same employee to prepare a draw, change the beneficiary, and release the payment through a separate banking portal.
Workflow software can help, but automation doesn't repair an undefined control. Teams evaluating technology can use a practical overview of 2025 workflow automation software to compare routing, permissions, and audit features. The selection should follow the control design, not replace it.
The control should also be measured correctly. Counting approval clicks tells you little. A better measure is whether the process prevented or resolved exceptions, preserved traceable approvals, and stopped unsupported overrides. Historical four-eyes practices have been used for decades in administrative and financial settings, with one published account tracing related error-prevention review practices to 1927 at Bell Labs (industry history of maker-checker controls).
Defining Maker, Checker, and Reviewer Roles
The role definitions should fit the transaction, not merely the organization chart. In a CEF, the maker usually originates the entry and attaches the evidence needed to support it. That might be a loan file, construction draw request, escrow instruction, vendor change ticket, investor confirmation, or approved payment batch.
The checker works independently. This person confirms the documentation, amount, payee, effective date, account, and applicable threshold. The checker either approves the entry or returns it with a reason code that tells the maker what must be corrected.
The reviewer is the escalation point. This role handles exceptions, overrides, unusual values, threshold breaches, and unresolved disagreements. The reviewer must not also act as maker or checker on the same record.
A working segregation-of-duties matrix
| Role Combination | Status | Rationale |
|---|---|---|
| Loan officer as maker, Controller as checker for a standard disbursement | Permissible | The originator and independent financial approver have separate responsibilities. |
| Construction administrator as maker, senior credit officer as checker for a draw above the defined threshold | Permissible | Operational evidence and credit authorization are separated. |
| Maker also serving as checker | Prohibited | One person can't independently validate their own work. |
| Checker also releasing the payment | Prohibited | Review and execution should remain separate for high-risk disbursements. |
| System administrator configuring workflows and approving transactions | Prohibited | The person controlling permissions shouldn't approve the resulting financial activity. |
| Same individual completing draw inspection sign-off and disbursement approval | Prohibited | Inspection evidence and payment authorization require independent review. |
| Reviewer serving as maker or checker on the same record | Prohibited | Escalation loses its independence when the reviewer participated in the original decision. |
| Two authorized checkers releasing a high-risk ACH file | Permissible where configured | Dual authorization adds a second release gate for a file with broad payment impact. |
A Controller can hand this matrix to HR, IT, and the system administrator as a starting point. User permissions should reflect it directly, with separate accounts, individual credentials, and role changes that require documented authorization.
The same discipline supports seamless payment workflows explained, but payment speed shouldn't come from removing review. It should come from routing clean transactions quickly while sending exceptions to the right person.
For a broader explanation of the control principle, see segregation of duties in finance operations. The practical test is simple: can an auditor identify who prepared the transaction, who checked it, who released it, and who handled any exception without relying on an email chain?
The Lifecycle of an Approved Transaction
A transaction should move through visible gates, with each gate preserving evidence and preventing unauthorized edits. Consider a $250,000 investor note rate change.
Seven stages from origination to archive
- Origination: The maker creates the record and attaches the note amendment, investor confirmation, and effective date.
- Evidence capture: The signed amendment, board resolution excerpt, and prior rate schedule are uploaded. Version locking prevents a document from being swapped after approval.
- Threshold routing: The system applies the dollar amount and risk tier. The entry may require a checker, dual authorization, or reviewer escalation.
- Checker review: An independent approver validates the agreement, rate, dates, and accrual impact. A returned entry must carry a reason code.
- Exception path: A change above fifty basis points routes to the reviewer with a memo explaining the deviation and its business justification.
- Release: After all required approvals are recorded with timestamps and user identifiers, the system releases the transaction to the core ledger or outbound file.
- Lock and archive: The final record becomes immutable, supporting documents are sealed, and the audit log retains maker, checker, and reviewer identifiers for reconciliation.
Keep the decision visible
The controller shouldn't have to pull a note amendment from one system, approval emails from another, and ledger history from a third. A practical implementation binds the maker and checker to the same transaction, stores evidence in the workflow, and locks the approved artifact after sign-off. Guidance on audit-ready transaction reporting recommends recording user identifiers, draft and submitted statuses, approval timestamps, action details, and record identifiers as immutable evidence (audit-ready maker-checker workflow guidance).
Each stage should appear on one transaction timeline. That timeline lets the Controller reconstruct what changed, who reviewed it, what exception arose, and when the entry reached the ledger or payment file.
Handling Construction Draws and Escrow Releases
Construction draws expose weak controls because the supporting evidence arrives in pieces. A church may submit the draw request before the inspection report is finalized, while the project manager is pressing for payment to keep contractors moving.
Take a $750,000 church construction draw. The project manager acts as maker and submits the request. The approval packet should include the inspection certificate, original construction budget, prior draw ledger, and AIA-style application. The system should stop the entry from reaching the checker until the required documents are present.
Four gates for a construction draw
Gate one, request creation. The maker enters the requested amount, project, borrower, payee, and draw purpose. The maker shouldn't be able to approve the request or release the funds.
Gate two, inspection and budget tie-out. The inspection report is compared with the work completed and the original budget. The prior draw ledger is reviewed for cumulative disbursements, remaining availability, and potential duplicate billing.
Gate three, checker verification. An independent checker reviews the complete packet, investigates budget variances, confirms the inspection basis, and verifies that the proposed release agrees with the loan terms. If the CEF releases less than the full requested amount, the checker should require an explicit reason code, such as incomplete work, unsupported cost, or reserve protection.
Gate four, reviewer release. A reviewer signs off when the draw is partial, carries an exception, or exceeds the configured per-file limit. Retention also needs separation. The maker can calculate or document the retention amount, but the checker should independently confirm it before release. The same person shouldn't book the retention and authorize its payment.
Escrow requires a related but distinct sequence. The borrower submits the request, the escrow officer reconciles the loan balance and reserve requirements, and the checker confirms the disbursement against the closing protection letter. A reviewer releases wires that exceed the per-file threshold. CEF teams should also maintain a separate escrow reconciliation process so the approval record and the escrow balance agree after settlement.
High-Risk Transactions That Need Stricter Controls
Some transactions deserve more than a routine maker and checker route because one error can affect many records or move funds outside the organization. The right response isn't to make every employee approve everything. It is to apply dual authorization and reviewer escalation where the impact is concentrated.
ACH file release
The maker assembles the NACHA file and records the file hash. A second maker, or designated file verifier, reconfirms the payment count and total against the approved batch. Dual checkers release the file before the bank cutoff, while a reviewer handles any single payment above the high-value threshold or any mismatch between the file and the approved batch.
The file itself should be treated as the released artifact. If someone regenerates it after approval, the new file needs a new review. A screenshot of a bank portal isn't a substitute for an approval record tied to the exact outbound file.
Investor note rate changes
The maker proposes the new rate and effective date. The checker validates the investor agreement, prior rate schedule, and accrual schedule. A reviewer should approve any change greater than 25 basis points, or any change affecting more than the defined note count.
The system should calculate the downstream impact before release. That includes future accruals, investor statements, and any reporting output. A rate amendment that looks small in a spreadsheet can create a broad reconciliation problem if the effective date is wrong.
Vendor master updates
The maker submits the request with the W-9 and OFAC screening evidence. The checker validates banking details through a callback to a trusted contact, not the contact information supplied only in the change request. A reviewer approves a new vendor above the defined spend threshold or any change to existing vendor banking details.
| Transaction Type | Maker Responsibility | Checker Requirement | Reviewer Trigger |
|---|---|---|---|
| ACH file release | Assemble and hash the file, then tie totals to the approved batch | Reconfirm file contents and authorize release | High-value payment, total mismatch, or file exception |
| Investor note rate change | Propose rate, effective date, and supporting amendment | Validate agreement and accrual schedule | Change above 25 basis points or affecting more than the defined note count |
| Vendor master update | Submit W-9, screening evidence, and change request | Validate bank details through an independent callback | New vendor above the defined spend threshold or any banking change |
A related fraud benchmark from the Association for Financial Professionals found that 63% of companies experienced check-fraud attempts in 2024 (AFP check-fraud benchmark reference). That figure concerns check fraud, not ACH or vendor changes, but it reinforces why payment controls still deserve operational attention.
Audit Trails, Evidence, and Reconciliation
An approval log must prove more than the fact that a button was clicked. It should capture the maker identifier, checker identifier, exact timestamp at each gate, reason code, supporting document hashes, and final released artifact.
Once the checker approves, the supporting file should be locked. If a document must change, the organization should create a documented reversal or correction entry that routes through the same dual authorization. Replacing the file destroys the connection between the evidence reviewed and the transaction ultimately released.
What the audit packet should contain
During a SOX review, investor reconciliation, or regulatory examination, auditors commonly ask for evidence that the control operated as designed. Prepare a packet that includes:
- Approved draws: The complete request, inspection evidence, budget tie-out, approval history, and released amount.
- Rejected entries: The original request, rejection reason, return timestamp, and subsequent disposition. Rejections shouldn't be deleted.
- Segregation report: A report proving no user appeared as both maker and checker on the same record.
- Configuration snapshot: The threshold and routing settings in effect when the transaction was processed.
- Released artifact: The exact ledger entry, ACH file, or payment record that received final authorization.
The approval record should remain queryable for the full audit window and should outlive the active loan file where retention requirements call for longer preservation. Audit trail best practices for financial operations provide a useful reference for structuring that evidence.
Reconciliation then becomes a comparison between approved intent and posted result. The Controller can match the approved amount, payee, date, and artifact identifier to the general ledger, bank activity, investor subledger, or escrow balance without reconstructing the transaction from disconnected spreadsheets.
Tuning Thresholds and Reviewing Exceptions Monthly
A maker-checker approval process isn't installed once and forgotten. The Controller, CFO, and senior operations staff should review the prior month's exceptions, overrides, stalled items, and any dual-authorization bypasses granted for time-sensitive releases.
Start with the exception log. Group entries by investor draws, vendor edits, ACH files, escrow activity, and other meaningful categories. A large volume of ordinary items waiting for a checker may indicate that the threshold is too low. A small exception population concentrated in unusually large or sensitive transactions may show that the threshold is too high.
A monthly control review
Review the operating evidence in a consistent order:
- Rejected transactions: Identify recurring reason codes and fix the source documentation or user guidance.
- Override activity: Confirm that every override had an authorized reason and a complete follow-up record.
- Approval bottlenecks: Examine the time from maker initiation to checker release, same-day clearance, and items aging past 48 hours.
- Threshold design: Adjust dollar limits, risk tiers, and reviewer levels based on transaction volume and loss history.
- Access permissions: Test role provisioning, terminated users, temporary access, and administrator privileges.
- Policy record: Document changes and calendar the next review.
The framework should be tuned quarterly when dollar thresholds, reason-code lists, or reviewer tiers need a more formal adjustment. Monthly review identifies the pattern. Quarterly governance makes the change defensible.
Control insight: Measure prevented or resolved exceptions and traceable approvals, not the raw number of approval clicks.
Publish the dashboard to the operations committee. The record should show why a threshold changed, who approved the change, which roles were tested, and whether the next review date is on the calendar. That visibility matters in a mission-focused organization because staff need enough speed to serve churches without turning urgency into an undocumented bypass.
CEFCore can hold the related approval, cash, loan, investor note, and reconciliation records in a unified financial workflow, including configurable approval queues for transactions above designated thresholds. A CEF preparing to operationalize the process should confirm that role provisioning, reason codes, exception logs, locked artifacts, and review dates are all tested before relying on the workflow in production.
CEFCore gives CEF teams a unified place to manage loan disbursements, investor notes, cash and ACH operations, reconciliation, and maker-checker approvals. Visit CEFCore to review how the platform can support a traceable approval framework for construction draws, escrow releases, and other high-risk financial transactions.
