well_measure_recurring_inflows

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

Measure who pays the workspace on a regular cadence, from its bank and credit card inflows: each recurring payer, its cadence, what it brings in per month, and the total per currency. It draws no card. Call it when a cash forecast should count the inflows that keep arriving, or when the user asks which customers pay them regularly. For a forecast, pass the `forecast_inflows` entry of the forecast's currency to `well_render_cash_forecast` as `recurring_inflow`, as it is. When `forecast_inflows` holds no entry in that currency, no recurring inflow was found: draw the worst case with no `recurring_inflow` and say so. **The server applies every rule, and the result states each one in `rules`.** Quote the figures as returned: never recompute an amount, a total or a cadence, never add a payer the person expects, and never add a one-off payment, an invoice not yet paid or a deal to the figure. Every amount in the result is in the major units of its currency, never in cents: `1860` is 1,860.00 EUR, not 18.60 EUR. The window is fixed: the last 24 complete calendar months in UTC and the running month. `measured_through` is the last complete month. What the result is: - `recurring_inflows`: the payers on a cadence (monthly, bimonthly, quarterly, yearly), largest amount per month first, at most 50; `recurring_inflow_count` is the full count. Each carries its cadence evidence, its amount pattern (fixed, changed, varying), the amount per month, its latest month, `possibly_ended` and its category. - `totals`: per currency, the payer count, the amount per month of every recurring payer (a quarterly or yearly payment spread over its months), the part from payers flagged as possibly ended, and `forecast_floor_per_month`, the inflow that arrives in every month. - `forecast_inflows`: per currency with a positive `forecast_floor_per_month`, the `{ amount, currency, measured_through }` the cash forecast takes. It is a floor that holds month by month, so it counts only payers on a MONTHLY cadence that may not have stopped and that paid in every month of their span: every payer counts at its smallest month (the smallest amount it paid in a month of the window), never the mean. Payers on a bimonthly, quarterly or yearly cadence, and monthly payers that skipped a month (a gap of 2 in their evidence), are in `totals` and NOT in `forecast_inflows`, because they pay in some months only. A payer whose latest payment is neither in the last complete month nor in the running month is not in it either. Payers that may have stopped, payments on no cadence, possible duplicates and unattributed inflows are not in it either. Say that these were left out. - `not_recurring_count`, `possible_duplicate_count` and `unattributed`: what was paid in but is in no total. - `excluded`: what fell out, counted apart. `internal_transfers` are movements between the workspace's own accounts. `payments_from_own_accounts` are drawdowns from an owned loan, `own_company` money in from the workspace's own company, `category_excluded` the inflows whose category is a transfer, treasury, financing or tax key (`category_keys`), `unreadable_rows` rows with no readable amount or currency, `no_asset_movement` rows with no leg on an owned bank account or credit card. A `null` count was not measured, which is not zero. `partial: true` means nothing was measured: the read was cut short, or the workspace holds no bank account and no credit card. `forecast_inflows` is then empty: say so rather than reporting no recurring inflow. `rows_truncated: true` means the smallest counterparties were not read, so every total is a floor. `scope` is required: `own_and_adopted` is the population the burn counts, `own` the workspace's own rows only. Use the scope the forecast's burn used. 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.