Controlling the Agentic Finance Function

EXECUTIVE SUMMARY

Agents now read invoices, prepare accruals, apply cash, route exceptions, and initiate actions. Agents in procurement, sales, payroll, supply chain, and data platforms can also affect ICFR given that they affect transactions.

For ICFR, this is more than a technology change. It challenges four long-standing assumptions

• Judgment has a human owner;
• Systems behave deterministically;
• Segregation can be enforced through roles; and
• Change arrives through managed releases.

The Committee of Sponsoring Organizations of the Treadway Commission (COSO) remains a sound framework. But the unit of control is now the full agentic workflow: model, prompts, and configuration, governed data and transformations, tools and permissions, orchestration, independent validation, human review, evidence, and recovery.

Not every AI tool belongs in ICFR. An agent enters the control perimeter when it performs or supports a control, produces information relied upon by a control, initiates, authorizes, or records a transaction, changes relevant master or reference data, or can affect a significant account or disclosure.

Management should first: build the register; identify financially relevant workflows; set clear authority limits; qualify the full workflow before production; capture evidence as the work happens; and monitor material changes, including vendor and data pipeline changes.

THE SITUATION

The accrual journal entry — and the question of judgment

Each month an agent ingests service agreements, purchase orders, receiving data, and prior-period entries; identifies obligations; proposes accruals; and drafts support. Deterministic routines calculate amounts and reconcile the population; cases outside approved criteria route to reviewers, who concentrate on amendments, disputes, and novel arrangements. No material agent-generated amount reaches the ledger without independently designed validation, and every entry retains a source-to-approval trail.

The control question this workflow raises is about judgment: when the agent proposes both the entry and the rationale the reviewer reads, who is actually exercising the judgment the control was designed around?

Procure-to-pay — and the questions of authority and inputs

In payables, agents read invoices from monitored channels, extract fields, match them to purchase orders and receipts, propose account coding, flag anomalies, and draft discrepancy communications. Independent matching and tolerance checks release routine items to a payment proposal; exceptions route to people. The complexity sits in partial receipts, unit conversions, non-PO invoices, and timing differences — precisely where judgment, fraud, and cut-off risk concentrate. Two control questions follow.

• Where does the agent’s authority stop? — at proposing a match, correcting reference data, or touching the vendor master where payment fraud concentrates?
• How are externally supplied documents treated as untrusted inputs? An instruction embedded in a supplier file must not be able to expand the agent’s tools, permissions, or routing.

At period end, open purchase orders and unmatched receipts processed by the payables agent may feed the incurred-but-not-invoiced accrual. A receipt-matching timing error can therefore become a cut-off error in the estimate.

Procure-to-Pay (P2P) — SOX Process Flowchart with AI Touchpoints & Controls

Exhibit — Procure-to-Pay: AI touchpoints mapped to SOX control points (C1–C5).

Order-to-cash — and the question of segregation

In receivables, agents apply cash, prioritize collections, draft outreach, and propose dispute resolutions or credit memos. The messy cases — short payments, bundled remittances, missing references — are where the workflow’s authority and review design matter most.

If one system identity can propose, justify, and post a credit adjustment, it combines duties that the control design should keep separate. Customer-facing messages add immediate external exposure, so communication authority also belongs inside the control boundary.

Order-to-Cash (O2C) — SOX Process Flowchart with AI Touchpoints & Controls

Exhibit — Order-to-Cash: AI touchpoints, control gates, and segregation of duties.

Across the three workflows, the main control questions are the same: who is making the judgment, what authority does the agent have, can it rely on the information it receives and how is segregation of duties preserved?

The same questions arise in close, estimates, disclosures, payroll, inventory, treasury, tax, sales operations, and upstream data services.

They also show why agents cannot be treated simply as faster employees or as another system feature. They challenge four assumptions that traditional control designs rely on:

THE FRAMEWORK

COSO frames the implementation itself as a six-step loop — from establishing governance through to monitoring — that repeats as the agent estate grows. It is the program-build companion to the agent lifecycle above: the framework and lifecycle that follow work through each step in turn.

The table below shows where each step is developed in this paper.

