well_retry_period_matching

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

Ask Well to look again for the bank payment behind a fiscal period's invoices that are marked paid with no confirmed bank payment, now. The automatic pass looks again at an invoice only when new bank activity arrives, so do not wait for it. Call it when `well_list_period_unmatched_invoices` shows `unmatched_count` above 0 for the period and the user asked to fix the gaps. It takes the period only. Well picks the invoices on its side, from the period's unmatched invoices (at most 20 per call, in a fixed order); you never pass invoice ids. An invoice whose matching is already queued or running is skipped, so a repeat call while it runs adds nothing; call it once per ask. The call itself books nothing. It only queues the matching, so it returns before any match lands: never say the gap is fixed. A match the matcher confirms later posts its payment journal like any automatic match, so do not tell the user that nothing will be posted. Say Well is looking again for `enqueued_invoice_ids`, and name each `skipped` invoice with its reason (`not_found`, `already_matched`, `already_queued`, `dispatch_failed`). `not_attempted_count` is the part of the period's unmatched invoices this call did not send. This call does not retry them, and the automatic pass re-checks them only when new bank activity arrives: do not tell the user they are covered. Read the period again later to see what matched. Take `fiscal_year` and `fiscal_period` from a `well_list_period_unmatched_invoices` or `well_list_periods` entry; never derive them from a calendar month yourself. **`success: false` means nothing was sent.** Never report a failed call as a retry in progress. When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.