How to Technically Prepare Your SaaS for SAP ICC ( A Practical Guide for Vendors)

This article was last updated on 17 March 2026 to keep the information current. 

Disclaimer: It’s a long read, but if you want real clarity on the ICC process, it’s worth going through the entire guide. Grab a coffee and take your time. :)

“Are you SAP certified?” 

How many times have you heard that question from enterprise prospects? Probably every single time.

SAP certification isn’t a vanity badge; it’s a business accelerator. Certified SaaS solutions instantly gain credibility and eliminate the “prove it works with SAP” hurdle that stalls so many deals.

For SaaS vendors selling into SAP accounts, getting certified through SAP ICC is one of the strongest ways to answer “yes” in a credible way.

Yet most SaaS companies approach certification like a compliance checkbox. They bolt on a half-baked integration, submit it to SAP’s Integration and Certification Centre (ICC), and get rejected, or worse, they build the wrong thing entirely and realise it six months in.

The real challenge isn’t technical complexity. It’s knowing the game.

This guide focuses exclusively on the ICC route for SaaS vendors. It’s the practical blueprint you won’t find anywhere in one place (not even in the SAP community). 

Let’s make sure you do it once, do it right, and turn it into your next competitive moat.

SAP Store Vs. SAP Certified Solutions Directory

Before diving into ICC preparation, let’s clear up this confusion. There are two different routes for SaaS vendors to gain visibility through SAP: getting listed in the SAP Certified Solutions Directory or getting a commercial listing on the SAP Store.

Both paths serve very different purposes, and many vendors confuse them. If you want to get listed in the SAP certified solutions directory, SAP ICC (Integration Certification) is your way to go. And if you want a commercial listing on the SAP store, then SAP PartnerEdge Build is your route. 

Most SaaS vendors waste months chasing the wrong path. Always remember that ICC is for technical certification of integrations, and PartnerEdge Build is for commercial partnership.

Understanding SAP ICC for SaaS

SAP ICC certification is a formal confirmation from SAP that your product integrates correctly with one or more SAP solutions using released and supported technologies. The ICC runs scenario-based testing across SAP products and BTP (not theoretical checkboxes, but real integration workflows) that prove your SaaS can handle production workloads.

You’re tested for correct implementation and stability in an SAP environment. Upon success, you receive a certificate, test report, logo usage rights, and a listing in SAP’s online solutions directory. These assets directly support enterprise due diligence and procurement. 

Partnering with SAP through certification also opens doors to technical resources, expert support, and early insight into SAP’s roadmap, helping you innovate faster and maintain a competitive edge.

Practically, ICC tests:

• Integration correctness: your flows use released APIs/events and behave as documented (paging, deltas, errors, retries).
• Security posture: your identity model, token handling, scopes/roles, and transport encryption are correctly implemented.
• Operational readiness: logging, monitoring, and failure handling enable supportable operations in customer landscapes.
• Clean‑core alignment: extensions run side‑by‑side on BTP or external runtimes rather than modifying SAP core logic.

New ICC 2026 Update:

SAP is restructuring the Integration Certification program in Q3 2026. The new framework has two distinct paths:

Integration Certification: for solutions built on BTP, aligned to Clean Core, targeting public cloud and Business AI. This is the full badge, the branding, the go-to-market support.

Interoperability Review: an open program for any solution, including those that don’t qualify for full certification. No “SAP Certified” stamp, but your solution gets listed on SAP Notes with a detailed review summary.

If you’re starting the ICC process now, the first decision is which path your solution actually qualifies for. The rest of this guide focuses on full Integration Certification requirements.

Preparing Your SaaS for SAP ICC (A 5-Step Process)

You can’t bolt SAP certification onto an existing integration and hope it works. The architecture decisions you make upfront determine whether ICC validation takes weeks or drags into months of rework.

Step 1: Map Your Product to the Right ICC Scenario

