Skip to main content

​
Follow accounting lineage

The lineage links described here are live in the GreatBook web application.

​
The chain of custody

This is a chain of links, not a claim that every item is the same kind of record or that every event began in intake. Evidence supports a decision; decisions may explain an accounting event; an event may lead to one or more journal entries; assurance records explain a control result. Native subledger rows, approved workpapers, reversals and system events are valid sources alongside document intake.

​
Accountant-originated work is durable

An Accountant adjustment, close calculation or import does not become auditable merely because a journal description names it. GreatBook records an independently approved immutable journal_workpapers source with the exact (source_type, source_id) used by the journal. The workpaper points to the containing accounting event and exact immutable journal entries, and Transactions or exact-entry detail resolves back to that same workpaper. This is bidirectional lineage, not copied labels. If the exact workpaper/source relationship cannot be established, the event remains missing or reviewed legacy_unverified; a descriptive key never upgrades it to resolved.

​
Worked example: trace a transaction to source, workpaper and reversal

  1. Start in Books → Ledger and select the Transactions event, or start in a Books native register and follow its accounting-event link.
  2. Record the stable greatbook.ref/v1 event reference rather than relying on row position or prose.
  3. Inspect the source category and lineage state, then open the exact source or durable workpaper reference.
  4. Open each journal-entry set inside the event and verify entry identity, status, date, complete debit/credit lines, posting actor and integrity state.
  5. Follow reverses or reversed_by to the exact correcting entry. A reversal is a new immutable write; the original entry remains.
  6. Return through the source link to the obligation, settlement, allocation, costing record, adjustment, intake item or workpaper that owns the accounting fact.
  7. If assurance identified a residual, open its finding and stored run evidence. A waiver remains visible as a waiver; it is not silently treated as resolved.

​
Honest failure behavior

Lineage is deliberately explicit about gaps:
  • Missing source means the event’s primary source could not be resolved.
  • Legacy / unverified means the event can be read but its older lineage was not established.
  • An unavailable detail or malformed response is an error, not a substitute source.
  • A partial Books family or tie-out cannot establish complete native-to-GL coverage.
The system preserves exact decimal representations across these reads and separates a statement’s evidence amount from a settlement or GL amount. When a period is closed, a correction is a new reversing accounting write rather than an edit to prior history.

​
Auditor jobs and browser access

The Auditor has two operator paths. A person can ask a conversational, read-only assurance question in the browser; scheduled or event-triggered audit jobs run in job mode with the job definition’s check family and scope. The browser cannot select job mode, privileged audit scope or an arbitrary job thread. The frontend passthrough accepts only messages in a browser-originated Auditor input; mode, requested check families and job-only scope are absent from that allowlist. If a browser request attempts them, it is rejected instead of becoming a scheduled run. The server job runner creates mode="job", selects the recognized family and scope, and sends the narrowed state through the graph. For an operator, the practical flow is simple: use the Audit workspace to read the durable findings, acknowledge or waive only through its stated controls, and let the scheduling path own job execution and retries. An audit read failure becomes inconclusive coverage, never a clean result.