# Members and billing

Two screens sit outside a project, because they are about the organization rather than about one piece of work: **Members** and **Billing**. Both are reached from the organization switcher in the console header.

## The shape of an account

An organization owns projects. A project owns keys, rules, connected accounts, and receipts. A person is a member of an organization, and separately has a role on each project they can reach.

Most accounts are one organization with one or two projects, usually one for real work and one to try things in. Splitting by project is how you keep a test run from touching real accounts: nothing crosses a project boundary, in either direction.

## Roles

Four roles, and what each means depends on whether it is held on the organization or on a project.

| Role | On the organization | On a project |
|---|---|---|
| Admin | Invites and removes people, changes roles, creates projects, manages billing, and reaches every project as an admin | Everything below, plus the project's own settings |
| Approver | Nothing organization-wide | Writes the rules, releases approvals, resets what a tool has learned |
| Agent | Nothing organization-wide | Searches, describes, acts, submits work, reads receipts |
| Viewer | Reads the member list and the invoices | Reads without changing anything |

One person in the organization is also its owner. That is a single fact rather than a fifth role, and it decides who may hand the organization to somebody else and who may delete it.

The approver and agent split is the one that matters for safety, and it is the same split your keys carry. Give your assistant an agent key; keep the approver key where a person uses it. See [Policies](./policies.md).

## Inviting somebody

Invite by email, choosing their organization role and, in the same act, the projects they should reach and with what role on each. They accept from the link, and if they have no account yet the link creates one.

An invitation is pending until it is accepted, and you can revoke it while it is. An invitation nobody accepts expires on its own.

The screen also carries the administrative record: who invited whom, who joined, who changed a role, and who was removed. It is readable by any member, which is deliberate: a membership change nobody can see is a membership change nobody can question.

## Organization settings

Three things live there.

**The name**, which is what appears in the switcher.

**How long a session lasts.** Lowering it signs people out sooner across the whole organization.

**Who owns it.** Transferring ownership needs the person receiving it to accept, so it cannot be done to somebody.

## Billing

The Billing screen shows the plan, what has been used against the meter, and the invoices.

Usage is metered from the same receipts everything else reads, so what you are billed for and what the receipts say are one number rather than two.

From that screen you can change plan, open the payment portal, set the address invoices go to, and put a purchase order number on them where your finance team needs one.

Spending ceilings are a different thing from a plan, and they live in the rules rather than here. A ceiling stops work before it runs; a plan is what you pay for the work that did. See [Policies](./policies.md).