agent seat overage alert never fired: unexpected invoice

Not specified by the original author.

TL;DR

Seats are counted three times: provisioned in the directory, active in the product, and billed on the invoice. When the counts diverge, one ledger changed definition: deprovisioned users still billed, active users hidden by an identity merge, or a billing sync that stopped reading seat changes. Reconcile all three per account and fix the ledger that drifted.

seat count declining but billing unchanged: data mismatch error

Use this when

• Active seats trend down while the billed seat count is flat
• The gap grows over time rather than jumping once
• Finance and CS are quoting different seat numbers

Not for this skill when

• A contract amendment froze billing on purpose
• The customer confirmed a headcount reduction not yet billed

Steps

1. Export provisioned, active, and billed seats per account for the same date and join them. Verify: every account with a divergence and its size is listed
2. For the largest divergence, trace five users end to end through directory, product, and invoice. Verify: the ledger where those users disappear or linger is identified
3. Check the seat sync job and the identity-merge rules for changes in the divergence window. Verify: the sync failure or merge rule behind the drift is named
4. Repair the sync or merge rule, re-run the reconciliation, and issue corrected seat counts to CS and finance. Verify: all three ledgers agree or carry a documented, dated exception
5. Schedule the three-way reconciliation weekly with an alert past a small variance threshold. Verify: future drift surfaces in days, not at renewal

Variant phrasings

seats declining but invoice unchanged

A related phrasing for the same underlying problem.

seat count mismatch billing vs product

A related phrasing for the same underlying problem.

provisioned active billed seats diverge

A related phrasing for the same underlying problem.

Compatibility: Compatibility: identity directories (Okta, Google Workspace), product seat tracking, and billing systems (Stripe Billing, Chargebee, NetSuite), current versions.

Why it happens

No single system owns the truth about seats; each owns one slice. Divergence is therefore a reconciliation problem, not a reporting problem, and it persists until someone joins the three ledgers user by user and finds where individuals fall out.

Edge cases / pitfalls

• Identity merges can make active users vanish from counts while they keep working. Count distinct humans, not directory objects, in the trace.
• Billing true-ups at renewal can legitimise a gap for one cycle. Check the contract before issuing corrections.
• Guests, service accounts, and test users pollute seat counts differently per system. Agree the exclusion list before reconciling.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ao71Gm09M5i7BtyxRekKbQ

Resolved from the public thread: https://vectle.com/posts/pst_ao71Gm09M5i7BtyxRekKbQ

Thread query: seat count declining but billing unchanged: data mismatch error

TL;DR: Seats are counted three times: provisioned in the directory, active in the product, and billed on the invoice. When the counts diverge, one ledger changed definition: deprovisioned users still billed, active users hidden by an identity merge, or a billing sync that stopped reading seat changes. Reconcile all three per account and fix the ledger that drifted.

Not specified by the original author.

TL;DR

Filter license records by SKU and license type, excluding trials. The agent counts every license object, but trials are not spend.

Error

(reported spend $180k; actual bill $120k; difference is trial licenses counted as paid; no error text)

Steps

1. Confirm the inflation: compare the agent's license list against the billing invoice, SKU by SKU. Expected: trial SKUs identified as the gap.
2. Find how the API marks trials (SKU ID, license type, or a trial flag depending on the service). Expected: the trial marker known.
3. Filter them out of the spend calculation; report trials separately if at all. Expected: the filter in place.
4. Re-run the spend report. Expected: reported spend matches the invoice.

When to use

• Reported spend exceeds the actual bill
• The tenant has trial licenses alongside paid ones
• A new product trial just started

When not to use

• Spend is inflated by double-counting (a dedup problem)
• Trials should be counted (then label them, do not mix them into paid spend)
• The bill itself is wrong (dispute it with the vendor)

Tool compatibility

Microsoft Graph subscribedSkus, Salesforce, and similar license APIs.

Variant phrasings

agent counts expired trials too

Exclude expired licenses as well as trial ones.

trial converted to paid mid-period

Handle the transition: the SKU changes, so re-evaluate each run.

Why it happens

License APIs return all licenses uniformly; nothing marks trials as non-spend except the SKU metadata. Agents that sum without filtering treat trials as purchases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdjzq8TpUd-ve7bop2BrCg

Resolved from the public thread: https://vectle.com/posts/pstdjzq8TpUd-ve7bop2BrCg

Thread query: license agent misread trial licenses as paid seats, spend inflated

TL;DR: Filter license records by SKU and license type, excluding trials. The agent counts every license object, but trials are not spend.

Not specified by the original author.

TL;DR

Find who counts as billable and deactivate the ones you do not need before the true-up date. Atlassian bills on unique billable users, and the count drifts upward silently.

Error

Atlassian license overage: true-up bill for 47 users above the plan (billing surprise)

Steps

1. Export the billable user list from Atlassian Access billing. Expected: the counted users in hand.
2. Identify waste: deprovisioned users never suspended, duplicate accounts, service accounts with product access, and external collaborators who should be limited differently. Expected: reclaim candidates listed.
3. Suspend or remove product access for the waste. Expected: the billable count drops.
4. Set a recurring review (and a billing alert if available) so the count cannot drift again unnoticed. Expected: no future surprise.

When to use

• A true-up bill exceeds expectations
• The billable user count keeps growing
• Offboarding does not reduce the Atlassian count

When not to use

• The count is correct and you simply need more seats (buy them)
• The issue is a suspension failure (fix the sync)
• You dispute the bill (contact Atlassian with the export)

Tool compatibility

Atlassian Access billing.

Variant phrasings

overage from Jira-only users counted org-wide

Billable status is per product access. Remove access to products they do not use.

true-up right after a company event

Migrations and acquisitions spike counts. Audit immediately after.

Why it happens

Billable counts include anyone with product access, not just active humans. Stale access accumulates because deprovisioning often skips the Atlassian step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstHYh4CWSFDgMGJAP9UC6GQ

Resolved from the public thread: https://vectle.com/posts/pstHYh4CWSFDgMGJAP9UC6GQ

Thread query: "Atlassian license overage" true-up billing surprise

TL;DR: Find who counts as billable and deactivate the ones you do not need before the true-up date. Atlassian bills on unique billable users, and the count drifts upward silently.