Negotiating with AWS: How Enterprise Teams Cut Cloud Costs Before They Compound

AWS is one of the most under-negotiated enterprise vendors in the market.

That sounds surprising. AWS is often one of the largest technology suppliers in an enterprise portfolio, with annual spend measured in millions, or tens of millions. Yet many organizations approach AWS as if the only available levers are architectural optimization, Savings Plans, and Reserved Instances.

Those tools matter. They are not the whole negotiation.

AWS spend grows organically through consumption rather than seats. New accounts appear. Workloads move into production. Data volumes increase. Development environments multiply. Business units adopt services independently. By the time finance sees the full picture, the organization may already have a substantial AWS run rate, and limited visibility into the commitments supporting it.

That is precisely when a large cloud bill becomes a negotiation opportunity.

The goal is not simply to obtain a larger headline discount. It is to build a commercial structure that aligns with actual consumption, protects flexibility, reduces commitment risk, and preserves leverage for the next renewal.

Why AWS negotiations work differently from SaaS negotiations

Seat-based SaaS contracts usually have a visible commercial unit: users, licenses, modules, or transactions. AWS is different. The bill is a portfolio of variable consumption lines.

AWS pricing can include:

  • On-Demand usage
  • Savings Plans
  • Reserved Instances
  • Data transfer and egress
  • Storage and requests
  • Managed database consumption
  • Support fees
  • AWS Marketplace purchases
  • Promotional credits
  • Migration funding
  • Enterprise-level private pricing

That creates two common mistakes.

First, teams benchmark the wrong number. They compare the total invoice to public list price without normalizing usage, regions, service mix, pricing model, and credits.

Second, teams negotiate the wrong commitment. They accept a spend target based on an optimistic cloud roadmap rather than a defensible forecast of eligible consumption.

In a seat-based negotiation, unused licenses are visible. In AWS, unused commitment can be buried inside a complicated consumption model and discovered only after the organization has already signed.

The AWS commercial landscape: what can actually be negotiated?

On-Demand pricing

On-Demand is the most flexible AWS pricing model, but generally the least economical for stable workloads. It is also the baseline against which many other discounts are presented.

On-Demand pricing is useful as a reference point, not as a complete benchmark. The real question is:

What effective rate is the enterprise paying for its actual service mix after all discounts, credits, commitments, and exclusions?

Savings Plans

Savings Plans provide discounted rates in exchange for a one- or three-year commitment to a consistent level of eligible compute spend.

Depending on the type, they may apply across services such as:

  • Amazon EC2
  • AWS Fargate
  • AWS Lambda
  • Selected database workloads

The tradeoff is flexibility versus discount depth. A Compute Savings Plan can provide broader portability across eligible compute, while an EC2 Instance Savings Plan may offer stronger economics with more constrained coverage.

AWS provides public documentation on how Savings Plans work, but the discount is not automatically a substitute for enterprise negotiation. Savings Plans typically do not address:

  • Data transfer out
  • AWS Support fees
  • Most Marketplace software fees
  • Broader enterprise commitment risk
  • Contractual protections around future services

Review the official AWS Savings Plans documentation before modeling a proposal.

Reserved Instances

Reserved Instances can reduce the cost of predictable EC2 and database usage, usually in exchange for a defined configuration and term.

They can be attractive when workloads are stable. They can also create avoidable lock-in when a business is changing instance families, regions, operating systems, or deployment patterns.

The right question is not “What is the maximum discount?” It is:

How much of this workload can the business confidently call stable for the full commitment term?

AWS explains the mechanics of Reserved Instances here. Your negotiation should go further by testing whether the commitment is operationally realistic.

EDPs and Private Pricing Agreements

Large AWS customers may negotiate an Enterprise Discount Program, often referred to in current market discussions as a Private Pricing Agreement or PPA.

The basic structure is straightforward:

  1. The customer commits to a minimum level of eligible AWS consumption.
  2. AWS provides a negotiated discount across defined eligible usage.
  3. The agreement runs for a set term, commonly one to five years.
  4. The customer must manage its usage carefully to avoid falling short.

AWS does not publish a universal public discount schedule for EDPs or PPAs. Rates depend on factors such as:

  • Annual committed spend
  • Total term value
  • Current run rate
  • Forecast growth
  • Service mix
  • Region and account structure
  • Competitive alternatives
  • Migration or modernization plans
  • AWS Marketplace participation
  • Timing and internal AWS priorities

