Level 4 taught a firm to govern AI. Level 5 is about building the part that acts. A drafting assistant suggests; an automation does. It requests documents from a new client, rolls a filing calendar forward, reads a bank feed, proposes a journal entry or prepares a payment run, and when it is wrong the error has already reached a client, a ledger or a return by the time anyone looks. This level teaches automation whose authority is bounded in writing, whose every action is recorded, and whose failures are caught by design. No coding is assumed or required.
The first three modules set authority and build the first orchestrations. Module one places every proposed automation on an authority ladder from suggesting to acting, treats excessive agency as the design risk to engineer against, writes the agent authority register by capability type, and names the acts that never go to an agent: signing, filing, paying and certifying. Module two automates intake and document requests while a partner decides acceptance and scope, routes the firm's section 7216 consents and service provider notices rather than drafting them, and surfaces independence issues for a partner to decide. Module three explains why an automated deadline alert is never the last line of defence, runs the filing and extension calendar with a named owner and a second check, catches consents that expire on recurring engagements, and closes an engagement without dropping a thread.
Modules four to six are the connections and the money. Module four maps every system, flow and owner an automation touches, decides at each boundary whether a recipient may receive tax return information without consent, writes a data contract for the boundary, and classifies missing, malformed, drifted and supply-chain data failures. Module five connects to the general ledger or ERP read-only first, separates proposed entries from posted ones with posting under a named approver, explains what changes for public-company clients under management's internal control over financial reporting, and shows what a SOC 1 report can and cannot tell you and where hosting a ledger for an attest client impairs independence. Module six draws the line at payment release, adds the automation to the segregation-of-duties matrix as a role of its own, sets approval thresholds, holds every payee and bank-detail change for independent verification, and defends payment workflows against impersonation, tool misuse and stolen credentials.
Modules seven to nine are human control. Module seven designs approval gates that produce a real decision, guards against both rubber-stamping and discounting good output, orders what the reviewer sees, and budgets gate load through busy season. Module eight gives every automation its own identity and owner, limits privilege by task and by the trust of the data it reads, enforces client segregation for software as for staff, and protects the people who administer automations with strong multi-factor authentication and periodic access reviews. Module nine sets stop triggers and who may pull them, builds stops that do not depend on the model, keeps client work moving on a manual route, and requires evidence before an automation resumes.
Modules ten to twelve are defence and observation. Module ten threat-models vendor invoices, client uploads and inbound mail as carriers of instructions, from the defender's side only, reads the 2026 OWASP list without its superseded numbering, and teaches prompt injection as a residual risk that design limits but no filter removes. Module eleven specifies the agent action record, separates it from the professional record of how AI was used and checked, keeps return information, credentials and client content out of the log, and sets retention and integrity where no US rule fixes the period. Module twelve catches confident wrong output before it becomes an entry, detects drift after model, vendor, data and terms changes, treats a changed model as a changed control, and sets cost limits and alerts a named person acts on.
Module thirteen applies the CSF 2.0 model of NIST SP 800-61 Rev. 3 to detecting, declaring, containing and recovering from an automation incident, separates the notice clocks that may follow, and runs the review afterwards. Module fourteen measures time, quality and cost against a baseline, removes double-counted savings, sets honest billing for automated tax work, and designs the capstone, the Automation Implementation Project: one bounded automation in a fictional firm, from baseline and pilot to stop criteria and a recorded decision on standard practice. The level ships with a printable workbook and nine templates, and the examination draws forty scenario questions from a reviewed bank.
Statements of authority are labelled throughout as law or rule, professional standard, professional guidance, best practice, emerging practice, or an AI Coalition Network recommendation, with whom each binds. Voluntary frameworks such as the NIST AI RMF and the OWASP lists are never presented as law, and requirements for issuer and non-issuer clients are kept apart.
Everything here is professional education. It is not tax, accounting, audit, legal or security advice, it does not replace the professional standards, SEC and IRS rules or state board requirements that govern accounting, tax and attest work, and learners must check the rules that apply to their own licence and practice. Completing the level earns an independent educational certificate issued by AI Coalition Network with a public verification page. It is not a CPA licence, carries no professional education hours, and does not satisfy any state board of accountancy requirement.