From GL upload to audit workpaper JSON in three steps.
Drop a CSV of AP rows at /audit. The same eight detectors a Continuous tier runs every business day run in your browser against your file — and you walk out with the workpaper JSON your auditor signs off against.
The workflow, end to end
Three steps from a CSV to a signed workpaper
The same closure path a Continuous-tier tenant walks every business day — read in order, each step ladders into the next: /audit is the surface for all three.
Upload GL file
Drop a CSV of AP rows at /audit — file stays in your browser.
- Accepts standard GL exports up to 50,000 rows — vendor name, invoice number, amount, posting date, cost center
- Processing runs entirely in your browser; the file is not uploaded to a server
- Format helpers (and a sample CSV) live next to the upload at /audit
Detector scoring across the 8 AP/procurement signals
The same eight functions a Continuous tier runs every business day.
- evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee — each firing on its own threshold
- Every fire ships a structured reason — the rule that tripped and the spend signal behind it
- Findings lift into a triage grid: detector name, severity, vendor, amount, and link into the workpaper
Export audit workpaper JSON
A signed envelope per finding — receipt, rule, override.
- Each finding exports as a workpaper: the receipt (the original transaction that tripped the detector), the rule that tripped, and any override applied
- The workpapers ship via /api/audit-workpapers/export as JSON — the same endpoint the production Continuous tier writes to
- For external signing, the PDF is built in-browser at /audit so the audit artifact never lands on our disk twice (see /security)
The coverage shift
From quarterly sample to population-level continuous audit
Three before / after shifts the three-step workflow unlocks — each one is a population-vs-sample move the same eight detectors make possible without a rewrite of the underlying AP flow.
Before
A 25-to-60-line quarterly sample review — one reviewer queue, weeks after disbursement.
After
95% of every transaction, every business day, before the wire clears.
Before
A one-off spot-check at quarter-end — the surface a fraud ring only has to outlast for one cycle.
After
A daily pre-payment gate — the same eight detectors run on the queued payment batch, not on a sample chosen weeks later.
Before
A PDF artifact locked at quarter-end — assembled under pressure from a single auditor laptop.
After
A JSON export on every run — the /api/audit-workpapers/export endpoint returns the same envelope on demand.
Frequently asked
Six questions on the three-step workflow
Upload time, file formats, the eight detector names, the workpaper envelope, export handoff to your auditor, and where the JSON lives — plain HTML answers, no JavaScript required to read.
How long does a step-1 upload take?
A 10,000-row CSV parses in under thirty seconds in your browser; a 50,000-row CSV tops out under ninety seconds. There is no server upload, so the latency you feel is the parser running locally — your ISP and your laptop determine the wall clock, not ours.
Which file formats does step 1 accept?
CSV today, with the column set expected by the eight detectors: vendor name, invoice number, amount, posting date, and an optional cost center / GL account. XLSX is on the roadmap; until then, the /audit surface ships an "Export as CSV" note next to the upload control for ERP exports that start in spreadsheet form.
Which 8 detectors run in step 2?
The same eight functions a Continuous-tier tenant runs every business day — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee. The /detectors page lists each one with its spend signal, persona, and a worked example finding; this page keeps the names aligned with the production set and the pricing feature matrix.
How is the workpaper JSON structured?
Each finding emits a workpaper envelope with three pieces: the receipt (the original transaction or vendor record that tripped the rule), the rule (detector name and threshold that fired), and any override applied. The envelope is what a PCAOB AS 2315 reviewer signs off against — produced continuously, not assembled at quarter-close.
Can I export the JSON to my auditor's tool?
Yes. /api/audit-workpapers/export returns the full per-finding envelope as a stable JSON shape, and the /audit surface also generates a PDF in-browser so the same report can be handed off in either form. Externally shared PDFs are gated by a signed download token issued by /api/audit/download/[id] — see /security for the integrity controls on that path.
Where does the workpaper JSON live?
For a one-off /audit run (a folder sliced from your CSV), the JSON export is generated in your browser — the file never crosses the wire to us. For a Continuous-tier tenant, workpapers are written to /api/audit-workpapers/export against the live run store, retained per-tenant settings (90 days by default), and can be re-fetched any time the envelope is needed.
See all three steps on your own ledger
Drop a CSV at /audit — or launch the eight continuously at /pricing.
The same eight detectors run on your AP ledger at /audit — no signup, no sales call required to see first findings. Pick Continuous or Enterprise at /pricing to launch them continuously against your live ERP. For the workpaper-integrity posture the export path rests on, see /security.