Zenmem
Login
๐Ÿงพ

Statutory audit & working paper copilot

TaxStatutory auditPython 3.14 ยท CLIzenmem-open/audit-shield

View source

About this agent

A working-paper copilot for statutory auditors, built on the Zenmem SDK, covering SA 320/530 materiality and sampling, CARO 2020 clause evidence linking, management query tracking and MRL drafting under SA 580, and a final, transaction-locked peer-review sign-off. One instance runs one engagement โ€” one client, one financial year โ€” with its ongoing state (query tracker, materiality threshold, sampling rationale) isolated in project-scoped memory so nothing leaks between clients. Materiality and sample selection are deterministic arithmetic, not model output: only the qualitative work โ€” evaluating fieldwork notes against a CARO clause, cross-referencing an uploaded invoice or board-minutes excerpt against the trial balance, drafting the MRL โ€” goes through the LLM, grounded in that engagement's own memory and the firm's shared CARO/SA reference material. The final sign-off is written inside a zenmem transaction so it lands whole or not at all. The workspace is explicit about what that does and doesn't guarantee: zenmem exposes no update or delete for this memory, so nothing in this codebase ever edits or removes a committed sign-off, but that is a convention this code follows, not cryptographic tamper-proofing enforced by the SDK. It also states plainly that it is a scaffold, not audit software validated for production reliance โ€” the materiality percentages and sampling formulas are illustrative defaults, and every real materiality basis, sampling methodology and CARO conclusion must still be made and documented by the engagement team.

RUNTIMEPython 3.14 ยท CLI
MEMORY TYPESession + project + company + transaction
SDKzenmem 0.4.4
INTERFACECLI ยท Python library

What changed with Zenmem?

The same agent, built twice against the same contract โ€” once on Zenmem, once on MongoDB + LangChain/LangGraph.

Before โ†’ after

Code for the query trackerโˆ’36%

Code for CARO evidence linkingโˆ’63%

New infrastructure to stand upnone

New dependencies to install0

Schema, collection and index worknone

Isolating one engagement's statea scope id

Atomic partner sign-offone transaction

Before With Zenmem

What the team gained

  • An engagement is a project scope, so one client's open queries cannot reach another's file without a tenancy layer written by hand.
  • The firm's CARO and SA reference material is read-only company scope, shared by every engagement rather than copied into each one.
  • The final sign-off is wrapped in one transaction, so materiality, CARO observations and MRL status land whole or not at all.
  • No update or delete is exposed for this memory, which is what makes the append-only working paper a property of the store rather than a rule the code has to police.
  • Deterministic materiality and sampling stay outside the model, with memory used only for the qualitative evidence work.

How memory is scoped

Session holds one active fieldwork conversation โ€” CARO clause evaluation chat, evidence-linking notes โ€” and ending it promotes the findings into the engagement's ongoing state. Project is scoped to one engagement (client plus financial year, via projectId), holding the query tracker, materiality threshold and sampling rationale; this isolation is per engagement rather than firm-wide, so one client's open queries can never leak into another's file. Company holds read-only, firm-wide reference material โ€” standard CARO 2020 reporting language and SA guidance โ€” that agents fetch but never write engagement facts into. A fourth mechanism, a zenmem transaction, wraps only the final partner-signed sign-off record, so that one write either lands complete or not at all.

How it works

One engagement's lifecycle, run by the AuditShieldOrchestrator.

Materiality & sampling

SA 320 benchmark and performance materiality are computed deterministically, then a Monetary Unit or stratified sample of the ledger is drawn against that threshold.

CARO evidence linking

Inside a fieldwork session, notes are evaluated against a CARO 2020 clause for discrepancies over threshold, and uploaded evidence (invoices, bank confirmations, count sheets, board minutes) is cross-referenced against trial balance line items.

Query tracking & MRL

Queries raised to management are tracked open-to-resolved, and once resolved the responses are synthesised into a formal SA 580 Management Representation Letter.

Immutable sign-off

The materiality threshold, CARO observations and MRL status are rendered into a final record and written inside a zenmem transaction, so it commits whole or not at all.

What it does

The four agents behind the orchestrator โ€” each independently usable.

Capabilities

  • compute_materiality โ€” SA 320 benchmark and performance materiality from revenue, profit before tax or total assets.
  • select_sample_mus / select_sample_stratified โ€” Monetary Unit or stratified sampling of the ledger against the performance-materiality threshold.
  • evaluate_caro_clause โ€” checks fieldwork notes against a CARO 2020 clause (e.g. Clause (ii) Inventory) for discrepancies over a configurable threshold, and drafts the resulting queries.
  • link_evidence โ€” extracts text from an uploaded document (mock, PDF or image-OCR provider) and matches it to trial balance line items.
  • raise_queries / resolve_query โ€” tracks management queries from open to resolved.
  • draft_mrl โ€” synthesises resolved queries and management's responses into a Management Representation Letter.
  • finalize_sign_off โ€” locks the materiality, CARO observations and MRL status into the immutable, transaction-committed audit record.
  • export_working_paper โ€” writes a finished document out to the configured working-papers directory.

Other agents

View all