pennylane-analysislisted

# Analysis and work lists **Prerequisite: `pennylane-access`.** Read scopes: `transactions:readonly`, `supplier_invoices:readonly`, `customer_invoices:readonly`, `ledger_entries:readonly`, `categories:readonly`, `trial_balance:readonly`. **This skill writes nothing.** It produces findings and work lists. As soon as action is needed, hand over to `pennylane-reconciliation`, `pennylane-supplier-invoices` or `pennylane-customer-invoices`. ## 1. The structural constraint **The API filters very little.** On transactions, only `id`, `bank_account_id`, `journal_id` and `date` are filterable server-side — **not** amount, label, counterparty, nor reconciliation state. On customer invoices, neither `paid` nor `status`. On bank accounts, no filter at all. Consequence: **fetch a date range, analyse in memory.** Hence: - always bound by `date` — the only filter that meaningfully reduces volume; - `limit` at 100 (1000 on `ledger_accounts`, `trial_balance`, changelogs); - re-send `filter` on **every** page — `PLGetAll` does; by hand, the omission returns unfiltered results **with no error**; - do not sweep all `ledger_entry_lines`: timeout risk. Initial export, then `GET /changelogs/ledger_entry_lines` differentially (**4-week retention**). ## 2. The reports most often needed ### Transactions to justify ```powershell $tx = PLGetAll 'company-a' 'transactions' @( @{ field = 'date'; operator = 'gteq'; value = '2026-01-01' } ) $tx | Where-Object { $_.attachment_required } | Sel