Architected a full-lifecycle audit automation SaaS for external audit firms, AI document ingestion, trial-balance normalization, materiality and sampling engines, and an ISA-aligned sign-off workflow.
Ingestion, normalization, mapping, materiality, risk, sampling, vouching, sign-off
Preparer, reviewer, partner, and admin roles with enforced sign-off sequencing
Working papers, review notes, and journal adjustments mapped to ISA requirements
External audit firms run the entire engagement lifecycle across spreadsheets and email: trial balances arrive in a dozen incompatible formats, account mapping is retyped every year, sampling is defended by memory, and review notes live outside any audit trail, which is exactly the evidence a regulator asks for.
Designed an audit platform where every artifact is a first-class database record: OCR-ingested documents feed a normalization layer, mapping is learned and carried forward year over year, and materiality, risk, sampling, and vouching are computed steps with a reviewable lineage instead of a spreadsheet formula.
The AI layer sits behind a deterministic normalization stage. Documents are OCR'd and coerced into a canonical trial-balance and general-ledger shape first, so the model reasons over structured records, never raw scans, and a bad extraction fails loudly at parse time instead of silently at conclusion time.
Account mapping is stored per client and carried forward between engagements. Year two starts from year one's mapping with only the deltas surfaced for review, which is where the majority of the manual hours actually go.
The AI copilot answers questions against the engagement's own working papers rather than a general corpus, and every answer it produces is attached to the working paper it came from, an assistant that leaves evidence.
A review note is a blocking state machine attached to a working paper, not a comment thread. A partner cannot sign off an engagement while any note is open, the constraint lives in the database, not in a process document.
Materiality and performance materiality are stored as versioned records with their inputs, so a revision partway through an engagement re-flags the samples it invalidates rather than quietly changing the basis of work already performed.
If something here looks like what you're facing, tell me about it. The first conversation is an architecture discussion, not a sales call.
