PRACTICAL PLAYBOOK / CFO / INTERNAL CONTROL
A finance playbook for judgment and human oversight in AI
Move from principles to operation: select a use case, align authority and controls, test readiness, and prepare to stop and restart. Download the PDF playbook and editable Word templates in Thai and English.
An AI policy or an approval click does not establish that a process is controlled. This playbook extends DHISORA’s synthesis and four articles, translating judgment, human oversight, DOA and risk into activities, owners, decision criteria and evidence that can be monitored.
Start with a clearly identified process problem and a designated process owner, such as receipt-to-receivable matching or preparation of an accounting estimate. The process owner coordinates outcomes, participants and remediation within delegated authority; the role is distinct from the business proprietor and does not confer approval authority over every transaction.
Then assess whether benefits remain worthwhile after review time, rework and control costs. Choosing not to use AI, or limiting it to recommendations without autonomous execution, can be appropriate when evidence does not support a wider scope.
Read the executive synthesis before applying the playbook
Process responsibility, system responsibility and approval are distinct roles
In governance, an owner is an organisational role assigned responsibility for a specified matter. Identify whether the role concerns a process, system, risk or control rather than referring only to a “clear owner”.
Define the role, scope, authority, resources, deputy arrangements and escalation route. Naming a person in a table is insufficient. One person may hold several roles, subject to conflicts and self-review safeguards.
| Role | Responsibility | Duties and boundaries |
|---|---|---|
| Process Owner | End-to-end process responsibility | Coordinates outcomes, issues and improvements across the assigned process within delegated authority. This does not mean the business proprietor or the approver of every transaction. |
| System Owner | Responsibility for the supporting system | Coordinates system suitability and availability, access, changes and incidents. The role need not be the technical administrator or the process owner. |
| Risk Owner | Responsibility for an assigned risk | Monitors and manages the assigned risk, coordinates responses and escalates matters beyond authority. The role does not automatically permit acceptance of every level of risk. |
| Control Owner | Responsibility for an assigned control | Ensures assigned controls have operators, criteria, information and evidence, and follows up deficiencies. The role may differ from the person performing an individual check. |
| Preparer / Reviewer | Preparation / substantive review | The preparer assembles information and proposals. The reviewer checks criteria and evidence, challenges conclusions and follows up questions. Review does not automatically confer approval authority. |
| Authorised Decision-maker | Decision or approval authority | Decides only the assigned matters and conditions. Inadequate evidence or out-of-scope matters require a hold or escalation. Go-live approval differs from transaction approval. |
Turn working terms into concrete activities and conditions
These terms help organise work, but require named roles, timing, information, criteria and observable outcomes. The explanations are this playbook’s operating vocabulary, not universal statutory definitions.
| Term | Meaning in operation | Illustration |
|---|---|---|
| Use case | AI use for a specified activity and objective. | Proposing receipt-to-invoice matches, rather than merely “AI in accounting”. |
| Exception | An item outside normal criteria or with insufficient information. | A payer mismatch or two equal-value invoices requires a hold and investigation, rather than permission to waive policy. |
| Escalation | Route the matter and evidence to suitable expertise or authority. | Send an out-of-authority adjustment to the relevant DOA approver; do not automatically add one approval level to every matter. |
| Close an exception | Resolve the matter with a supported conclusion and accountable follow-up. | Confirm the payer, correct the match, assess related items and retain reasons; changing the status to “closed” is insufficient. |
| Override | An authorised departure from a system proposal or result under defined conditions. | Reject a proposed match because references conflict and record why; this is not unrestricted permission to bypass controls. |
| Stop trigger | An event or condition requiring suspension of a specified activity. | Incomplete source data stops automatic match acceptance and alerts the assigned role; verify that stopping works. |
| Fallback | A workable alternative with available information, people and time. | Use a tested manual matching method, checking pending and duplicate items before reintegration. |
| Baseline | Pre-change performance over a comparable period and scope. | Compare preparation and review time, rework and total costs; do not compare only AI generation time with the whole former process. |
| Cutoff / Write-off | Period allocation and writing off a receivable or difference are distinct matters. | Cutoff concerns the appropriate accounting period; a write-off requires the applicable conditions and authority. |
Define the outcome and prohibited actions
Create a use case card stating purpose, process, reporting period, owner, source data, systems or providers, and permitted AI actions. Separate recommendation, matching, posting, write-off and payment. “Automation” should not accidentally include all decision powers.
Inventory approved use and actual use outside the register, including information sent to external tools. Check entity requirements, financial reporting framework, confidentiality and access before selecting an approach.
Choose oversight and verify that it works
These terms are design vocabulary for this playbook, not a mandatory classification shared by all standards. European ethics guidance discusses HITL, HOTL and HIC; Australia’s DTA also defines HOOTL. We apply human-in-command as governance of goals, policies, boundaries and stopping, overlaying other operating arrangements. [9–10]
Consider impact, reversibility, speed of harm, detection, containment and reviewer capacity together. HITL can fail when reviewers lack time, information or competence. Where controls remain inadequate, reduce scope, redesign the process or suspend use.
| Arrangement | Designed activity | What must be verified |
|---|---|---|
| Human-in-the-loop | A person decides before a specified important action | Evidence and alternatives, time, competence and authority to reject |
| Human-on-the-loop | The system operates within boundaries under supervision | Signals reach the responsible person and intervention precedes unacceptable harm |
| Human-out-of-the-loop | No person participates in a specified execution cycle | Tested boundaries, ownership, monitoring and incident handling remain |
| Human-in-command | People set direction, authority, limits and system changes | Real authority and intervention mechanisms, beyond naming an owner |
Align authority with controls
DOA specifies who may decide what and under which conditions; RACI describes working roles; system permissions implement boundaries. A RACI “Accountable” role does not automatically confer legal signing or approval authority.
Approving a rule or operating scope does not replace transaction approvals reserved by law, policy or specific conditions. AI is not a person receiving delegated authority. Separate rule preparation or change, approval, and checking in proportion to risk, with safeguards for conflicting roles.
Management owns and operates controls. Risk and compliance functions support and challenge within their roles. Internal audit provides independent assurance. The audit committee has a governance role, rather than operating as a second-line function. [6]
Maintain a connected minimum evidence set
Use references that connect results to sources, risks, rules, decision makers and relevant versions. Documents need not all share one ID or a one-to-one relationship. Completed forms do not by themselves establish effective control.
| Record | Essential information | Role-based owner |
|---|---|---|
| Use case card | Permitted and prohibited actions, data, period, owner and expected benefit | Process owner |
| Risk and control matrix | Causes, events, impacts, control points, checks and evidence | Risk and control owners |
| Authority record | Decisions, rule changes, exceptions, stop and restart powers | Authorized DOA roles |
| Judgment record | Information, significant alternatives, contrary evidence, reasons and limits | Preparer, reviewer and decision maker within scope |
| Test and readiness record | Predetermined criteria, results, open issues and conditions | Tester and go-live approver |
| Incident and restart record | Affected scope, containment, correction and retesting | Incident owner and restart approver |
Test readiness against actual results
Distinguish design assessment, implementation and operation during the tested period. Set pass criteria in advance. Cover normal and exceptional items, missing or wrong-period data, access, version changes, failed alerts, stopping and fallback. Compare against independently validated outcomes; the previous method may also be wrong.
Use approved isolated environments for simulated faults, rather than inserting false entries into live accounts. Effective IT general controls do not establish that a particular matching or calculation rule is correct; test the logic used for decisions.
An authorized go-live decision considers test results, limitations and residual risks. Conditional approval needs an expiry, limits, monitoring owner and suspension triggers. Mandatory requirements cannot be replaced by risk acceptance. Do not relax criteria retrospectively merely to obtain a pass.
Design stopping and restart into operations
Assess exposure through execution rate, detection and stop latency, shared failures and reversibility, rather than item value alone. Financial limits do not replace privacy, fraud or other mandatory constraints.
| Stage | Activity | Decision evidence |
|---|---|---|
| Detect or receive a signal | Pause affected activities, restrict access or volume, and escalate | Timing, versions, potentially affected items and periods |
| Assess and correct | Look back, identify causes, correct entries and notify as required | Actual and uncertain impacts, corrections and owners |
| Test restart readiness | Verify fixes and related scenarios, including stopping again | Results, remaining limits and proposed scope |
| Authorize restart | An authorized person decides with closer monitoring where needed | Reasons, conditions, review date and owner |
A walkthrough from source information to decision and monitoring
Hypothetical example: two customers pay identical amounts and AI proposes invoice matches. Totals agree with bank records, but one match has a conflicting reference. The designed process must hold that item and route it for a competent, authorised decision before use.
The receipt process owner coordinates the whole process; the system owner coordinates relevant access and changes. A preparer validates sources, a reviewer examines assigned matters, and the authorised role approves posting or adjustments under DOA. Define these separately even where one person holds multiple roles.
| Stage | Required activities | Evidence or condition |
|---|---|---|
| 1 Validate inputs | The preparer checks counts, amounts, period, payer and source references. | Record the dataset and checks; agreeing totals alone is insufficient. |
| 2 Propose and screen | AI proposes matches; tested criteria hold conflicting items. | Retain proposals, failed conditions and actual system permissions. |
| 3 Review exceptions | The reviewer examines documents and confirms payer and invoice; unresolved matters are investigated. | Record sources examined, corrections, reasons and required escalation. |
| 4 Decide and execute | Reserved actions receive appropriate approval; authorised users execute within scope. | Distinguish match confirmation from posting, adjustments and write-offs. |
| 5 Monitor and respond | Check overdue exceptions and passed items; suspend specified actions when triggers occur. | Test alerts, stopping and fallback, and follow remediation to completion. |
An example of evidence supporting review and judgment
“Reviewed; agreed with AI” does not explain what was examined or why the proposal was accepted. For important matters, connect information examined to conclusions, including sources, findings, corrections, reasons and relevant limitations.
Hypothetical record: “Compared the bank item, receipt evidence and invoice. Amounts agreed, but the proposed reference belonged to another customer. Rejected the proposal and held the item pending receivables confirmation. With consistent evidence, submitted the corrected match to the relevant DOA role and retained sources and changes.”
This shows consideration of contrary evidence, rather than approval to post, write off or accept all risk. Identify preparation, review, approval and execution according to actual roles, with assigned follow-up and deadlines for unresolved questions.
Do not copy and sign this example without performing the checks. Routine items may use suitable structured records; judgment-intensive matters require greater explanation. Useful evidence supports assessment, without guaranteeing auditor reliance.
Two hypothetical finance examples
Expected credit loss: AI may organize data, explore scenarios and draft explanations. Decision makers assess methods, assumptions, forward-looking information and bias. Apply TFRS 9 when the entity and transactions fall within its scope; not every SME uses the same reporting framework. [7]
High-volume receipt matching: a proposed match is distinct from authority to post, write off or pay. Test control totals, duplicates, payer identity and references, including independent samples of items the system marks as passed. Equal totals can hide incorrect individual matches. Monthly retrospective review alone does not demonstrate timely HOTL intervention.
Records support review and assessment, but do not guarantee auditor reliance. Auditors independently assess and determine procedures under applicable standards, including TSA 330 and TSA 540 (Revised). [8]
Respect the status of each reference
Check version, scope, roles, system type and effective dates before describing obligations. Connecting frameworks in this playbook is DHISORA’s synthesis, not a legal compliance crosswalk or certification.
| Reference | Status | Use in this playbook |
|---|---|---|
| COSO and NIST AI RMF | Frameworks and guidance, rather than law or certification | Connect controls, assessment and monitoring [1–2] |
| ISO/IEC 42001 | AI management system requirements | Organize management; a reference does not establish certification [3] |
| EU AI Act | Law with defined scope and implementation dates | Check covered roles and systems; finance use is not automatically high-risk [4] |
| BOT policy of 12 September 2025 | Policy for financial service providers within its stated scope | Use the issued version, distinguish drafts and avoid extending it to every company [5] |
| IIA and TFAC standards | Professional roles and scoped standards | Distinguish roles and relevant accounting or auditing frameworks [6–8] |
Measure value after control costs
Before a pilot, establish a baseline for processing and review time, rework, escaped errors, overdue exceptions and total costs. Also assess explanation and traceability. Prompt counts or faster output production do not represent the whole value.
A low override rate can indicate good results or weak challenge. Read it alongside independent checks, information completeness and workload. A signature or framework label alone does not justify higher pricing; value should arise from better decisions and operating outcomes.
Download the bilingual playbook and templates
Read the PDF playbook with 12 practical chapters, two hypothetical cases and eight templates. For completion or adaptation, download the separate editable Word template pack. Both formats are available in Thai and English.
Public Reference Edition | Version 1.0.1 | 10 October 2026
This publication provides general educational guidance. It is not entity-specific advice, a legal opinion, an assurance report or system certification. Examples and templates must be adapted and reviewed against the entity’s facts, authority, risks and applicable requirements before use. Downloading does not constitute an advisory engagement or confirmation that DHISORA Advisory has accepted an engagement.
Reference use and internal template adaptation are permitted with source/version attribution and identified user modifications. Full public redistribution, adaptations for publication and commercial incorporation require permission, except where permitted by law. Read the notices in the files and the website-use terms. Scope and permitted use
Download the Thai playbook (PDF)
Download the English playbook (PDF)
Download editable Thai templates (Word)
Download editable English templates (Word)
Published 10 October 2026. DHISORA’s original proposals and templates support assessment and design; they are not legal advice, certification or an assurance report. Technical, security and legal work requires appropriate expertise where needed.
Questions to ask yourself
- When a shared AI failure affects many items, how soon will we know and what can we actually stop?
- Were readiness criteria set before the test results were known?
- What does each sign-off establish, and what remains unassessed?
- Do reviewers have adequate information, time and authority?
Start with a bounded process and evidence. Connect use case → risk → control → decision → test → monitoring. Expand when information and operating results justify it, with clear authority to stop and approve restart.