The ground is shifting under Microsoft Business Applications ISVs. Only time will tell if it is shifting forward or backward. Regardless, to continue existing, you will need to sign a new document, so let’s take a look at it.
A room full of Elephants
Microsoft’s new “Business Applications ISV Connect Program” hopes to be a comprehensive program for ISV success, yet it’s most often referred to by partners as the “Revenue Sharing Program”, due to its prickliest aspect. But sharing 10% or 20% of your revenue with Microsoft is not the only thing you need to understand. In fact, that’s probably the simplest thing to understand.
I recently wrote a post highlighting Microsoft’s plan to eliminate IUR benefits. In that post I said that I did not think they would back down… and they backed down the next day. I have been assured that this was not to make me look like an idiot. When I first wrote about the new ISV program, I also said I did not think Guggs would back down, and it looks like he is going to prove me right. So I have a 50% accuracy rate on back down predictions!
Between now and October, ISVs will need to agree to the compulsory ISV Addendum in order to continue to offer solutions (apps) that are built on, connected to, or extend Microsoft’s Business Applications platform including Dynamics 365 and PowerApps, and where there is a revenue opportunity, Microsoft Flow. Microsoft Business Central and Power BI are exempt, for the time being.
The Whole Truth
It’s not enough to just review the Addendum, as it references other documents, including the ISV Program Policies, as well as the Publisher Agreement. I am not a fan of spreading terms across multiple documents. The Addendum is 9 pages and the Policies are only another 5 pages, with a lot of duplication between them. Why was this not a single document? This is so they can change the policies whenever they need to, without having to get you to re-sign anything. Classic lawyer games.
The Publisher Agreement is an additional 47 pages, but my quick scan of it seems less related to the specifics of the Bizapps ISV Connect Program. So while everyone seems to be focused on a single aspect of this program, let’s take a look at some of the other terms of these agreements. I am not a lawyer, but I do know how to read, and I’ll share my “Business Owner” interpretation.
Tiers are per app, and while the “Standard Tier” (10%) is compulsory, the “Premium Tier” (20%) is optional… for both sides. While there appear to be some specific requirements, Microsoft has maintained the discretion to accept or deny your Premium Tier request arbitrarily. I expect that this will cause some drama, but I see the rationale. The primary additional benefit of the Premium Tier is the activation of Co-Sell. This means Microsoft’s own internal sales teams out there hawking your app, and being spiffed for doing so. Obviously salespeople, and hours in the day are both finite resources that Microsoft would rather not waste on “crappy” apps. But who judges “crapiness”? I would assume that any ISV solution that generates the sale or activation of Microsoft product licenses will pass muster, regardless of its intrinsic value, but what else? What about an app that reduces the need for additional Microsoft licenses?
If you determine that you are not getting value for an app from the co-marketing and co-selling motions of the Premium Tier, you can “Down-Tier” that app back to the Standard Tier. It is not clear what percentage you will pay for any deals closed for that app while it was previously in the Premium Tier. Nor is it clear what you will pay for prior deals after you “up-tier” an app. There also does not appear to be any language preventing you from have having two versions of your app, one on each tier, possibly at different prices… I’ll let that settle into your brain.
The definition of a “Business Application”, that falls within this agreement is quite comprehensive. It also includes so-called “free” apps, that connect to paid services you offer, so no Trojan Horses.
Some math is required to figure out how much you’re supposed to pay Microsoft, regardless of the tier. Basically, the total amount of your customer bill, less taxes and “non-recurring” services you perform, and your cost of any CSP licenses you may have included. So this includes your license margin also, if you sell Microsoft licenses as a part of your solution. It really feels and sounds like Microsoft does not think ISVs need to make any margin on Microsoft licenses, and while most don’t… some do. It also appears to me to include any and all recurring revenue, like for example monthly or annual support plans, or any sort of managed service type offerings related to your solution. So as an ISV, if I offer a monthly support plan to the customer, I have to pay the fee, but if a reseller of my app offers the same monthly support plan, no fee would apply.
The agreement includes this line: “you are solely responsible for End Customer credit decisions and Total Solution Value will not be reduced for uncollectible accounts.” So you will still have to pay Microsoft, even if your customer stiffs you. I have no idea how this is supposed to work in the future when a customer purchases directly via Microsoft’s AppSource Marketplace with a credit card.
The agreement also includes this line: “You will accurately report each Paid Eligible Sale to Microsoft within 30 days of a Paid Eligible Sale occurring“. Self-reporting always works! Of course Microsoft has the right to audit you, at their expense, and go back 3 years. Interestingly, their audit not only covers fees that may be due to them, but also appears to include your violation of any applicable laws? If they discover anything, you will foot the audit bill.
I think Microsoft is going to lose many Connect ISVs right out of the gate. Remember the “Connect” pattern is the one where you already have your own service, and you offer an app to connect it to D365. For example, let’s say you offer some deep industry bench-marking service for the princely sum of $10,000 per month. Users typically gain access to your high-value data directly on your secure web portal. As a convenience, you decide to make a small free app, available to your paying customers, that will push your service’s resulting “Account Score” field over to Account records in your customers’ D365 instances. Guess what? You owe Microsoft $1,000/month for each customer that uses it.
The technical definition of a “Business Application”, as I read it, would also include third-party published “Connectors”, based on what they do, and I am not seeing an exemption for them. So as soon as I wire up the CDS connector to some third-party’s connector, is that third-party on the hook for a fee? Or, will they create an exception for connectors? If so, then won’t all savvy Connect pattern ISVs just publish connectors instead?
For any customers that you may have invested heavily in marketing and selling your solution to, possibly involving significant costs for travel, wining and dining, and ultimately heavily discounting your product to land their “Logo” account, all without any assistance from Microsoft… there is some good news. You have about a year to either raise your prices or decide to absorb the new fees. I assume many ISVs have some sort of term, and the fee will start being due if your customer has to renew between now and next July also. If you have a month-to-month auto-renewing agreement, it looks like you have until about the first of next July. Hopefully, not many ISVs had multi-year agreements with their customers.
On the Ball
If you sold 100 licences of your product to a customer, and Microsoft began invoicing you for their fee, and later the customer reduced their license count to 50, you better move fast. Your Microsoft fees will not be reduced for any current invoices, or any invoices that were to be sent to you within 30 days. If you somehow mess up and forget to let Microsoft know about the reduction for a while, no credits will be issued to you. In fact, it appears that no credits will ever be issued to you, regardless of… anything.
I found interesting in Guggs’ Inspire session, his referring to “access to Microsoft’s platform” as a program “benefit”. Guggs says he does not like the term “Tax”, and I agree… based on this, “Tariff” seems better. This “benefit” had not come up in my past conversations with them for my post about the various benefits ISVs can expect. It looks like the catch-all for anyone trying to avoid the new program. Basically, part of what you are paying Microsoft for, is their permission to play in their playground, that they built, expand and maintain.
Microsoft reserves the right to change any of the rules at anytime. So regardless of how much you may have invested to go “all-in” on D365/Power Platform, if you fail to meet some new or changed future requirement… you’re out.
While I am optimistic about the concept, some of the execution so far feels ham-fisted. The agreements, as you would expect, are pretty one-sided. Establishing a “here’s the rules” approach for new ISVs is one thing, simultaneously enforcing a “take it or leave it” approach with long-standing ISVs feels pretty arrogant, even when wrapped in a “for the good of us all” message. While some ISVs may leave, most probably have too much invested and really can’t leave, even if they wanted to. Clearly Microsoft’s focus is on large ISVs for enterprise customers, as they were the ISVs that were engaged to help craft this. For all other ISVs, time will tell if this is a shift forward or backward.
07/29/19 Clarifications from Microsoft
- You asked which revshare rate would apply when apps that change tiers. The revshare % is “based on the App Tier in effect when the [sale] occurred” (Addendum, Section 5.a.i). In other words, if an app’s tier changes, the new revshare rate will apply to future sales but not prior sales.
- You asked whether the same app can have two listings, one in Standard tier and one in Premium tier. While not discussed explicitly, that isn’t our intent and we wouldn’t expect to approve (in certification) the second listing for the same app.
- You wondered if credit decisioning works differently when customers transact directly on AppSource. I believe it works differently on direct AppSource transactions. With respect to the ISV Connect program, please note that direct AppSource transactions are specifically excluded, since they are subject to different terms and an agency fee under the commercial marketplace agreement. (The Addendum’s definition of a “Paid Eligible Sale” excludes sales “through a Direct AppSource Sale”).
- Lastly, I wanted to clarify when fees apply on pre-existing deals. On pre-existing deals (i.e., entered into before 7/1/2019 and registered by 12/1/2019), no revshare is due until 7/1/2020. This waiver period also applies to renewals (before 7/1/2020) of these pre-existing deals. In addition, on multi-year fixed term pre-existing agreements with a term that extends beyond 7/1/2020 (without renewing), revshare doesn’t begin until it does renew/extend (even if that is after 7/1/2020). This is the intent of Addendum Section 5.b.