Unannounced Atlassian accounting change for subscription upgrades

Hi @ChrisHemphill1

I am hoping to get your attention regarding Atlassian’s unannounced accounting change that will soon start to negatively impact partner revenue. I suspect that this change is also not in line with GAAP, since it will force vendors to redo revenue that has been already recognized on the vendor’s financial statements from previous accounting years.

Since the dawn of the Marketplace in 2012, Atlassian has always treated subscription upgrades as atomic transactions, where the customer is billed the difference between the old and the new tier prices. The difference is then remitted to the vendor, less Atlassian’s discount share.

Since the migration to CCP, these upgrade transactions are no longer atomic. Instead of having a single “upgrade” transaction, the CCP issues a complete refund of the old tier and then an upgrade to the new tier, with the latter being a complete rebilling of the entire amount of the new subscription price (not just the difference). Currently, this works out to the same net payment to the vendor.

However, this will change starting in 2026 due to Atlassian’s revenue share updates. I predict that a lot of major apps will be unable to migrate off Connect by 2026-01-01, which means that the Atlassian revenue share is increasing for many top-selling apps from 15% to 20% (and later 25%).

Your Marketplace team recently confirmed that the “refund” part of this transaction is refunded at the prior-year Atlassian discount rate, but the “new” part of the transaction will be billed at the current Atlassian discount rate, which will be 5% or 10% higher than before. This occurs despite the fact that the money was, in fact, still previously received by Atlassian from the customer during the period with the lower discount rate.

This creates an accounting nightmare, because the CCP is now pretending that this revenue (which was received and accounted for in years past) is actually new revenue, and it consequently applies the new (and higher) revenue share to revenue that was previously received and paid.

As a simple example, suppose that a customer purchases an app where the future part of the subscription totals $1,000 gross at 15% discount. In 2026, the customer upgrades that subscription to a higher tier valued at $1,100 gross, but with 25% Atlassian discount.

The net result of the upgrade transaction is that the vendor owes Atlassian money for the “upgrade”.

There is $100 of new revenue from the customer, but Atlassian sticks $125 in its own pocket by taking everything that the customer just paid, and then Atlassian further takes previously-paid revenue away from the vendor:

Original transaction:

Gross price: $1,000
Atlassian share @ 15%: $150
Vendor share @ 85%: $850

CCP upgrade transaction:

Atlassian first refunds the earlier sale and takes $850 away from the vendor, then:

Gross price: $1,100
Atlassian share @ 25%: $275
Vendor share @ 75%: $825

Vendor total payment: -850 + 825 = $-25

Net result

The “upgrade” results in the vendor owing Atlassian $25, despite $100 of new revenue.

As previously processed by the old commerce platform, the vendor would have instead received a payment of $75, so the vendor is $100 worse off than they would have been before.

I do not know if this behavior was previously considered or intended, but it does not seem correct accounting-wise (let alone fair).

Can your team investigate this and see if there is a way to make things right before the discount change arrives?

24 Likes

fyi that migration to CCP also resulted in a massive fake churn spike in June: https://jira.atlassian.com/browse/MP-437

I’m requesting they do a full audit to ensure they didn’t also screw-up elsewhere.

1 Like

Can someone point me to any material on the change to CCP?

(There’s so much churn and miscellaneous busy-work being a Marketplace vendor these days that, despite my best efforts, I can’t quite keep up with everything that is happening).

I had suspected something changed a while back as the number of Refund transactions we see is significantly higher that it was a year or two ago, and I was getting worried that we might have had a lot of unsatisfied customers, but then spot checks revealed that many of these refunds had a corresponding purchase transaction, so we figured that this was just a change in how upgrades/downgrades were being processed/accounted for.

But it would be good to learn more about this change, so a pointer to a changelog entry or Partner Portal post that describes CCP would be greatly appreciated.

3 Likes

Maybe Atlassian has a source, but as a vendor, I am have not seen any documentation for this change.

Empirically, these “refund transactions which are actually upgrades” are hard to identify when viewed individually:

  • purchaseDetails.refundReason is usually empty
  • purchaseDetails.creditNoteReason is also usually empty
  • purchaseDetails.originalTransactionDetails is rarely populated (and this doesn’t help differentiate between real refunds and upgrades anyway)