Industry-observed ranges are directional rather than official. As a rough negotiating reference, enterprise proposals may fall into bands such as:

Annual commitment Directional observed discount range*
$1M–$5M 5%–8%
$5M–$10M 8%–12%
$10M–$25M 10%–15%
$25M–$50M 14%–19%
$50M+ 17%–23%

*These are market observations, not AWS-published tiers or guaranteed outcomes. A discount is meaningful only when you understand exactly which services, charges, accounts, and commitment calculations it covers.

Do not negotiate on the headline percentage alone. Ask AWS to define:

  • Eligible services
  • Excluded services
  • Treatment of new AWS services
  • Treatment of Marketplace spend
  • Treatment of support charges
  • Credit application order
  • Account and region portability
  • Ramp mechanics
  • Shortfall consequences
  • True-up and true-forward provisions
  • Renewal and repricing rights

Flat-design illustration showing enterprise cloud spend benchmarking with normalized rates, usage bars, and a benchmark line

The growth commitment trap

The most dangerous AWS commitment is not necessarily the one with the lowest discount. It is the one based on a forecast that the business cannot reliably achieve.

AWS teams may present a larger commitment as a way to unlock better economics. The logic can be compelling:

  • The business is migrating workloads.
  • AI and analytics usage will grow.
  • New regions are planned.
  • More business units will consolidate onto AWS.
  • A modernization program will increase consumption.

Some of those assumptions may be correct. The problem is that a forecast is not the same as committed usage.

If actual consumption falls below the commitment, several outcomes are possible depending on the agreement:

  • The customer receives less economic value than expected.
  • Unused commitment may expire.
  • The customer may need to accelerate migrations or shift workloads.
  • Finance may face a true-up or shortfall obligation.
  • The customer may have less leverage at renewal because it appears to have underperformed against its promise.

A strong AWS negotiation separates three numbers:

  1. Current run rate: what the company is consuming today.
  2. Committed base: what the company can defend with high confidence.
  3. Strategic upside: what may happen if planned migrations and growth materialize.

Only the first two should form the foundation of a hard commitment. Strategic upside should be rewarded through ramps, expansion rights, reopener clauses, or incremental discounts, not automatically converted into a fixed liability.

Committed spend, true-ups, and unused commitment liability

Before signing, model the agreement month by month.

At a minimum, calculate:

  • Expected AWS usage by service
  • Eligible versus excluded spend
  • Existing Savings Plans and Reserved Instances
  • Marketplace spend
  • Credits and expiration dates
  • Support fees
  • Migration-related costs
  • Seasonality
  • Business-unit allocations
  • Downside and upside scenarios

Then test three cases:

Base case

The organization follows its current migration and growth plan.

Downside case

Migration is delayed, a major workload remains on-premises, or optimization reduces consumption.

Upside case

AI, data, or application workloads grow faster than expected.

The agreement should not be economically attractive only in the upside case.

Ask for mechanisms that reduce unused commitment liability, including:

  • A lower first-year commitment
  • Annual ramps rather than a flat commitment
  • Carry-forward rights
  • Reallocation across accounts and regions
  • Broader eligible-service coverage
  • The ability to apply certain Marketplace purchases
  • A formal review if consumption falls materially
  • No automatic conversion of a shortfall into a new long-term commitment
  • Clear treatment of credits when calculating commitment attainment

Flat-design illustration of the enterprise cloud growth commitment trap, with usage falling below a commitment threshold

Use AWS Marketplace, credits, and MAP as negotiation levers

AWS Marketplace can be commercially important in two ways.

First, Marketplace may be part of the broader enterprise cloud commitment. If your organization already purchases significant third-party software through AWS Marketplace, ask whether that spend can contribute to commitment attainment. Do not assume it qualifies. Get the treatment documented.

Second, Marketplace can provide a procurement path for third-party software, including negotiated private offers. AWS explains the mechanics of Marketplace private offers.

Credits are another lever, but they should never be treated as equivalent to a permanent price reduction.

Separate:

  • AWS promotional credits
  • Migration credits
  • Marketplace-related credits
  • Partner-funded incentives
  • MAP funding
  • Service-specific discounts
  • Contractual PPA discounts

For migration programs, AWS’s Migration Acceleration Program terms should be reviewed carefully. MAP may support migration and modernization activities through funding or credits, but eligibility, included services, timing, and exclusions matter. For example, credits may not cover all data transfer costs or third-party software charges.

