well_list_unposted_journals

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

List the transactions AND invoices of a fiscal period whose journal entry a posting retry can still clear on its own — the re-triggerable posting gap. An empty list with `scan_truncated: false` means no re-triggerable row remains in the rows scanned. That is NOT proof the period is posted: this read omits rows halted on a substantive reason a repost cannot clear (a missing ledger account, a tax gate, a locked period), so never declare the period posted on an empty read alone. If the close still reports an unposted blocker for this period, those rows need an accounting decision, not a re-trigger. This is NOT the categorization surface. For a row that still needs a category or a ledger account, use `well_list_unposted_transactions`. This read carries only the rows that are ready to post and simply have not yet: the posting pipeline did not run. It never lists a row halted on a substantive reason (a missing ledger account, a tax gate, a locked period) — a retry only re-fails those, and the categorization and hydration steps own them. Each row carries `source_id`, `source_kind` (`transaction` or `invoice`), `name` (the counterparty composite), `amount`, and `period_date`. **`in_flight_processing: true` means Well is still processing these rows — enrichment (classification, matching, re-extraction) is in flight, so wait and re-read rather than reposting.** Re-read on the close's wait cadence until it is false; only then is the (i)-set settled enough to re-trigger. The paired write is `well_repost_journals`. **`scan_truncated: true` means the (i)-set was read from a bounded slice of the workspace's rows, not all of them.** An empty list under this flag means "no re-triggerable row was found in the rows scanned", NOT "every row is posted" — do not tell the user the close can skip this step on a truncated empty read. The period is named in FISCAL terms, and a workspace's fiscal calendar need not follow the calendar year. 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. **`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". 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.