The only way to identify these algorithmically is to search for another paired transaction, where this other transaction:

  1. is on the same date,
  2. has the same transactionId (invoice #),
  3. has the same appEntitlementNumber,
  4. has the same purchaseDetails.maintenanceStartDate and purchaseDetails.maintenanceEndDate, and
  5. has saleType=Upgrade

The CCP often splits these renewal/upgrade transactions into year periods, so if the upgrade date is not aligned with the customer’s original subscription dates, it is not uncommon for a single upgrade to be transformed into an orgy of 4-6 individual transactions. (I mention this, in part, to help Atlassian understand how much extra complication this creates for vendors.)

If these transactions are going to remain as pairs, at the very least, the creditNoteReason or refundReason fields should be populated with something that specifically identifies this “upgrade” case, and vendors ideally need a new upgradeTransactionDetails field that provides a link to the paired upgrade part of the transaction.

The issue of how to transparently represent these transactions in the API is also compounded by the upcoming cloud discount rate change. In effect, only the net new $$ should be subject to the Atlassian discount, but the current method of breaking down the transaction into a refund and a repurchase obscures these details, and I do not believe that the current MPAC model is capable of representing these accurately if the transactions are split into refund/repurchase pairs.

For example, supposing that Atlassian corrects the accounting part of the problem, the example I gave above should result in a $75 payment to the vendor. But the transactions are currently recorded as “refund of net $1000 at 85% discount, repurchase at $1100 at 75% discount”. How would these two transactions get represented in the Marketplace API so that the vendor payment numbers (for the $100 of new revenue) yields $75 net to vendor? The repurchase transaction would need to show an effective Atlassian discount rate of 15.9% to make the numbers even.

In effect, I have difficulty seeing how the MPAC API can accurately and transparently represent these transactions as a pair. If the “refund” transaction numbers stay as-is, you are left with having to fudge the discount on the repurchase to make the numbers add up, as above. This problem is presumably further compounded if you throw in MQB that overlaps any the two upcoming discount period change dates. All of this makes partner reconciliation of transactions difficult, if not impossible.

If MPAC were to go back to representing these as a single transaction, like it did previously with HAMS, the accounting becomes easy and transparent, and nothing needs to be fudged.

6 Likes

I share @scott.dudley concern that Atlassian is creating accounting complexity. As these changes are not due to start until 2026 I believe there is still a chance to catch this unintended error and correct it.

As a vendor whenever Atlassian adds an administrative burden it takes away from our ability to focus on supporting Atlassian clients, which is a key value of app vendors for Atlassian.

Working with the team to look into this @scott.dudley - thank you for raising and articulating the issue from your perspective.

2 Likes

@ChrisHemphill1

We, TechTime Initiative Group, are both a Marketplace Partner and a Solution Partner.

Without any particular desire to add more FUD to this specific discussion – please be aware that CCP is currently full of bugs, incapable of producing correct quotes for upgrades mid-term (which is why I think it’s relevant to this discussion) when a Solution Partner is present in the deal and a Solution Partner discount applies. This is similar to the use case outlined by @scott.dudley for when the Atlassian’s share changes in 2026.

Currently CCP credits the unused periods that were purchased in the past (with some discount specific to that time, e.g. 10% for a renewal of the Atlassian or Marketplace app), using the discount applicable to the purchase in the present, e.g., if you are upgrading then it will be 20%.

Apparently the policy this is done by was written very sloppily – take the difference in list price, and apply the Solution Partner discount (as in the current, at the time of the upgrade) on top of that difference.

This will never work for renewal + upgrade, or when applicable discount changes between the original purchase or the current one (e.g. Marketplace Partner stops giving discounts, or starts giving them).

Our gripe with this is due to this under-refunding the Solution Partner, but I am sure this should pop up on the Marketplace Partner side as well. I have multiple examples of this with invoices and quotes. I just can’t find anyone at Atlassian with the open mind to actually listen!

CCP currently also applies some mind-boggling durations to mid-term upgrade durations which have been dubbed a “millisecond precision” feature-not-a-bug by Atlassian.

We see list prices for apps quoted for durations like 323 days 8 hours. I have a strong suspicion that when an agent enters some future date in some UI, e.g., to co-term, or to start the upgrade from this date – the code doesn’t clear time part of the date somewhere, so you end up with an offset equal to the timezone of the agent.

2 Likes

Hey everyone, while we don’t have a public answer back for you yet, I wanted to confirm that this post has been raised internally along with your feedback and our Marketplace and Commerce teams are reviewing. Appreciate you raising the real world impacts of these changes and we will work to get a response and additional details back to you all.

5 Likes

Hi @ChrisHemphill1

I wanted to inquire if any updates were available yet on this issue?

Thanks!

5 Likes