Negotiate the value of credits as part of the total economic package, while keeping the underlying price and commitment structure transparent.

Data egress: negotiate it before you need it

Data egress is often treated as an unavoidable technical cost. In a negotiation, it is also a portability and concentration-risk issue.

Your AWS analysis should distinguish between:

  • Routine operational egress
  • Cross-region replication
  • Internet delivery
  • Data movement during migration
  • Exit-related data transfer

The EU Data Act is changing the discussion. The European Commission states that switching charges, including switching-related data egress, must be eliminated from 12 January 2027, with a transitional cost-based approach before then. The official European Commission explanation of the Data Act provides the relevant context.

That does not mean all ordinary AWS outbound data transfer becomes free. Day-to-day operational egress remains a separate commercial issue.

For a multinational enterprise, negotiate:

  • A clear definition of switching-related egress
  • Data export assistance
  • Migration support obligations
  • Advance notice requirements
  • Portability of data and metadata
  • Treatment of egress outside the EU
  • No contractual language that defeats applicable regulatory rights

Support fees are negotiable too

AWS Enterprise Support is generally calculated as a percentage of monthly AWS charges, subject to minimum fees and tiered rates. At large spend levels, even a modest reduction in the effective support rate can produce meaningful savings.

Ask AWS to clarify:

  • The exact fee base
  • Whether credits reduce the support calculation
  • Whether Marketplace charges are included
  • Whether support fees increase automatically as usage grows
  • Minimum monthly charges
  • Enterprise Support versus other support tiers
  • Technical Account Manager coverage
  • Service-level commitments
  • Response-time remedies

Do not accept support as an automatic percentage of every dollar on the invoice without testing the calculation. Support is a distinct commercial line and should be benchmarked separately. Review AWS’s current Support pricing directly, then negotiate the enterprise-specific application.

How to benchmark AWS spend properly

You cannot benchmark AWS effectively by asking whether you received “20% off list price.”

That number may exclude the services where your spend is concentrated. It may also combine different pricing mechanisms and obscure the cost of commitment risk.

A useful AWS benchmark normalizes:

  • Service and SKU
  • Region
  • Usage volume
  • Instance family
  • Operating system
  • Pricing model
  • On-Demand equivalent
  • Effective unit rate
  • Discount off On-Demand
  • Savings Plan or Reserved Instance coverage
  • PPA/EDP discount
  • Credits
  • Support fees
  • Data transfer
  • Marketplace charges
  • Term length and commitment

Track at least three measures:

Effective discount rate

The total discount against the relevant On-Demand baseline.

Effective unit rate

The actual price paid per unit of compute, storage, request, transfer, or database capacity.

Net economic rate

The cost after credits, funding, support, and commitment liabilities are included.

This is where Right Price Benchmarking™ adds value. Benchmarking should reveal not just whether the discount looks attractive, but whether the total structure is commercially fair.

The AWS negotiation playbook

1. Start early

Begin at least six to nine months before a major renewal, PPA, or commitment decision. AWS has more flexibility when the customer has time to create alternatives and does not appear trapped by an expiration date.

2. Build an internal fact base

Bring together:

  • CIO or CTO
  • CFO or finance leader
  • Procurement
  • Cloud economics or FinOps
  • Enterprise architecture
  • Legal
  • Business-unit owners

Agree on the target architecture, migration timetable, acceptable commitment, walk-away position, and priority terms before engaging AWS.

3. Build competitive pressure

Azure and Google Cloud do not need to replace AWS entirely to create leverage. A credible alternative may include:

  • A workload migration
  • A regional deployment
  • A data and analytics platform
  • A disaster recovery environment
  • A new AI workload
  • A dual-cloud architecture
  • A competitive benchmark

The objective is not to threaten a migration the company cannot execute. It is to demonstrate that AWS is competing for future workload allocation.

4. Use timing deliberately

AWS’s fiscal calendar, quarter-end priorities, renewal windows, migration milestones, and internal account planning cycles can affect responsiveness.

Do not wait until AWS presents its final proposal. Establish your economic requirements early, then create a structured process with multiple proposal rounds.

5. Negotiate the complete package

