Cursor Enterprise Billing Groups: Spend by Team, SCIM & Chargebacks

Each member belongs to exactly one billing group at a time. Anyone not assigned lands in the reserved Unassigned group. Usage is attributed to the member's group at the time it occurs. Moving someone later does not rewrite history unless you delete a group (historic usage then moves to Unassigned).

The one-group rule is more consequential than it reads. Because nobody can sit in two groups, billing groups give you a single axis of attribution, so you choose between slicing spend by department and slicing it by cost centre or product line. Pick whichever axis your finance system already reconciles against. The reporting is only worth anything if somebody downstream can match it to a budget they own, and rebuilding the groups later means the history is split across both schemes.

Everybody starts in Unassigned, which is why the first month of a rollout often reports as one large undifferentiated number.

Attribution at the time of usage is the part that surprises people. It is the correct behaviour, and it means a reorg mid-quarter leaves one person's spend split across two groups, matching neither the old org chart nor the new one. Nothing is wrong when that happens. You just cannot reconcile that quarter against the current structure, so do the reconciliation on the billing cycle while the moves are still recent.

Groups are created and populated from the dashboard, and you have four ways to put people in them: SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. sync, the Admin API, a CSV upload or manual selection. Pick the one that matches how you already manage identity. The order below walks the flow from creating a group to choosing how membership is assigned.

1. 1Open the web dashboard Members & Groups tab (Enterprise admins only).
2. 2Click Create Group and name the group.
3. 3Assign members via SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. (sync with an IdP group), Admin API, CSV (group name + email) or manual selection from Unassigned.
4. 4SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.-synced groups cannot be edited via CSV, API or manual UI. Membership must flow from your identity provider.

Those four assignment methods are not interchangeable, and the choice is really about where the truth about your org already lives. SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. if your identity provider carries departments, because then Cursor mirrors it instead of keeping a second copy. The Admin API when an internal platform owns cost centres and can push changes. CSV for a one-off backfill of the people who predate the whole scheme. Manual selection is fine for a small org and quietly expensive for a large one, since it depends on somebody remembering.

Step four in that list reads like a limitation and it is the reason to use SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. in the first place: a SCIM-synced group cannot be edited by CSV, by API or by hand, so membership has exactly one source. What it does is move the cost from IT to finance. Regrouping one person for a chargeback becomes a change request against the directory, which in most orgs means a different team and a different week.

Decide the source of truth before you create the first group. A group managed in two places drifts, and the drift arrives as a number nobody can explain. Worth remembering too that the CSV is keyed on group name plus email, so a rename leaves whatever spreadsheet finance saved last quarter matching nothing.

Moving and renaming are routine; deleting is the one to watch. How you move members depends on whether the group is manual, SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.-synced or driven by the API, and deleting a group reassigns all of its historic usage to Unassigned with no way back.

• Move members: use Move on manual groups; SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. moves follow IdP group changes automatically; API has add/remove member endpoints.
• Rename: gear menu on the group list or Rename on the group page; API update endpoint also supported.
• Delete: gear menu or Delete on the group page. This one is destructive; all historic usage for that group is reassigned to Unassigned and cannot be recovered.

Delete is the one to handle carefully, and handling it carefully usually means not deleting at all. Losing that attribution silently rewrites every report the group appeared in, including the ones already circulated. When a department stops existing, rename it instead (something like Platform (through 2026)) and leave it in place: rename works from the gear menu, from the group page and through the API update endpoint, and the history stays attached to a name that still explains itself.

When a chargeback report looks wrong, check three things, in this order. Is the member sitting in Unassigned, which is where anyone the process missed ends up. Did they move groups mid-cycle, in which case the split is real and the report is right. Is the group SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.-synced, because then the answer lives in your identity provider and no amount of clicking in Cursor will change it. I would work through those before concluding the numbers are broken.

Billing groups manage spend attribution within one Enterprise team. For org-level groups that span linked teams, Cursor documents separate Organizations functionality. Use that when you need cross-team rollups rather than per-team chargebacks.

What makes this confusing is that one person can sit in a billing group, a directory group and an Organization Group simultaneously, often with all three fed from the same place in your identity provider. Attribution is the only one of the three that this page governs. Who may spend what is a directory-group question, and which cohort gets a particular setting is an Organization Groups question.

One thing billing groups do not do is create a budget. They tag usage for reporting; they do not carve out a pool. Per-group ceilings come from spend limits: SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. directory groups take per-group limits, and where somebody belongs to several groups the highest applicable limit wins. Pooled usage covers how the shared budget behaves underneath all of this.