Premium books tier
Close + Attest
Lawenots Close Graph coupled to settlement anchors and portal daily attestation — marketed as attestation, not custody.
$399 / yr
Product spine
Close Graph
A period-close model where each close input is a weighted readiness gate with evidence — not scattered checklist folklore.
In production today, Close Graph readiness is computed from DB-backed gates: categorized transactions, pending review, bank reconciliations, ledger balance, open AR (SENT invoices), and open AP (APPROVED bills). Imported Stripe/payroll expectation feeds and hash-chained carry-forward notes are on the roadmap — shown below as such, not as shipped workspace features.
Node lifecycle
Transaction
shippedPlaid row, CSV import, exchange/on-chain activity
Must be categorized with no pending-review rows before close.
Reconciliation item
shippedBank reconciliation difference, duplicate suspect, feed gap
Open or in-progress reconciliations block close.
Invoice / AR expectation
shippedCustomer invoices in SENT status (AR posted to GL until paid)
SENT invoices are open AR close blockers; Mark Sent posts Dr AR / Cr Revenue; Mark Paid applies cash.
Bill / AP expectation
shippedVendor bills in APPROVED status (AP posted to GL until paid)
APPROVED bills are open AP close blockers; Approve posts Dr Expense / Cr AP; Mark Paid clears AP.
Compensation expectation
roadmapGusto/Deel/ADP/PEO register import, contractor accrual (import evaluators)
Evaluator + Verify taxonomy exist; not yet a persisted readiness gate in the workspace close score.
Settlement anchor
roadmapShould-settle vs did-settle evidence (Plaid ACH, Stripe payout, on-chain) via the Verify evaluator
Verify evaluator only — not yet a persisted readiness gate in the workspace close score.
Tax remittance expectation
roadmapStripe Tax report import (manual CSV or auto-fetched via report-ready webhook) vs filing/remittance evidence
Verify evaluator only — not yet a persisted readiness gate in the workspace close score.
Crypto tax export match
shippedKoinly / CoinTracker / ZenLedger CSV ingest — lots, disposals, income, 1099-DA proceeds vs books disposals
When crypto-tax vendor data is present, unmatched 1099-DA vs disposal proceeds block close.
Readiness formula
readiness = round((sum(weight for passed nodes) / sum(all node weights)) * 100)
Shipped gates block close when they fail. Roadmap node types (compensation imports, hashed carry-forward) are labeled separately and do not yet change the production score.
Carry-forward with content-hashed note (roadmap)
Planned as a first-class graph transition with hashed operator notes in the evidence package. Today, open AR/AP and recon items must be cleared (paid/voided/completed) or they block close.
Evidence package
- Period readiness checks (weights, pass/fail, issue classes)
- Locked trial balance and statement exports
- Lawenots Verify findings for import / native close
- AR/AP invoice and bill status with GL journal references when posted
- Export receipts with SHA-256 content hashes and source revision
- Close + Attest metadata when enabled (Merkle root, Ed25519 signature, public key id)
- Roadmap: serialized subgraph with hash-chained node timeline + carry-forward notes
Hash-chained close timeline (roadmap)
Planned: every graph mutation records previousEventHash + eventBodyHash + actor + timestamp. Today, audit activity logs and readiness checklists are the shipped evidence trail.
{
"eventId": "evt_close_01HW...",
"nodeId": "node_txn_9421",
"transition": "matched -> settled",
"actor": "user_123",
"previousEventHash": "b83f...19aa",
"eventBodyHash": "ad91...0e7c",
"eventHash": "1c4d...91bf"
}[
{
"id": "check_categorized",
"type": "transaction",
"state": "settled",
"label": "All period transactions categorized",
"weight": 20,
"maturity": "shipped"
},
{
"id": "check_reconciliation",
"type": "reconciliation_item",
"state": "matched",
"label": "Bank reconciliations completed",
"weight": 20,
"maturity": "shipped"
},
{
"id": "check_ar",
"type": "ar_expectation",
"state": "open",
"label": "SENT invoice INV-12 unpaid",
"weight": 10,
"maturity": "shipped"
},
{
"id": "check_ap",
"type": "ap_expectation",
"state": "open",
"label": "APPROVED bill BILL-4 unpaid",
"weight": 10,
"maturity": "shipped"
}
]{
"period": "2026-05",
"closePolicyVersion": "close-graph-v1-shipped-gates",
"readinessFormula": "readiness = round((sum(weight for passed nodes) / sum(all node weights)) * 100)",
"canonicalLedger": "single books ledger for transactions and AR/AP journals",
"shippedGates": [
"categorized",
"pending",
"reconciliation",
"ledger",
"ar_expectation",
"ap_expectation"
],
"evidencePackage": "readiness checks + locked trial balance + AR/AP GL refs + export receipts + optional attestation metadata"
}Publishable methodology: Close Graph formula and evidence model →
Close feeds
Revenue, settlement, compensation, and tax remittance feeds one close engine
Lawenots is not a bill-pay rail, payroll tax engine, or tax remittance service. Customer invoices and vendor bills post to the GL and feed shipped AR/AP readiness gates. Imported Stripe/settlement/comp/tax expectation evaluators exist for Verify; settlement, compensation, and tax remittance import nodes remain roadmap for the production close score.
Expectation objects
Shipped: invoices and bills as AR/AP close gates with GL journals. Roadmap: imported provider expectations (Stripe MRR, payroll registers, Stripe Tax collected-vs-remitted) as the same weighted readiness rollup.
Revenue / AR
nodeType: ar_expectation
shippedExpected: Customer invoices (Mark Sent posts AR)
Observed: Mark Paid applies cash against AR; bank deposits remain in the ledger
Blocker: SENT invoices unpaid at close
Shipped GL + readiness gate — not a full invoicing suite
Settlement reconciliation
nodeType: settlement_anchor
roadmapExpected: Imported settlement events that should couple to GL
Observed: GL references on settlement anchors
Blocker: Should-settle vs did-settle / missing GL refs
Roadmap for production close score — Verify evaluator today
Compensation reconciliation
nodeType: comp_expectation
roadmapExpected: Comp run-rate and provider register imports (Gusto, Deel, ADP, PEO)
Observed: Posted GL and register rows (evaluator path)
Blocker: Register / GL discrepancy by close
Roadmap for production close score — Verify evaluator today
Tax remittance reconciliation
nodeType: tax_expectation
roadmapExpected: Tax collected per jurisdiction/period (Stripe Tax report import)
Observed: Filing/remittance confirmation evidence per jurisdiction
Blocker: Collected-but-unremitted tax at close / remittance amount variance
Roadmap for production close score — Verify evaluator today
Crypto-leg evidence reuse
Crypto legs carry tx hash + FMV as evidence, reuse the lot and 8949 machinery, and can emit an outflow event into allocation drift when that module is provisioned.
{
"id": "exp_settlement_usdc_2026_05_01",
"module": "settlement",
"provider": "Ethereum",
"closeGraphNodeType": "settlement_anchor",
"expectedAmount": 1200,
"currency": "USD",
"expectedAt": "2026-05-28T17:00:00Z",
"evidence": {
"txHash": "0x7e3a...91bc",
"fmvUsd": 1200,
"ledgerReference": "gl_44291"
}
}Lawenots Verify
Lawenots can review any books — and close them
Import QuickBooks, Xero, or CSV. Lawenots Verify surfaces close blockers, scores readiness, and returns a hashed readiness report that looks like a real close package. Works even if the client never migrates.
Standalone Close Readiness Check
Import QB / Xero / CSV → Lawenots Verify flags uncategorized rows, duplicates, feed gaps, open recon, lot mismatch, and ledger imbalance → readiness score + fix list.
Firm / CPA mode
A reviewer runs the check across client books they don't own. One CPA, many accounts — the multi-client distribution node.
Mini evidence artifact
Every check produces a content-hashed readiness report with the same receipt look as a full close package — natural upsell to attested close.
Built-in migration path
Every blocker fixed in the check is one step toward running the whole close on Lawenots. Import first; Close Graph when ready.
Import is the top of the funnel. Close Graph is the destination.
Primary proof
Your first attested close is free
Start native or import from QuickBooks. We deliver one real evidence package for your first period — with a verify link your CPA can open without a Lawenots account.
What's in the package
- Locked trial balance
- Issue / blocker list
- Matched ledger extract
- Export receipts
- Public verify link
- Any organization. Start in Lawenots or import QuickBooks data. The first period’s attested close package costs nothing.
- One real package. A locked period export with a public verify link — not a mock walkthrough.
- CPA becomes the salesperson. Share /verify with your accountant. When they trust period one, they ask for it every period.
Free covers period one. Close + Attest ($399/yr) covers ongoing attestation, batch closes, and firm workflows.
Visual proof of correctness
Close → attestation → export receipt
The brand is auditable artifacts, not neon dashboards. Step through what Close + Attest produces — then verify offline with open verification tooling.
Every close input becomes a graph node with a reproducible state: open, matched, settled, attested, or carried forward.
{
"period": "2026-05",
"closePolicyVersion": "close-graph-v1",
"canonicalLedger": "matched/unmatched source of truth",
"nodeStates": {
"open": 1,
"matched": 14,
"settled": 9,
"attested": 4,
"carried_forward": 1
}
}Provable close
What Close + Attest gives you that a PDF export cannot
When you lock a period on the Close + Attest tier, Lawenots signs the export receipt with an Ed25519 key it controls. You get evidence an auditor or CPA can verify independently — not just a spreadsheet snapshot.
1 · Close Graph in Lawenots
Complete checklist-driven close against graph nodes and lock the period. Hash-chained activity log captures every mutation.
2 · Cryptographic proof chain
At export time, Lawenots signs the receipt's content hash with its own Ed25519 key — no third-party signer. Anyone can verify the signature offline with the published public key.
3 · CPA / auditor handoff
Export the serialized period subgraph plus attestation metadata. Operators, firms, and auditors verify evidence packages with MIT open tooling — no Lawenots account required. Attestation, not custody — Lawenots never holds funds.
Example attestation record (illustrative)
period: 2026-05 contentSha256: 8f3a…c21e signature: ed25519-signed bundle signingKeyHash: 4d9e… export: activity log + locked trial balance + export receipt
Open verification
Independently verify Close + Attest evidence
Lawenots publishes verification tooling for Close + Attest so operators, firms, and auditors can independently validate evidence packages without a Lawenots account.
- @lawenots/attestation-verify
Offline Ed25519 signature checks, Merkle root rebuilds, and export-receipt hash verification for proof bundles.
View on GitHub → - @lawenots/schemas
JSON Schema for pipeline attestation, export receipts, period-close checklist items, and evidence manifests.
View on GitHub → - @lawenots/openapi
Versioned OpenAPI 3.1 spec for the public API — books, pricing, and firm portfolio sync.
View on GitHub →
These are verification and contract artifacts — not the full product. Reconciliation matching and allocation drift logic remain proprietary.
What's included
- Close Graph nodes for transactions, recon items, and AR/AP expectations
- Deterministic readiness formula from node weights and states
- Canonical matched/unmatched ledger shared by AR, AP, comp, and settlement references
- Carry-forward transition with content-hashed reviewer note
- Hash-chained close timeline / activity log for SOC 2 evidence packaging
- Lawenots-signed Ed25519 attestation on every export receipt — no third-party signer
Sign in to your books workspace to subscribe. Billed annually — cancel any time from your subscription settings.
Settlement exceptions surface to the principal operator directly — not a Lawenots UI surface. Lawenots anchors funded and released receipts; human override is handled out-of-band by the operator.