Ask for more than a discount:

  • Better PPA or EDP economics
  • A defensible ramp
  • Carry-forward rights
  • Broader eligible spend
  • Marketplace treatment
  • Credits and MAP funding
  • Reduced support fees
  • Egress protections
  • New-service coverage
  • Renewal caps
  • Exit and portability language
  • Governance and reporting rights

AWS contract traps to review

Before signing, specifically test for:

  • Auto-renewal: Does the agreement renew automatically, and how much notice is required to prevent it?
  • Term escalators: Can the commitment or support fee increase during the term?
  • Service-level carve-outs: Are critical services excluded from meaningful remedies?
  • True-forward language: Can a shortfall or added usage create a higher future commitment?
  • Repricing risk: Can AWS reprice new services or move them outside the negotiated discount?
  • Credit expiration: Do credits expire before planned workloads go live?
  • Account restrictions: Can spend move between accounts, regions, and subsidiaries?
  • Marketplace exclusions: Does Marketplace spend count toward the commitment?
  • Support calculation: Are support fees calculated on gross or discounted usage?
  • Change-in-control language: What happens after a merger, divestiture, or acquisition?
  • Exit costs: What data, assistance, and egress obligations apply when workloads move?

Flat-design illustration of an enterprise cloud contract risk review showing auto-renewal, escalators, true-forward, carve-outs, and an exit path

Key takeaways for CIOs, CFOs, and procurement teams

  • AWS is not simply a usage bill. It is a portfolio of pricing models, commitments, credits, support charges, and contractual risks.
  • The largest discount is not always the best deal if it requires an unrealistic commitment.
  • EDPs and PPAs should be negotiated around eligible spend, flexibility, shortfall protection, and future-service treatment, not just the headline percentage.
  • Savings Plans and Reserved Instances optimize specific workloads. They do not replace enterprise-level negotiation.
  • Marketplace, MAP, credits, support fees, and egress can materially change the total economics.
  • Benchmark effective unit rates and net cost, not just “discount off list.”
  • Competitive pressure from Azure and Google Cloud is useful only when it is credible.
  • Contract language determines whether savings survive after the signature.

Frequently asked questions

How much discount can an enterprise get from AWS?

There is no universal public AWS discount table. Directional market ranges may vary from single digits for smaller commitments to the high teens or low twenties for very large, well-structured commitments. The actual result depends on spend, term, service mix, growth, competition, and negotiation timing.

Should we commit to all projected AWS growth?

Usually not. Separate current run rate, defensible committed spend, and strategic upside. Use ramps, expansion rights, and review mechanisms to capture upside without turning an uncertain forecast into a fixed liability.

Do Savings Plans replace an AWS EDP or PPA?

No. Savings Plans address eligible compute consumption. An EDP or PPA may provide broader enterprise pricing, but its scope and exclusions must be negotiated. The two mechanisms can coexist.

Can AWS Marketplace spend count toward an enterprise commitment?

Sometimes, depending on the agreement and eligible products. Never rely on a verbal assurance. Require the treatment of Marketplace spend to be stated clearly in the commercial documents.

Is AWS egress now free?

Not generally. Ordinary operational egress remains a cost category. Switching-related charges are subject to evolving regulatory requirements, including the EU Data Act, and AWS has separate policies and eligibility conditions for migration-related transfers.

When should we begin an AWS negotiation?

For a major renewal or enterprise commitment, begin six to nine months ahead where possible. Earlier preparation creates room for benchmarking, competitive pressure, internal alignment, and contract review.

Negotiate AWS before the commitment becomes the constraint

AWS spend compounds quietly. A small pricing gap across thousands of usage lines becomes a major financial issue when consumption grows every month.

The answer is not to avoid cloud commitments altogether. It is to make commitments that reflect reality, reward growth without overpaying for it, and preserve options when the roadmap changes.

The Negotiator Guru is an impartial negotiation firm. We do not accept vendor referral fees, and we operate discreetly as an extension of your team. We have delivered $1.05 billion in total cost impact globally, with average savings of 37% per deal. If we cannot identify at least 10% savings, we do not take the deal.

For a pending AWS negotiation, we can help with:

AWS may control the pricing model. Your team can still control the negotiation.

More resources

From Fortune 500 giants to fast-growing innovators, TNG has helped clients save 20% – 40%+ on enterprise software contracts — even when they thought it was impossible

Software Audits from Oracle, SAP, Microsoft, and Salesforce: What You Should Know

Getting an audit notification from your software provider can be nerve-wracking, but after reading this you’ll realize this is less likely due to something you’ve done wrong and more likely a tactic to throw you off-course.

​If you’ve never been through an audit before, you don’t know what to expect, what to do, or how to make sure it’s over as quickly as possible with minimal expense to your organization.

​​In this article, we’re going to make all this crystal clear by outlining the audit processes of large enterprise software providers like Oracle, Salesforce, SAP, and Microsoft.  There are a few key things you need to take into account that apply to all of these providers: ●     Use your contract as your best weapon to defeat audits. Take action if there is any sort of grey space in terms of what is allowed by the supplier.

  • Use your contract as your best weapon to defeat audits. Take action if there is any sort of grey space in terms of what is allowed by the supplier.
  • You’ll do best if you bring in outside assistance. An expert who has experience guiding businesses through software audits will be a huge help throughout the process.
  • You need to control all the information that is shared with the supplier in your own format and spreadsheets.
  • The more you are proactively sharing information with suppliers, the less basis they have to bring up an audit.
  • Audits are brought forth to customers for many commercial reasons. The more proactive you (the customer) are with sharing information, addressing audit risks in meetings, and creating a paper trail, the less likely your supplier is to audit you.

What is a Software Audit and How Did Your Company Get Selected for One?

A software audit is both a technical and contractual review of your organization’s use of a specific software platform within your IT environment. Most large enterprise software companies like Oracle and SAP have separate departments that focus purely on license compliance audits. These teams look and feel like a shared service organization inside of a large software company. They work with a customer’s account management team to take an aligned, yet separate and distinct, position on behalf of their software company. We will discuss the similarities and differences between these different teams later in the article.

One common similarity across all of these suppliers is that the audits will compare your usage and processes to any specifications, standards, or contractual agreements in place.

Why your company? Why did you get singled out for an audit?

​There are three primary operational/contractual triggers for a software audit:

  1. If there is any sort of consumption-based pricing in your contract;
  2. If you have any sort of restricted-use license in which you are only allowed to use a license for certain functionality; or,
  3. If you have recently acquired or divested a company.

While not mutually exclusive, you’ll also find the timing of these audits is very suspect and robotic in nature. The two primary timing triggers are:

  1. Anytime a large software company needs to identify “unearned revenue” to meet quarterly revenue targets; and,
  2. A pending contract renewal.

These large enterprise software companies know that it’s very common for their customers to be out of compliance due to the sheer size and scope of their operations. This is augmented by the fact they know anytime there is employee turnover within a customer’s IT organization (especially their “software asset management” department) the company is susceptible to additional compliance risk as a result of lost tribal knowledge of the environment, past internal audits, etc.

Taking all of this into consideration makes it relatively easy to understand why a company like Oracle can confidently predict net new revenue from their existing client base.

In addition to market pressure for additional revenue, a customer’s upcoming contract renewal also serves as an all too common trigger. The general rule of thumb we tell clients is anytime you have a contract renewal coming up nine to twelve months, your supplier is likely to introduce an audit. Your supplier will use this as an opportunity to distract you and gain the upper hand in an anticipated contract negotiation that hasn’t even started.

Suppliers do this because it automatically puts you in a defensive position. Naturally, you will be forced to concentrate on defeating the audit instead of allocating that same time to figuring out what you need for the upcoming contract renewal. They want to gain as much leverage and understanding of your business as possible before going into a renewal negotiation.

The audit is merely a tactic large software providers use to 1) seek out unearned revenue for their company to meet revenue targets and 2) gain the upper hand in your contract renewal negotiations in the hopes of minimizing any revenue loss from your account.

The fact of the matter is that it’s very common for customers to be unintentionally out of compliance. Knowing this, it’s important you know what to do in order to defend your company from what is potentially a very costly situation.  

Here’s an example to help illustrate this tactic

​By way of an audit, an ERP provider could discover you are misusing the license, giving the supplier reason to charge you a larger fee. Often, sales revenue targets for these audits are about 30% of your annual maintenance/subscription costs.

Let’s say you are spending $1M on core licenses, the audit will likely lead to around $300k in costs on top of that. If you can defeat the audit and keep your core license costs at $1M, then you will be happy and reward yourself for fending off the extra charges. In reality, the supplier didn’t expect the $300k in the first place, the audit was just a way to distract you from putting time and effort into your upcoming renewal negotiation.

