Building Your Own SAP BoM Counter-Proposal

Why Building Your Own BoM Counter-Proposal Changes Everything

The standard SAP commercial process follows a predictable script: SAP's account team presents a renewal proposal with a revised BoM reflecting their view of your licence requirements; you review it, push back on headline price, negotiate a discount improvement, and sign. This process is designed by SAP, for SAP. It anchors every negotiation on SAP's preferred starting position — an inflated BoM that reflects peak usage metrics, upward user classification, and product inclusions that serve SAP's upsell agenda.

Building your own SAP BoM counter-proposal breaks this dynamic. When you arrive at the negotiation table with your own version of what the BoM should contain — supported by evidence from USMM measurements, access profile analysis, and deployment audits — you force SAP into a defensive position. Instead of you justifying why you should pay less than SAP is asking, SAP must justify why their proposal differs from yours.

This is not a theoretical advantage. Enterprises that present counter-proposals supported by independent analysis consistently outperform those that negotiate on SAP's terms. The average total contract value reduction achieved through counter-proposal negotiation, compared to headline discount negotiation, is 25–40% on comparable deal sizes. The SAP contract negotiation team at SAP Licensing Experts builds counter-proposals as a standard deliverable for every renewal engagement — because the data consistently demonstrates its effectiveness.

For context, the counter-proposal sits within a broader BoM management process. Before building a counter-proposal for renewal, it is worth understanding the pre-signature BoM audit process, the post-signature expansion risks, and the BoM vs usage gap analysis that feeds into the counter-proposal structure.

The Foundation: Data You Need Before You Start

A SAP BoM counter-proposal without supporting data is a commercial aspiration, not a negotiating position. SAP's legal and commercial teams know the licence rules in detail and will immediately challenge any counter-proposal that is not grounded in evidence. Building a defensible counter-proposal requires the following data assets.

• USMM Output (most recent 12 months): The User System Measurement output across all productive SAP systems is your primary source of Named User data. Run it independently, without SAP involvement, to establish your own baseline. Extract not just the summary classification counts but the detailed user-level data showing individual classification and access profile assignment.
• Transaction Usage Logs (6–12 months): For users in high-cost classification categories (Professional, Developer), extract transaction execution logs showing what each user actually executes, not what they have access to. This is the evidence base for reclassification arguments.
• LAW (License Administration Workbench) Consolidation: In multi-system landscapes, LAW consolidates USMM data across systems and produces the consolidated licence measurement. The LAW output is the primary data source for any discussion with SAP about Named User counts.
• Engine Usage History (24–36 months): For each Engine-based licence in the BoM, extract the actual business metric performance data for the past 24–36 months. Calculate the range, average, and realistic growth projection. This defines your counter-proposal engine metric.
• System Deployment Inventory: For each product in the BoM, document the deployment status: fully deployed in production, partially deployed, development only, or not deployed. This determines which products belong in the active BoM and which should move to deferred options.
• Existing Entitlement Schedule: A complete inventory of all SAP products you are currently entitled to under all existing agreements. This prevents SAP from proposing new licences for products you already own and identifies the exact entitlements that are in scope for the renewal.

The Eight-Step Counter-Proposal Process

1. Obtain a Complete Copy of the Current BoM Request the current, signed Bill of Materials from SAP's contract management team. Confirm it matches the version in your internal records. Identify every product, user count, engine metric, and cloud entitlement currently contracted.
2. Run the Full Data Collection Execute USMM across all productive systems, run LAW consolidation, extract transaction logs for Professional and Developer users, pull engine metric history, and complete the deployment inventory. Allow 10–15 business days for this step.
3. Build the Named User Counter-Position For each user type in the current BoM, build your proposed count based on LAW output, adjusted for ghost user removal and reclassification candidates identified through access profile analysis. Document the evidence basis for every count reduction.
4. Build the Engine Metric Counter-Position For each Engine licence, determine the appropriate metric quantity based on actual usage history plus a reasonable growth projection (typically 5–10% per year). Compare against the current BoM metric. Document the historical data supporting your proposed metric.
5. Review Product Inclusions For each product in the BoM, categorise it: active deployment (retain in BoM), partial deployment (retain with reduced quantity where applicable), development or pilot only (move to deferred option), or no deployment (remove or move to option). Build the justification for each categorisation.
6. Construct the Counter-BoM Document Build a structured counter-proposal document that mirrors the format of SAP's BoM but reflects your evidence-based positions. Include for each line item: your proposed quantity, the current BoM quantity, and a brief reference to the supporting evidence. Keep it factual and specific.
7. Calculate the Financial Impact Apply SAP's list prices and current maintenance rates to both the existing BoM and your counter-proposal to quantify the financial difference. This gives you the headline negotiating number and demonstrates the commercial significance of the counter-proposal.
8. Prepare Your Escalation Strategy Anticipate SAP's objections to each counter-proposal element and prepare evidence-based responses. Identify your walk-away positions — items you will not concede without equivalent compensation elsewhere. Determine your escalation path if account team negotiations stall.

Building the Named User Section of Your Counter-Proposal

