ERP Integration Without the Nightmare: How a Single API Layer Replaces 12 Custom Integrations

If you've ever built an integration with an ERP system, you know the experience is rarely pleasant. ERP APIs are complex, inconsistently documented, and designed for a different era of software development. If you need to connect to multiple ERPs, the complexity multiplies.

This post explains why ERP integrations are uniquely difficult, what it actually costs to build and maintain them, and how a single API abstraction layer can replace dozens of custom integrations without sacrificing data quality or coverage.

Why ERP integrations are different from other API integrations

Integrating with a modern SaaS product like Stripe or Shopify is relatively straightforward. They have REST APIs, OAuth authentication, good documentation, and sandbox environments. You can typically ship a working integration in a few weeks.

ERPs are a different story. Here is why:

• Legacy API architectures: Many ERPs, particularly NetSuite and SAP, use SOAP-based APIs or proprietary query languages rather than REST. NetSuite requires SuiteScript for many advanced operations. SAP has multiple API layers depending on the deployment model. These architectures require specialized knowledge that most development teams don't have. We use a SuiteScript methodology for NetSuite where we're essentially installing a router app into the customer's instance, because that's what's required to support robust read-write operations on the platform.
  
• Complex data models: ERP systems manage the full spectrum of business operations: accounting, inventory, procurement, manufacturing, HR. The data models are massive and deeply interconnected. A single invoice object might have dependencies on customers, items, tax codes, departments, locations, and currency configurations.
  
• Environment and access requirements: Many ERPs require formal onboarding processes, dedicated sandbox environments, and specific permission configurations before you can even start building. A NetSuite sandbox can cost thousands per year. Some configurations require working directly with the customer's ERP administrator.
  
• Platform-gated access: Some ERP capabilities aren't available through standard API access and require formal partnerships or marketplace listings. Intuit's bank feeds program, for example, requires a partnership agreement that can take years to establish. It took us two years to get our partnership with Intuit in place. Without that kind of partnership, you simply can't build certain product features, no matter how good your engineering team is.
  
  

The real cost of building in-house

Teams often underestimate the cost of building ERP integrations because they extrapolate from their experience building simpler API integrations.

When the Notch team built their QuickBooks integration in-house, they initially estimated it would take two engineers a couple of months. It ended up taking at least three months with multiple iterations. And that was for a single platform with a modern API.

For more complex platforms like NetSuite, the timeline stretches to six to twelve months. And that's just the initial build. Ongoing maintenance, including handling API version updates, addressing edge cases, and debugging customer-specific issues, adds a continuous engineering tax.

Multiply those timelines across the five to ten ERP platforms your customers might use: QuickBooks Online, QuickBooks Desktop, Xero, NetSuite, Sage Intacct, Sage Business Cloud, Microsoft Dynamics 365, FreshBooks, Zoho Books. Even at a conservative estimate of three engineering-months per platform, you're looking at years of cumulative effort.

How a unified API layer solves this

A unified API for ERP integrations works by abstracting away the platform-specific complexity behind a single, normalized API. You build one integration against the unified API, and the provider handles the translation layer for each underlying platform.

The key capabilities that make this work:

• Normalized data model: A single schema for invoices, bills, journal entries, payments, and other accounting objects that maps correctly to each underlying platform. Your application code works with one data structure regardless of whether the customer uses QuickBooks or NetSuite.
  
• Authentication abstraction: One authentication component handles the OAuth, API key, or credential-based flows for every supported platform. Your customer authenticates once, and you get access to all the data you need.
  
• Write support with accounting accuracy: The provider handles the platform-specific rules for creating and updating financial records. This includes structuring journal entries correctly, applying the right tax codes, handling multi-currency, and respecting business rules like reconciliation locks. At Rutter, we support native idempotency for writes, which ensures data is updated once and only once even when network retries occur.
  
• Partnership access: Established unified API providers have formal partnerships with platforms like Intuit and Sage that give them access to capabilities not available through standard API access. Our partnership with Intuit enables bank feeds integration that would otherwise require each customer to establish their own partnership. A newly chartered bank called Erebor is going live on Intuit bank feeds in three weeks end-to-end through us. Without that partnership, they'd likely still be stuck in partnership conversations.
  
  

What this looks like in practice

Flippa, an online business marketplace, was managing 50+ integrations in-house. Staying current with API updates across all those platforms consumed engineering resources that should have been focused on their core marketplace product. After switching to a unified API, they saved approximately $500,000 per year in integration maintenance costs.

Pex chose a unified API specifically for NetSuite, which they found to be extremely difficult to integrate with directly. Using a normalized data model across platforms let them dramatically reduce their integration cost and avoid dealing with the heterogeneous requirements of different accounting APIs.

PayPal made the decision to consolidate their integration strategy under a single provider after managing fragmented integrations across their merchant ecosystem. The driver wasn't cost savings but quality control: they wanted to own the quality of their product integrations rather than depending on individual platforms to maintain them. They envisioned an ecosystem of twenty or more products and workflows, and foundational to all of that was product integrations through a single provider where their customers authenticate once and only once.

The AI coding argument

One objection we hear increasingly is that AI coding tools have made it fast enough to build integrations in-house. And for simple read-only integrations with well-documented APIs like QuickBooks Online or Shopify, that's partially true. A developer with Cursor or Claude can scaffold a basic integration in hours. One prospect recently told us they coded integrations for both Xero and QuickBooks in two hours with Claude, and that covers roughly eighty percent of the SMB market.

But the complexity of ERP integration isn't in the code. It's in three things AI coding tools can't solve. First, gated access: many platform capabilities require formal partnerships that no amount of code can bypass. Intuit's bank feeds program took us two years to establish. Second, on-premise and non-standard architectures: NetSuite requires a SuiteScript-based router app installed into the customer's instance for certain operations. No AI tool will figure that out from documentation. Third, ongoing maintenance and edge case handling: normalizing data across multiple systems, handling error states, managing rate limits, and ensuring idempotent writes all require operational infrastructure that goes beyond generating code.

The code is the easy part. The hard part is everything around the code.

Making the decision

If your product needs to integrate with one or two ERPs with well-documented APIs for a simple read-only use case, building in-house is reasonable. If you need to integrate with multiple ERPs, support write operations, or build features that require platform partnerships, a unified API will save you months to years of engineering effort and reduce ongoing maintenance to near zero.