It’s a win-win situation for them - if they win the audit, they put the money towards their sales revenue to meet their quota; if they don't, they’ve distracted you from being prepared to save money on your upcoming contract negotiation.

As a sales rep, finding new business is much harder than auditing an existing customer. Suppliers will target big companies because they don’t have perfect internal controls and mistakes are likely to happen.

What to Do When You Get an Audit from Oracle

​​When Oracle conducts an audit, they engage their License Management Services (LMS) team to run the process.

The audit process often involves installing software code within your secure environment. It is a listener software that will hit your mainframe servers and figure out how many other systems are connected.

This is important because, historically for this on-premise software, you are licensed based on the interconnectedness of both physical and virtual server environments. Your supplier wants to know how much “value” you are getting from their platform so the software they install provides a report of how many systems are interconnected. In a nutshell, the software delivers a report that illustrates when your technical architecture is in non-compliance. This automatically gives Oracle the upper-hand as it forces the customer to validate the information.

The best tactic to defeat this process is to never allow the software in your environment to begin with.

You have the right to refuse listening software within your Oracle contract.

Unless your contract explicitly calls out installing software, tell Oracle that installing software does not comply with your IT security protocols.

Look to determine if you have audit language specified in your contract. The older the contract you have with Oracle, the more likely you have the right to refuse the audit, or to at least not allow the listener software to be installed within your environment.

If this is the case, tell Oracle that instead of installing the software, you will run the audit yourself using their tools and spreadsheets with no software included. This means you are in control of what information is being shared with Oracle. Controlling the information is incredibly important in any audit, especially when suppliers are involved.

​What to do when Salesforce Conducts an Audit

​Salesforce audits customers when there is a restricted-use license available. When this happens you need to think critically about negotiating with Salesforce.

Salesforce is Software as a Service (SaaS) in the cloud which means they have more ability to freely monitor your utilization of licenses within your environment and can freely audit for misuse.

When you have a Restricted Use License (RUL), you have permission to use the product for a specific business purpose leveraging a certain number of standard and custom objects. Standard objects are modules within the Salesforce platform, such as contacts, accounts, or prospects. A custom object is something that was built by a Salesforce developer specifically for your company.

The license limitations in an RUL are a contractual limitation, not a technical one. A contractual limitation means there is legal language on your Order Form specifying how the license may use a predetermined number of standard/custom objects even though there is a set quantity limitation, technically there is no way to shut off access to other custom objects for that user.

This license is often in place for a subset of users who only need limited access to your tool. For example, an employee who is only viewing the data and not editing it. If this group starts editing objects, it becomes in and of itself a compliance issue.

Salesforce makes it easy for the end-user to accidentally do this without realizing they are in breach of the license. They will use this opportunity to accuse you of using the license incorrectly and request that your organization upgrade these licenses to full users and will seek compensation since the inception of the misuse. Contractually, Salesforce has the right to charge you full retail price for those non-compliant users.

Another time when Salesforce audits come into play is when a client is on a SELA Agreement (Salesforce Enterprise License Agreement).

How do you get around Salesforce RUL audit problems?

The best thing you can do is to establish quarterly check-ins with your account team at Salesforce. Use these meetings to stay on the same page with your account team and create a paper trail that shows how your users are engaging with the platform.

If you are accused of breaching restricted use, but have established quarterly check-ins with a paper trail, you can respond to Salesforce by saying “We met with your team and they didn’t bring anything up during our meeting so why should we believe you now?” Without quarterly check-ins and a paper trail, you get into a he-said-she-said argument.

Often times, the employee in breach of license may have accessed the wrong objects once or twice throughout the life of an account. Salesforce will create an argument that the license has been systematically misused for a long period of time.

We treat this event like a litigation. If you don’t have a paper trail of record, then you have no legal foundation for a defense. When comparing the perspective outcome of the party that has records and the other that does not, the person with records almost always wins in court.

Keep careful documentation about your interactions with Salesforce, and have open conversations about audit and license use risk. This will build a strong foundation and reduce the risk of an audit.

​How to Handle an Audit from SAP

An audit by SAP is very similar to an audit by Oracle in that, historically, their licensing model is primarily “consumption-based.” This means your price is based on your company’s revenue, profit, services used, how many suppliers you have, or any number of a series of variables.

This model falls under the concept of Value-Based Pricing and is a subjective assessment of value captured from the utilization of the software.