COSO classifies GenAI by what it does. Products change; capabilities persist. Using shorter finance labels for the eight official categories, the sequence is ingestion, transformation, transaction processing and reconciliation, orchestration, judgment, monitoring, knowledge retrieval, and human-AI collaboration. This capability view is precise enough to describe and control any agentic workflow.

Start with significant accounts, disclosures, relevant assertions, and likely sources of misstatement; then identify which agent impacts this workflow. Capability is a design lens, not a substitute for assertion-level assessment. “AI in payables” is too broad. “A transaction-processing workflow affecting occurrence, accuracy, and cut-off of cash disbursements, with independent release authorization” is specific enough to design and test. In practice this classification is applied one workflow at a time in the inventory that opens the lifecycle (Section 5): each registered workflow is tagged by capability, and that tag drives its risk assessment and control design.

Rebuild segregation of duties on capability boundaries. The agent that interprets is separated from the one that posts; posting cannot alter reference data; and monitoring is sufficiently independent. In payables, the invoice-processing identity has no vendor-master write access, and payment release sits behind independent authorization and deterministic controls the proposing agent cannot satisfy or alter. In O2C, the proposing agent cannot authorize its own credit memo; posting occurs only after independently controlled approval. Separation is enforced across identities, tools, data, and configuration — not merely stated in policy.

Agentic components can change through more — and less visible — channels than traditional applications, increasing the evidence burden for continuity: immutable version and configuration records, change detection, requalification triggers, and operating telemetry.

How AI controls relate to ITGCs and application controls

AI-specific controls are not a third, mutually exclusive category. Relevant ITGCs govern the enabling environment: access to model endpoints and configuration repositories, authorization and deployment of changes, technology operations, interfaces, incidents, and third-party services. Automated application controls address transaction-level risks through reconciliations, matching, duplicate checks, authorization blocks, and completeness checks.

Controls over model qualification, prompts, retrieval sources, data provenance, drift, autonomous tool use, and human review address AI-specific failure modes. Depending on the objective, they may operate as general controls, automated application controls, or IT-dependent manual or management-review controls. The risk and control objective — not the label — determine how each control is scoped and tested.

The remaining principles still apply. The table above identifies where agentic work most changes control design, operation, and evidence.

THE LIFECYCLE

Our view of the agentic workflow follows 5 distinct steps:

This lifecycle operationalizes COSO’s six-step roadmap for financially relevant workflows, making change and retirement explicit because control evidence must survive repeated change and decommissioning.

Every agentic control program begins by finding what is already deployed: transformation-team workflows, SaaS features enabled by administrators, departmental experiments that became operational, and embedded vendor capabilities introduced through product updates.

One row per capability per workflow, classified against the eight-capability taxonomy of Section 2, is a practical starting point. Record the purpose; affected accounts, disclosures, risks, and assertions; authority; approved data, transformations, tools, and retrieval sources; model and configuration versions; shared dependencies; control reliance; lifecycle status; and named business, technology, control, and risk-acceptance owners. Use the enterprise register for the full agent population and document both in-scope and out-of-scope ICFR decisions. Periodically test the register for completeness.

Risk assessment then applies that capability lens to each workflow: from the affected accounts, disclosures, assertions, and materiality, it weighs authority, autonomy, reliance, reversibility, fraud susceptibility, volume, observability, and common dependencies. Controls scale accordingly: read-only drafting may need approved-source and review controls; posting, payment, master-data, or external-communication authority requires stronger separation, traceability, validation, and suspension and recovery. Bounded, observable, recoverable workflows generally make better first deployments.

The register is a living control. New agents must enter through it and material changes should trigger reassessments. An agent in use but absent from the register is a control gap.

Familiar ICFR qualification disciplines carry over but must be designed for variability introduced by agents. Before production:

• Test the full workflow. Cover data sources and population completeness, transformations, prompts and configuration, tool permissions, independent checks, exception routing, human review, evidence capture, and suspension, rollback, and recovery.
• Use a controlled evaluation library. Entity-specific cases with adjudicated answers, stratified to overweight material, rare, adversarial, and historically failure-prone items; version, restrict, and approve the set.
• Keep an independent holdout. A separate set, not used to tune the workflow and never exposed to developers, so repeated qualification does not become a test of memorized cases.
• Fix acceptance criteria in advance. Approve exit criteria before the evidence arrives, or deadline pressure will move them: agreement by risk stratum, with a higher bar for the high-materiality population; no new categories of error regardless of aggregate score; escalation behavior preserved within tolerance; full schema conformance; error weighted by materiality, not count; and cost within a defined envelope.
• Run in shadow before cutover. The agent processes live inputs, its outputs compared with the incumbent process, without touching the ledger, over a risk-based period covering representative activity, high-risk exceptions, and period-end conditions.
• Make cutover an evidenced approval. Business-owner sign-off supported by the qualification and shadow-operation evidence, followed by hypercare and re-baselined monitoring.
• Treat vendor evidence as input, not proof. A benchmark or assurance report may inform the assessment; neither establishes effectiveness for the entity’s control.

Regulation will continue to evolve. Companies can act now by applying existing ICFR, technology, vendor, and risk disciplines in proportion to the workflow’s use and risk.

Three disciplines define the operating stage:

Evaluating exceptions and deficiencies

When an agentic control exception occurs, management should assess more than whether an error reached the financial statements. Consider the control objective, the affected accounts and assertions, the population and period exposed, the risk of fraud, related control failures, and any compensating controls. Evaluate exceptions together when they arise from a shared model, data source, configuration, or workflow component. A detected error may show that a control worked; an undetected or uninvestigated pattern may indicate that the control environment needs further evaluation.

What this looks like in practice

For an ICFR leader, the test of any framework is whether it survives contact with the risk-and-control matrix. The exhibit below applies the six blocks to payables in control-description form, ready to adapt to the entity’s facts.

Everything to this point could be qualified once and operated indefinitely if the workflow held still. It will not — an agentic workflow changes through five principal channels.

• Prompts, configuration, and thresholds change at the entity’s initiative, under the configuration governance already described. This channel is manageable because it is visible.
• A model version may change on a provider-defined timetable. Govern the version change as a program change: qualify against pre-approved criteria, protect the close calendar, recalibrate thresholds, verify rollback, and retain prior outputs and evidence for the required period. A withdrawn version may not remain reproducible, so the historical record must stand on its own.
• The third channel is feedback-driven change. Even when the base model does not learn in production, reviewer corrections may update memory, retrieval stores, exemplars, or routing. Define what may update automatically; keep thresholds and authority under formal change control; review accumulated changes; and re-run qualification on a defined cadence.
• Behavior can also change behind a stable endpoint. Pin immutable versions where available; otherwise use a controlled probe that compares material attributes and structured conclusions with a baseline, using repeated runs where variability requires them. A probe triggers investigation and can narrow the exposure window; it does not prove the exact change date or cause.
• An upstream schema, mapping, transformation, semantic layer, or retrieval index changes while the model and prompt remain untouched. The control response is source-to-target reconciliation, schema-drift detection, versioned transformation logic and lineage, impact assessment across downstream consumers, and requalification when the change can alter a financial conclusion.

The sensible question after an agentic workflow change is whether a new control or a modification to an existing control operation is necessary. Such change does not automatically create a new control but management must assess whether model behavior is integral to how a key control prevents or detects misstatement. Where it is, the pre- and post- change configurations are distinct operating controls; a superseding control must operate for a sufficient period and the external auditor may still test the pre-change control when it matters to the financial-statement audit or control-risk assessment.

The COSO six-step roadmap does not name retirement as a discrete step; it sits implicitly within monitor-and-adapt. With models, vendor features, and tools now turning over quickly, decommissioning is a routine, recurring event rather than a rare one — which is why this lifecycle makes it an explicit stage with its own evidence obligation.

Agents leave service — workflows are redesigned, vendors change, capabilities consolidate. Retirement done casually leaves two exposures:

GOVERNANCE: MANAGEMENT AND THE AUDIT COMMITTEE

Agentic finance requires two connected layers of governance. Management owns the design and operation of the control environment. The audit committee oversees whether management has set appropriate boundaries, understands the exposure, and responds effectively when risk changes.

Management’s reporting should provide six recurring views.

