What this sheet teaches. The raw posting ledger — supersession-aware Money records (transaction legs) filtered by the analyst's criteria. Every row is one Money record in its current state — prior versions of overwritten entries don't appear.
A single table scrolls the entire posting ledger one leg per row. No KPIs headline the sheet — the value is "show me the legs I ask for." At the top sit six filter dropdowns: Account, Transfer, Transaction ID, Status, Origin and Transfer Type. Pick any combination and the table narrows to rows matching ALL filters (AND logic). The table shows each leg's account, transfer membership, direction (Debit / Credit), amount in dollars, status (Pending / Posted / Failed), origin (internal or external routing), rail name and posting timestamp. Sorting is by posting time descending, so the most recent activity reads at the top.
The dataset reads directly from the <prefix>_current_transactions (matview — a read-optimized materialized view) — a view of the <prefix>_transactions base table filtered to each Money record's MAX(entry) version only. Supersession is baked in: when an append-only entry gets rewritten, the current view skips the prior versions and shows only the latest. This is the truth the institution posted now, not an audit trail of corrections.
The SQL selects these columns from the matview:
id (renamed to transaction_id) — unique identifier for this Money recordaccount_id, account_name, account_role — identifying the account the leg posts toaccount_parent_role — the account's parent role if it belongs to an aggregate; NULL for leaf accountstransfer_id, transfer_parent_id — the transfer this leg belongs to and its parent if part of a meta-transferrail_name — the named transfer family (ACH, Wire, Check, etc.)amount_money — the leg's amount in dollars (converted from cents at projection)amount_direction — Debit or Creditstatus — Pending / Posted / Failedorigin — how the leg entered the system: InternalInitiated / ExternalForcePosted / ExternalAggregatedposting — the timestamp when the leg recordedSix dropdown filters push predicates into the SQL WHERE clause via dataset parameters. The account_id filter uses the _account_display_clause() pattern (showing accounts with stored daily balances only); the Transaction ID search filters on the matview's id column; the rest use _data_value_clause() with the sentinel-OR guard so "all" defaults to PASS. A universal date-range filter (date start / date end) narrows by posting timestamp, with the upper bound expanded +1 day so same-day non-midnight rows on the end day are included.
Filter to Status = Pending. Look at posting timestamps and calculate the days elapsed. Cross-reference the rail (rail_name column) against the L1 (account-integrity) instance's configuration — each rail carries a max_pending_age threshold (visible on the Pending Aging sheet). A leg sitting in Pending past that cap is one symptom of a stuck-transfer pattern. The Daily Statement's detail table for that account-day may show whether other legs of the same transfer posted or failed.
Filter to a specific transfer_id (visible once you click into one row). If you see both status='Posted' and status='Failed' on different legs of the same transfer, the transfer partially executed — the boundary rejected one leg but the institution's system recorded a balance change anyway. This is the classic boundary-rejection shape the Drift sheet's "Single big magnitude, single account, single day" pattern flags. Drill to Daily Statement for the account-day to see the cumulative impact.
Filter to Transfer Type = <aggregator_rail> and look for rows where status='Posted' but posting is older than the rail's max_unbundled_age cap. These legs made it to the settlement side but the bundler hasn't grouped them yet. The Unbundled Aging sheet surfaces the time-bucketed cohort; here you see the raw timestamps. Compare against the rail's expected cadence (typically a day or two for ACH/wire aggregators).
Look at rows where account_role indicates an external account (bank, payment network, the fed). The origin column tells you which direction the leg came from. Internal-initiated legs show as InternalInitiated; legs forced into the posting ledger by an external actor (ACH file from the Fed, wire settlement from the correspondent bank) show as ExternalForcePosted or ExternalAggregated. This flow pattern is how you spot when an external counterparty unilaterally posted something the institution didn't explicitly initiate.
A blank Transactions sheet means no Money records match your filter criteria. This usually means:
<prefix>_current_transactions row's latest_date. If it lags the base tables' most recent latest_date, the matview hasn't refreshed since postings arrived. Ad-hoc dashboard hits don't trigger a refresh — the institution's ETL pipeline does on its schedule.If App Info shows that latest_date as null or the matview row count as zero across the board, the L1 transaction pipeline didn't run — that's an ops alert, not a "no data" state.
account_id column → Daily Statement (right-click → View Daily Statement for this account-day). Lands on the per-account-per-day narrative for the leg's business day so you can read the full balance walk around that posting.transfer_id cell there). Each narrows this sheet to only the legs of that transfer so you can inspect the full multi-leg structure.{} View metadata entry on the row-drill ⋯ menu; opens a side panel with the row's pretty-printed JSON metadata.First time here? See the Vocabulary for L1, matview, rail, account_role and the other project-specific terms.