The SAP Integration and Certification Centre (ICC) doesn’t test “integrations” generically. They validate against specific scenarios tied to SAP products and integration patterns. Picking the wrong scenario means you’ll build the wrong test plan.

Here’s how to match your SaaS to an ICC scenario:

1a. Identify Your Target SAP Products

List every SAP application your SaaS touches:

• S/4HANA Cloud (public or private edition)
• S/4HANA on-premise
• SuccessFactors (Employee Central, Recruiting, Learning, etc.)
• Ariba (Procurement, Sourcing)
• SAP Commerce Cloud, SAP Customer Experience products
• Industry clouds (Utilities, Banking, etc.)

Be specific. “We integrate with SAP” isn’t enough. ICC scenarios are product-specific.

1b. Map Your Integration Touchpoints to Published APIs

For each SAP product, document exactly how you connect:

• OData/REST APIs: Which API packages? (e.g., API_SALES_ORDER_SRV, Workforce Person API)
• SOAP services: Legacy, but still valid for several cloud and on-premise scenarios
• Events: Which topics from Event Mesh or enterprise messaging channels?
• Batch/file interfaces: Where the SAP product officially supports them (IDoc, flat file, EDI, etc.)

You must use released, public SAP APIs. If you’re calling an undocumented endpoint or private field, or relying on a “partner insider URL”, it will fail certification. Check the SAP Business Accelerator Hub to confirm your APIs are released.

1c. Define Your Integration Pattern and Runtime

How does your SaaS physically connect to SAP? Choose your runtime stack:

• SAP Integration Suite: Cloud Integration flows (iPaaS adapters), API Management (gateway/policies), Event Mesh (pub/sub broker)
• SAP Cloud Application Programming Model (CAP): Node.js or Java microservices running on BTP Cloud Foundry or Kyma
• External SaaS runtime (AWS/Azure/GCP) with secure connectivity to SAP APIs

Most modern SaaS vendors use Integration Suite + CAP. If you’re building a side-by-side extension with complex business logic, CAP gives you a full dev framework. 

If you’re primarily moving data between systems, Integration Suite handles routing and transformation without custom code.

1d. Validate Your Scenario Early with ICC

Before you build anything, contact SAP ICC with your high-level architecture:

• Target SAP products
• API/event list
• Runtime stack (BTP services you’ll use)
• Deployment model (multi-tenant SaaS, single-tenant managed app, etc.)

ICC does not provide the scenario catalogue publicly in full; vendors usually request the scenario sheet after initial contact. Use the provided scenario catalogue to match your SAP product + integration pattern combination to the current scenario name and test plan. 

If nothing fits perfectly, you’ll need to work with ICC to define a custom scope.

ICC will then confirm which scenario applies and send you the formal test plan for that scenario. This test plan defines exactly what they’ll validate: which APIs you must call, error-handling requirements, security checks, and performance benchmarks.

Don’t skip this step. Building without ICC confirmation is how vendors end up with reworks.

Step 2: Architect Your SaaS the SAP Way (Clean Core, BTP-Native)

SAP has strong opinions about how certified solutions should be built. Violate these patterns, and you’ll fail technical validation, even if your integration “works” in production. ICC does not require your SaaS to run on BTP, though BTP-aligned patterns are strongly recommended and make certification easier.

2a. The Clean Core Mandate: No Modifications to SAP Systems

Clean core means all your custom logic lives outside SAP’s ERP core. You build side-by-side extensions on SAP BTP that interact with SAP via released APIs and events. Your code runs in your BTP subaccount, not inside the customer’s S/4HANA system.

Why does SAP enforce this? Because modifications break upgrades. When SAP releases a new version, custom code can conflict with core changes, forcing customers to delay updates or hire consultants to rework customisations. Clean core keeps SAP systems upgrade-safe.

What this means for SaaS vendors: SAP is shifting new partner development toward clean-core architectures and ABAP Cloud for sanctioned ABAP extensions, while restricting new classic ABAP add-on certifications. If your integration relies on core modifications, direct table access, or classic add-ons, plan to refactor to a side-by-side BTP extension or ABAP Cloud that uses released APIs/events. Always confirm your specific path and timing with ICC.

