Financial Compliance Sox

Financial Compliance — SOX

Overview

SOX (Sarbanes-Oxley Act) Section 302 and 404 require publicly traded companies to maintain documented internal controls over financial reporting (ICFR). For e-commerce, this means implementing controls across the order-to-cash and procure-to-pay cycles: segregation of duties (no single person can initiate and approve a financial transaction), approval workflows for high-value transactions, automated reconciliation, and immutable audit evidence. SOX compliance is primarily a process and documentation challenge, not a software challenge — but the systems you build must generate auditable evidence that controls are operating.

When to Use This Skill

• When your company is preparing for an IPO and must establish SOX-compliant ICFR
• When external auditors are requesting evidence of IT General Controls for your e-commerce platform
• When building approval workflows that demonstrate segregation of duties
• When designing access controls for systems that feed financial statements
• When remediating a material weakness or significant deficiency identified by an auditor

Core Instructions

Step 1: Map your financial data flows and control points

Before any configuration or code, document which systems contain financial data and what controls apply. SOX auditors want to see this documentation:

Order-to-Cash control points:

• Order entry → Payment capture → Revenue posting
• Key controls: approval for high-value orders, fraud rules, GL auto-posting, monthly reconciliation

Procure-to-Pay control points:

• Purchase order creation → Invoice matching → Payment release
• Key controls: 3-way match for POs above threshold, dual approval for large payment runs

Document each control with: 1. Control objective (what risk does this control mitigate?) 2. Control owner (which role performs this control?) 3. Frequency (continuous, daily, monthly, per transaction) 4. Evidence (what record proves the control operated?)

Step 2: Platform-specific SOX implementation

---

Shopify

Shopify does not provide SOX-specific tooling, but you can implement key controls using platform features and third-party integrations.

Access controls (segregation of duties): 1. Go to Settings → Users and permissions 2. Configure staff account permissions — Shopify allows granular permission scoping:

• Separate "can issue refunds" from "can edit orders" from "can access reports"
• Create separate accounts for each staff member (no shared admin credentials)

3. For stricter SOD, use Shopify Plus organizations to manage permissions across stores

Approval workflows for high-value orders: Shopify does not have native approval workflows. Use Shopify Flow (Shopify/Plus) to create a hold-and-notify workflow: 1. In Shopify Flow, create a trigger: Order created 2. Add a condition: Order total > $10,000 3. Add an action: Add a tag "pending_approval" and send an internal email/Slack notification 4. Your team reviews and either manually removes the tag and fulfills, or cancels the order 5. Log the approval decision as an order note (for audit evidence)

Reconciliation: 1. Use Shopify's Finances → Payments report to see all payment captures, refunds, and payouts 2. Download monthly reports and reconcile against your payment processor's (Stripe, PayPal) settlement reports 3. Document any variances with explanations — this is your reconciliation control evidence

Change management evidence: For Shopify theme and app changes: 1. Use a version-controlled theme development workflow (GitHub) 2. Require pull request reviews before deploying theme changes 3. Document app installations and permission grants in a change log

---

WooCommerce

WooCommerce gives you more control over role-based access and custom approval workflows.

Role-based access (segregation of duties): 1. Install User Role Editor or Members plugin 2. Create separate WordPress roles with specific WooCommerce capabilities:

• Order Viewer: can view orders, cannot edit or refund
• Order Processor: can update order status, cannot refund
• Finance Manager: can issue refunds, cannot create orders
• Auditor: read-only access to all reports, cannot make any changes

3. Assign staff to roles; no single person should have both "create order" and "issue refund" capabilities

High-value order approval workflow: Install WooCommerce Order Approval (free) or YITH WooCommerce Order Approval (~$70/year): 1. Configure an approval threshold (e.g., orders over $10,000 require manual approval) 2. The plugin holds the order in "Pending Approval" status 3. A designated approver receives an email notification and can approve or reject in the WooCommerce admin 4. Approval decision and approver name are logged in the order notes (audit evidence)

Audit logging: Install Simple History (free plugin) to capture all WooCommerce admin actions with user attribution, timestamps, and before/after values.

Monthly reconciliation: 1. Export WooCommerce order totals by month (WooCommerce → Reports → Orders) 2. Download Stripe/PayPal settlement reports for the same period 3. Reconcile totals; document variances; store evidence in a shared compliance folder

---

BigCommerce

User access controls: 1. Go to Account Settings → Users → Add User 2. BigCommerce supports role-based access with granular permissions 3. Create roles aligned to SOD requirements: separate Order Processing from Refund Authorization from Report Viewer

Approval workflows: BigCommerce does not have native approval workflows. Options:

• Use BigCommerce Webhooks to trigger an approval process in an external workflow tool (Zapier, Monday.com, or a custom app) when a high-value order is created
• Manually hold high-value orders via a custom order status and a standard operating procedure

Reconciliation: Use the BigCommerce Analytics → Revenue report and compare against your payment processor settlement. Export both as CSV and document the comparison monthly.

---

Custom / Headless

For custom storefronts, implement the controls programmatically. The three most critical controls for a SOX audit are: segregation of duties enforcement, approval workflows with evidence capture, and automated reconciliation.

Segregation of duties — role model:

enum FinancialRole {
  ORDER_ENTRY      = 'order_entry',
  ORDER_APPROVER   = 'order_approver',
  CASH_RECEIPTS    = 'cash_receipts',
  PO_REQUESTER     = 'po_requester',
  PO_APPROVER      = 'po_approver',
  PAYMENT_INITIATOR = 'payment_initiator',
  PAYMENT_APPROVER = 'payment_approver',
  AUDITOR          = 'auditor',  // Read-only — zero transaction capability
}

// SOD conflicts — these role combinations are prohibited
const SOD_CONFLICTS: [FinancialRole, FinancialRole][] = [
  [FinancialRole.PO_REQUESTER,       FinancialRole.PO_APPROVER],
  [FinancialRole.PAYMENT_INITIATOR,  FinancialRole.PAYMENT_APPROVER],
  [FinancialRole.PO_REQUESTER,       FinancialRole.PAYMENT_APPROVER],
  [FinancialRole.ORDER_ENTRY,        FinancialRole.ORDER_APPROVER],
];

function hasSodConflict(roles: FinancialRole[]): { conflict: boolean; pairs: [FinancialRole, FinancialRole][] } {
  const conflicts = SOD_CONFLICTS.filter(([a, b]) => roles.includes(a) && roles.includes(b));
  return { conflict: conflicts.length > 0, pairs: conflicts };
}

// Enforce SOD when assigning roles
async function assignRoles(userId: string, newRoles: FinancialRole[], assignedBy: string) {
  const { conflict, pairs } = hasSodConflict(newRoles);
  if (conflict) {
    throw new Error(`SOD conflict: ${pairs.map(([a, b]) => `${a} + ${b}`).join(', ')}`);
  }
  await db.userRoles.setRoles(userId, newRoles);
  // Log to immutable audit trail
  await auditLog.record({ eventType: 'user_roles_changed', actorId: assignedBy, aggregateId: userId,
    afterState: { roles: newRoles }, controlRef: 'SOX-ITGC-AC-001' });
}

High-value order approval control:

const HIGH_VALUE_THRESHOLD_CENTS = 1_000_000; // $10,000

async function processOrderApproval(orderId: string, approverId: string) {
  const order = await db.orders.findById(orderId);
  const approver = await db.users.findById(approverId);

  if (order.total_cents >= HIGH_VALUE_THRESHOLD_CENTS) {
    const hasRole = approver.roles.includes(FinancialRole.ORDER_APPROVER);

    await auditLog.record({
      eventType: 'high_value_order_approval_check',
      aggregateId: orderId,
      actorId: approverId,
      afterState: { orderTotal: order.total_cents, hasApprovalRole: hasRole, outcome: hasRole ? 'pass' : 'fail' },
      controlRef: 'SOX-OTC-001',
    });

    if (!hasRole) throw new Error('ORDER_APPROVER role required for orders above $10,000');
  }
}

Monthly reconciliation automation:

async function runMonthlyReconciliation(month: Date) {
  const [ordersRevenue, processorSettlements] = await Promise.all([
    db.orders.sumRevenue(month),
    paymentProcessor.getSettlementsForMonth(month),
  ]);

  const varianceCents = ordersRevenue.totalCents - processorSettlements.totalCents;
  const outcome = Math.abs(varianceCents) <= 100 ? 'pass' : 'exception'; // $1 tolerance

  await auditLog.record({
    eventType: 'monthly_revenue_reconciliation',
    aggregateId: month.toISOString().slice(0, 7),
    actorId: 'system_recon_job',
    afterState: { ordersRevenue: ordersRevenue.totalCents, processorSettlements: processorSettlements.totalCents, varianceCents, outcome },
    controlRef: 'SOX-OTC-RECON-001',
  });

  if (outcome === 'exception') {
    await alertFinanceTeam(`Reconciliation exception: ${varianceCents / 100} variance for ${month.toISOString().slice(0, 7)}`);
  }
}

Quarterly user access review:

async function generateQuarterlyAccessReview(quarter: string) {
  const financialUsers = await db.users.findWithFinancialRoles();
  const report = {
    quarter,
    generatedAt: new Date().toISOString(),
    users: financialUsers.map(u => ({
      userId: u.id, email: u.email,
      roles: u.financialRoles,
      lastLogin: u.lastLoginAt,
      dormant: !u.lastLoginAt || u.lastLoginAt < new Date(Date.now() - 90 * 86400000),
      sodConflict: hasSodConflict(u.financialRoles).conflict,
    })),
  };
  report.exceptions = report.users.filter(u => u.dormant || u.sodConflict);
  // Route to manager for sign-off with 30-day deadline
  await routeForManagerApproval(report);
  await auditLog.record({ eventType: 'quarterly_access_review_generated', aggregateId: quarter,
    actorId: 'system', afterState: { exceptionCount: report.exceptions.length }, controlRef: 'SOX-ITGC-AC-002' });
  return report;
}

Best Practices

• Document controls before automating them — write a one-page control description (objective, risk mitigated, owner, frequency, evidence) before building the code; auditors read documentation first
• Make control failures throw exceptions, not log warnings — a SOX control that logs a failure and allows the transaction to proceed is worse than no control; preventive controls must block the transaction
• Use immutable audit log storage — grant the application role only INSERT on the audit table; revoke UPDATE and DELETE; use an append-only log service as a secondary store
• Log the control reference ID on every audit event — when an auditor requests evidence for Control SOX-P2P-002, a single query filtered by control_ref should return all evidence
• Automate the quarterly access review — manual reviews are the most common control deficiency; automate report generation and route to managers with a deadline
• Test controls in staging quarterly — run a mock walkthrough; submit a sample transaction through each control and verify the evidence is captured before auditors test in production

Common Pitfalls

Related Skills

• @financial-audit-trail
• @pci-dss-compliance
• @account-security
• @data-retention-policies

Financial Approval Controls for Order and Payment Processing

Problem/Feature Description

NovaTrade is an ecommerce marketplace preparing for its first external financial audit. The audit committee has flagged two gaps in their transaction controls: large wholesale orders can be fulfilled without any management sign-off, and the accounts payable team can release payment batches to vendors without a second reviewer. These gaps represent material risks that auditors expect to see addressed with automated, traceable controls.

The head of engineering has been tasked with implementing two preventive controls that block transactions from proceeding when they don't meet approval requirements, and ensure every control decision is captured in a structured, queryable evidence log. The controls must be implemented at the service layer so they cannot be bypassed by calling the API directly. Each log entry must carry enough information for an auditor to understand what happened, who was involved, and whether the control passed or failed — without needing to consult any other system.

Output Specification

Produce a TypeScript implementation in src/ that includes:

1. A FinancialControlEvent interface and an FinancialAuditLog class that writes control events to a store. The log must be designed so that entries cannot be modified after writing. 2. A function implementing the high-value order approval control: orders meeting a specific monetary threshold require a user with the appropriate approval role; the function should throw a typed error if the check fails. 3. A function implementing the large payment run control: payment runs meeting a specific monetary threshold require at least two distinct approvers; the function should throw a typed error if the check fails. 4. Both control functions must write to the audit log on every invocation (pass or fail), including the relevant control reference ID.

Write a controls-design.md file that lists each control, its monetary threshold, what role or approval count is required, and what error type is thrown on failure.

Do NOT use any external HTTP APIs or cloud services in your implementation — use in-memory or mock storage so the code can run standalone.

Financial Access Review and Auditor Evidence Package

Problem/Feature Description

Frontier Payments is a payments infrastructure company that recently received a letter from its external auditors requesting evidence for two IT General Controls: a quarterly review of who holds financial system access, and an exported evidence package for a specific control covering the last fiscal quarter. The audit engagement partner noted that the previous year's review was done manually in a spreadsheet, and several stale accounts were missed — resulting in a significant deficiency finding. This year, the controls need to be automated and generate machine-readable evidence.

The compliance engineering team needs to build two capabilities: first, a report generator for the quarterly user access review that surfaces any accounts requiring attention from managers; second, an evidence export function that an auditor can run to pull all recorded control events for a given control reference over a specific date range. The company's security team has also flagged that the audit function must be completely separated from the ability to perform financial transactions. All of this needs to be documented clearly so that a new team member — or an auditor — can understand the controls without reading the source code.

Output Specification

Produce a TypeScript implementation in src/ that includes:

1. A quarterly access review function that, given a quarter identifier, returns a report containing: all users with financial roles, their last login date, whether each account is dormant, whether each account has any role conflicts, and a separate list of exceptions (dormant or conflicted accounts). 2. An evidence export function that accepts a control reference ID and a date range, retrieves all matching control events, and produces a structured report object with a summary section (total events, pass/fail/exception counts) and a detail section (all individual events). 3. A controls-documentation.md file that documents: the quarterly access review control (objective, who runs it, frequency, what evidence it produces), what constitutes a dormant account, and why the AUDITOR role must never hold transaction permissions.

Use in-memory or mock data — no external services or databases required.

Input Files

The following file provides sample user data to use as mock input for the access review function. Extract it before beginning.

=============== FILE: inputs/users.json =============== [ { "userId": "u001", "email": "alice@frontier.com", "name": "Alice Tan", "roles": ["po_requester", "order_entry"], "lastLogin": "2026-01-15T09:00:00Z", "active": true }, { "userId": "u002", "email": "bob@frontier.com", "name": "Bob Okonkwo", "roles": ["po_approver"], "lastLogin": "2025-09-30T14:22:00Z", "active": true }, { "userId": "u003", "email": "carol@frontier.com", "name": "Carol Reyes", "roles": ["payment_initiator", "payment_approver"], "lastLogin": "2026-02-28T11:00:00Z", "active": true }, { "userId": "u004", "email": "dan@frontier.com", "name": "Dan Novak", "roles": ["auditor"], "lastLogin": "2026-03-01T08:00:00Z", "active": true }, { "userId": "u005", "email": "eve@frontier.com", "name": "Eve Müller", "roles": ["revenue_reporter"], "lastLogin": null, "active": true }, { "userId": "u006", "email": "frank@frontier.com", "name": "Frank Osei", "roles": ["invoice_processor", "cash_receipts"], "lastLogin": "2026-03-10T16:00:00Z", "active": true } ]

User Access Management for Financial Systems

Problem/Feature Description

Meridian Commerce is a fast-growing B2B ecommerce company that recently hired a new CFO. During their first week, the CFO discovered that several warehouse managers have been assigned both purchasing and payment approval responsibilities — a legacy arrangement that grew organically as the company scaled. External consultants have flagged this as a potential audit risk ahead of the company's Series C financing round, which requires demonstrating credible internal controls.

The engineering team has been asked to build a user role management module for the admin backend. The module needs to handle assigning financial roles to staff members and must enforce the appropriate constraints. The system should make it impossible to assign a user a combination of roles that would give them unchecked financial authority, and every role change must be traceable. The company currently has around 40 admin users whose role assignments need to be validated as part of the rollout.

Output Specification

Produce a TypeScript module (or set of modules) that implements:

1. A role model defining the financial roles for the order-to-cash and procure-to-pay cycles, plus system administration roles. 2. Logic to detect prohibited role combinations when assigning roles to a user. 3. A function to assign roles to a user that enforces the prohibited combinations and records the change to an audit log. 4. A one-time scan function that checks all existing user-role assignments for conflicts and returns a report of any violations found.

Write the implementation to src/financial-roles.ts (and any supporting files you need).

Also write a design-notes.md file explaining:

• Which role combinations are prohibited and why
• How the audit log entry is structured
• What happens when a violation is detected

Input Files

The following file describes the existing user population. Extract it before beginning.

=============== FILE: inputs/existing-users.json =============== [ { "userId": "u001", "email": "alice@meridian.com", "name": "Alice Chen", "roles": ["po_requester", "order_entry"] }, { "userId": "u002", "email": "bob@meridian.com", "name": "Bob Martinez", "roles": ["po_approver", "invoice_processor"] }, { "userId": "u003", "email": "carol@meridian.com", "name": "Carol Smith", "roles": ["po_requester", "po_approver"] }, { "userId": "u004", "email": "dan@meridian.com", "name": "Dan Lee", "roles": ["payment_initiator", "payment_approver"] }, { "userId": "u005", "email": "eve@meridian.com", "name": "Eve Johnson", "roles": ["invoice_processor", "payment_initiator"] }, { "userId": "u006", "email": "frank@meridian.com", "name": "Frank Brown", "roles": ["order_approver", "revenue_reporter"] }, { "userId": "u007", "email": "grace@meridian.com", "name": "Grace Kim", "roles": ["auditor", "revenue_reporter"] }, { "userId": "u008", "email": "henry@meridian.com", "name": "Henry Davis", "roles": ["user_admin"] }, { "userId": "u009", "email": "iris@meridian.com", "name": "Iris Wilson", "roles": ["po_requester", "payment_approver"] }, { "userId": "u010", "email": "jake@meridian.com", "name": "Jake Taylor", "roles": ["cash_receipts", "revenue_reporter"] } ]