Get Billing Status

Authoritative inference-admission result computed by the server. Frontend refusal surfaces must consume this field rather than re-deriving it from payment or balance details.

Authoritative wallet balance the inference gate will honour, in credits. Frontend balance surfaces MUST consume this field so the display matches the wallet the request path spends.

The team's exact ledger balance — the most recent monthly snapshot plus every entry since it — in dollars, not credits. Decimal, not float, matching the ledger EDD's invariant 8 ('Money is Decimal end to end... No float on any path that touches a balance') and the sibling LedgerBalanceResponse.total this value is sourced from (billing/ledger/balance.py::read_exact_balance). This is the EDD's 'display, disputes, and reconciliation' number, distinct from spendable_credit_balance on purpose: that field mirrors the aggregator cache admission reads, which can lag a real top-up or debit by up to one fold cycle (ENG-7048). Frontend balance surfaces that render a dollar figure to the user MUST prefer this field; surfaces that decide whether a spend would be admitted (the zero-balance CTA, funding gates) MUST keep reading spendable_credit_balance so the decision never disagrees with the gate. None only when the caller has no active team.

Whether the admission gate will still serve this team with the visible balance at or below zero, because auto-refill is on and the overdraft floor has headroom left. Surfaces exist to stop the UI announcing 'out of funds' during the seconds between the balance reaching zero and the refill landing, which invites a second manual payment for a top-up already being collected. Computed server-side from the same headroom_to_floor the request path reads, so the copy cannot drift from the gate.