• The exposure: built and embedded agents that can affect ICFR, including outside finance, with value and volume processed, autonomy, affected accounts and assertions, owners, and control status.
• The horizon: announced model retirements and platform releases, vendor evidence gaps, and the qualification or compensating-control plan for each.
• The changes: material model, prompt, configuration, tool, data, transformation, retrieval, and vendor changes, with qualification results and approvers.
• The incidents: boundary crossings, detected drift, unauthorized changes, correlated failures, open deficiencies, and remediation status.
• The assurance: balanced control and outcome indicators, workflows qualified or requalified, key-control evidence, and tested fallback readiness.
• The frontier: embedded agentic features enabled in systems of record, what provider assurance does and does not cover, and how management closes each gap.

These views let the committee ask the right questions: who set the agent’s authority; which accounts and controls rely on it; what happens when a shared provider or data pipeline changes; how management knows review remains substantive; and whether suspension and recovery have been tested.

QUESTIONS FOR MANAGEMENT

In Closing

Practice is still evolving in several areas. Management should revisit these questions as technology, control environment, and audit/control expectations develop:

Eight questions establish whether an organization is governing agentic workflows or merely running them.

• Can we produce, today, a register of every built or embedded agent that can affect ICFR — including agents outside finance — with capability, authority, ownership, approved data and transformations, and shared dependencies for each?
• For each agent that can post, pay, change master data, or communicate externally, can we state its authority limits and show the technical enforcement and independent authorization?
• Are end-to-end qualification criteria approved before testing, supported by an independent holdout, and repeated after relevant change?
• Could we trace any financially relevant output to its model, prompt, configuration, data snapshot, transformation, retrieval source, tools, validation, exceptions, and approval?
• Would we detect an unauthorized change or correlated failure in a model, prompt, shared component, schema, transformation, retrieval source, or embedded platform — and could we identify affected workflows, records, and recovery actions?
• Does a balanced scorecard reveal displaced human judgment, false negatives, aging exceptions, unauthorized actions, and control drift — and did management investigate material movement?
• If the reviewer of an agentic workflow were challenged to evidence their challenge — not their approval — could they?
• What feature-specific assurance do vendors provide, where are the evidence or continuity gaps, and how does management compensate or limit authority?

Organizations that can answer these eight with current evidence have turned agent adoption into a governed capability.

SOURCES, METHOD, AND ATTRIBUTION

This publication is a practitioner synthesis prepared from primary materials available through 17 August 2026. The three finance workflows are illustrative composites informed by advisory experience; they do not describe a single client or establish prevalence. The control patterns, interpretations, and recommendations are Uniqus Consultech’s own.

COSO’s Achieving Effective Internal Control Over Generative AI (GenAI) is the principal organizing source. Its five components, seventeen principles, eight capability types, and six-step roadmap are applied to financial reporting and extended here to end-to-end agentic workflows, authority boundaries, evidence, change, and recovery. The SEC’s ICFR rule and PCAOB AS 2201 anchor the discussion of ICFR scope, significant accounts and disclosures, relevant assertions, control selection, and deficiency assessment.

Regulatory-horizon references are deliberately limited. Federal Reserve SR 26-2 is banking supervisory guidance; its attached interagency guidance expressly excludes generative and agentic AI from scope while noting that existing risk-management and governance practices should inform controls for out-of-scope tools. The FSB’s June 2026 document is a consultation report proposing twelve sound practices, not a final standard. Both are used as directional evidence, not generally applicable requirements.

• COSO, Achieving Effective Internal Control Over Generative AI (GenAI), released February 23, 2026.
• PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements, as in effect at August 17, 2026.
• SEC, Management’s Report on Internal Control Over Financial Reporting and Certification of Disclosure in Exchange Act Periodic Reports, issued June 5, 2003.
• Federal Reserve, SR 26-2: Revised Guidance on Model Risk Management, April 17, 2026.
• Financial Stability Board, Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Consultation Report, June 10, 2026.

Examples, control designs, and policy positions are the authors’ interpretations. Organizations should adapt them to their facts, reporting obligations, risk profile, and applicable law.

Amrita Kapoor, Internal Audit, Snowflake, contributed perspectives on controls over the data layer, correlated failures and recovery, testing across model versions, and the relationship between AI controls, ITGCs, and application controls. Her affiliation is listed for identification only; the views expressed do not necessarily represent Snowflake Inc.