How it works

Two independent reads of every figure, and a tool that says what it did not test.

This page is written to be checked. Every claim on it describes something the tool does in code, and the sections on your files name the providers, the country, and the number of days.

What runs

You upload the agent's month-end reports for the audit year, one folder per month, plus the bank statements. The tool walks the folder and reports anything it cannot place rather than skipping it. It then runs three phases, each gated on what is actually in the folder.

  1. balances

    Reads the five money figures and the date prepared off each month's reconciliation report, checks the two accounting identities, and writes the twelve-row audit table.

  2. sample

    Enumerates every receipt in each month's cash book, ties the total to the platform's own printed figure, then draws the sample.

  3. match

    Parses the bank statements and traces each sampled receipt to a credit, then compares every bank credit for the month against the cash book's receipts total.

A re-run is safe. Rows already written are skipped, the sample comes back identical, and nothing that a reviewer has edited is touched. The input PDFs are never modified.

The double-read

Every balance figure is read twice, by two methods that share nothing. A model (Anthropic's Claude, pinned to the dated model id claude-haiku-4-5-20251001 so a re-run months later reads with the same model the figures were verified against) is sent the rendered page and asked to copy the digits printed beside a label. In parallel, a positional scrape reads the PDF's text layer, anchored to the label rather than pattern-matched from a blob of text. The scrape's output is never shown to the model; the test suite asserts that the request carries the PDF and no scraped text, because feeding one read to the other would collapse both onto a single text layer.

When the two reads agree, the row is written and the sources cell records llm+scrape. When they disagree, the figure is flagged amber and read once more with a second model (claude-sonnet-5). If the retry matches either prior read, that value is taken and the amber marker stays in sources so the row remains auditable. If all three differ, the row is flagged for a human. There is no tie-break, no closest-two, no confidence score. The model never gets the last word.

Two identities are then checked on every row: the printed discrepancy against the reconciled bank balance less the trial balance, and each month's opening balance against the prior month's closing. A figure that is absent is left as an empty cell with the reason, never written as zero, because a report that was never produced and a balance that is genuinely zero are different findings. A scanned report with no text layer is flagged and skipped, not OCR'd.

Bank statements never reach a model

Bank statements are parsed deterministically by a per-bank adapter. No page of a bank statement is ever sent to a model. The same is true of the cash books, trial balances, ledgers and journals: they are read by code, and only the reconciliation report is read by the model.

A bank with no adapter fails closed, with no output at all. That is deliberate. A sample file whose bank columns are empty looks like work product and would be read as one, so the tool refuses to produce it. Adapters are built for a bank before its first engagement, which is why the start form asks which bank the trust account is with.

The sample is reproducible

The receipt sample is drawn by a keyed hash, salted per engagement, so running it again produces a byte-identical file. The sample in your working papers can be regenerated and defended. Before anything is drawn, every cash book is enumerated and its total tied to the platform's own printed figure and to the reconciliation report; a month whose frame does not reconcile is written into the file as an explicit not-tested row, with the reason, rather than left out. Absence is invisible; presence is loud.

Each sampled receipt is traced to a bank credit at the same amount within three days of the receipt date, with the payer's name checked against the bank narration. Green is a unique match. Amber is a candidate the narration could not confirm by name, and it is the review queue, not a failure. Red is no bank credit of that amount in the window at all. The verdict tally, the match parameters, and the denominator for every month are printed at the top of the file.

Your edits are frozen

Every row the tool writes is fingerprinted. If you change a cell, the fingerprint no longer matches and the row is frozen: a re-run skips it and reports it as frozen. If the tool cannot vouch for a row, because its state file is unreadable or the row has no recorded fingerprint, it treats the row as yours. The delivered file is the record of what was selected and what you concluded, and a re-run cannot regenerate over it.

What it does not test

This test verifies that recorded receipts were banked; it does not test whether all funds received were recorded.

That sentence is printed at the top of every receipt sample file, verbatim. Sampling from the cash book to the bank tests occurrence; it cannot test completeness, and completeness is the direction the classic trust account fraud runs. The month-level comparison of every bank credit against the cash book's receipts total narrows that gap for the gross case, and the file says so, and says what it still does not catch.

What happens to your files

What leaves Australia, and what does not

One document per account-month leaves Australia: the reconciliation report, sent as a rendered PDF to Anthropic's API in the United States so the model can read the five balance figures. On the agent software seen so far that is a single page.

Nothing else does. Bank statements, cash book reports, trial balances, folio ledgers, journals, transaction audit reports and unreconciled-items reports are processed by code on Google Cloud in Sydney, Australia and are never sent to a model or to any provider outside Australia.

The model provider

Anthropic's commercial API terms do not permit training on API inputs or outputs. The reconciliation page is sent, the five figures come back, and the result is written to your CSV; nothing about your engagement is used to improve a model.

Sub-processors

Every provider that touches your files or your details, listed in full.

ProviderRoleLocationTrust documents
Anthropic, PBCModel provider. Reads one document per account-month, the reconciliation report, to extract the five balance figures.United StatesReconciliation reports only
Vercel Inc.Hosts this website. The start form passes through it in transit.United StatesNone
Google WorkspaceEmail. Carries correspondence and the secure upload link, so it holds your name, firm and email address. Working papers are collected from the secure link, not sent as attachments.United StatesNone
Google AnalyticsWebsite analytics only. Never sees a file or a form submission.United StatesNone
Google CloudSecure upload store and processing. Holds every uploaded file for the life of the engagement.Sydney, AustraliaAll

Deletion

Uploaded files, the generated CSVs and the run state are deleted 30 days after the working papers are delivered. Keep your copy; after that date ours is gone and a re-run needs a fresh upload.

Before the first upload

A confidentiality agreement is offered before anything is uploaded, on your paper or ours. Ask for it in the start form or by reply to the upload link email.

Where the line is

Your firm is the auditor. Mushin is a supplier. We perform mechanical checks and produce working papers; we form no opinion, sign nothing, and never resolve an amber. The tool declares its own scope limitation in its output and the review queue is yours to decide.