expansion accounts flagged as contraction after seat true-up: license sync ove

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

Fix this in health score licence utilisation measure by acting on the exact message first: update the licence denominator in the measure to the true up contract count, cap active seat counting at distinct named users, recalculate utilisation for the affected accounts, and verify a named account now reports at or below one hundred percent. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.

health score license utilization measure exceeds 100 percent after contract true up

Use this when

• The operation in health score licence utilisation measure fails with this exact message or symptom: health score license utilization measure exceeds 100 percent after contract true up.
• The same failure repeats on retry with unchanged inputs.
• Health scoring, alerting or routing is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in health score licence utilisation measure, and copy the full message plus the account, measure or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: update the licence denominator in the measure to the true up contract count, cap active seat counting at distinct named users, recalculate utilisation for the affected accounts, and verify a named account now reports at or below one hundred percent. Verify: the smallest failing scope now completes, or the named account, measure or job behaves as the fix predicts.
3. Check the neighbouring accounts, measures or jobs that share the same config, schema or source, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in health score licence utilisation measure on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, scores or status against the source in health score licence utilisation measure so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Utilisation divides active seats by contracted seats, and a true up that raises the real seat count without updating the denominator pushes the ratio above one hundred percent.

Variant phrasings

health score license utilization measure exceeds 100 percent after contract true up

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - health score license utilization measure exceeds 100 percent after contract true up

The how-to phrasing for the same failure in health score licence utilisation measure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

health score licence utilisation measure troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Edge cases

• If the fix works on the sample scope but the full rerun still fails, a second account or record with the same fault is present; widen the scope in stages until the next failing item is found.
• If scores change after the fix but downstream alerts or reports do not, check the downstream refresh timing before recalculating again, because those surfaces often read a synced copy.
• If the source information itself is missing for the affected accounts, record that as a source gap rather than scoring the accounts as zero.

Compatibility: health score licence utilisation measure at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: health score license utilization measure exceeds 100 percent after contract true up

TL;DR: Fix this in health score licence utilisation measure by acting on the exact message first: update the licence denominator in the measure to the true up contract count, cap active seat counting at distinct named users, recalculate utilisation for the affected accounts, and verify a named account now reports at or below one hundred percent. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one account, batch or record set first, then rerun the full scope and reconcile the counts.

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.