Account Balance Drift?

Stored vs computed balance disagreements at end-of-day. Leaf table covers individual posting accounts — ledger drift (computed = cumulative net of every Money record through that BusinessDay's end; stored ≠ computed ⇒ ledger doesn't agree with the postings). Ledger table covers parent accounts — aggregation drift (computed = sum of child accounts' stored balances; stored ≠ computed ⇒ rollup doesn't match the children). Both tables only show rows where stored ≠ computed — every row is one SHOULD-constraint violation. Distinct from Daily Statement's "Posting Drift" KPI (single-day flow drift); both are correct, they answer different questions at different time grains.



Internal Accounts in Scope
Accounts where drift is checked — drift surfaces where stored balance disagrees with the cumulative net of posted Money records (leaf) or the sum of child stored balances (parent):

Leaf Account-Days in Drift

Count of leaf-account day-rows where stored balance disagrees with the cumulative net of posted Money records in the current date window.

Largest Leaf Drift (anywhere in window)

Max |drift| across any single leaf-account day-row in the current date window. Sibling of the count KPI — count + magnitude together prevent the failure mode where a SUM-based KPI cancels positives + negatives to ~0 while per-account drifts remain non-trivial. Distinct from Drift Timelines' "Largest Leaf Drift Day" KPI, which is the peak Σ|drift| on the worst single business day (day-grain rollup) — this one is the peak account-day (row-grain peak). The ✓/✗ glyph next to the number is the accessible state signal — green ✓ when the largest absolute drift in the window is $0, red ✗ otherwise.

Parent Account-Days in Drift

Count of parent-account day-rows where stored balance disagrees with the sum of child accounts' stored balances. Demos with the bundled sasquatch_pr fixture show a persistent ~$2.8M ledger drift on gl-2010-dda-control — that's the Drift Parent (DDAControl) plant, the L1 SPEC example showing cross-boundary drift propagation. Real deploys should see 0 here unless there's a real ledger rollup gap.

Largest Parent Drift (anywhere in window)

Max |drift| across any single parent-account day-row in the current date window. Sibling magnitude KPI to the Parent count — see Leaf sibling subtitle for rationale. Distinct from Drift Timelines' "Largest Parent Drift Day" — that one rolls up to a per-business-day Σ before taking the max, so it answers "worst SINGLE day in the window" rather than "worst single account-day row". The ✓/✗ glyph next to the number is the accessible state signal — green ✓ when the largest parent drift in the window is $0, red ✗ otherwise. Closed-loop pool note: demo pools accumulate pre-settlement value at the parent layer by design (the SPEC's L1 example); a persistent non-zero parent drift on a known pool account is expected for the demo seed, not a real ledger gap.

Leaf Account Drift

Each leaf account's stored vs computed balance per BusinessDay. Computed = cumulative Σ signed Money through that day's end. Drift = stored − computed; non-zero ⇒ feed diverged from the underlying ledger. Right-click any row → View Daily Statement to open that account-day.

Parent Account Drift

Each parent account's stored vs computed balance per BusinessDay. Computed = Σ stored balances of its child accounts on that day. Drift = stored − computed; non-zero ⇒ a child posting didn't roll up correctly. Right-click any row → View Daily Statement to open that account-day.



Sub-ledger drift

For every internal leaf Account, on EVERY business day — emitted or carried — Drift(Account, BusinessDay) SHOULD equal 0.

Each leaf-account day where the effective stored balance disagrees with the cumulative net of every Posted Money record posted to that account through the BusinessDay's end. A balance entry is the source of the account's balance UNTIL a newer entry supersedes it, so days between emits carry the last claim forward and are checked too — a posting that lands on a quiet day moves the computed side while the carried claim stands still, and that gap is drift the same as on an emit day. The carried day's cutoff keeps the last loaded balance day's END time: an account whose business day ends 17:00 keeps a 17:00 cutover on every quiet day until the next loaded balance row (a leg posting after the carried cutover belongs to the next day's check). The disagreement is the *drift*; a non-zero value signals the feed diverged from the underlying ledger. The computed side sums from account origin (no opening-balance term) — see Schema v6's zero-start precondition for what that demands of a mid-history cutover.

Columns: account_id, account_name, account_role, account_parent_role, business_day_start, business_day_end, stored_balance, computed_balance, drift.

Action. Diff the day's transactions for account_id against the stored balance — the gap is missing or duplicated postings on that account-day. Re-load the source feed for the account-day and refresh matviews.



Parent-account roll-up drift

For every CurrentStoredBalance where Account.Scope = Internal and IsParent(Account), LedgerDrift(Account, BusinessDay) SHOULD equal 0.

Each parent-account day where the stored balance disagrees with the sum of its child accounts' stored balances PLUS the parent's own direct Posted postings (a parent GL can carry activity of its own; those legs count toward its expected position alongside the child roll-up). Surfaces a child posting that didn't roll up correctly to its parent — or a direct parent posting the stored balance never absorbed.

Columns: same as _drift minus account_parent_role (parents ARE the parents).

Action. Sum the child accounts of account_id on business_day_start and compare to the parent's stored balance. The gap is a child posting that didn't propagate to the parent — usually a missing FK in the feed. Fix the parent link upstream, re-load, refresh.