SAP will use many of the same tactics as Oracle which we’ve outlined above. One thing to specifically note about SAP is that they very frequently introduce audits during merger & acquisition (M&A) announcements. When supporting clients with M&A IT Sourcing, we commonly tell our clients to “get ready for the ‘ransom letter.’” These aren’t our words but rather those of our clients who received notifications from suppliers such as SAP immediately after announcing a large acquisition to the market.

Want to know if you’re susceptible to these ‘ransom letters?’ Take a look at your contract and keep an eye out for any language within your contract that indicates they will “readdress the terms of the contract if you the customer acquires or divests entities during the term of the contract.” If you have this language within your contract you will more than likely receive a similar notification within 1 month of publicly notifying your M&A intent.

In order to defeat an SAP audit, take the same approach we would take with Oracle and then protect yourself moving forward by changing your pricing model to a fixed baseline model that is attached to the reasonably certain variables in your company such as the number of employees.

​What to Do When Microsoft Audits You

​Microsoft’s audits vary depending on the products and services within your contract. Similar to Salesforce, Microsoft will commonly focus on those licenses that have restricted use. A very common audit for those clients with perpetual Microsoft Office licenses is the 1-to-1 validation of windows desktop licenses to computers within a customer’s environment. Similarly, for those clients with an active Office 365 subscription, Microsoft will look closely at the utilization of subscriptions that are inherently limited in their intended use. This is augmented by a deep analysis of computers and users in your ecosystem to ensure the capabilities being used are properly licensed.

If you are paying for any physical or virtualized servers from Microsoft within an SCE agreement,  you will commonly be audited to ensure your consumption metrics are within your contracted allocation.

Frequently with Microsoft, you are leasing the utilization of servers either on-premise or in the cloud. Generally speaking, if you have a physical piece of hardware from Microsoft on-premise, they will almost certainly conduct an audit at renewal time to monitor utilization as part of their “optimization analysis.” In a nutshell, they will try to move you from an on-premise environment to the cloud.

Conceptually this is fine but they will use that audit as leverage to do a lift and shift into Microsoft Azure.

Microsoft Azure is a very attractive product for the sales team because they are heavily incentivized to get your company into the cloud. The market is looking at how Microsoft’s cloud growth is going year after year and as a result, the company wants to increase its usage.

Essentially, Microsoft will audit to try and sell you on Azure. This isn’t necessarily a bad move to make but knowing key motivators will keep you ahead of the game and alleviate any potentially detrimental surprises.

What Happens Next?

​​If you’ve been audited by any of your enterprise software providers, we recommend bringing in outside help to guide you through the process. Leveraging their experience and expertise will go a long way to mitigate both short and long term risk that can easily rise into the millions.

Don’t solely believe what your account executive is telling you, oftentimes they don’t have all the information needed and they are heavily incentivized by their employers.

Your outside expert will be able to comb through your contracts, identify risks/opportunities, and drive both cost savings and containment.  With the proper assistance, you’ll be able to confidently stand your ground and mitigate risks before they are realized.

3 Strategies to Elevate Your Software Supplier Relationship

Over the years, our TNG client family has requested more and more guidance related to managing and elevating their commercial supplier relationships. Within this article, you’ll find our top 3 proven strategies to transform IT supplier relationships from tactical to strategic.

Strategy #1 – Control the Flow

When we say “control the flow”, we’re referring to conversation, meeting, and engagement flow.

When prospective clients reach out to TNG, they almost always have the complaint that the supplier knows more about the “needs” of their organization than they do. This most typically is due to the internal lack of time and/or resources to focus on a specific supplier or digital capability. On the other hand, the supplier’s sales team is laser focused on opportunities to grow their business inside of your organization. Immediately, this creates an unfair environment for all parties involved.

You may be thinking that this only creates an unfair advantage for you, the customer. Well, in most situations that’s true. However, it should also be noted that in some circumstances, the supplier’s sales team may be operating with good intentions and simply answering your internal stakeholder’s demand for attention. In short, when one side knows more than the other, it creates an uncomfortable situation for at least one party.

As our team brings 100+ years of collective experience, we have seen just about everything. Most of TNG’s clients are very well-established companies that have $5 billion+ in annual revenue. These companies typically have a “center of excellence (COE)” and/or a “software asset management (SAM)” team. While the overall intent is good, we typically see only about 10% of our clients leveraging these teams of resources correctly.

