Finance process audit trail builder · free AI skill

Generates complete audit trail documentation for any automated finance process — including a field-level log schema, event capture map, retention schedule tied to regulatory drivers, reviewer access control matrix, and…

Purpose

Produce ready-to-implement audit trail documentation for a specific automated finance process — a log schema engineers can build to, a retention schedule tied to actual regulatory drivers, and an access control matrix auditors will accept. Solves the gap where finance automations run without defensible, reviewable evidence of who did what, when, and on whose authority.

When to Use

Invoke this skill when the user asks to:

Document the audit trail for an automated finance process (e.g., AP automation, revenue recognition, reconciliations)
Design logging and retention for a new finance automation before it goes live
Prepare audit trail evidence for a SOX walkthrough or external audit
Define reviewer access controls and segregation of duties for a financial workflow
Remediate an audit finding about insufficient logging or traceability

Inputs Required

Before starting, collect:

Process name and description: What the automation does, start to finish (2–4 sentences)
Process steps: The discrete stages, decisions, and hand-offs in the workflow
Regulatory/framework context: SOX, SOC 2, GAAP, IFRS, PCI-DSS, tax retention rules, or internal policy — whichever apply
Systems involved: ERP, database, workflow tool, or scripting environment where logs live
Actors: Human roles and system/service accounts that can trigger, approve, or modify actions
Materiality/risk level: High / Medium / Low — dollar thresholds or risk classification for this process
Existing logging: What is captured today, if anything

If regulatory context is not provided, default to SOX + SOC 2 controls for a public/audited company and note the assumption.

Instructions

Step 1: Map Auditable Events

Decompose the process into discrete auditable events. For each step in the workflow, identify:

Trigger events: What initiates an action (invoice received, threshold crossed, schedule fired)
Decision/approval events: Where a human or rule approves, rejects, or routes
Data mutation events: Any create, update, or delete of financial records
Exception events: Failures, overrides, manual interventions, retries

Produce an event map listing every event with its type. Every state change that affects a financial figure, approval status, or record must appear.

Step 2: Design the Log Schema

Build a field-level schema for the audit log. Every log entry must capture:

event_id: Unique, immutable identifier
timestamp: UTC, ISO 8601, with source clock note
actor_id: Authenticated user or service account (never anonymous)
actor_type: Human / System / Service Account
event_type: From the Step 1 event map
object_reference: The record, transaction, or document affected (with ID)
before_value / after_value: For any data mutation (redact PII/PCI fields per context)
authorization_basis: The rule, policy, or approver that permitted the action
source_system: Where the event originated
correlation_id: Links related events across systems in one process run

Present the schema as a table: Field | Type | Required | Description | Example. Flag which fields are sensitive and require masking.

Step 3: Define Retention Requirements

Set retention per record type, tied to its regulatory driver — not a blanket rule:

Map each log category to its governing requirement (e.g., SOX: 7 years for records supporting financial statements; tax: per jurisdiction; PCI: minimum 1 year, 3 months immediately available)
State the retention period, the driver, and the disposition method (archive vs. delete)
Specify immutability window: how long logs must be write-once/tamper-evident
Note legal hold override: retention pauses when litigation hold is active

Present as a table: Log Category | Retention Period | Regulatory Driver | Immutability | Disposition.

Step 4: Build the Reviewer Access Control Matrix

Define who can read, export, and administer the audit trail — enforcing segregation of duties:

Roles: List each role (Preparer, Approver, Controller, Internal Audit, External Auditor, System Admin)
Permissions: Read / Export / Configure / None — per role
SoD rule: No actor may approve their own action or edit logs of a process they operate
Least privilege: Admins can configure logging but must not be able to alter or delete existing entries
Access review cadence: How often access is recertified

Present as a matrix: Role | Read Logs | Export Logs | Configure Logging | Alter Entries (must be "No" for all). Follow with the SoD rules in prose.

Step 5: Specify Tamper-Evidence and Integrity Controls

State the controls that make the trail defensible:

Append-only storage or WORM configuration
Cryptographic integrity (hash chaining or signed entries) where risk level warrants
Separation of log storage from the operational system
Alerting on gaps, deletions, or clock discrepancies
Periodic integrity verification procedure

Step 6: Auditor Walkthrough Summary

Write a short narrative an auditor can follow: how a single transaction is traced end-to-end through the logs, which fields prove authorization, and how completeness is demonstrated.

Output Format

Structure: Six sections in order, with the schema, retention, and access controls as tables
Length: 1,000–1,400 words
Format: Structured document — tables for schema/retention/access, prose for event map and walkthrough
Sections: Event Map → Log Schema → Retention Requirements → Reviewer Access Control Matrix → Tamper-Evidence Controls → Auditor Walkthrough Summary
Tone: Controls specialist — precise, defensible, implementation-ready; every requirement traceable to a driver

Quality Checklist

Before delivering output, verify:

[ ] Every process step from the input maps to at least one auditable event
[ ] The log schema captures actor, timestamp (UTC/ISO 8601), authorization_basis, and before/after values
[ ] Each retention period cites its specific regulatory driver — no blanket "keep 7 years" without reasoning
[ ] The access matrix shows "Alter Entries = No" for every role, including admins
[ ] Segregation of duties rules explicitly prevent self-approval and self-audit
[ ] The auditor walkthrough traces one transaction end-to-end using named log fields

Notes

Data mutation events are the most audited and most often missing — before/after capture is non-negotiable for financial records
If the process involves PCI or PII, mask sensitive values in logs while preserving the object_reference for traceability
Retention conflicts (e.g., GDPR erasure vs. SOX retention) should be flagged, not silently resolved — surface them for legal review
For high-materiality processes, recommend hash chaining even if not strictly required; it is the cheapest way to prove non-tampering during an audit

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
<your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

Drag this file into a new chat, or copy and paste its contents
Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills