1. Why This Project

Manual ledger scrutiny and audit sampling are repetitive, time-consuming, and inconsistent across auditors. This project automates both — turning hours of manual checking into a fast, repeatable first pass, so the auditor can focus judgement where it matters most.

Vision

An audit practice where every ledger entry is screened before a human eye ever reaches it — making scrutiny faster, wider in coverage, and free from fatigue-driven oversight.

Mission

Build an accessible, automated ledger-scrutiny and audit-sampling tool that flags anomalies and picks samples systematically — leaving the final judgemental call to the auditor.

2. How It Was Built — End-to-End Process

The project was built using four components working together: Antigravity for direction and vibe coding, Python and its libraries for implementation, a reusable Skill for repeatability, and parallel threading for speed.

2.1 Antigravity — Setting the Direction

Antigravity was used at the start of the build to set direction for the project: the audit standards to follow, where each standard applies, and the formulas to use for scrutiny and sampling. The AI was used solely to write the code and trigger the Python application — it does not consume or process any data itself. All data ingestion and processing happen entirely within the Python process, running locally.

2.2 Vibe Coding — Building and Running the Pipeline in Python

The entire pipeline was vibe-coded in Python. Rather than issuing a fresh prompt for every run, the process was built to run as a standing Python command: once started, it keeps running in the background, continuously carrying out ledger scrutiny and sampling without needing to be re-prompted each time. This keeps the workflow intact and removes the need for manual intervention between steps.

2.3 The Skill — skill.md

1. What it is — a packaged, reusable skill — defined in a skill.md file — that encodes the ledger scrutiny and audit sampling logic for a given company, triggered as /audit-sampling-[company name].
2. Why it was built — to make the process repeatable. Instead of re-explaining the scrutiny and sampling logic every time, the skill packages it once so it can be invoked directly.
3. How it was used here — this skill was used to run the ledger scrutiny and audit sampling for this project's demonstration, and is reusable for any future audit engagement without rebuilding the logic from scratch.

2.4 Parallel Threading — Processing Multiple Ledgers at Once

With multiple ledgers to process, the skill originally ran them one after another in Python, which took a significant amount of time. Parallel threading was introduced so that all ledgers run simultaneously in the background, with output released in far less time than the original sequential run.

3. Where AI Is Used

AI's role in the pipeline is deliberately narrow and clearly bounded from the rest of the process:

1. AI (external/vibe-coded) — searches for and drafts the company description, using the company name, this is used for deciding Overall materiality and to start the Python application and to monitor it .
2. Python, running locally — handles everything else — choosing the materiality model, computing Overall Materiality and Performance Materiality, and running the full ledger scrutiny and sampling logic.

This separation keeps the sensitive, data-heavy part of the process — the ledger analysis itself — entirely local, with AI used only for a narrow, non-sensitive drafting task.

4. Data Privacy

In line with the Digital Personal Data Protection (DPDP) Act, no financial data is sent to any external system. All ledger data, materiality computations, and scrutiny/sampling logic are processed locally through Python; only the company-description search touches an external AI service, and that step does not involve financial data.

5. Current Scope & Limitations

The current build automates ledger scrutiny and audit sampling on a systematic, rule-driven basis — it is not yet judgemental. The tool flags anomalies and selects samples consistently and at speed, but the final judgemental call on any flagged item remains with the auditor. Extending the system toward judgemental assessment is identified as a future direction for the project.

6. Output — What the Tool Produces

The core output of the pipeline is two-fold: a Trial Balance reconciliation and a sub-ledger (ledger-wise) reconciliation, followed by a fully worked audit sampling pack built on top of that reconciled base. The example below is an actual run of the tool, on a real engagement, shown to demonstrate the output in full.

6.1 Worked Example — Varnika Foods & Beverages Limited, FY 2025-26

This is the live run demonstrated at the hackathon, shown here in two phases — the engagement initially halting for lack of data, and then completing once the required ledgers were supplied — to demonstrate both the output and the resumability of the tool in a single real case.

Phase A — Initial Run, Halted at Trial Balance Scoping

