well_list_unposted_transactions

io.github.WellApp-ai/well-mcp · Verify this server

List the transactions of a fiscal period that carry a category or a role and have STILL not reached the ledger, so a close can say exactly what is holding it. This is the posting gap, not the categorization gap. A row here already has a category; what it lacks is the ledger account its journal entry would post to. For rows carrying no category at all, use `well_list_uncategorized_window`. Each row carries `transaction_id`, `label`, `amount`, `period_date`, the `current_ledger` already attached where one is, and `ledger_suggestions` — the classifier's proposals, each with the account's `code` (its number, e.g. "6156") beside its name. The `ledger_catalog.accounts` list carries every account this workspace can post to, with the id `well_set_transaction_ledger_account` takes. A row whose `ledger_suggestions` is empty is assigned from that list: the classifier proposed nothing, which is not the same as the row having nowhere to go. **The rows arrive snake_cased** (`period_date`, `ledger_suggestions`, `current_ledger`), unlike `well_list_uncategorized_window`, whose close cousin emits camelCase. A caller reading one shape against the other silently sees empty fields rather than an error. The period is named in FISCAL terms, and a workspace's fiscal calendar need not follow the calendar year — "June 2026" is not reliably fiscal period 6. Take `fiscal_year` and `fiscal_period` from a `well_list_periods` entry, or from the months the user already selected this session; never derive them from a calendar month yourself. Most categories already determine their ledger account: the chart maps each category key to a canonical code, and only a handful abstain because the category alone cannot pick a safe account without the transaction direction. So a long list here usually means the categories are missing, not the accounts. **`success: false` means the period is UNKNOWN, not clear.** The read failed, so no count exists, and an empty `records` on a failed read is not "everything posted". `truncated: true` means the period holds MORE unposted rows than this page carries, so `returned` is a floor rather than the period's total. Narrow the period, or state the count as "at least". When the token authorizes one workspace, call this directly — no other tool call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.