> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # Plan & Billing > Open Plan & Billing in an agent host, read an organization's billing, accept Terms, set up payment and find who can change what. Plan & Billing is where an organization sees its commercial standing: the Terms it has accepted, how it pays, the plan it is on, the offer it can accept, its renewal, its recent invoices and the one next step, if any, that keeps billing in good standing. In an agent host it is a Page, and every fact the Page shows is also available to an agent through `get`. ## Open the Page Call `open_page` with `{ "page": "plan_and_billing" }`. It is available to Buyer, Seller and Organization accounts. The opening call changes nothing. The Page reads the organization of the selected account itself, so you do not pass an organization. A person can do the work that needs a human in the Page: review and accept the current Terms, and set up where a Seller is paid. Bank details are typed into the Page and never pass through the model. ## Read billing from an agent `get` with `{ "kind": "billing" }` returns the organization's billing in one read. It takes no ID, filter or include. It always reads the organization of the selected account, so check `object.organization.customerId` before you act on it. [Billing: plan and invoices](/v3/billing-plan-and-invoices) lists every field. Start with `nextAction`: the server names the next step, so a caller never works it out from raw fields. `nextAction.type` is `NONE` when nothing is owed. Any other type is the step to take, in this order: accept Terms, accept the governing agreement, choose a plan, add billing details, then set up payment. `nextAction.severity` is `success` or `warning`, and `nextAction.canCompleteInChat` is `true` only when the step is accepting Terms and the signed-in person can do it from this session. ## What you can do | To do this | Use | | - | - | | Accept the current Terms, or choose payment terms | `save_billing`. See [Check and complete Terms setup in text-only chat](/v2/setup/v3/tool-reference#check-and-complete-terms-setup-in-text-only-chat). | | Start card setup for the organization | `request_payment_authority`, then `confirm_payment_authority`. The person completes the card on a hosted page, and the status comes back in the next `get`. | | Set up where a Seller is paid | The Plan & Billing Page. Payout details are never written by an agent call. | Every write needs an authenticated user with direct authority on the organization. An administrator of a child account does not have that authority over its parent organization. A write that names a Terms version is refused when that version is no longer current, and nothing changes. Read again, then ask the person to review the new version. ## When another organization manages billing A member of an account whose organization manages its billing, and who is not one of that organization's administrators, does not get a failure from the read. `get` returns the organization that manages billing and `changeableBy: "organization_administrator"`, and the Page shows the same message. Only an administrator of the managing organization can view or change its billing. See [Response variants](/v3/response-variants). ## Plans and pricing How plans, included IUs, the IU price and renewal work is described in [Organization IU Rate Card](/v2/buyer/billing/organization-iu-rate-card). The read returns the plan in force, an accepted plan that starts at the end of the term, and the offer the organization can accept at its exact version. ## What stays out of an agent call Card numbers, processor secrets, setup tokens, hosted payment links and bank details never appear in a read or pass through the model. Public Terms and documentation links do appear. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.