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):
CashDueFRB (gl-1010-cash-due-frb) — SNB's master settlement balance with the Federal Reserve. Every net-settled flow (ACH origination, wire settlement, daily cash concentration sweep, card-acquiring net settlement) ultimately credits or debits this account. Drift here means SNB's view of its FRB balance and the Fed statement disagree — a regulatory exposure.
ACHOrigSettlement (gl-1810-ach-orig-settlement) — Holding account for the daily ACH origination batch before it sweeps to the Fed. Activity nets to zero each cycle; a non-zero EOD balance means a batch leg failed to settle as scheduled.
CardAcquiringSettlement (gl-1815-card-acquiring-settlement) — Pass-through GL for daily card-processor settlements. Card authorizations debit here when the processor force-posts; the offsetting credit lands on the customer's DDA when SNB matches the auth to a card transaction.
WireSettlementSuspense (gl-1820-wire-settlement-suspense) — Holding account for inbound wires awaiting Fedwire confirmation and outbound wires awaiting beneficiary bank acknowledgment. A wire is fully reconciled when both legs have posted; rows stuck here past the same-day cutoff are reconciliation work.
InternalTransferSuspense (gl-1830-internal-transfer-suspense) — Two-step suspense for on-us transfers. The source DDA debits here, then the destination DDA credits from here, allowing the two halves to be authorized independently. A non-zero balance means a credit-half is stuck — the source-DDA owner's money is in flight.
MerchantPayableClearing (gl-1840-merchant-payable-clearing) — Holding GL for merchant-acquiring settlement. Card sales (every MerchantCardSale firing) credit here as the card network delivers the funds; merchant payouts (one of MerchantPayoutACH / Wire / Check, per the XOR chain) debit here when SNB releases the held balance to the merchant. Per-merchant balance equals sales-not-yet-paid-out.
ConcentrationMaster (gl-1850-cash-concentration-master) — Concentration target for SNB's ZBA (zero-balance account) operating sub-accounts. Every operating sub-account sweeps its EOD balance to this master; the master then makes a single aggregate transfer to the Fed. Reduces wire and ACH count vs. settling per sub-account.
InternalSuspenseRecon (gl-1899-internal-suspense-recon) — General-purpose suspense GL for entries that don't fit a more specific suspense account. Manual reconciliation entries (research adjustments, stale-suspense reclassifications) flow through here. Should be empty or near-empty on any given day.
DDAControl (gl-2010-dda-control) — Aggregate GL for all customer demand-deposit accounts. The customer DDA template (CustomerDDA role) rolls up to this control account. SNB's regulatory deposits balance is the sum of the children minus float in the suspense GLs.
MerchantDDAControl (gl-2020-merchant-dda-control) — Aggregate GL for all merchant demand-deposit accounts. Mirrors the customer DDA control but tracks the merchant-acquiring book (merchants who hold an SNB DDA receive ACH payouts directly to it; merchants banking elsewhere get wire / check payouts to external counterparties). Per-merchant LimitSchedules cap outbound payout flow per type.
CustomerDDA (template) — Per-customer demand-deposit account. One runtime instance per retail or commercial customer; the account number and name are supplied by SNB's onboarding ETL. Balance and transaction activity are reconciled per-customer; the DDA Control GL is the aggregate roll-up.
MerchantDDA (template) — Per-merchant demand-deposit account. Merchants who bank at SNB receive their card-sales payouts directly via the MerchantPayoutACH rail (one of the XOR payout vehicles). Merchants banking elsewhere get MerchantPayoutWire / Check to an external counterparty instead.
ZBASubAccount (template) — Operating sub-account under the cash-concentration master. Each ZBA location (a customer's main location, a separate operating site, etc.) has its own sub-account; nightly sweeps zero them and consolidate the balance at the master.
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.
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.