> ## Documentation Index > Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt > Use this file to discover all available pages before exploring further. # Organization Billing > Understand Starfire AI organization billing accounts, seats, shared credits, usage ownership, and subscription context. # Organization billing Organization billing lets a team own the subscription, credits, seats, and usage context behind shared Starfire work. ## Billing ownership An organization billing account is separate from a member's personal billing account. This distinction matters because team resources should not depend on one employee's personal subscription. ## Seats Business-oriented organization plans can use seat concepts to represent the number of members covered by the organization subscription. Seat rules can affect invitations, member activation, plan changes, and billing. Exact seat pricing and minimums are controlled by the current plan configuration. ## Shared credits Organization usage can draw from a shared credit pool when configured. This allows work performed by different members to be measured against the organization rather than against unrelated personal allowances. Administrators should still be able to understand **who** generated usage and **which workload** consumed it. ## Project attribution Organization-owned projects make billing attribution clearer because a build, research run, API request, or chat can be associated with the same organization context as the project that requested it. ## Developer usage Organization-owned API keys, applications, or service accounts should meter usage to the organization's billing context when configured that way. This prevents production automation from consuming a developer's personal credits by accident. ## Plan changes Organization upgrades, downgrades, and seat changes should reconcile the Stripe subscription and Starfire entitlements together. Before changing an organization plan, consider: * current seat count * active projects and workloads * shared credit consumption * storage and artifact limits * Developer Platform usage * features that may be lost on downgrade ## Member removal Removing a member should not cancel the organization's billing account or delete organization-owned resources. The subscription belongs to the organization, not to the individual member. Always confirm whether checkout is operating in personal or organization context before purchasing or changing a subscription. Creating a second subscription in the wrong context can make the billing state harder to reconcile.