Why ERP integration is the make-or-break feature for B2B SaaS
You’ve built a great SaaS product. The demo closes deals. The pilot goes well. And then the customer’s IT team says “great, now integrate with our SAP.” And your roadmap for the next 18 months is written.
ERP integration is the single most common blocker for B2B SaaS companies crossing the $1M ARR mark. Every enterprise customer has one. None of them are the same. And none of them were designed to talk to your modern API.
This article walks through the architecture patterns we ship at Ideaxa for ERP integration, the gotchas we’ve hit, and the engagement model that keeps it from consuming your entire engineering team.
The three integration patterns
Every ERP integration falls into one of three patterns. Choosing the right one up front saves you months of pain.
Pattern 1: Read-only sync (the easy 80%)
Pull data from the ERP into your product. Customer list, chart of accounts, item master, open invoices. Your product reads, never writes.
Implementation: scheduled job, pulls delta every 15 minutes, maps ERP fields to your schema, exposes them via your existing API.
Examples: pulling customer master from SAP into a CRM, pulling item master from NetSuite into an e-commerce platform.
Pattern 2: Bi-directional sync (the dangerous 20%)
Read AND write. Customer is created in your product → pushed to ERP. Order is fulfilled in ERP → pulled into your product. Both systems are source-of-truth for different fields.
Implementation: event-driven architecture, idempotent operations, conflict resolution, replay capability. This is where the engineering effort goes.
Examples: synchronizing customer and order data between a SaaS CRM and SAP S/4HANA, syncing inventory between a SaaS WMS and NetSuite.
Pattern 3: Embedded UI (the “Copilot in ERP” play)
Your product surfaces inside the ERP, or vice versa. Microsoft 365 Copilot extensions are an example. SAP BTP side-by-side panels are another.
Implementation: iframe, custom UI component, or native integration SDK (Dynamics 365 PCF controls, SAP UI5).
Examples: surfacing a SaaS analytics dashboard inside Dynamics 365, surfacing ERP data inside a custom Copilot agent.
SAP: the most common, the most painful
SAP is the 800-pound gorilla of ERP. Every Fortune 500 enterprise has SAP. Every one of them has a slightly different SAP installation. And the public APIs (OData, BAPI, IDoc) are functional but not pleasant.
SAP integration options, ranked by effort
-
SAP BTP + Integration Suite — the modern way. Pre-built connectors for most things, visual flow editor, hosted by SAP. $5K-$50K/month depending on volume.
-
SAP OData APIs (S/4HANA only) — REST-ish, mostly works. Rate limits are real (100 req/sec per user).
-
SAP BAPIs / RFC — the legacy way. Requires SAP JCo or NW RFC SDK on your server. Painful in non-Java stacks. Use only when OData doesn’t cover what you need.
-
SAP IDocs — for EDI-style integrations. XML over a file transfer or HTTP. Old but reliable.
-
Database direct reads (NEVER do this) — yes, some companies do this. It works until SAP does an upgrade and your schema breaks. Don’t.
The authentication nightmare
SAP supports 7+ authentication methods, and every customer uses a different one. The most common:
-
Basic auth (user + password) — common in dev, deprecated in prod
-
SAML 2.0 — common in mid-market
-
OAuth 2.0 with SAP IAS / IAS-IPS — the modern standard
-
Client certificate (mTLS) — for high-security environments
-
SNC (SAP-specific) — only when nothing else works
Our default: build an abstraction layer that supports all of them, with a configuration UI so the customer’s IT team can plug in their own credentials.
Microsoft Dynamics 365: easier, with gotchas
Dynamics 365 is the easier ERP to integrate with, by an order of magnitude. The Dataverse API is modern, well-documented, and rate-limited in a reasonable way.
The two integration paths
-
Dataverse Web API (recommended) — REST, OAuth 2.0, well-documented. Most entities are queryable. ~95% of integration use cases can be done this way.
-
Custom API / Plugin — for the 5% of cases where Dataverse doesn’t expose what you need. Write a plugin in C#, deploy to the customer’s Dynamics instance. Slow iteration cycle, hard to test.
The gotchas
-
Solution layering — your custom entities / fields need to be in a managed solution. Done wrong, you can’t upgrade later.
-
API limits per user — Dynamics 365 has per-user API rate limits. Plan for this.
-
The “Dynamics 365” naming confusion — there are 7+ products in the “Dynamics 365” family. Each has a different API surface.
The architecture we ship
Our reference architecture for ERP integration:
-
Connector service — one service per ERP type (SAP connector, Dynamics 365 connector, NetSuite connector). Each encapsulates the auth, rate limiting, and field mapping for that ERP.
-
Mapping layer — declarative config that maps ERP fields to your internal schema. Stored in your database, editable by the customer.
-
Sync engine — handles delta detection, conflict resolution, retry logic, dead-letter queue. Same engine across all ERPs.
-
Event bus — Kafka / Pub/Sub, where all sync events are published. Lets you build side effects (notifications, audit logs, etc.) without touching the connector.
-
Admin UI — for the customer’s IT team to configure auth, schedule syncs, view sync history, replay failed events.
For bi-directional sync, add:
-
Conflict resolution rules — declarative config that says “ERP wins for these fields, SaaS wins for those fields, last-write-wins for everything else.”
-
Replay capability — for when a sync fails and you need to re-run it without duplicating data.
The engagement model
ERP integration is a continuous investment, not a one-time project. We structure engagements accordingly.
Phase 1: Foundation (4-6 weeks, fixed fee)
Build the connector + sync engine + admin UI for one ERP (typically the customer’s ERP). One customer’s integration serves as the reference implementation.
Phase 2: Templatize (2-4 weeks)
Abstract the customer-specific config. Document the field mapping, the auth flow, the rate limiting. Now the integration can be re-deployed for a new customer in 1-2 weeks instead of 6-8.
Phase 3: Continuous (retainer)
Each new customer integration is 1-2 weeks of work. ERPs get upgraded, breaking changes happen. New ERP types get added (NetSuite, Workday, Odoo) as the customer base expands.
The ongoing cost is the price of staying enterprise-friendly. It’s worth it.