The Named User section is typically the largest and most complex part of the counter-proposal. The core principle is simple: every proposed count reduction must be supported by data, and every proposed reclassification must be accompanied by access profile remediation evidence.

Professional User Count Reduction

Your LAW consolidation will show a total Professional user count across all systems. From this, subtract: users who have had no system access in the past 12 months (ghost users); users whose transaction logs show activity limited to a defined subset consistent with Limited Professional classification (reclassification candidates); and users who are documented as employees who have left the organisation since the last measurement. The resulting number is your counter-proposed Professional user count. Attach the LAW extract and transaction log summary as supporting evidence.

Reclassification Candidates

For each user proposed for reclassification, document: current classification, proposed classification, transaction log evidence showing actual usage, and confirmation of access profile modification to restrict to the proposed classification level. This documentation removes SAP's ability to argue that the user retains Professional-level access. Our SAP licensing basics guide provides the specific transaction sets that define each user classification, which are essential reference material for this analysis.

Growth Headroom

Your counter-proposal should include appropriate growth headroom — typically 10–15% above the current active user count — to avoid going immediately under-licensed as the organisation grows. Proposing zero headroom is commercially unrealistic and will give SAP grounds to challenge the counter-proposal's credibility. The headroom calculation should be grounded in your HR forecast or system deployment plan, not a round number.

Building the Engine and Product Sections

Engine metrics and product inclusions are less intuitive than Named User counts, but the same evidence-based principle applies. Every counter-position must be supported by specific data.

Engine Metric Negotiation

Present a 36-month chart of the relevant business metric — revenue, order volume, or similar — with a clearly labelled trend line and growth projection. Calculate the metric value at your proposed contract ceiling, showing that it covers the projected business volume with a defined buffer. If the current BoM metric ceiling is 40% higher than your data-based projection, this difference represents direct financial over-licensing that is indefensible once the data is on the table.

Product Deferral vs Removal

For products with no current deployment, the counter-proposal should propose either: outright removal from the BoM (eliminating both licence and maintenance cost); or deferral to an options schedule (maintaining the right to add the product at pre-agreed pricing without paying maintenance until activation). SAP will strongly resist outright removal of products they consider part of the "platform bundle." Deferral to an options schedule is the realistic compromise — it costs SAP a maintenance stream but preserves their relationship with the product and the future upsell opportunity.

Presenting Your Counter-Proposal to SAP

Timing and presentation matter as much as the substance of the counter-proposal. The optimal timing is to present your counter-proposal before SAP presents their renewal proposal — typically 3–4 months before the contract end date. This anchors the commercial discussion on your numbers from the start. Presenting a counter-proposal after SAP has already proposed a renewal value is significantly less effective: SAP's commercial team has already built an internal business case around their proposed number, and any counter-proposal becomes a challenge to that case rather than the starting point.

The presentation format should be formal and structured. A written document, not a verbal discussion, is the appropriate vehicle. The document should present your proposed BoM in the same format as SAP's standard BoM schedule, with your evidence references clearly attached. This level of formality signals that you have invested in the analysis and are not open to informal responses.

Request a formal written response from SAP's commercial team within a defined timeframe — typically 10 business days. This prevents SAP's standard tactic of deferring to "strategic account reviews" and "global deal desk approvals" that consume months of negotiating time. If SAP's initial response does not directly address your counter-proposal line by line, escalate the request in writing.

Managing SAP's Pushback: What to Expect and How to Respond

SAP's response to a well-constructed counter-proposal follows predictable patterns. Understanding these patterns in advance — and preparing specific responses — is essential for maintaining the negotiating advantage the counter-proposal has established.

"Your User Counts Don't Reflect Future Requirements"

SAP's most common objection to Named User reductions is that your counter-proposal reflects current usage but does not account for future growth. Response: your counter-proposal includes growth headroom — document the specific percentage and the basis for it. If SAP wants to negotiate a different growth assumption, ask them to provide the specific business case supporting a higher headroom requirement.

"Those Products Are Part of Your Core Platform Entitlement"

When you propose removing or deferring products from the BoM, SAP will often argue that those products are intrinsic to your platform licence or that removing them creates compliance risk. Response: request the specific contractual clause that requires these products to be in the active BoM rather than on an options schedule. "Core platform entitlement" is a commercial argument, not a legal one, in most SAP standard agreements.

"We Need to Escalate This to Our Global Deal Desk"

Escalation to "global deal desk" or "pricing committee" is SAP's standard stalling mechanism. It removes the account team's authority to accept any counter-proposal element and creates a multi-week delay while the urgency around your contract deadline builds. Response: escalation is fine — but set a specific deadline for the escalated response and make clear that after that deadline, you will proceed with alternative options (which may include S/4HANA on alternative cloud platforms, third-party support, or other commercial alternatives that reduce SAP dependency).

Our SAP contract negotiation team manages this pushback process as a routine part of our engagement. Having independent negotiators present with deep SAP commercial knowledge removes the psychological pressure SAP's account teams routinely exploit when negotiating directly with customers. See our SAP licensing case studies for outcomes achieved through this approach.