2b. Your BTP Architecture Stack

Here’s what a clean-core SaaS architecture looks like on BTP:

Rule of thumb: 

If you need to process SAP data or trigger SAP workflows, do it from your CAP service or Integration Suite flow, never by modifying SAP directly.

Note on hybrid scenarios: If you need to support customers with on-premise SAP systems, you’ll route through Cloud Connector. The biggest enterprises are still running on-premise or private cloud. Both of which use the cloud connector.

Step 3: Get Connectivity and Integration Right

Never hardcode SAP URLs or credentials. Always use the BTP Destination service:

• Decouples endpoints and credentials from your code
• Supports token propagation, principal propagation, and OAuth flows
• Enables customer-managed credentials (they own their SAP system passwords, not you)

Terminate connections with mutual TLS (mTLS) where possible. Validate certificates. Don’t accept self-signed certs in production.

Event-Driven Integration (Prefer Events Over Polling)

If SAP publishes events for your use case (e.g., BusinessPartner.Changed, SalesOrder.Created), consume events instead of polling APIs:

• Subscribe to topics via Event Mesh or Enterprise Messaging
• Implement durable subscriptions (survive restarts)
• Handle replay (re-process events after downtime)

Events scale better, reduce API quota consumption, and deliver near-real-time updates.

Step 4: Nail Identity and Access Management

4a. Authentication Flow (IAS + XSUAA)

• User login: Identity Authentication Service (IAS) handles SAML/OIDC federation with customer IdPs
• App-to-app trust: XSUAA issues OAuth2 tokens for service-to-service calls
• Token lifetime: Issue short-lived access tokens (5–15 min), support refresh tokens
• Rotation hygiene: Don’t cache tokens forever; refresh proactively before expiry

4b. Authorisation (Scopes and Role Collections)

Define the scopes (permissions) your app needs:

read_orders, write_invoices, configure_tenant

Map scopes to role templates, then role templates to role collections that customers assign to users.

Document Segregation of Duties (SoD) requirements; which roles are mutually exclusive (e.g., “Approve Payments” + “Create Payments” should not go to the same user). Enterprise security teams will audit this.

Step 5: Observability and Operations (ICC Will Check This)

5a. Logging (Structured, Tenant-Aware)

• Use structured JSON logs with correlation IDs that trace requests across BTP → Integration Suite → SAP
• Tag every log with tenant_id so you can filter issues per customer
• Redact secrets: Don’t log passwords, tokens, API keys, or PII

5b. Metrics (What ICC Expects You to Track)

• Latency: p50, p95, p99 for critical API calls
• Throughput: Requests per second, records processed per hour
• Error ratios: 4xx (client errors) vs. 5xx (server errors) per endpoint
• Queue depth: For event-driven flows, how backed up are your subscriptions?
• API rate utilisation: How close are you to SAP’s rate limits?

5c. Distributed Tracing

Propagate trace context across service boundaries:

• Your CAP app → Integration Suite → SAP API
• Use OpenTelemetry or similar; sample intelligently (trace 1% of requests, 100% of errors)

5d. Operational Runbooks

Document standard procedures ICC will ask about:

• Incident triage: How do you diagnose a failed integration?
• Rollback: How do you revert a bad deployment?
• Tenant freeze/unfreeze: How do you pause a misbehaving tenant without affecting others?
• Key rotation: How do you rotate credentials (OAuth clients, certificates) without downtime?

Technical Readiness Checklist: What to Build Before ICC Submission

Treat this as a pre-flight checklist. If you can’t check every box, delay your ICC submission.

a. API Hygiene

• Only calling released, public SAP APIs (verified in API Business Hub)
• Implemented pagination (server-driven cursors or client-side $skip/$top)
• Using delta reads (change tracking) where available to avoid full data dumps
• Batching writes with OData $batch or equivalent
• Idempotent writes (natural keys or idempotency tokens to deduplicate retries)
• Respecting rate limits: exponential backoff with jitter, circuit breakers

