A client-trust closeout usually means two separate checks: does the trust account reconcile, and is the matter's docket current. Most firms run those checks in two different places, a reconciliation workbook and a calendaring system, and the two never get compared. This pack composes three nodes so a firm's own finance staff can run both checks from the same declared inputs, get a receipt of each, and see the two side by side: a period that reconciles cleanly but leaves a filing deadline open is a fact this pack is built to surface, not to smooth over.
Stage 1 does the arithmetic a trust reconciliation already does by hand: a three-way comparison of bank, trust ledger, and per-client balances, plus a walk of each client's period activity to catch a ledger that dips negative even when its ending balance looks fine. Stage 2 sweeps the matter's declared docket against declared roll rules and bands every record. Stage 3 turns both receipts into something you can hand over: a bundle labeled with exactly the verification tier its declared gate results support.
The trust reconciliation. You declare the statement period, a reconciliation tolerance, the bank's ending balance and statement date, the trust ledger's ending balance and as-of date, every client ledger's ending balance and its period activity entries, and any outstanding deposits in transit or uncleared checks. The node adjusts the bank balance for the declared outstanding items, compares it against the trust ledger and against the sum of client ledgers, and separately walks each client's declared entries to find the lowest running balance the ledger touched during the period, not just where it ended. A client ledger that goes negative mid-period even briefly, the classic pattern where one client's disbursement is fronted by another client's money, is flagged regardless of how the period closes. Outstanding items are aged from the period end so a check that has sat unresolved for months is visible rather than buried in a balancing adjustment. The reconciliation tolerance is always a declared input, never defaulted, and a negative client low point is never tolerance-gated.
The docket sweep. You declare an as-of date, a due-soon window with a labeled default of 7 days, roll rules for weekends and holidays, and the docket itself as a flat list of records, each a date, an action, a type, a source, and whether it is done. The node computes each record's rolled due date using your declared roll rules, shows that derivation step by step, and bands every record. A record marked done stays in the sweep and reports DONE; it is never dropped, because the receipt is meant to cover the full declared docket at one moment, not a filtered view of what remains open. Two records that declare the same action on different dates are flagged as a conflict worth a human look. The roll rules are declared parameters with labeled defaults, never a jurisdiction table this pack maintains, because baking one in would be exactly the kind of standing legal-rules duty this suite avoids.
The evidence bundle. The Stage 2 receipt's execution hash goes in, along with your declaration of which verification gates the receipt trail has passed, and out comes a shareable bundle stamped OCG-Verify, OCG-Execute, or OCG-Prove, whichever tier those declared results support. Because Stage 2's own receipt already carries Stage 1's hash in its parent-hash chain, wrapping the later receipt covers the reconciliation evidence too. The label re-expresses gate outcomes you declare; it re-runs nothing and mints no new trust claim.
Stage 1's subject is the statement period: it gets exactly one verdict. Stage 2's subject is the individual docket record: each one gets exactly one status, not the docket as a whole. Neither vocabulary is a reading rule this guide adds; both come straight from the node that computed them. Keeping the two apart is deliberate: a period that is RECONCILED can still carry a record that is OVERDUE, and a single combined status would hide that.
| The receipt proves | The receipt does NOT prove |
|---|---|
| That the declared bank, trust-ledger, and per-client balances, measured against each other and against each client's declared period activity, produce the recorded three-way verdict and any recorded negative-balance findings. | That the declared balances are real, that the money sits where the trust ledger says it does, or that the declared client entries reflect actual transactions. A ledger copied from a faulty export checks out exactly as well as a true one. |
| That every declared docket record was tested against the declared as-of date and roll rules and produced the recorded status, with the weekend and holiday roll shown step by step. | That the docket itself is complete. A matter deadline that was never entered cannot be swept, and this pack has no way to know one is missing. |
| That the evidence bundle's tier label matches the gate results declared for the receipt trail, per the cumulative SIDECAR.1 tiers. | That any gate actually passed, or that any CTAPP requirement has been satisfied. The label re-expresses your declaration; a wrong declaration produces a confidently wrong label. |
That a third party can replay the same arithmetic from the same declared inputs and reach the same execution_hash for each stage. | That a trust-accounting duty has been discharged, that any filing obligation is satisfied, or that any docket item still carries legal effect. |
Carried here as orientation, not restated as facts of our own. Confirm current statutory and rule text with the State Bar and your own counsel before relying on any of it.
As read on 2026-08-08: California Business and Professions Code section 6091.3 requires an active State Bar of California licensee who holds client funds to certify compliance with trust-account recordkeeping. The State Bar's Client Trust Account Protection Program ties that certification to a self-assessment and, for accounts selected under its risk-based criteria, a compliance review. This pack produces evidence a licensee can hold for that certification and review; it does not perform either one and does not claim to satisfy either on its own.
The matter-closeout workflow, the point where a matter's SSHSIG countersignature and a Helm workspace record tie the reconciliation and docket receipts to the matter's actual closing, is a deliberate second phase, waiting on the Helm matter-workspace artifact, and is not part of what ships here. Phase 1 stops at the two receipts and the evidence bundle.