Migrating From Cursor Teams to Enterprise: What Actually Changes, and What Catches Finance Off Guard

Every FinOps and engineering leader with 50+ Cursor seats is having the same conversation right now. The team plan is fine — until it isn't. Usage has scaled, procurement wants a contract, security wants SCIM and audit logs, and the CFO wants volume pricing. Sales sends over an Enterprise proposal. The line item looks simple. Everyone signs.

Three months later the invoice doesn't reconcile to the internal tracker, finance is asking why spend is 22% above plan, and nobody can explain what changed because on paper, the rate went down.

The migration from Teams to Enterprise is not a plan upgrade. It's a category change in how you're being billed. The per-user SaaS subscription becomes a commitment contract, with up to five commercial levers stacked on top of each other, only one of which is exposed in Cursor's Admin API. Finance teams that treat Enterprise as "Teams with a discount" miss budget inside a quarter. This post is about why.

Why The Migration Is Happening Now

Three forces are pushing organizations off teams:

• Seat count has crossed the volume-discount threshold. At 50+ seats the effective rate on Enterprise is meaningfully below list, and at 200+ the math is hard to ignore.
• Security and IT need enterprise controls. SCIM provisioning, SSO, audit logs, granular admin controls, model allow-lists — these land only on Enterprise.
• Engineering leadership wants pooled usage. On Teams, model spend is per-seat allotments. Heavy users hit caps while lighter users leave credits on the table. Pooled usage fixes this.

All three pressures point the same direction. The migration itself is usually the right call. What goes wrong is the assumption that the commercial model is a scaled-up version of what you already have.

Teams Is a Subscription. Enterprise Is a Contract.

On Teams, the math is straightforward: seats × rate + metered usage. The invoice is predictable. Finance runs a simple spreadsheet. Chargeback is per-user.

Enterprise doesn't work that way. A typical contract stacks some combination of:

• An annual commitment sum invoiced upfront or quarterly.
• A committed seat count you pay for regardless of active users.
• A per-seat overage rate for seats above the commitment.
• Pooled usage credits drawn down across the org, sometimes with a prepaid credit.
• A negotiated markup discount on Cursor's pass-through of provider API costs (OpenAI, Anthropic, Gemini, xAI).

Not every contract uses every lever. Some are pure usage-based with a prepaid credit. Some are seat-commit with overage and no pooled usage discount. The flexibility is genuinely useful. It's also why a generic "headcount × rate" model doesn't survive contact with the invoice.

This is why Enterprise behaves more like a cloud reservation than a SaaS subscription. You're not buying access for users. You're buying a commitment against projected consumption.

Five Pitfalls in the Migration

These are the ones that show up repeatedly in finance post-mortems. None are exotic. All are avoidable if you know to look.

1. Budget math that still assumes per-seat pricing. The moment the contract includes a commitment sum or committed seats, the seat line on the invoice decouples from active users. A customer committed to 100 seats pays for 100 seats whether 80 or 120 show up. The spreadsheet that worked on Teams — users × rate — will be wrong every month on Enterprise, sometimes under, sometimes over, rarely right.

2. "Active user" as an undefined contract term. Every Enterprise deal with a seat commit has to answer the question: what counts as an active user? "Logged in at least once" is the most permissive. "Issued at least one chargeable request" is stricter. "Exceeded a usage threshold" is stricter still. The definition is in the contract, not in the product. If finance pulls the team list from the Admin API and multiplies, they're using a number that doesn't match the one Cursor's billing engine uses.

3. Overage sticker shock. The committed rate is the discounted one. The overage rate — for seats beyond the commitment — is separately negotiated and usually closer to list, sometimes at list. A team that grows 30% in Q3 hits overage at a rate materially higher than the committed rate, and the blended effective price per seat drifts up quietly. If overage wasn't modeled before signing, the first big hiring month is the moment finance finds out.

4. Markup discounts obscured by moving model prices. Cursor's usage billing is a pass-through of provider API costs plus a Cursor markup. Enterprise contracts can negotiate the markup percentage separately from the underlying model prices. Model prices themselves move quarterly (see Claude Opus's tokenizer changes). Tracking only the final invoice hides which side moved. A 20% negotiated markup discount is being eaten alive by a tokenizer change on the provider side and nobody notices because the total bill looks stable.

5. Pooled usage that behaves differently than per-seat allotments. Teams gives each user a capped allotment. Enterprise gives the org one pool. This is an improvement — heavy users stop getting cut off — but it also breaks per-user chargeback unless you explicitly allocate pool draw-down by token usage per user. The default is everyone sees zero attribution and one big pooled number. That's fine until a team triples their spend and nobody can pin it.

What the Cursor Admin API Does Not Expose

This is the reconciliation gap, stated plainly.

The Admin API exposes current team membership, cumulative cycle spend, per-event usage with token breakdowns, and model names. That's it.

It does not expose: committed seat counts, overage seat rates, annual commitment sums, prepaid credit balances, markup discount percentages, or the billing definition of "active user." Every commercial lever that was negotiated into your contract is invisible to the API. If finance is reconciling the invoice against the API monthly, they're reconciling the usage column against a five-column invoice.

What to Nail Down Before You Sign

Four variables are worth pushing on at the contract table — ideally before procurement finalizes terms, because changing them at renewal costs more than raising them now.

• The "active user" definition. Get it in writing. The difference between "logged in" and "issued a chargeable request" at 200+ seats is meaningful monthly.
• The commitment vs. overage split. Negotiate both rates. Model the crossover — at what seat count does committing more become cheaper than paying overage? That number is the one you'll revisit at renewal.
• The markup discount. Cursor's markup on provider API costs is a separate line in most contracts. Discounting it 20–30% compounds across a 2–3 year term, especially as model prices change.
• Termination and reallocation clauses. If headcount drops, can you reduce committed seats mid-term? If a team restructures, can you move committed spend between billing groups? These are rarely in the first draft and standard to add.

What Has to Change in Tracking After You Sign

The day the Enterprise contract goes live, three things need to exist that probably didn't on Teams.

Commitment-aware allocation. Committed dollars have to be distributed across users, teams, and models by actual consumption — typically by token usage ratios — not flat per-seat. A heavy user generating 60% of token spend carries 60% of the committed sum for that period. Flat allocation makes chargeback meaningless and hides the signal finance needs.

Subscription vs. on-demand separation. Cursor Enterprise costs split cleanly into two behaviors: seat-based subscription (fixed, predictable) and usage-based on-demand (variable, elastic). A CFO modeling quarterly spend needs these as separate lines. Collapsing them into one number erases the ability to forecast either.

Anomaly detection on usage pools. A runaway agent loop, a default-model change pushing a team from cheap cache-read rates to expensive output rates, a new feature rollout — any of these can draw down a prepaid credit weeks ahead of schedule. The signal has to reach the owning team the day it happens, not at month-end close when the budget is already gone.

Whether this is built in-house, bolted onto a BI tool, or handled by a dedicated FinOps platform, these are the capabilities the spreadsheet doesn't cover and the Admin API doesn't hand you.

The Bottom Line

The migration from Teams to Enterprise is almost always the right commercial move at scale. What goes wrong isn't the decision. It's the assumption that the tracking, forecasting, and chargeback model built for a per-seat subscription will work for a commitment contract. It won't.

Teams is simple because it's a subscription. Enterprise is complex because it's a contract. Treat it that way before you sign and the migration saves the money it was supposed to save. Treat it like a plan upgrade and you'll spend the first year finding out which lever moved and why.