b. Error Handling Matrix

Build a table per API endpoint:

No silent failures. Every error must either auto-recover, alert an operator, or notify the end user.

c. Security Evidence Pack

Prepare these artefacts for ICC review:

• Identity flow diagrams: How users authenticate, how apps get tokens
• Token lifetimes: Access token TTL, refresh token rotation policy
• Scope mapping table: Which OAuth scopes map to which role collections
• TLS/cypher suites: Versions supported (TLS 1.2+), cypher preferences
• Data encryption at rest: Which fields are encrypted, KMS ownership
• Audit logs: What events you log, retention period, export mechanism (SIEM-ready?)
• Data privacy: Categories of personal data processed.

d. Performance & Resilience Testing

• Created representative test datasets (1K, 10K, 100K records)
• Validated latency budgets: p50 and p95 end-to-end for critical flows
• Chaos testing: injected failures (expired tokens, SAP API unavailability, partial timeouts, malformed events)
• Proven scale safety: parallel threads vs. API quotas, queue sizing, back-pressure behaviour

ICC will ask for test results (performance evidence) if scaling is a must. Don’t claim “it scales” without data.

e. Documentation Bundle (Your “Architecture Dossier”)

Package these for ICC submission:

• Component diagram: BTP services, your app, SAP touchpoints. 
• Data flow diagram: How data moves between your SaaS and SAP (request/response, events, batch)
• Interface specs per SAP touchpoint: URL, OAuth scopes, payload examples, error model
• Operational playbooks: incident response, backup/restore, version upgrade process.
• Security posture summary: Aligned to enterprise security questionnaires (SOC 2, ISO 27001, etc.)

Your 7-Step Certification Plan: From Gap Analysis to ICC Approval

Now that you understand the architecture and readiness requirements, here’s the execution timeline that takes you from “we think we’re ready” to “we’re SAP certified.”

Step 1: Gap Analysis (1 week)

What you’re doing: Comparing your current implementation against the ICC test plan you received.

Specific tasks:

• Map each API your SaaS calls to the test plan’s integration requirements
• Identify missing event subscriptions, role/scope definitions, or security controls
• Document gaps in monitoring, error handling, and operational runbooks
• Create a backlog with owners and due dates for every gap

Deliverable: A prioritised work-item list that closes the gap between your current build and ICC requirements.

Common gaps vendors discover:

• No correlation IDs in logs (can’t trace requests end-to-end)
• Hardcoded credentials instead of using the Destination service
• Missing idempotency keys (retries create duplicate records)
• No circuit breakers (integration floods SAP APIs during outages)

Step 2: Environment Strategy (concurrent with Step 1)

What you’re doing: Deciding where to run your certification tests and preparing that environment.

Your options:

• Your own BTP subaccount + customer’s test SAP system (if you have a design partner)
• SAP Remote Access and Connectivity: SAP provides shared or exclusive test landscapes for S/4HANA, SuccessFactors, etc. (additional cost, requires planning)

Specific tasks:

• Provision test tenants or test accounts in your SaaS with a realistic configuration
• Seed test data: master data (business partners, materials), transactional data (orders, invoices), events
• Automate environment reset scripts so you can return to known preconditions between test runs

Deliverable: A reproducible test environment where you can execute ICC scenarios end-to-end without manual setup. If you join the SAP Open EcoSystem, you’ll get access to cheap licences, and SAP systems can always be launched in CAL. 

Budget consideration: If you need SAP-hosted test systems via Remote Access and Connectivity, factor in a few thousand dollars for shared or exclusive access and lead time (often a few weeks) to provision.

Step 3: Build Your Test Harness (1–2 weeks)

What you’re doing: Scripting the exact scenarios ICC will validate, so you can rehearse them repeatedly.

Specific tasks:

• Script end-to-end flows for each ICC scenario (e.g., “Create customer in SaaS → Sync to S/4HANA → Receive confirmation event”)
• Capture golden traces: Expected log patterns, API calls, response times for successful runs
• Build failure injection: Scripts that simulate expired tokens, SAP API outages, malformed events, and rate limit hits
• Create reset utilities: Scripts that clean up test data and return the environment to Day 0 state

Deliverable: Automated test scripts that prove every scenario works, plus documented failure-handling behaviour.

Pro tip: Record screen captures of successful test runs. ICC may ask you to replay specific flows during validation—having a reference video speeds up troubleshooting.

Step 4: Security & Performance Hardening (1–2 weeks)

What you’re doing: Proving your SaaS is production-ready from a security and performance perspective.

Security testing:

• Penetration testing: Can an attacker escalate privileges, exfiltrate data, or inject malicious payloads?
• Token misuse scenarios: What happens if a user presents an expired token, a token with insufficient scopes, or a token for a different tenant?
• Data leakage checks: Can Tenant A access Tenant B’s data through API manipulation or SQL injection?

Performance testing (where relevant):

• Execute ICC scenarios at expected concurrency (for example, 10, 50, 100 parallel requests)
• Validate quota-aware throttling: does your app respect SAP’s rate limits without crashing?
• Test backpressure: what happens when SAP APIs slow down or return 429 rate limit errors?

Deliverable: Test reports showing your SaaS handles realistic load and adversarial scenarios without breaking.

Step 5: Dry Run with Observers (≤1 week)

What you’re doing: Rehearsing the ICC test day exactly as it will happen, with internal stakeholders watching.

Who attends: Your engineering lead, product manager, and optionally a design partner customer.

Specific tasks:

• Execute the full certification script, timed (ICC test days typically take 4–6 hours)
• Capture screenshots and logs at every step
• Demonstrate failure paths: Show what happens when an API call fails, and how your app recovers
• Document any issues that arise and fix them before the ICC test day

Deliverable: A rehearsed, timed demo that proves you can execute the certification script without surprises.

What you’re validating:

• Can you complete all scenarios within the time window?
• Are your logs clear enough to debug issues on the fly?
• Do you have playbook steps memorised (e.g., “If token refresh fails, here’s how we reset tenant credentials”)?

Step 6: ICC Test Day (≈1 day)

What happens: Your engineers drive the demo; ICC observes and records outcomes.

Logistics:

• Schedule a full-day session (typically virtual, via screen share)
• ICC will work through the test plan scenario by scenario
• You execute each flow in your test environment while ICC validates the outcomes
• ICC may inject failures or ask “what if” questions (e.g., “What happens if this API times out?”)

What to have ready:

• Test environment: Pre-seeded with data, tenants configured
• Logs and traces: Real-time access to your logging dashboard with correlation IDs
• Playbook: Step-by-step instructions for each scenario, including reset procedures
• Point of contact list: Who to escalate to if you hit a blocking issue (e.g., SAP test system is down)

Deliverable: ICC records the test session and generates a preliminary report (pass/fail per scenario).

Common blockers on test day:

• The SAP test system is unavailable (plan for this—have a backup date)
• Credentials expired (refresh test credentials 24 hours before)
• Network issues (test your VPN/connectivity in advance)

Step 7: Post-Test Wrap and Certification (≤1 week)

ICC sends you a formal test report. If you passed, you receive your certificate and go-to-market assets. If you have minor findings, you address them and resubmit evidence.

If you passed:

• You get an official SAP certification document for your integration
• Logo usage guidelines on how to display the SAP Certified badge
• You get access to the SAP Certified Solutions directory to list your solution or update it over time
• You can reference the ICC certificate in your sales materials, get access to co-marketing templates, case study programs, and PartnerEdge GTM resources

If you have findings:

• ICC provides a list of issues (e.g., “Error handling for 503 responses is insufficient”)
• You fix the issues and provide updated test evidence
• ICC reviews the fixes (typically remote review, no second full test day required)
• Once resolved, you receive certification

Recertification requirements:

• Most software integration certifications are valid for 3 years
• Some cloud/HANA integrations require annual recertification
• Plan for recertification in your engineering roadmap
• Integration scenarios for cloud and SAP HANA are typically valid for 1 year due to higher update frequency.

Timeline and Costs: What to Expect

Typically, the SAP integration certification process takes up to two months (8 weeks from preparation to certification), depending on solution complexity and the readiness of technical documentation and testing. The base Certification fee (software integration) typically starts from €3,000 for most integration scenarios and covers ICC consulting, test plan, and validation activities. 

Additional costs to budget:

• If you need SAP-hosted test systems (S/4HANA, SuccessFactors, or Ariba), there’s an additional cost. Confirm options and pricing directly with ICC.
• Integration Suite, CAP runtime, and HANA Cloud used during development and testing typically cost between €500 and €2,000/month, depending on consumption.
• Your engineering time. The real cost is internal, such as architecture alignment, test harness development, documentation, and pre-certification testing (typically 4–8 weeks of engineering effort)

Expect to budget €5,000–€10,000 total for your first certification (ICC fee + optional SAP test systems + BTP runtime), plus 1–2 months of engineering time. Also, keep in mind that these certification costs are separate from your overall product development budget. Building a production-grade SaaS extension or integration typically requires 3–6 months of engineering effort.

Staying Certified After Go-Live

To maintain your certification, always validate that your integration still works before each release. Use contract tests to catch breaking changes early. 

Monitor SAP API deprecation notices. Subscribe to “What’s New” feeds for your target SAP products and Integration Suite. When APIs deprecate, plan migrations with feature flags to avoid customer disruption.

Refresh your security evidence annually. Update your pen-test reports, SOC 2/ISO mappings, compliance docs, and data processing agreements. Enterprise customers will ask for current evidence during renewal cycles.

Rotate credentials regularly. Use secure credential storage mechanisms (such as the BTP Destination service if you run on BTP) and short-lived workload identities. Prefer short-lived credentials over long-lived secrets.

Want guidance on your ICC path? We help SaaS vendors certify with confidence.

If you’re preparing for SAP ICC, we can help you get it right the first time. We support SaaS teams with both SAP certification strategy and SAP-certified integration development. If you need architectural guidance, a technical review, or a full end-to-end integration and certification support, let’s connect. 

Visit our offer page to learn more about our packages. 

FAQs 

What is the validity of the SAP Integration certification? 

Most software integration certifications are valid for three years. But Cloud and SAP HANA integration certifications are typically valid for one year (require annual recertification), due to faster update cycles.

What support does SAP provide during the certification?

SAP offers dedicated consulting through SAP ICC, scenario confirmation and test-plan definition, technical guidance on SAP-released interfaces, access to SAP-hosted test systems (optional, paid), live oversight during the certification test session, and written certification results and the official ICC certificate. This support is included in the ICC certification fee.

Can we certify AI-powered SaaS extensions?

Yes, of course! SAP supports certification for AI-powered extensions/integrations as long as the integration uses released SAP interfaces and aligns with the ICC test scenario. AI features themselves are not certified; the integration with SAP is. If your AI logic runs on BTP (or externally) and interacts with SAP using supported APIs/events, it can be included in your ICC scope.

Is the SAP Store listing mandatory?

No. SAP Store listing is not required for ICC certification and is handled separately through PartnerEdge Build + SAP Store readiness (ARC). However, ICC certification is often recommended before Store listing because the store highlights ICC-certified integrations, and ARC reviewers often expect released SAP APIs and clean integration patterns. 

Where do we find SAP APIs and prebuilt integrations?

All released SAP APIs, events, and packaged integrations are published on the SAP Business Accelerator Hub (formerly API Business Hub). This is also where you confirm whether an interface is officially released, a requirement for ICC.