Before You Build ERP Integrations: A Product Team Guide (September

Your customers' ERP is their source of truth. If your product can't talk to it, you're creating manual work for them, and manual work is a fast path to churn. ERP integration sounds like a single technical task until you realize QuickBooks Online, QuickBooks Desktop, NetSuite, and Sage are four completely different problems. This is what product teams wish they'd known before they started.

TLDR:

• 98% of SaaS companies say integrated customers churn less, making ERP sync a retention lever.
• On-premise ERPs like QuickBooks Desktop and Sage 300 CRE require local installs, not API calls.
• Building one ERP connector takes ~6 weeks; maintenance across 4+ ERPs consumes entire engineering teams.
• Buy over build once you're supporting more than two ERPs or integrations aren't your core differentiator.
• Hotglue ships prebuilt connectors for QuickBooks, NetSuite, Sage, Dynamics, and Acumatica with per-tenant pricing.

What Is ERP Integration?

ERP integration is the process of connecting your software product to a customer's ERP system so data can flow between them automatically. Orders, invoices, inventory levels, payroll records, general ledger entries: depending on the ERP and the use case, any of these might need to move between your product and the customer's system of record.

For end users, the ERP is usually the source of truth for their business. If your product can't talk to it, your product creates extra manual work, and that's often the short path to churn.

For product teams, "ERP integration" covers a wide range of systems (QuickBooks, NetSuite, Sage, Microsoft Dynamics, Acumatica), each with different APIs, data models, and authentication quirks. Building one doesn't mean you've built them all.

Why ERP Integration Matters for B2B SaaS Products

ERP integration requests rarely come from a product roadmap review. They come from a sales call you almost lost, or a customer success note that says "they're considering switching."

The business case is straightforward. According to the 2026 State of SaaS Integrations Report, 98% of SaaS companies say customers who use integrations are less likely to churn, and according to the 2024 State of SaaS Integrations Report, 84% of businesses call integrations "very important" or a "key requirement." When your product connects to a customer's ERP, it stops being a point solution and starts being part of how their business runs. That's a very different retention position.

There's an acquisition angle too. Buyers assessing B2B software want to know it fits their existing stack before they sign. If a competitor offers a native NetSuite or QuickBooks sync and you don't, that gap shows up late in the deal and rarely in your favor.

Ownership of this usually lands with the CPO or Head of Partnerships: either someone is accountable for the integration roadmap, or everyone assumes someone else is. (Spoiler: no one is.)

Customers who connect more systems use more of your product and are easier to grow. ERP integration ties your product to revenue-critical workflows, and once it's in place, switching costs go up considerably.

The Most Common ERP Systems Your Customers Actually Use

The table below gives you a quick reference for the ERPs that show up most often in customer requests, along with the verticals and deployment types that shape how you'll need to build.

QuickBooks Online dominates the SMB and nonprofit space by a wide margin, making it usually the first ERP request you get. QuickBooks Desktop is a different beast, requiring a Windows agent instead of a standard API call, with a large installed base in construction and light manufacturing. NetSuite is the default for mid-market companies that have grown past QuickBooks, so expect those requests early if your customers are scaling e-commerce or SaaS businesses. Acumatica has been gaining ground fast in field service and e-commerce manufacturing, while SAP deals tend to come later given the implementation complexity involved.

How ERP Integration Works: The Core Methods

Three approaches dominate how product teams connect their software to ERP systems. Each carries real tradeoffs.

There are a few ways to think about the range of options here, from raw custom builds to fully managed infrastructure.

Point-to-Point

You build a direct API connection between your product and the ERP. Fast to start, painful to scale. Every new ERP you support means another custom build. When the ERP's API changes (and it will), you own the fix. Teams often start here and regret it by the third connector.

Enterprise Service Bus (ESB)

An ESB acts as a central hub that routes data between systems through a shared messaging layer. It was the enterprise standard before cloud became the default. Setup takes months, requires specialized middleware expertise, and works best for large organizations running on-premise infrastructure. For most B2B SaaS teams, it's more architecture than the problem warrants.

iPaaS (Integration Platform as a Service)

iPaaS sits between point-to-point and ESB in complexity. Pre-built connectors, hosted infrastructure, and managed authentication handle the parts that eat engineering time. The tradeoff is in how much control you retain over data transformation and connector behavior. Some iPaaS tools are black boxes; others let you write Python scripts and fork open-source connectors when the defaults fall short.

For product teams shipping customer-facing ERP integrations, iPaaS is where most decisions land. The real question is which flavor fits your architecture.

On-Premise vs. Cloud ERP: Why It Changes Everything About Your Integration

Cloud ERPs give you an API endpoint, OAuth, and documentation. You call it, you get data. On-premise ERPs give you a machine running somewhere in a customer's office, usually behind a firewall, with no public endpoint to call.

That distinction breaks a lot of integration plans mid-build. Usually around the time someone realizes the customer's QuickBooks Desktop is running on a Windows box under a desk in Accounting. No public endpoint, no OAuth, no sympathy.

As covered earlier, on-premise ERPs like QuickBooks Desktop and Sage 300 CRE require local installs instead of standard API calls. Construction, manufacturing, real estate, and parts of the nonprofit sector run heavily on-premise, and if your customers work in those verticals, you will hit this.

The practical consequence is that your original architecture assumes an API. On-premise connectors assume physical access to a machine, a local install, and resilience to software updates that might change the underlying database schema. That's a different engineering problem entirely, and finding this out after scoping your Q3 roadmap is not fun.

Plan your ERP integration roadmap around both deployment types from the start. Cloud-first is fine, but map out which ERPs your customers actually run before you commit to an architecture that only works for one of them.

The Top Use Cases for ERP Integration in B2B SaaS

The use case that triggers an ERP integration request usually comes from one frustrated customer, not a product strategy session. Here are the scenarios that come up most often.

• AP automation and billing sync (spend management tools like Tipalti or Rillet): bills, payees, and journal entries need to flow into QuickBooks, NetSuite, or Sage without manual export.
• Order and inventory sync (e-commerce ops tools like Linnworks): fulfillment data hits the ERP so finance sees it without a CSV upload.
• Payroll journal entries (HR and payroll tools): pay runs generate GL entries that accountants need in their ERP on payday, not three days later.
• CRM-to-ERP account matching (sales and revenue tools): customer records created in Salesforce or HubSpot need corresponding accounts in the ERP to avoid duplicate data entry.
• Expense and spend sync (payments tools like Airwallex): expense reports and card transactions need to land in the right GL accounts with attachments intact.

If your product touches money, headcount, or inventory, your customers' accountants are already asking why it doesn't connect to their ERP.

The Real Challenges of Building ERP Integrations In-House

Building your first ERP connector feels manageable. You find the API docs, you scope two weeks, and you ship something. Then the second ERP request comes in, and you realize the first one taught you almost nothing transferable.

Each ERP has its own authentication model. QuickBooks Online uses OAuth 2.0. NetSuite uses token-based auth with OAuth 2.0 for REST. QuickBooks Desktop routes through a Windows agent. Legacy systems sometimes hand you a SOAP endpoint from 2009. None of these patterns reuse cleanly, and each needs its own error handling, token refresh logic, and edge case coverage.

Schema complexity compounds this fast. Two customers on the same ERP can have different custom fields, different chart of accounts structures, and different fiscal calendars. A connector that works for customer A breaks silently for customer B because their GL account IDs are formatted differently. That's a data mapping problem you find in production, usually after a customer notices it first.

There's also API rate limiting, which teams hit later than they should. ERPs throttle aggressively, especially QuickBooks API usage and NetSuite under heavy sync loads. A connector that handles 50 records in testing falls over at 50,000 in production. Building retry logic, backoff handling, and graceful degradation into every connector is unglamorous work nobody budgets for upfront.

Then there's maintenance. ERP vendors deprecate endpoints, change field names, and ship breaking API versions on their own schedule. Between 55% and 75% of ERP implementations fail to meet their original goals, and ongoing integration drift is a real contributor. Multiply that across six ERPs and two engineers, and you understand why integration backlogs grow faster than they shrink.

ERP Integration Best Practices for Product Teams

A few principles separate teams that ship reliable ERP integrations from those that spend Q4 fixing broken connectors.

• Define the data contract before writing code. Know exactly which objects, fields, and sync directions you need. Bidirectional sync sounds simple until you hit a write conflict.
• Design deduplication logic upfront. Match records on multiple fields (email plus account ID, never a single field alone) so customer A's chart of accounts doesn't collide with customer B's.
• Separate dev and production environments from day one. A schema test that touches live GL entries is a bad day for everyone.
• Build error handling into every job, not as an afterthought. Log failures with enough context to diagnose them without reproducing the sync.
• Pull your customer success team into requirements early. They know which fields customers actually care about, and they'll find the gaps your API docs won't mention.

Build vs. Buy: How to Make the Decision

The default assumption for most product teams is to build. You already have engineers, you understand your data model, and the first connector seems tractable. The math changes once you're supporting four ERPs across twenty customer configurations while your roadmap falls behind.

Total cost of ownership is where build decisions quietly fall apart. The initial connector is maybe six weeks of engineering. API maintenance, schema drift, rate limit handling, and connector rebuilds for each new ERP version don't show up in the estimate. They show up in Q3 when two engineers are fixing integrations instead of shipping features your sales team promised.

Time-to-market is the other lever. A new connector from scratch takes months. With an embedded iPaaS, a NetSuite connector can be live in one to two weeks once you have test account access. At a market valued at roughly $59 billion and growing, ERP decisions made today compound for years.

A rough framework for making the call:

• Build if ERP integration is genuinely core to your product's value proposition and you need custom behavior that no connector library will cover.
• Buy if integrations are a customer requirement but not your differentiation. Your engineers' time is worth more on features only you can build.
• Buy if you're supporting more than two ERPs, or expect to. Maintenance costs scale faster than connector counts.

Team size matters too. A 10-person engineering team maintaining five ERP connectors has almost no capacity left for product work. The smaller the team, the faster the build-vs-buy math resolves toward buying.

What to Look for in an Embedded ERP Integration Solution

When reviewing embedded ERP integration solutions, a few criteria separate the ones worth building on from the ones that create more work than they save.

• Prebuilt connectors for the ERPs your customers actually use, including on-premise systems beyond the popular cloud ones. If your customers run QuickBooks Desktop or Sage 300 CRE, confirm on-premise support before you sign anything.
• Data transformation capabilities so you can reshape data between your schema and the ERP's without writing glue code from scratch each time.
• Open-source or inspectable connectors, because black-box connectors make debugging painful and create vendor dependency you cannot negotiate your way out of.
• Tenant-based pricing that scales predictably. Volume-based billing creates surprise invoices as your customer base grows; per-tenant pricing ties cost directly to revenue.
• SOC 2 Type II and GDPR compliance. Your customers' ERP data includes payroll, invoices, and GL entries, so compliance is non-negotiable.
• White-label deployment so your customers see your product, not your vendor's.
• Realistic time-to-new-connector estimates. Ask directly: how long from API access to a live connector? Weeks is acceptable. Months is a roadmap problem.

How hotglue Approaches ERP Integration for B2B SaaS Teams

Hotglue was built for product teams in exactly this position: too many ERP requests, not enough engineering capacity to handle them cleanly.

The connector library covers the ERPs that show up most in customer requests: QuickBooks Online, QuickBooks Desktop, NetSuite, Sage 100, Sage 300 CRE, Sage 200, Microsoft Dynamics 365, and Acumatica, among hundreds of others. On-premise support is real. QuickBooks Desktop runs through a Windows agent and the QuickBooks Web Connector. Sage 300 CRE installs directly on the customer's machine and connects to the local database, resilient to software updates that would break a naive API approach.

Each connector ships with a Python-powered transformation layer, so you control exactly how data maps between your schema and the ERP's. Complex deduplication, multi-field matching, custom GL account structures per customer: all handled in code you own. Syncs run on cron-based schedules configurable per connector, so QuickBooks can run nightly while NetSuite runs hourly in the same deployment.

Customers like Tipalti, Rillet, Airwallex, and Paylocity run production ERP workflows through hotglue today, processing roughly 10 billion records weekly across 38,000+ active tenants. New connectors go live in one to two weeks. Pricing is per active tenant, so costs scale with revenue, not data volume.

Hotglue is SOC 2 Type II and GDPR compliant. ERP data is processed and delivered directly to you and never stored. For product teams that need ERP integrations done right, without the six-month sidequest, it's the strongest embedded option on the market.

Final Thoughts on ERP Integration Strategy for Product Teams

The gap between scoping an ERP integration and actually shipping a reliable one is where most roadmap confidence quietly disappears. Your customers' ERPs are messy, opinionated, and not designed to make your life easy, but the teams that get this right tend to retain better, close faster, and spend less time in incident channels. A little upfront clarity on deployment types, data contracts, and total cost of ownership goes a long way. When you're ready to pressure-test your approach, book a demo with hotglue to see how it handles your specific ERP stack.

FAQ

How do I let my SaaS customers connect their own ERP without my engineering team building each connector?

An embedded iPaaS like Hotglue handles connector infrastructure, authentication, and sync orchestration so your team ships the integration without building it from scratch. Your customers connect their QuickBooks, NetSuite, or Sage account inside your product, and Hotglue manages the API calls, token refresh, and data mapping on the backend. This is the approach teams like Tipalti and Rillet use to support multiple ERP connections without dedicating engineers to connector maintenance.

What is the fastest way to ship a NetSuite integration for a B2B SaaS product?

The fastest path is an embedded iPaaS with a prebuilt NetSuite connector, a Python transformation layer for schema mapping, and tenant-based auth handling out of the box. Building from scratch typically takes months once you account for OAuth, field mapping, rate limit handling, and error logic. With Hotglue, a new NetSuite connector goes live in one to two weeks from API access.

Should I build ERP integrations in-house or buy an embedded solution?

Build if ERP integration is genuinely core to your product's value and you need custom connector behavior no library covers. Buy if integrations are a customer requirement but your real differentiation lives elsewhere. The math tips toward buying fast: the first connector looks like six weeks of work, but ongoing API maintenance, schema drift, and connector rebuilds for each new ERP version quietly consume two engineers who were supposed to be shipping features.

How does on-premise ERP support change what I need from an integration solution?

On-premise ERPs like QuickBooks Desktop and Sage 300 CRE don't expose an API endpoint you can call. They require a local agent install, direct database access, and resilience to software updates that can break a naive connector overnight. Most embedded iPaaS providers skip on-premise support entirely, so if your customers work in construction, manufacturing, or real estate, confirm on-premise coverage before you commit to a vendor.

What should I look for in embedded ERP integration pricing to avoid surprise invoices?

Tenant-based pricing ties your integration costs directly to your active customer count, so costs scale with revenue instead of spiking when sync volumes grow. Volume-based billing creates unpredictable invoices as customers run more records through your product. Hotglue charges per active tenant on a 30-day rolling window, counting only tenants with a sync in that period, which means you're not billed for dormant accounts sitting idle between months.