Building ERP connectors in-house sounds reasonable until it isn't. One connector for one customer is fine. But when the requests stack up and your on-premise ERP support is held together with a custom agent someone wrote in a hurry (at 11pm, before a customer call), the math stops working. Here's a clearer way to think about where your team's time should actually go.
TLDR:
- Building one ERP connector in-house costs $20,000-$40,000 and takes 3-6 weeks before a single customer goes live
- On-premise ERPs like QuickBooks Desktop and Sage 300 CRE require local agents and direct database access, not REST APIs
- Most embedded iPaaS providers stop at cloud APIs, leaving your construction, manufacturing, and nonprofit customers stranded
- Buy over build when maintenance is stealing sprint capacity or an enterprise deal is gating on an integration you won't reach for two quarters
- Hotglue supports on-premise ERP connectors including QuickBooks Desktop and Sage 300 CRE, with open-source connectors your team can inspect or fork
Why ERP Integration Is a SaaS Product Problem, Beyond IT
ERP connectivity used to live squarely in IT's domain. A systems integrator would show up, wire two systems together over a long weekend, charge a lot, and disappear. Job done, until it wasn't.
For B2B SaaS companies, that model collapsed. Your customers aren't asking IT to handle integrations with your product. They're asking your product to handle it. If your app can't sync with the ERP they run their business on, the conversation often ends there, before procurement, before legal, before the deal closes.
The stakes are straightforward. Customers select SaaS products based on fit with their existing stack. They renew when the product works without friction. They expand when they trust the data flowing between systems. ERP sits at the center of that stack for most mid-market and enterprise buyers, housing inventory, financials, purchasing, and payroll. A gap there is a reason to look elsewhere.
"We need this to work with our ERP" isn't a feature request. It's a qualifier.
ERP integration is now a product decision with revenue consequences, and it belongs on your roadmap whether your engineering team has bandwidth for it or not. That makes it a CPO or Head of Partnerships problem first, not an engineering ticket that floats to the top whenever a deal is on the line.
What "ERP Integration for SaaS" Actually Means
There's a common mix-up worth clearing up. When most people search "ERP integration for SaaS," they're thinking about two very different problems.
The first is a SaaS company adopting an ERP internally, like switching from spreadsheets to NetSuite to manage their own finances. That's a standard software implementation project.
The second, which is what this article is about, is a SaaS company building connectivity between their product and the ERPs their customers already run. Your customer uses Sage 100 to manage inventory. They want your app to read from it, write to it, or both. You have to build that bridge, maintain it, and make sure it works across every variation of how that customer has configured their ERP.
That second problem is a product engineering challenge, not an internal IT one. You're syncing data continuously across dozens or hundreds of customer tenants, each with their own ERP version, schema customizations, and authentication setup.
The scope compounds fast. One connector for QuickBooks Online is manageable. Add QuickBooks Desktop, NetSuite, Microsoft Dynamics 365, Sage 300, and Acumatica, and you're looking at a catalog that takes years to build and a team to maintain.
The ERP Ecosystem Your Customers Are Actually Running
Your customers are not running one ERP. They're running whichever ERP made sense when they started, which means you're dealing with a fragmented mix that spans decades of software history.
On the cloud side: NetSuite, Microsoft Dynamics 365, Sage Intacct, Acumatica. On the on-premise side: QuickBooks Desktop, Sage 300 CRE, SAP ECC, older Sage 100 installs. 79% of new ERP deployments are cloud-based, but "new deployments" is doing a lot of work in that sentence. The installed base of on-premise systems is enormous, especially in construction, manufacturing, and nonprofits, where upgrading a working ERP is a years-long project nobody wants to own.
For your product, this fragmentation is a direct engineering problem. Each ERP has its own auth model, data schema, API quirks, and versioning behavior. SAP ECC mainstream maintenance ends in 2027, which means your customers in that ecosystem are either mid-migration or ignoring the deadline entirely. Either way, you still need to connect to what they have today.
Why Legacy and On-Premise ERP Connectors Are the Hard Part
Cloud ERPs at least give you an API to call. On-premise ERPs give you a server you can't touch, running software from 2009, behind a firewall your customer's IT team controls.
That gap is where most embedded iPaaS providers quietly stop. REST APIs are clean. On-premise connectors require local agents, direct database access, or Windows-specific protocols that most integration vendors have no interest in supporting.
Two Examples Worth Knowing
QuickBooks Desktop uses the QuickBooks Web Connector, a Windows-only service that runs locally and brokers sync requests. There's no cloud endpoint to call. Your connector needs to install on the customer's machine, authenticate through that local service, and handle multi-user environments without corrupting data mid-sync.
Sage 300 CRE follows the same pattern. The connector has to reach the local database directly, which means the integration installs on-premise and needs to stay resilient when Sage pushes a software update that changes the schema underneath it.
For SaaS engineering teams, this usually becomes a one-off project. Someone builds a custom agent for one customer, it works for six months, then something breaks during an ERP patch and a support ticket arrives. There's no shared connector to fix. There's just an engineer who remembers writing that code.
The Hidden Cost of Building ERP Integrations In-House
Initial development is the part that gets budgeted. Everything after it is what breaks the math.
Building a single ERP connector from scratch takes somewhere between 3 and 6 weeks of engineering time. At a typical fully loaded engineering cost, that runs $20,000 to $40,000 per integration before a single customer goes live. Multiply that across five ERPs your customers actually use, and you've consumed a quarter of a mid-size engineering team's annual output on connectors alone.
Then the ERP vendor ships an update. An API endpoint changes. A customer has a custom field that breaks your field mapping. Another customer runs a version two major releases behind what you built for. Each variation is a maintenance contract your team never signed up for.
The compounding is what CPOs miss when they greenlight in-house builds. One connector at launch feels tractable. Twelve connectors across three ERP generations, each with tenant-specific quirks, is a support surface that grows every time you close a deal.
What an Embedded iPaaS Does Differently for ERP Connectivity
An embedded iPaaS sits inside your product, not beside it. End users authenticate their ERP from within your app, not through a separate tool or a manual setup process someone on your team has to walk them through. The integration layer handles OAuth flows, credential storage, sync orchestration, and error handling. Your engineering team controls the data model and transformation logic, but the connector infrastructure is already there.
That architectural split is what matters in practice. With an in-house build, you own every layer: auth, sync, mapping, maintenance, monitoring. With an embedded iPaaS, you own the data model and the experience. The connector itself is someone else's problem.
For ERP connectivity in particular, that separation carries real weight. ERP connectors have an unusually high maintenance surface, covering API versioning, schema drift, on-premise agent updates, and tenant-specific field customizations. Offloading connector maintenance keeps your engineers focused on what your product actually does, instead of becoming reluctant ERP specialists.
There is also the question of multi-tenancy. An embedded iPaaS runs every customer's sync through isolated tenant contexts, so one customer's NetSuite configuration cannot affect another's. That isolation is genuinely hard to build correctly in-house, and easy to get wrong in ways that only surface after a bad sync event.
Build vs. Buy: How to Make the Call on ERP Integrations
Building a single ERP connector in-house is often fine. If one customer needs NetSuite and your engineers have the bandwidth, ship it.
The math changes when requests become a pattern. A few signals that point toward buying:
- You're fielding integration requests faster than your team can build them
- Customers are asking for on-premise ERPs your team has never touched
- You've already built three connectors and maintenance is starting to steal sprint capacity
- An enterprise deal is gating on an integration your roadmap won't reach for two quarters
The opportunity cost question is the one skeptical engineering leads tend to underweight. Every sprint spent maintaining a QuickBooks Desktop agent is a sprint not spent on the feature that actually sets your product apart. That tradeoff is invisible in a single quarter and obvious over two years.
On-premise ERP connectors are poor candidates for in-house builds given agent installation complexity, local database dependencies, and version fragmentation across your customer base.
Types of ERP Integration Approaches (and Their Tradeoffs)
The table below gives a quick read on how the four main approaches compare before we get into the nuance.
| Approach | How it works | Upside | Tradeoff |
|---|---|---|---|
| Direct API integration | Your engineers call the ERP's API directly | Full control, no intermediary | You own auth, rate limits, versioning, and every breaking change |
| ETL/ELT pipeline | Extract ERP data, load to your warehouse, reshape it there | Good for analytics and reporting | High latency, poor fit for real-time customer-facing sync |
| Unified API abstraction | One normalized schema across multiple ERPs | Faster to start, consistent shape | Schema flattening loses ERP-specific fields; less control per connector |
| Embedded iPaaS with data mapping | Connector layer embedded in your product, transformation logic in code | Ships fast, tenant-isolated, maintainable | Requires vendor trust; connector depth varies by provider |
Direct API integration gives you the most control, but also the most exposure. Calling QuickBooks or NetSuite directly means your team absorbs every API deprecation, rate limit edge case, and auth flow change. Fine for one connector at one customer. Painful at scale.
ETL pipelines work well for internal analytics, but customer-facing sync is a different animal. If your customer wants ERP purchase orders reflected in your app within minutes, a nightly warehouse load won't cut it.
Unified APIs standardize the schema across ERPs, which sounds appealing until a customer asks why their Sage 300 cost center data isn't coming through. Normalization trades fidelity for convenience, and ERP data is too vertical-specific to flatten without losing something important.
The best embedded iPaaS solution sits closest to what most SaaS product teams actually need, as long as the provider has real depth on the ERPs your customers run, including the on-premise ones.
Key Requirements for Production-Grade ERP Integrations
A connector that works in a demo and a connector that works across 200 tenants in production are not the same thing. The gap between them is where ERP integration debt accumulates.
Here's what actually separates the two:
- Bidirectional sync: Reading from a customer's NetSuite is the easy half. Writing back, whether purchase orders, journal entries, or vendor records, requires handling conflicts, sequencing, and failure modes that one-directional connectors never surface.
- Retry logic and failure isolation: A sync failure for one tenant should never cascade. The connector needs to preserve state on failure and retry cleanly without duplicating records or silently dropping data.
- Schema mapping flexibility: Every customer has customized their ERP. Fixed field mappings break the moment a customer has a non-standard chart of accounts or a custom cost center field. Production-grade connectors need per-tenant mapping support.
- Configurable sync scheduling: Some data needs to move hourly, some nightly. Locking all connectors to the same cadence is a mismatch for how ERP workflows actually run.
- Rate limit management: ERP APIs enforce rate limits that vary by vendor, tier, and endpoint. Your connector needs to handle backoff without dropping jobs or surfacing errors to the end customer.
- Record matching and deduplication: Syncing 10,000 vendor records twice should not create 20,000 vendors. Multi-field matching on name, billing address, or external ID has to be built in from the start.
- Audit trails: Enterprise customers and certification requirements often demand a log of what synced, when, and what changed. Without it, support tickets become archaeology projects.
- On-premise deployment support: For QuickBooks Desktop or Sage 300 CRE, the connector has to run where the ERP runs, which means local agent installation, direct database access, and resilience to ERP software updates.
Most connectors pass the demo on the first three. The last five are where production breaks down.
How hotglue Handles ERP Integration for SaaS Products
Hotglue was built for this exact problem. Not the clean, cloud-API version of it, but the full thing: on-premise ERPs, tenant-by-tenant schema variations, and the maintenance that never ends.
On the on-premise side, hotglue supports QuickBooks Desktop via a Windows agent and the QuickBooks Web Connector, handling multi-user environments that cloud-only providers cannot reach. Sage 300 CRE installs directly on the customer's machine and connects at the database level, staying resilient when Sage pushes a software update underneath it. Most embedded iPaaS providers stop at REST APIs.
The broader connector catalog covers NetSuite, Microsoft Dynamics 365, Acumatica, Sage Intacct, Sage 200, and more. All connectors are open-source and fully visible to your engineering team. If you need to fork a connector or inspect exactly what's being pulled, you can. New connectors go from API access to live in one to two weeks.
At the infrastructure level, hotglue runs across 38,000+ active tenants and processes roughly 10 billion records weekly. Sync scheduling is cron-based and configurable per connector, so QuickBooks can sync nightly while Microsoft Dynamics runs hourly in the same deployment. The product is SOC 2 Type II and GDPR compliant, and never stores customer data. It processes and delivers.
Your engineering team keeps control of the data model and transformation logic. Connector maintenance, auth handling, rate limit management, and on-premise complexity sit with us.
Final Thoughts on Solving On-Premise and Cloud ERP Integration for SaaS
Whether your customers run NetSuite or QuickBooks Desktop from 2014, the expectation is the same: your product should just work with their ERP. Getting there without burning your engineering team on connector maintenance is the actual challenge. Book a demo with hotglue to see how we handle the on-premise side, the cloud side, and everything in between.
FAQ
Embedded iPaaS vs building ERP integrations in-house: what should a SaaS product team actually choose?
Building a single ERP connector in-house is often the right call if your team has the bandwidth and the request is a one-off. The math changes when you're fielding multiple requests, maintaining connectors across ERP versions, or spending sprint capacity on QuickBooks Desktop agent fixes instead of product work. At that point, an embedded iPaaS like Hotglue offloads connector maintenance, auth handling, and on-premise complexity so your engineers stay focused on what your product actually does.
How does Hotglue handle on-premise ERP connectors like QuickBooks Desktop and Sage 300 CRE?
Most embedded iPaaS providers stop at REST APIs, which means on-premise ERPs are simply out of scope for them. Hotglue supports QuickBooks Desktop via a Windows agent and the QuickBooks Web Connector, handling multi-user environments that cloud-only platforms cannot reach, and connects to Sage 300 CRE at the database level with an on-premise install that stays resilient when Sage pushes a software update underneath it.
How do I know when my SaaS product has outgrown in-house ERP integration builds?
Watch for these four signals: integration requests are arriving faster than your team can ship them, customers are asking for on-premise ERPs your engineers have never touched, you've already built three or more connectors and maintenance is bleeding into sprint capacity, or an enterprise deal is gating on an integration your roadmap won't reach for two quarters. Any one of these is a reasonable trigger to revisit the build vs. buy calculation.
What's the realistic timeline to go from a new ERP connector request to a live integration?
Once Hotglue has sandbox access to the target system, a new connector goes from API access to live in one to two weeks. That turnaround covers auth, field mapping, sync scheduling, and the on-premise deployment requirements that typically add months to an in-house build. The connector also ships maintained, not handed off to your team the moment something breaks.
Can a B2B SaaS product support ERP integrations without requiring engineering to embed a widget for every customer?
Yes. Hotglue's Magic Link feature lets end users authenticate and connect their ERP without your engineering team embedding the Hotglue widget at all. The customer follows a link, completes auth, and the integration is live. It's a lower-friction path that works particularly well for enterprise customers where IT controls the environment and a full embedded widget deployment isn't practical on short notice.