A manual nobody can search
It is the new controller's second week. The company's lender wants "the current accounting policies and procedures manual" for its annual review, and the only candidate is a 140-page Word file last saved in 2019. It names a bank the company left two years ago. It gives a former CEO a signing limit of $50,000. The wire procedure, which she finds on page 87, says to "confirm changes with the vendor by email." The example is illustrative, but none of its details are rare.
The manual exists, but nobody can use it. Nobody owns it, nobody can search it, and the one procedure that matters most would help a fraudster.
Write modules, not a book
A useful manual keeps two things apart. A policy states what is expected: "Two people release every payment above $10,000." A procedure says how the work is done: which bank portal role, which report, which reviewer, what evidence is kept. COSO's internal control framework draws the same line, with policies setting expectations and procedures putting them into action. Mixed together, they produce long paragraphs that nobody reads and nobody updates.
One module, one owner
Build every section on the same template, so a reader always knows where to look:
- Purpose and scope. What the section covers, and which entities, accounts or roles it applies to.
- Policy statements. Short, numbered, testable rules. Write "must", not "should".
- Procedure. The steps in order, with the system and role for each one.
- Evidence. The record that proves the control ran: a signed reconciliation, a callback log, a system approval.
- Exceptions. Who can approve a departure from the policy, and where it is recorded.
- Control block. Owner, approver, version, effective date and next review date.
Make it searchable
- Number every section and every policy statement (FIN-07.3), so people can cite them in tickets, emails and audit requests.
- Keep one list of defined terms. If "release" means the final approval in the bank portal, say so once.
- Put every approval limit in a single delegation-of-authority table and link to it. Limits copied into five sections will disagree within a year.
- Publish it where people already work, such as an intranet or wiki with version history, rather than as an email attachment.
- Keep a change log at the front: date, section, what changed, who approved it.
The table of contents
Copy this list, delete what does not apply, and assign an owner to each line before anyone starts drafting.
| No. | Section | What it must say |
|---|---|---|
| 00 | About this manual | Purpose, entities covered, how to read it, defined terms, owners, review cycle and change log |
| 01 | Delegation of authority | Every approval and signing limit in one table, by role and transaction type, plus matters reserved to the board |
| 02 | Policy exceptions | Who may approve a departure from any policy, how it is documented and how exceptions are reported upward |
| 03 | Conduct and conflicts | Annual conflict disclosures, how conflicts are reviewed and who must step aside from a decision |
| 04 | Related parties | Who counts as a related party, approval by people with no interest, and the log that feeds disclosure |
| 05 | Speak-up and investigations | Reporting channels, triage, who investigates, protection from retaliation and reporting to the board |
| 06 | Cash and banking | Opening and closing accounts, signatories, bank portal roles, positive pay and reconciliation deadlines |
| 07 | Payment verification | How payment instructions and bank-detail changes are verified, dual release limits and rules for urgent requests |
| 08 | Vendor master data | Documents required for a new vendor, who can create or change records, and removal of inactive vendors |
| 09 | Purchasing | Purchase order thresholds, when quotes or bids are required and who can sign contracts |
| 10 | Accounts payable | Matching rules, invoice approval, payment run preparation and review |
| 11 | Revenue and receivables | Customer setup, billing, credit memos, write-offs and cash application, each with its approver |
| 12 | Payroll | Who can add employees or change pay, review of every payroll register and rules for off-cycle payments |
| 13 | Expenses and company cards | Card-first spending, receipt and file standards, prohibited items and what approvers must check |
| 14 | Journal entries and close | Who can post entries, review of manual entries, the close calendar and reconciliation sign-off |
| 15 | Accounting policies | The policies the company has elected: revenue recognition, capitalization threshold, accruals, reserves and leases |
| 16 | Fixed assets and inventory | Tagging, counts, disposals and who approves write-downs |
| 17 | Financial reporting | The monthly management pack, the board pack, lender covenant certificates and who signs each |
| 18 | Budgets and forecasts | The budget calendar, approvals, reforecast triggers and the variance that requires an explanation |
| 19 | Grants and restricted funds | Allowability, time and effort, procurement and subrecipient rules where award terms require them |
| 20 | Tax filings | Which filings exist, who prepares and reviews each, and where outside advisers take over |
| 21 | Treasury and debt | Investment limits, borrowing authority, covenant monitoring and intercompany funding |
| 22 | Systems access | Requesting, approving and removing access, with a quarterly review of rights in the ledger, bank and payroll |
| 23 | AI use in finance | Approved tools, data rules, human review before posting, agent permissions and logging |
| 24 | Records retention | What is kept, for how long, where, and who authorizes destruction |
| 25 | Fraud risk and monitoring | The annual fraud risk assessment, the analytics that run and who reviews the exceptions |
| A | Appendices | Forms, the full approval matrix, the glossary and the review calendar |
Nonprofits with federal awards should treat section 19 as mandatory. Under 2 CFR 200.302, a recipient's financial management system must include written procedures for payments under 200.305 and for determining whether costs are allowable. Section 200.318 requires documented procurement procedures and written standards of conduct on conflicts of interest. Organizations that file Form 990 are also asked, in Part VI, whether they have written conflict of interest, whistleblower and document retention policies, so sections 03, 05 and 24 do double duty.
Two sections that cannot wait
AI use in finance
Finance teams already use generative AI to draft reconciliations, code invoices and summarize contracts, often before anyone has written a rule. COSO's February 2026 publication on internal control over generative AI begins with governance and an inventory of AI use cases, and it names shadow AI as a risk. Section 23 should say, at a minimum:
- Which tools are approved, for which tasks, and who approved them.
- Which data must never be entered, such as bank credentials, full account numbers, employee personal data, and unreleased financial results outside approved tools.
- That a named person reviews AI output before it is posted, paid or sent outside the company.
- That an AI agent or its service account is treated as a user. It gets the narrowest permissions it needs, and it never holds both the right to prepare and the right to approve the same transaction.
- What is logged (prompts, outputs and actions taken by agents) and how long the logs are kept.
A fuller version of these rules is in our AI governance policy for finance teams.
Payment verification
The Association for Financial Professionals reported on April 14, 2026 that 76 percent of US organizations experienced attempted or actual payments fraud in 2025. In November 2024, FinCEN alerted financial institutions to fraud schemes that use deepfake media (FIN-2024-Alert004). A payment-verification section written before either of those is probably too thin. Section 07 should state:
- A change to a vendor's bank details is confirmed by calling a number already on file, never a number supplied in the request.
- No payment is released on the strength of an email, voice message or video call alone, whoever appears to be asking.
- Payments above a set limit need two people to release them in the bank portal, and neither of them set up the payee.
- Urgent or confidential requests get more checking, not less, and the procedure names who to call.
- Every verification leaves a record: date, number called, person reached and result.
The controls behind these rules are covered in more depth in vendor bank-change fraud: five controls that stop it.
Keep it true after approval
A manual is accurate on the day it is approved. After that, people, systems and limits change. Three habits keep it honest.
- Review on a calendar. Each owner reviews their section once a year, and sooner when a system, role or limit changes. The change log shows that it happened.
- Ask for attestation. The people who run each process confirm every year that they have read their section and that it describes what they actually do.
- Test it against the ledger. Pull a year of payments and approvals and compare them with the delegation-of-authority table. A $14,000 payment approved by someone with a $10,000 limit is a finding about the control, and possibly about the manual.
Where to start
Write sections 01, 07 and 23 first. They carry the most risk and change most often, and the rest of the manual will refer back to them. If you want the modules drafted from how your team works today and checked against your own transactions, that is the scope of our financial policies and procedures work. To decide which other sections come next, the free controls health self-check shows where your current controls are weakest.