Case Study

AIS Audit Sandbox v2

Vanilla JS Randomized Data Engine Three-Way Match GAAP Compliant Infinite Practice Mode
Origin

Why I Built This

An offhand comment made me think — my portfolio was impressive, my experience was solid, but my technical accounting skills? Still unproven.

I'm at SJCC. My accounting classes haven't even started yet. So instead of waiting, I had an idea: what if auditing was a game you could actually practice?

I built a sandbox that generates randomized company transactions seeded with real fraud patterns. Every round is unique. You review the transactions, flag what looks suspicious, identify the fraud type, and submit your audit for scoring.

Honestly? I expected it to be easy. It wasn't. That told me it was worth building.

I wanted to see if I could.
Turns out I could.
The Tool

How It Works

Each audit session generates a fictional company with 18–22 randomized transactions. Hidden inside are 6–10 fraudulent entries across 3–5 active fraud types. Your job is to find them.

● Duplicate PO
Same PO number appears on two transactions — a payment already issued, billed again.
● Threshold Splitting
Amounts clamped just under $25k to avoid director-level approval. The pattern is in the cluster.
● Unregistered Vendor
Vague shell company names that don't appear in the approved vendor directory.
● Missing Docs
Invoice and PO exist — but the Receiving Report is absent. Payment can't be verified.
● Unauth. Approver
A supervisor signed off on a transaction that required manager or director authority.
📄
Three-Way Match Panel Every transaction has a slide-in panel showing the Purchase Order, Invoice, and Receiving Report. Discrepancies are flagged across all three documents — Duplicate POs show a fulfilled status, Missing Docs show a blank receiving report, Vendor mismatches show conflicting names across PO and invoice.
📊
Audit Scoring Submit your audit and get an instant breakdown — correct flags, wrong flags, missed issues, and a percentage score. Every flag requires you to identify the specific fraud type, not just mark it suspicious.
🎲
Infinite Practice Mode No two audits are the same. Company, industry, transaction count, fraud distribution, PO numbers, vendor mix — all randomized every round. The patterns become instinct over time.
Professional Skepticism

I Audited My Own Code

The first version of this tool had a logic error. When a Duplicate PO was detected, the risk calculator summed both transactions — the original and the duplicate — inflating the at-risk figure. A $5,000 fraudulent charge was reporting $10,000 at risk.

Under GAAP, only the second payment is the loss. The first is a legitimate obligation. The model was double-counting.

I caught it, traced it through the aggregation logic, and refactored the calculation to only count the flagged transaction as exposure. The Total Issues counter was also updated to treat a duplicate pair as one finding — consistent with how an auditor would document it in a workpaper.

Professional skepticism doesn't stop at the data. It applies to the systems you build to analyze it.

Technical Appendix

Under the Hood

Session Randomizer

Every audit is generated fresh — no two rounds are the same. Each session picks a random company from a pool of 8 fictional firms across different industries, then assigns a randomized fiscal year, employee count, and revenue figure. Transaction count varies between 18–22 per round, and PO/TXN counters start at random offsets so the IDs never look patterned.

A Fisher-Yates shuffle determines which transaction slots receive fraud assignments, so the position of red flags changes every time. From there, 3–5 fraud types are activated per round and distributed across 6–10 fraud slots using modulo cycling — ensuring variety without clustering.

Fraud Generation Logic

Each fraud type has its own dedicated generation rules — amount ranges, vendor pools, approver filters, and document states are all set independently:

Duplicate PO First occurrence generated clean with no flag. Second reuses the same PO number and is marked fraudulent — mirrors a real double-payment scenario.
Threshold Splitting Amount clamped to $24,500–$24,999, just under the $25k director approval ceiling. Exploits the approval tier gap.
Unregistered Vendor Pulls from a separate shell vendor pool with intentionally vague names. Three-Way Match shows vendor mismatch across PO and invoice.
Missing Docs Legitimate vendor and amount — but the Receiving Report is null. Three-Way Match panel shows the document as absent with no verification possible.
Unauth. Approver Approver pool filtered to supervisor-level only, below the authority threshold required for the transaction amount.
Ready?
Try the Sandbox
A new audit — different company, different fraud, different patterns — every time you click.
Launch Audit Sandbox →