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.