AI Journal Entries and SOX: AI Considerations for Financial Statement Auditors

  Prof. Hernan Huwyler, MBA CPA CAIO · AI GRC Director · Academic Director, IE Law School

Published 11 November 2026 · Last reviewed 11 November 2026

In short

• Name who or what operates every AI-supported control step in the financial closing, then seed known errors into the review queue to prove a reviewer could actually catch mistakes.
• Reconcile what enters the model and what leaves it against ERP records, because a polished AI summary is not audit evidence of completeness or accuracy.
• Confirm vendor SOC reports cover the AI feature, give agents unique identities and posting limits, and approve prompt changes like code releases.

Consider a controller who opens a monthly report containing a significant number of AI-classified invoices, spends eleven minutes scrolling through the list, and signs the sign-off block. On paper, the control is executed and fully documented. In reality, it is incapable of detecting a single misclassification because the report displays no confidence scores, no anomaly flags, and no links to source documents. The moment an auditor asks what specific error that reviewer could have realistically caught, the illusion of control disappears.

This disconnect illustrates the core flaw in traditional human oversight of automated systems. When a manual check lacks the context, data sampling, and diagnostic tools to reveal operational errors, it produces audit documentation without providing actual risk mitigation.

Here is the short answer for SOX control owners and internal auditors. When AI touches financial reporting, treat it as a new operator inside controls you already have. Name the operator of each step and keep evidence that the review could change the result. The AICPA practice aid on AI considerations for financial statement auditors, issued on 13 October 2026, takes the same position: auditing standards are technology neutral, so the old questions still apply. The questions are the familiar ones: what could go wrong, and which control and evidence answer it.

This guide is for people who own or test controls over AI-supported processes. Think of AI-suggested journal entries, invoice extraction, close support, and agents that post into the ERP. The same logic covers tax determination and anomaly detection, though I use fewer examples there. The reader I have in mind is a SOX program manager or an internal auditor planning next year's scope.

The nine moves below follow the order you would work in. Find the AI, redraw the controls, test the human review, prove the data, control changes, restrict the agents, read vendor reports, widen the fraud and disclosure view, and package the evidence. Sources are the AICPA practice aid, a published audit firm guide on AI and automation in financial reporting, the COSO internal control framework, and for SEC issuers, PCAOB AS 2201 and Item 308 of Regulation S-K. Where a point is my recommendation and not a requirement, I say so.

Moves for Internal Auditors for AI Assurance

 By Prof. Hernan Huwyler, MBA CPA CAIO · AI GRC Director · Academic Director, IE Law School

Published 11 November 2026 · Last reviewed 11 November 2026

In short

• Build the AI inventory yourself from procurement, gateway, discovery and repository data, and register each system with an owner and risk tier.
• Treat vendor certificates as inputs: check scope, exclusions, date and auditor credibility, then test what you control, such as access, logging and change handling.
• Audit the approved performance envelope instead of single outputs, and run the kill switch and a seeded bad output to prove oversight works.

Walk into an audit committee meeting, and you will almost certainly hear the board ask one uncomfortable question: who is actually verifying the AI systems already running in our business?

Usually, the head of audit hands over a single spreadsheet from the data science team listing a dozen active tools. Deep down, everyone in the room knows the real number is higher, but nobody can pinpoint the actual count. That exact blind spot is where a real AI audit begins.

Auditing artificial intelligence does not mean throwing out classic audit principles. The core foundation remains the same: risk-based scoping, objective benchmarks, clear evidence, and independent review. What changes is the tech itself. Unlike traditional software, an AI system adapts to its environment and can quietly drift out of alignment without anyone making a code update. Auditors simply need to apply their standard discipline with much sharper focus, concentrating on two core questions:

• Where did the training data come from, and who owns the output when a model makes a mistake?
• How quickly will the team spot a failing model before it causes operational or financial damage?

This guide walks through a nine-step framework for auditors, risk leaders, and board members preparing to scope or execute an AI assurance review. Running from initial discovery through to final board reporting, this method evaluates the full AI lifecycle across four primary lenses: governance, security, third-party reliance, and model risk.

Governance Guide for AI-Supported SAP Platforms

By Prof. Hernan Huwyler, MBA CPA CAIO · AI GRC Director · Academic Director, IE Law School
Published 9 November 2026 · Last reviewed 9 November 2026

In short

• SAP Business AI brings together Joule, Joule Studio, the Knowledge Graph, the AI Gateway and the Agent Hub. These capabilities can help move agent governance from written policies into platform-level controls. It is important, however, to distinguish generally available features from roadmap items.
• Approving an AI agent is an authority decision as much as a technical one. Before deployment, define which actions the agent is allowed to perform, which business data it can access and where human approval is required, especially in finance processes.
• Demonstrate that an agent is both useful and controlled through auditable evidence. Track traffic through the AI Gateway, actions performed by agents, exceptions and the frequency of human intervention.

Monday morning, a business owner asks for Joule Work to be switched on for four thousand users by the end of the month. The request cites a vendor announcement, and nobody in the room can say which parts of that announcement are live, which are in early access, and which are plans. The SAP and AI Architects have one question: who approves what an agent is allowed to do inside the finance system?

SAP told its developer conference that the SAP Business AI Platform, with Joule Work, Joule Studio, the Knowledge Graph and Business Data Cloud, is available to customers. General availability of a platform does not mean your governance is finished. It means the tooling now exists, and the decisions about ownership, autonomy limits, evidence, and cost remain yours. Some items in the same announcement, including the Enterprise AI Gateway and the AI Governance Assistant for the EU AI Act, were described as new or planned, with early adopters first.

