List every account on the workspace with its stored balance. Rows only — this tool holds no definition of cash, and returns no figure the app renders.

Use it when you are computing a cash figure whose RULES you are stating yourself: which accounts belong to the business, which account types count as cash, which stored field is "the balance", what each currency converts at. The server derives no cash position of its own from this call, so a cash figure starts here: state the rules, keep exactly the rows they admit, then put the result on a card with well_render_cash_position — or, when the answer is cash month by month rather than one total, with well_render_cash_forecast.

It applies no scope. Every active account comes back, including ones you will almost certainly exclude. ownership is workspace, counterparty or unknown, and it decides membership together with company_id:

• workspace — the business's own, EXCEPT when own_company_id is set AND the row names a different company. A row with no company_id is trusted, because a connector tags a row before any holder is known; so is a row naming a company while own_company_id is still null, because nothing has disproved the pairing yet. Only a tag contradicting a resolved anchor is stale, and counting that one widens the owned scope and overstates the figure.

• counterparty — not the business's, unconditionally. A counterparty row's balance, or its absence, is never reported: a null there is expected, not a missing reading, and its cash_exclusion_reason says nothing to report. Never report its balance gap or its state: do not call it missing, waiting, unclassified or syncing. At most count it.

• unknown — unsettled, and settled ONLY by the anchor: own when company_id equals own_company_id, a counterparty's when it names a different one.

own_company_id is null when the workspace has not set one. Nothing is settled against it then — no unknown row, and no workspace row's company pairing either — so say so rather than counting or dropping on a guess. This is the same three-way rule the app's own canvas account scope applies, and a figure that departs from it disagrees with the number the product shows.

It applies no type filter. account_type is one of deposit, credit, loan, investment, payroll, other. A credit or loan account is a liability, so its balance normally nets out of cash rather than adding to it — but that is your decision to state, not a fact about the row, and the sign stored is the sign the provider sent.

It returns both amounts. closing_booked is SETTLED cash; closing_value includes pending and uncleared movements. The two differ by every initiated-but-unsettled payment, so which one you total is the single most consequential choice a cash figure makes: state it. opening_booked is the fallback for a freshly-opened balance with no settled activity yet. Any of them is null when the stored value was absent or not a finite number, which is not a zero balance.

One field for every account. A balance per account is closing_booked, or opening_booked when closing_booked is null. Read that same field on every row, deposit, credit and loan alike. Never quote closing_value as one account's balance: on a credit or loan account it can hold the provider's available figure (the unused credit line), which is not a balance. Quote closing_value only when the person asks for available funds, and then for every account.

It converts nothing. Each reading carries its own currency, which can differ from the account's own account_currency. Convert per row at the stored rate for that currency as of the reading, read from exchange_rates and never estimated, then total — a sum across currencies is denominated in nothing and no field here would say it happened.

It lists each copy of an account. One physical account can arrive once per connector that syncs it. duplicate_of_account_id names the account a row is a second copy of, and is null on every other row. Leave a marked row out of every total and every count: the balance that counts is the named account's, which is the one the app's own figure reads, and the transactions of both copies are counted once. Total both copies and the figure holds that money twice. When the named account has no readable balance, report it as having none rather than taking the copy's reading in its place, or the figure departs from the app's. Marking follows the ownership rule above: only the business's own accounts are marked, and an unknown row only once own_company_id settles it.

institution_name is the bank that holds the account: the bank company Well identified, else the connector that syncs the account. When the person names a bank ("how much at Chase"), keep the rows whose institution_name is that bank; account_name is the label the provider sends and often does not name the bank.

source_workspace_connector_id is the workspace_connector_id of the connection that syncs the row, or null when no connection does. A live read on that same connection (well_invoke_connector_tool, well_get_investment_holdings) reads the same money as the row: never add both.

unlinked_accounts: true marks a row that carries ZERO weight in cash, and cash_exclusion_reason says why. It is present only on such a row, and its value is one of three:

• unbound_mirror — a proven mirror of an account already in the list: a second connector's view of the same physical account, counted through the other row.

• bound — an alias of another account in the list; that account, the keeper, carries the weight.

• pending — an arrival not yet judged to be a new currency pocket or a duplicate of an account already listed. It counts for nothing until that is settled, so keep it out and, for a row the ownership rule admits, say it is waiting rather than calling it a duplicate. A counterparty row in this state is not waiting for anything: say nothing about it.

A row with no cash_exclusion_reason is counted. Like a duplicate_of_account_id row, an excluded row is listed and flagged, never dropped: keep it out of every total and every count, and when you tell the reader what was left out, give its reason in plain words. Its balance still reads as stored.

balance is null when no row was selected for that account. Two different situations produce it and they must not be reported the same way: verification_rejected: true means the newest balance failed verification and the bounded walk back found no verified one, so the data is repudiated; false means the account simply has no history yet. This applies to the business's own accounts only: a counterparty row's null balance is expected, never a reading to report.

months_back adds month_ends to every row: one reading per complete month end, oldest first, keyed YYYY-MM, ending on the last COMPLETE month. This series is where a cash forecast starts — "what will our cash look like", "project our cash forward", "when do we hit zero" — and it is the settled half of well_render_cash_forecast; the projected half is that series' last settled month minus the burn you measure with well_sum_transactions. A null reading is a month no stored row covered — not a zero balance, so never plot it as one and never interpolate between two real points. Omit months_back for the current reading alone; the series is a second query and is not free.

partial: true means the read was cut short BEFORE RETURNING ANYTHING, so it always arrives with an empty rows — it is a fact about the call, never a coverage figure over rows you received. Nothing is known about what is there, so derive no figure from it: say the read was cut short and offer to try again. unreadable_rows is the separate case and the only one that continues: the read finished, and that many rows carried a stored balance that could not be parsed. They hold a null balance, sit in no figure, and make any total a floor, by up to their count: the count covers every row, whatever its owner or type.

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.