Skip to main content

​
Canonical settlements register

Books → Settlements at /books/settlements is the canonical register of payments and receipts. Each readable row comes from GET /bankrec/settlements and binds the native settlement record to its exact immutable journal entry, matching evidence, allocation analysis, source documents, and any verified authorization evidence the server publishes. The register is deliberately read-only. The backend publishes no canonical settlement approval or execution endpoint, so the browser offers neither action and does not relabel the legacy QuickBooks task queue as settlement authority.
The current canonical settlements register refusing an invalid pagination order and showing the no-browser-authority notice

The current demo response contradicts the settlement pagination contract. GreatBook refuses the page, names the exact reason, and still explains that no browser approval or execution authority exists.

This is an unretouched capture from the current default-branch UI running against its credential-free demo services. It demonstrates fail-closed behavior; it is not a claim that a live organization’s settlement register is unavailable.

​
What a readable row proves

  • The settlement has a native payment or receipt identity, rail, counterparty, exact amount, currency, and date.
  • A posted claim exists only when the server supplies the exact journal-entry link.
  • Matching and allocation reasons remain visible, including currency, direction, or rail mismatches.
  • Unverifiable authorization evidence is quarantined at the cluster, so the rest of the settlement can remain readable without naming an approver.
A valid VND settlement may therefore remain readable beside USD bank evidence while the mismatch reason explains why the amounts are not comparable. That is evidence of a discrepancy, not permission to manufacture a converted total.

​
What approval would require

A future action must be owned by the backend and must include an enforced decision role, exact-revision confirmation, idempotent receipt, and commit-time refusal of a stale revision. Extra fields in a response cannot opt the browser into authority, and the current frontend intentionally defines no settlement mutation request type or client.

​
Verified at source

  • The GreatBook web repository’s src/lib/settlements.ts defines the response contract, evidence clusters, mismatch rules, and explicit absence of mutation authority.
  • Its src/app/books/settlements/page.tsx renders the register and the no-browser-authority refusal.
  • backend/app/routers/bankrec.py and the settlement service own the canonical read and immutable journal link.
  • Merged web PRs #56–#58 shipped the register, exact authorization evidence, mismatch handling, and bounds.