Use cases · Reconciliation · PG-27
Billing, terminals, channels, bank — one verified number, and the evidence path to defend it
For close teams: exception queues with owners and aging, evidence an auditor can sample, and adjustment proposals that post only when a human approves them.
- owners + aging on every exception
- evidence paths, not screenshots
- proposals, never silent postings
- sealed sign-off bundle
- air-gap installable
What the close team actually does here
Four jobs, each with the primitive that answers it — no feature tour, no workflow screens we do not ship. The mechanisms live on the reconciliation feature page; this is the work in front of it.
PH-1
Work exceptions, not spreadsheets
The exception queue is ranked by materiality × age, and every row carries its reason code, its owner and its aging band — so Monday's stand-up starts from a ranked list instead of a fresh extraction.
FR-150/151 · PH-1
PH-1
Answer the auditor's sample
Pick any finding and follow its evidence path — each hop with its residual — back to the source rows and forward to the bank. The path a reviewer asks about is a query, not an archaeology project.
FR-153, FR-525–527 · PH-1
PH-1 · T0/T1
Propose the adjustment, approve the posting
Each exception can produce a proposed provisional entry from a reason-code template — and it moves only through the same materiality gates as any other entry. Nothing about the close posts silently.
FR-154, FR-217 · PH-1
PH-1
Sign off with a sealed bundle
A completed run can produce a sealed evidence bundle — manifest, KPI snapshot and pinned rule versions — that an auditor can verify offline. The fuller evidence packages arrive later.
FR-157 basic · PH-1; fuller packages FR-907 Roadmap
The close week, from statement to sign-off
One path through the period — and the state your workpaper is in at each step.
-
Statements land source control totals + bank statement
Declared sides enter the run; a side that never arrives shows up as its own exception rather than silently shrinking the chain.
-
The run completes counts and states per side
Matched, suggested, unmatched and exceptional are counted per side, with per-hop deltas under the declared tolerances.
-
The queue is worked reason code · owner · aging
Exceptions are assigned, aged and escalated; the residual — what does not tie — stays attached to each one.
-
Proposals are reviewed hash-bound approvals
Adjustments are proposed against their findings; approvers decide inside the T0/T1 gates, and any edit voids a pending approval.
-
The period is sealed evidence bundle
The bundle a sign-off rests on is produced from the run itself — verifiable later, offline, without ledger access.
Links up and sideways
- The reconciliation feature page
- All use cases
- Finance teams: the ledger of record
- FP&A: plan against numbers you can verify
- Security: what is held, in progress, and out of scope
- Talk to us about a security review
No benchmark strip on this page — pre-launch, we publish numbers only when they are reproducible from the product and dated. The evidence you can inspect today is the mechanism itself. The proof strip holds until real numbers exist
What Ledgerbook is not
Three boundaries that decide what your team still owns after this lands.
- No exception-queue screens (NG-1). The run, every match, every exception case with its reason code and every reviewer action are recorded objects and events. The screen your close team works in is yours or your close-management vendor's — reading those objects rather than storing its own copy.
- No model-based matching in the core (NG-4). Rule and tolerance matching is deterministic and reproducible from recorded rules. Scored or fuzzy matching belongs above the ledger, where a human reviews it — which is also where an auditor expects to find it.
- No money movement (NG-3). Adjustments are raised as proposals and reviewed. The transfer that actually settles a break happens in treasury, and the ledger records what happened.
Where the boundary is
- Not an ERP, and not a replacement for one — the ledger beneath your estate (NG-2).
- No close workflow screens, no AP/AR — your application renders the queue; the ledger proves it (NG-1).
- No money movement — PSPs and banks are ingestion sources (NG-3).
- No model in the posting path — agents propose over MCP; policy approves (NG-4).
Tell us about your close
The evaluation we run with design partners starts from your source mix and the audit question that keeps recurring — not a demo script.