This guide is for AI architects, Chief AI Officers, SAP enterprise architects, internal auditors, SOX control owners, and AI product owners. It separates what SAP has said is live from what is announced, explains what the announcements change for SAP as a vendor, and walks through the controls to put in place before agents act on SAP data: the tabular prediction model, the gateway, the agent inventory, the approval path for new agents, and the measures that show whether the agents help.

Passkeys vs Passwords: Controls for Cyber Security Experts and Auditors

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 8 November 2026 · Last reviewed 8 November 2026

In short

• Passkeys are cryptographically bound to the legitimate website or service where they were created. They will not authenticate on look-alike phishing pages, providing phishing resistance that passwords cannot match.
• Passkeys do not eliminate every authentication risk. Account recovery, shared devices and legacy password fallbacks can remain weak points, so these paths need controls of their own.
• Prioritise controls according to their effectiveness and measure rollout success by protection coverage across high-value accounts, not simply by the total number of passkeys registered.

Picture a finance manager who types her password into a login page that looks exactly like her bank's. The attacker behind the page now holds a working credential, and she notices nothing until the transfer alert arrives. A passkey would have refused to answer that page, because the browser ties each passkey to the real domain where it was created. That single design property is why passkeys are more secure than passwords against phishing and remote attacks, and it is the reason this article exists.

The short answer for cyber security experts and risk owners is yes, with conditions. A passkey keeps a private key on the user's device and gives the website only a public key, so a breached server or a fake page has nothing worth stealing. What changes is where the attacker goes next: the phone in a thief's hand, the recovery flow, the cloud account that syncs the keys, malware on the laptop, and the old password that most accounts still keep alive. A recent TechRadar explainer by Mark Gill reaches a similar verdict. It calls passkeys an upgrade, warns against treating them as a cure-all, and names device access and platform lock-in as the main residual risks. This piece adds recovery, rogue enrollment and malware to that list and turns each gap into a control.

You can apply the nine controls below this week. They are ranked from most efficient to least, where efficient means the amount of risk removed for each hour of effort and each user you inconvenience. The first six suit any individual or small team. The last three matter most to security teams, administrators and anyone who builds a login. Each control names an owner and the evidence an auditor would ask for, so the work survives a review.

Controls to Prevent AI-Supported CEO/CFO Impersonation Frauds

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 8 November 2026 · Last reviewed 8 November 2026

In short

• Voice and video are no longer reliable proof of identity. In the widely reported Hong Kong case, criminals used an AI-generated video conference to impersonate colleagues and induce a transfer of approximately US$25.6 million.
• Effective protection depends on verification steps that cannot be bypassed through a convincing conversation. Require payment authorisation through an independent channel, callbacks to previously verified numbers and additional approval for new beneficiaries or unusual transfers.
• Make these safeguards part of tested operational controls, not just written policies. Run realistic impersonation exercises and measure whether employees consistently follow verification and approval procedures before releasing funds.

A finance employee at the Hong Kong office of a London-based engineering firm received a message from someone posing as the group CFO. The message mentioned a confidential transaction, and the employee suspected phishing. Then he joined a video call, saw the CFO and several colleagues on screen, and heard voices he knew. The doubt faded, and he sent 15 transfers worth HK$200 million, about $25.6 million, to five accounts. Hong Kong police said everyone else on that call was a digital fake, as CNN reported.

Looking harder would not have saved him. People flag well-made fake video poorly even when they are told to hunt for fakes, so a defense built on spotting the fake fails at the moment the fake is good. The controls that work keep the payment safe when the voice, the face and the paperwork are all perfect. At the top of the ranking sit a callback to a number you already hold, approval only inside the system of record, two approvers reached on separate channels, and a cooling period for new payees. This article ranks twelve controls from most to least effective and explains how AI builds the fake documents and fake video meetings those controls have to withstand. It is written for controllers, treasury leads, accounts payable managers and the CFOs whose faces get borrowed.

The Hong Kong case was not a one-off. In November 2026, US prosecutors announced an indictment of three people accused of stealing about $129 million from companies between July 2024 and February 2026, using CEO emails, AI-generated executive voices and impostor attorneys, as AP reported through PBS NewsHour. The charges are allegations, and the defendants are presumed innocent. The FBI's Internet Crime Complaint Center counted $3.05 billion in business email compromise losses for 2025, and for the first time it broke out complaints that referenced AI: 22,364 of them, with about $893 million in reported losses across all fraud types, according to coverage of the report.

Turning Fragmented Operational Risks into Decisive Business Action

By Prof. Hernan Huwyler, MBA CPA CAIO · Academic Director, IE Law School
Published 4 November 2026 · Last reviewed 4 November 2026

In short

• Operational risk is often assessed separately by departments using different methods, metrics and assumptions. This creates fragmented views that can hide how risks accumulate or interact across the organisation.
• A shared financial loss taxonomy provides a common language for comparing cyber, operational, safety and other risk exposures. It helps leadership understand potential losses across the business and prioritise them at portfolio level.
• Aggregation should not erase specialist knowledge. Preserve the assumptions behind each domain's assessments and make cross-domain dependencies and cascading loss scenarios visible when translating risk information into business decisions.

 

The transition from domain specific risk management to true enterprise risk quantification marks a fundamental shift in how organizations evaluate uncertainty and protect corporate value. Historically, departments have operated within isolated silos. Cybersecurity teams calculate system vulnerabilities, operational units log equipment failures, health and safety groups track physical workplace incidents, and corporate finance tracks liquidity and credit exposures. When presented to executive leadership or the board, these disparate operational domains are often aggregated into chaotic, color-coded heat maps that obscure real financial exposure.

Operational risk quantification solves this fragmentation by establishing a common currency across every corner of the business. By grounding risk analysis in a unified financial loss spectrum and consistent scenario modeling, risk leaders move away from abstract rating systems and deliver concrete decision support that protects corporate balance sheets.