SAP Integration Services: A Guide for B2B SaaS Teams

What are SAP integration services, and what do they cover?

SAP integration services connect a B2B SaaS product to its customers’ SAP systems, covering the protocol layer, authentication, field mappings, customer-specific configuration, and ongoing maintenance. The point is to let the SaaS team sell into SAP-running enterprises without building deep SAP expertise in-house.

In practice the work splits into two delivery shapes: one-time custom integrations built for individual enterprise customers, and productized connectors shipped inside the SaaS product so customers can self-serve. Both depend on the same underlying skills: knowing what each SAP product exposes, choosing the right protocol, and dealing with the heterogeneity that makes every SAP instance behave differently.

That last part is the reason SAP integrations don’t behave like other integrations. Two customers can run the same SAP product, same version, and still have completely different field names, mandatory fields, approval workflows, custom validations, and number ranges. SAP is configured per business, and most enterprises have been adding configurations for a decade or more. A purchase order that posts successfully against one S/4HANA instance will throw three validation errors on the next.

This guide covers direct system-to-system integration with SAP. For an example of connecting SAP to an AI agent layer instead, see our S/4HANA MCP case study.

---

Which SAP systems do these services usually cover?

SAP isn’t a single product — it’s a portfolio of ERPs and line-of-business systems, each with its own integration surface. The ones B2B SaaS teams most often need to integrate with:

Each has its own quirks. ECC integrations almost always involve RFC or IDoc because OData was bolted on later through NetWeaver Gateway. S/4HANA Public Cloud restricts you to allowlisted APIs and a Clean Core philosophy. Business One has a completely different API model from S/4HANA. SuccessFactors and Ariba are essentially separate products that happen to share the SAP brand and a single sign-on.

We maintain pre-warmed sandboxes across these systems so we can develop and test against a live SAP instance from day one, not after a three-week procurement loop on the customer side.

---

Which SAP protocols do integration partners work with?

SAP exposes a handful of integration protocols, and the right one depends on system version, use case, and how much real-time behavior matters.

Where you have a choice, OData v4 is the right pick for newer S/4HANA instances — REST-based, JSON-friendly, and SAP’s strategic direction for new APIs. The catch: v4 coverage isn’t uniform across SAP’s API portfolio. Some business objects are only exposed via v2 services, others only via v4, and a few have both at different feature levels. Before committing to a protocol, map your required workflows (purchase orders, sales orders, master data, financial postings, whatever your use case touches) against what each version actually exposes for your target SAP version. Otherwise you end up running v2 for some endpoints and v4 for others, which doubles the client code, error-handling, and serialization work you have to maintain.

For non-trivial writes, the underlying ABAP code path is the same one BAPIs use, so the same per-instance customizations apply regardless of which protocol you pick. You don’t escape heterogeneity by switching protocols.

SOAP shows up on older systems and in formal B2B scenarios. RFC and IDoc dominate on ECC, where OData often doesn’t exist or only covers a fraction of the data model. CDS views are great for analytical reads on S/4HANA, with sub-second responses on complex joins, but they’re read-only.

A practical rule: pick the highest-level protocol that exposes the data you need with acceptable performance, and only drop down to RFC or IDoc when nothing else does the job. We’ve covered the broader API integration approaches B2B SaaS teams use elsewhere — the same patterns apply here.

---

How does a B2B SaaS company integrate its product with customers’ SAP systems?

Two patterns, and most SaaS companies eventually run both.

Pattern 1: one-time custom integrations. Your SaaS has an enterprise customer running SAP. They want your product to read or push data to their instance. You (or we) build a dedicated integration for that customer: authenticate against their SAP, map their fields to your data model, handle their custom validations, set up monitoring. The integration is owned per customer, lives in your codebase or theirs, and is sized to one deployment. Typical fit: high-value enterprise contracts where the SAP connection is part of the deal.

Pattern 2: productized connectors inside your SaaS. You build SAP integration into your product as a feature any customer can configure themselves. The customer enters their SAP credentials (or completes an OAuth flow), picks what to sync, and your product handles the rest. Typical fit: SaaS targeting mid-market companies running SAP, where you can’t afford a custom build per customer.

Most teams start with pattern 1 to land the first few enterprise deals, then move to pattern 2 once they have enough demand to justify the engineering investment. The transition is harder than it looks, because pattern 2 surfaces the heterogeneity problem in a way that pattern 1 doesn’t. For a wider view on structuring these decisions across multiple ERPs, our piece on B2B SaaS integration strategy covers the roadmap layer.

---

Why do self-service SAP connectors usually break on write operations?

Because every SAP instance has different mandatory fields, custom validations, custom approval workflows, and custom number ranges — and writes have to satisfy all of them.

Reads are the easy half. If your connector calls a standard OData service to list purchase orders, the response shape is consistent enough across instances that you can rely on it. You’ll see custom fields on some instances and not others, but you can ignore what you don’t recognize.

Writes are where it falls apart. To create a purchase order in SAP, you need to know which company code applies, which document type the customer uses, which payment terms they allow, what their plant and storage location structure looks like, which approval workflow gets triggered, and whether they require any custom Z-fields populated. None of that is in the standard API documentation; it lives in each customer’s SAP configuration. A connector that worked perfectly for the first three customers will fail validation on the fourth because they enforce a custom field that nobody else uses.

This is why a productized SAP connector almost always needs a configuration layer per customer. Either your customer’s SAP admin maps the customizations through a setup wizard, or someone (your team, your partner, or theirs) does the mapping during onboarding. The connector handles the API call; the configuration handles the heterogeneity.

The honest framing for prospects: read-only sync works out of the box. Write operations work for a defined slice (standard fields, common workflows) and need scoped configuration for everything else. Promising “self-service writes” without that nuance is how connector products end up with customer-support backlogs.

---

How long does an SAP integration take, and what does it cost?

Most SAP integrations land between EUR 3,000 and EUR 15,000, delivered in 2–6 weeks, with simpler scopes shipping in 1–2 weeks when scope and requirements are already well defined. Particularly complex projects (multi-system, bidirectional, heavy custom mappings across modules) can run above that range.

Pricing varies because SAP integrations vary. The lower end of the range covers a single-direction sync against standard SAP APIs with one auth method, light field mapping, and basic monitoring. The upper end covers bidirectional sync with custom field mappings, complex business logic, error handling across multiple SAP modules, and instance-specific configuration logic. Several factors push cost up: ECC vs S/4HANA (RFC/IDoc work runs longer than OData), the number of objects in scope, write volume and throughput requirements, and how much custom configuration each customer’s SAP enforces. Cost ranges are indicative; we come back with a fixed quote after a 30-minute scoping call.

The single biggest lever on cost is the partner. A team that has built SAP integrations multiple times before doesn’t need to spend the first two weeks learning the protocol stack, the auth quirks, or the per-instance customization patterns. They can reuse battle-tested code from previous builds and start shipping working endpoints on day one. A team learning SAP for the first time on your project will spend that time on your budget. The pricing range above assumes the former; the latter typically costs 1.5–2× more for the same scope.

For multi-customer productized connectors, the cost structure is different — you’re paying for one connector that serves many customers, plus per-customer configuration. We size the connector build separately from the recurring onboarding work.

---

How do you choose an SAP integration partner?

Pick a partner who knows both SAP and the SaaS world — most SAP integrators only know the first half.

Most SAP Implementation Partners and system integrators focus on enterprise SAP rollouts: greenfield S/4HANA implementations, ECC-to-S/4HANA migrations, custom ABAP development, and multi-quarter transformation programs. Their teams are deep on SAP internals, and that expertise is real — but the shape of those engagements is wrong for SaaS work. They run like enterprise consulting: long timelines, heavy project management, steering committees, multiple stakeholders signing off on every change. For a B2B SaaS team trying to ship a Salesforce-to-S/4HANA sync or build a productized SAP module inside a product, that overhead is overkill.

What you actually need is a partner with SAP technical depth who has also shipped SaaS-side integrations: per-customer configuration layers, OAuth flows for multi-tenant SaaS, productized connector architecture, and the kind of velocity SaaS engineering teams operate at. That combination is rarer than it sounds, because the two skill sets usually sit in different shops.

Beyond fit, three things matter on technical execution:

Delivery experience. SAP integrations punish teams that have only read documentation. The protocols are well-documented; the configurations aren’t. Look for a partner who’s shipped writes against multiple SAP customers and can talk specifically about what broke and how they handled it.

Sandbox availability. This is the operational lever most teams underestimate. We maintain pre-warmed sandboxes for S/4HANA (Cloud and on-prem), ECC, and Business One — meaning we develop against live SAP instances from day one, not after a three-week procurement loop on the customer side. For projects where the customer’s SAP team is overloaded, our sandboxes are how we keep timelines tight.

SAP Partnership. Inovaflow is an official SAP Partner as of 2026, and focuses exclusively on SaaS-side integrations rather than enterprise rollouts. This partnership gives us direct channels with SAP for technical clarifications, access to development instances, early access to evolving APIs, and an audit trail customers can verify. Combined with our SaaS integration track record, you can be sure you’re in the right hands.

For the broader framework on partner selection across systems, our piece on choosing an API integration partner walks through five evaluation criteria.

---

What if you’re an enterprise SAP customer, not a SaaS?

We work with enterprise SAP teams too — connecting SAP to CRMs, data warehouses, procurement portals, or custom internal tools. The work shape is the same as the SaaS case: same protocols, same heterogeneity, same partner discipline. The only thing that changes is what sits on the other end of the integration — another enterprise system rather than a SaaS product. And since we focus on enterprise tools across the integration space, we usually already know that system too.

Common enterprise scenarios include pushing master data from SAP into a CRM, syncing financial postings into a data warehouse, exposing material data to a procurement portal, and building event-driven flows where SAP triggers downstream systems. If you’re running S/4HANA, ECC, or any of the line-of-business systems and need a connection out to something else, the rest of this guide still applies — same partner-selection criteria, same protocol decisions, same heterogeneity to plan around.

---