Exporting Ledgers: CSV, Excel and Certified PDF

The export controls turn the Audit Trails ledger into files: CSV and Excel for working, and a certified PDF for the proceeding. All three are Partner-and-up actions, and each one is itself recorded.

The three formats

Format	Role	Best for
CSV (text/csv)	Working file	Filter, pivot, feed into another tool — opens anywhere
Excel (.xlsx)	Working file	Review distribution and annotation, one sheet (audit_trails)
Certified PDF (application/pdf)	Proceeding-grade artifact	The file you put in front of a TPO, a court, or a MAP authority

Each export renders the same merged ledger — study audit rows, override rows and (for admin exporters) the access rows — as the 200 most recent entries, newest first, on one page. It is a fixed window, not a filtered one: the tab’s filter bar does not narrow an export, and there is no date range or study selector on the endpoint. Rows carry fourteen fields: timestamp, source, study name, category, action, actor name, actor email, actor role, IP address, user agent, target email, previous value, new value and justification notes.

The certified PDF

The PDF is the artifact with integrity markers:

• Branded title — “Certified Audit Trail Ledger”, A4.
• Metadata block — the tenant id, the export timestamp in UTC, and a note that the document was generated from the immutable audit ledger. The firm name is not resolved in the export path, so the label prints as Firm: Unnamed Firm next to a real tenant id — identify the firm by the tenant id, or hand-annotate the cover.
• Content fingerprint — the SHA-256 of the sorted JSON dump of the exported rows, printed under the metadata, with a statement that any alteration invalidates the fingerprint.
• The ledger table — the same rows, header repeated on every page (repeatRows), with three columns dropped and long text clipped for fit: the print grid shows Timestamp, Source, Study, Category, Action, Actor, Role, IP, Previous, New and Justification. Actor email, user agent and target email are not printed, and study (32 chars), action and actor (24), previous/new (40) and justification (48) are truncated in the cells.
• Certification block — a JSON block on its own final page carrying firm name, tenant id, exported_at, row_count and the same sha256.

Be precise about what “certified” buys you: the file is generated by reportlab with no encryption, no permissions lock and no digital signature. The SHA-256 over the row set is the only integrity device in the document, and it is a claim printed on paper until someone re-computes it.

How export works

• Permission — Partner, Firm Admin, Superadmin. The buttons are absent otherwise, and the backend re-checks the role on every call; there is no plan-feature gate on this endpoint.
• Scope — the export reflects the caller’s scope: a Superadmin exports the ledger of their own studies; a Firm Admin their tenant; the access rows are merged in only for admin views, so a Partner’s PDF carries transition and override rows and blank IP columns.
• Delivery — a streaming attachment over the authenticated session, not a presigned link (the evidence packet export is the one that hands back a time-limited URL). The server names the file audit-trails-{YYYYMMDDHHMMSS}.{ext}; the browser saves it under the client-generated name audit-trails-{YYYY-MM-DD-HH-MM-SS}.{ext}, so expect the timestamp format to differ between the two.
• Self-recording — a successful export appends a Ledger Export access row with {"format": …} in the details plus the caller’s IP and user agent, so the export lands in the access and security log; the Overview “Exports (30d)” card refreshes right after the download.
• Validation — a format other than the three is rejected (400).
• Empty ledger — CSV still returns its header row, and the PDF prints its metadata, fingerprint and certification block with row_count: 0.

What to keep where

• Working: the CSV and Excel go in the engagement folder as the filterable copy — and as the only copy carrying the email, user-agent and target fields.
• Proceeding: the certified PDF, and its fingerprint, go in the retention file — alongside the audit packet, which is the evidence-side archive. The PDF certifies the ledger; the packet certifies the evidence.

The verification workflow

The point of the fingerprint is a check you can repeat later — but it is a manual one. The platform offers no verify endpoint or uploader: you recompute the digest yourself.

1. At export — keep the certified PDF and the CSV or Excel taken in the same action, and note the printed SHA-256. The hash covers the exported row set, not the PDF bytes.
2. At dispute — reload the retained CSV/Excel, rebuild the same fourteen fields per row (empty cells as empty strings), serialize the list of rows as JSON with sorted keys and recompute the SHA-256 over the UTF-8 bytes.
3. Match — the rows are the ones that were in the ledger at that time. Mismatch — either the document or the rows were altered; that is the finding.

Two constraints follow from that design. You cannot verify from the PDF’s own printed table, because it drops three columns and truncates others — the CSV/Excel of the same window is the reference. And a later re-export will not match, because the ledger is append-only and the 200-row window moves: the fingerprint proves a saved pair of files, not a permanent checkpoint.

FAQ

Is the export the whole history? No — it is the most recent 200 ledger entries, newest first: the current working window of the ledger, not an unbounded dump. Page through the tabs for anything older.

Can I verify the PDF later? Yes, manually — recompute the SHA-256 over the CSV/Excel rows kept with it and compare to the printed fingerprint. Without that companion file the hash has nothing to be checked against.

Does exporting change anything in the ledger? Nothing that rewrites history — the ledger is append-only and the export only reads it. The one write is the export’s own Ledger Export row, which then appears in later exports and searches.