What happens to the other 90%? Well, one of the most classic inside sales techniques is for a supplier’s sales team member to establish, chair, and/or participate in a COE with a specific focus on their software and its many digital capabilities. This type of group typically meets either monthly or quarterly and is sold as a way in which the sales team member can “inform” the COE/SAM team members of the “demand” coming from inside of the organization. The reality is that the “demand” is often created by the sales team member who has been pushing a land-and-expand strategy inside of the organization.

The easiest way to not only level the playing field with your software suppliers, but also elevate the relationship from tactical to strategic, is to set up strict governance around the overall engagement. Every supplier engagement is slightly unique, but we recommend focusing on the following core tenants:

  • Focus your efforts on your Top 10 software suppliers.
  • Develop a steering team of executive IT leaders that are in control of the Digital Capability strategy for your company.
  • Develop an internal COE for each of your Top 10 suppliers. The size and scope of them should proportionally match the importance of the supplier’s impact on your business.
  • Identify and assign clear roles & responsibilities for each employee team member that is part of their performance objectives.
  • Do not allow supplier sales team members to be a member of the core team but rather serve as an invited guest on a routine cadence.

This is about the time where traditional sales team members will indicate that this approach will slow down process, innovation, growth, etc. The reality is quite the opposite when properly set up and managed. The primary outcomes you want to achieve are the following:

  • Shift the communication paradigm from outside-in to inside-out. This allows the company to ideate, contemplate, and organically socialize a software roadmap (vs. constantly asking the supplier for a list of their asset inventory).
  • Share information with suppliers only when it has been fully vetted and approved as a sanctioned project or approved proof of concept. If done properly, this drastically decreases the chance of duplicate purchasing, split requirements, and/or random unwarranted proof of concepts (that usually turn into shelfware) around the enterprise.
  • Allow everyone to be more efficient and structured with their time by eliminating the need for follow-up meetings, etc. In other words, engaging suppliers only after decisions have been made internally by the COE will enable the COE to be treated as a true authoritative entity vs a “check the box” exercise.
  • Provide opportunities for suppliers to suggest innovative solutions in a fully committed environment.

We find that our TNG clients save an average of 26% annually by deploying this strategy alone (with our help, of course).

Strategy #2 – Manage Upwards

Anyone who knows the basics of selling understands that the easiest way to make a sale is to identify and influence the decision-maker directly. For large enterprise sales teams who are managing multi-million-dollar contracts, that decision-maker is very often an executive leader within the company. Far too often, we find that organizations provide unfettered access to executives without reason. This, in short, usually enables a very unhealthy and complacent comfort for the supplier sales team that (if not properly managed) rarely produces intrinsic value for the company.

By far one of the most effective ways to elevate your supplier relationship is to set up strategic business discussions between company and supplier executives. The key here is to establish equal representation on both sides and ensure there is proper attention and respect established between both companies. Access to your company’s executives should largely be restricted to these meetings which, where possible, should be set up by the COE/SAM teams mentioned in Strategy #1.

Subsequently, it’s important to know that you can leverage access to your executives to exemplify to a new supplier that any new proof of concept, tool, etc. will be given the highest level of attention and visibility. This means a lot for any supplier (new or existing) as it ensures the right eyes are engaged.

Strategy #3 – Set Realistic Milestones that are Mutually Achievable

Just as employees like to understand their performance objectives for each year, it has been proven by TNG that suppliers who understand what “great looks like” outperform those that are not given clear business objectives. Nearly everyone in the business world understands the concept of milestones; however, the implementation of the methodology is highly inconsistent.

One of the many mistakes companies make when establishing a milestone-based contract is they make the actual milestones either ambiguous or unrealistic. Both are equally as dangerous. Ambiguity allows everyone to be right and wrong at the same time. Unrealistic milestones, if accepted by the supplier, often induce unhealthy behaviors by those chartered with meeting or exceeding the same. It doesn’t take much to set a once “strategic” relationship on a path to implosion with either of these scenarios.

Establishing realistic milestones is important for your suppliers. Everyone, at every age, enjoys accomplishing a goal. It’s important to recognize this fact since at the end of the day, as this is a human reaction, and well, we’re all human.

To learn how to properly set up a milestone plan and/or implement any other strategies mentioned above that drive performance for both the company and the supplier, here’s a hint: It’s not just the supplier that has performance milestones!