Varnika Foods & Beverages Limited is a Bengaluru-based FMCG manufacturer (snacks, juices, dairy drinks) with ₹21.23 Cr revenue and ₹2.86 Cr Profit Before Tax for FY 2025-26. At the start of the engagement, only the Financial Statements and Trial Balance had been provided by the client — no general ledgers.

1. Step 0 — Trial Balance Checks — the Trial Balance's internal debit/credit equilibrium was verified (100% balanced, nil difference), and the Financial Statements were tied out exactly to the Trial Balance groupings (100% reconciled).
2. Steps 1 & 2 — Materiality Calibration — completed in full even at this stage — Overall Materiality of ₹14,29,366.42 (PBT @ 5.0%, per SA 320) and Performance Materiality of ₹10,00,556.49 (a 70% calibrated haircut after the 5-dimension risk assessment).
3. Step 3 — Layer 1 Trial Balance Scoping — of the 81 Trial Balance accounts, 69 were scoped in for transaction-level audit (99.84% of financial value), and 12 low-risk accounts were routed to analytical review instead.
4. Steps 4 & 5 — Hard Stop — with zero general ledgers in the client folder, the pipeline halted before sub-ledger testing. Under SA 500 and SA 330, an auditor cannot fabricate transaction extracts or run statistical sampling without the primary books of account, so the tool stopped rather than proceed on incomplete data. It generated a formal In-Scope Ledgers Demand Schedule naming all 69 ledgers required from the client, and preserved its exact execution state in a checkpoint file.

This halt is not a failure state — it is the tool correctly refusing to sample without primary records, and handing back a precise, ready-to-send data request instead.

Phase B — Resuming via MD Trackers, Run to Completion

Once the client supplied the demanded ledgers, the engagement was resumed with a single command rather than restarted — the tool picked up exactly from the checkpoint where Phase A had stopped.

1. Step 1 — Trial Balance & Ledger Reconciliation — all 81 Trial Balance accounts were reconciled 3-way against their underlying sub-ledgers. 81/81 accounts tied out with zero variance.
2. Step 2 — Sampling & Stratification — against a total population of ₹161.98 crore across 601 vouchers in 81 sub-ledgers, the tool selected a sample of ₹161.15 crore across 519 vouchers — 99.48% financial coverage — split across four tiers: Stratum A (393 vouchers at or above the sampling interval of ₹3,33,518.83, 100% substantively vouched, 0% sampling risk, 98.05% of audited value), Tier 2 (14 period-end cut-off vouchers, 100% verified against delivery records), Stratum C (credit notes and reversals, segregated and examined without netting), and Stratum B (21 residual vouchers selected by Poisson Monetary Unit Sampling at 95% confidence).
3. Step 3 — Deliverables Generated — a master Excel workpaper (a 7-card Executive Dashboard with the full technical defense memo, PM Decision Rationale, Full vs Residual Sample Guide, Trial Balance Scoping Classification, Selected Audit Invoices Master, SA 530 Error Projection, and 10 embedded sub-ledgers), an interactive HTML audit dashboard, and a separate Pre-Audit 3-Way Reconciliation workpaper.

Outcome: evaluated misstatement of ₹0.00, at or below Performance Materiality — supporting an unmodified audit opinion.

6.2 Working from Incomplete Data — Resuming via MD Trackers

The Varnika Foods run above is a direct demonstration of this: when only financial statements and a trial balance are available, the tool completes everything that can honestly be done at that stage — reconciliation and materiality calibration — and then stops cleanly at the point requiring primary ledgers, rather than guessing. It records exactly what has been processed and what remains in a markdown-based tracker and checkpoint file. When the client supplies the outstanding ledgers — in full or in part — the engagement resumes from that exact checkpoint with a single command. Nothing already reconciled or calibrated is redone, and if only part of the data arrives, the tool processes that batch, updates the outstanding schedule, and pauses again until the rest follows.

6.3 A Flexible, Standards-Based Model

Because the underlying logic is built around general auditing standards (SA 320, SA 530, SA 240, SA 500, SA 330, SA 700, among others) rather than one company or one industry, the same model is reusable across different types of audits. Varnika Foods (FMCG manufacturing) and the methodology's use on other entities in earlier runs show the pipeline is not specific to one sector — it applies wherever a trial balance and ledger-level data are available, whatever stage that data arrives in.

7. Summary