Forem: Kate Apideck

The Complete Guide to Exact Online API Integration in 2026

Kate Apideck — Sat, 09 May 2026 21:30:46 +0000

Exact Online is the leading cloud-based accounting software in the Netherlands and Belgium, with growing adoption across the UK, Germany, and other European markets. For developers building financial integrations, vertical SaaS products, or multi-tenant applications, the Exact Online API is essential—but it comes with unique challenges that trip up even experienced teams.

What You'll Learn

How Exact Online's OAuth 2.0 flow works (and its unusual requirements)
REST API structure with OData filtering
Rate limiting strategies and how to handle them
Multi-division architecture and why it matters
Working code examples in Python and JavaScript
How to reduce integration complexity by 10x with unified APIs

Understanding the Exact Online API Architecture

Two APIs, Different Purposes

Exact Online provides two distinct APIs:

API Type	Protocol	Use Case	Limitations
REST API	OData-based REST	Primary integration method	60 records per request (bulk: 1000)
XML API	SOAP/XML	Legacy operations, specific actions	Being phased out, limited support

For new integrations, always use the REST API. The XML API exists primarily for edge cases not yet supported by REST—like programmatic invoice-payment matching (reconciliation), which has no REST endpoint. Note that XML reconciliation requires manual file upload through the Exact Online web interface rather than true API calls.

Multi-Division Architecture

Unlike most accounting software, Exact Online uses a division-based architecture. Every API call requires a division ID:

/api/v1/{division}/salesinvoice/SalesInvoices

A single Exact Online account can contain multiple divisions (essentially separate accounting environments). Before making any API call, you must:

Authenticate the user
Fetch their available divisions via /api/v1/current/Me
Let them select which division to work with
Include that division ID in all subsequent requests

This catches many developers off guard—you can't simply authenticate and start fetching invoices.

Authentication: OAuth 2.0 with Exact Online

Registering Your Application

Before you can authenticate users, register your app in the Exact Online App Center:

Navigate to Manage > Apps
Create a new app (choose Public or Private)
Note your Client ID and Client Secret
Configure your Callback URL

Critical limitation: Until your app passes Exact's internal review, it can only connect with users from the same Exact instance that created it. This means you cannot onboard pilot customers from other tenants until approval—a significant blocker for startups testing with beta users.

OAuth 2.0 Endpoints

Exact Online uses regional endpoints. Here are the primary ones:

Region	Auth URL	Token URL
Netherlands	`https://start.exactonline.nl/api/oauth2/auth`	`https://start.exactonline.nl/api/oauth2/token`
Belgium	`https://start.exactonline.be/api/oauth2/auth`	`https://start.exactonline.be/api/oauth2/token`
UK	`https://start.exactonline.co.uk/api/oauth2/auth`	`https://start.exactonline.co.uk/api/oauth2/token`
Germany	`https://start.exactonline.de/api/oauth2/auth`	`https://start.exactonline.de/api/oauth2/token`

Native OAuth Implementation

Here's a complete OAuth 2.0 implementation in Python:

import requests
import base64
from urllib.parse import urlencode

class ExactOnlineAuth:
    def __init__(self, client_id, client_secret, redirect_uri, region='nl'):
        self.client_id = client_id
        self.client_secret = client_secret
        self.redirect_uri = redirect_uri
        self.base_url = f"https://start.exactonline.{region}"
        self.token_data = None

    def get_authorization_url(self):
        """Generate the OAuth authorization URL."""
        params = {
            'client_id': self.client_id,
            'redirect_uri': self.redirect_uri,
            'response_type': 'code',
            'force_login': 0  # Set to 1 to force re-authentication
        }
        return f"{self.base_url}/api/oauth2/auth?{urlencode(params)}"

    def exchange_code_for_token(self, authorization_code):
        """Exchange authorization code for access token."""
        token_url = f"{self.base_url}/api/oauth2/token"

        # Exact Online requires Basic auth header for token exchange
        credentials = base64.b64encode(
            f"{self.client_id}:{self.client_secret}".encode()
        ).decode()

        headers = {
            'Authorization': f'Basic {credentials}',
            'Content-Type': 'application/x-www-form-urlencoded'
        }

        data = {
            'grant_type': 'authorization_code',
            'code': authorization_code,
            'redirect_uri': self.redirect_uri
        }

        response = requests.post(token_url, headers=headers, data=data)

        if response.status_code != 200:
            raise Exception(f"Token exchange failed: {response.text}")

        self.token_data = response.json()
        return self.token_data

    def refresh_token(self):
        """Refresh the access token using the refresh token."""
        if not self.token_data or 'refresh_token' not in self.token_data:
            raise Exception("No refresh token available")

        token_url = f"{self.base_url}/api/oauth2/token"

        credentials = base64.b64encode(
            f"{self.client_id}:{self.client_secret}".encode()
        ).decode()

        headers = {
            'Authorization': f'Basic {credentials}',
            'Content-Type': 'application/x-www-form-urlencoded'
        }

        data = {
            'grant_type': 'refresh_token',
            'refresh_token': self.token_data['refresh_token']
        }

        response = requests.post(token_url, headers=headers, data=data)

        if response.status_code != 200:
            raise Exception(f"Token refresh failed: {response.text}")

        self.token_data = response.json()
        return self.token_data

    def get_current_division(self):
        """Fetch the user's current division."""
        if not self.token_data:
            raise Exception("Not authenticated")

        headers = {
            'Authorization': f"Bearer {self.token_data['access_token']}",
            'Accept': 'application/json'
        }

        response = requests.get(
            f"{self.base_url}/api/v1/current/Me",
            headers=headers
        )

        if response.status_code != 200:
            raise Exception(f"Failed to fetch user info: {response.text}")

        user_data = response.json()
        return user_data['d']['results'][0]['CurrentDivision']

That's about 100 lines just for authentication. And you still need to handle:

Token storage and encryption
Automatic token refresh before expiry
Multi-region endpoint routing
Division selection UI
Error handling for revoked tokens

Working with the REST API

OData Query Parameters

Exact Online's REST API is OData-based, supporting these parameters:

Parameter	Description	Example
`$select`	Choose specific fields	`$select=InvoiceID,InvoiceNumber,AmountDC`
`$filter`	Filter results	`$filter=AmountDC gt 1000`
`$orderby`	Sort results	`$orderby=InvoiceDate desc`
`$top`	Limit results (max 60, bulk: 1000)	`$top=60`
`$skip`	Pagination offset	`$skip=60`

Important: Unlike many OData implementations, Exact Online does not support the $expand parameter. Related entities (such as invoice line items) must be fetched through separate API calls rather than expanded inline.

Fetching Sales Invoices

class ExactOnlineClient:
    def __init__(self, auth, division_id):
        self.auth = auth
        self.division_id = division_id
        self.base_url = f"{auth.base_url}/api/v1/{division_id}"

    def _get_headers(self):
        return {
            'Authorization': f"Bearer {self.auth.token_data['access_token']}",
            'Accept': 'application/json',
            'Content-Type': 'application/json'
        }

    def get_invoices(self, top=60, skip=0, filter_expr=None, order_by=None):
        """Fetch sales invoices with OData parameters."""
        url = f"{self.base_url}/salesinvoice/SalesInvoices"

        params = {
            '$top': top,
            '$skip': skip,
            '$select': 'InvoiceID,InvoiceNumber,InvoiceTo,InvoiceDate,AmountDC,Currency,Status'
        }

        if filter_expr:
            params['$filter'] = filter_expr
        if order_by:
            params['$orderby'] = order_by

        response = requests.get(url, headers=self._get_headers(), params=params)

        if response.status_code == 429:
            # Rate limited - check headers for retry info
            raise RateLimitError("Rate limit exceeded", response.headers)

        if response.status_code != 200:
            raise Exception(f"API error: {response.text}")

        data = response.json()
        return data['d']['results']

    def get_invoice_by_id(self, invoice_id):
        """Fetch a single invoice by GUID."""
        url = f"{self.base_url}/salesinvoice/SalesInvoices(guid'{invoice_id}')"

        response = requests.get(url, headers=self._get_headers())

        if response.status_code == 404:
            return None

        if response.status_code != 200:
            raise Exception(f"API error: {response.text}")

        return response.json()['d']

    def get_invoice_lines(self, invoice_id):
        """Fetch invoice lines separately (no $expand support)."""
        url = f"{self.base_url}/salesinvoice/SalesInvoiceLines"

        params = {
            '$filter': f"InvoiceID eq guid'{invoice_id}'"
        }

        response = requests.get(url, headers=self._get_headers(), params=params)

        if response.status_code != 200:
            raise Exception(f"API error: {response.text}")

        return response.json()['d']['results']

    def create_invoice(self, invoice_data):
        """Create a new sales invoice."""
        url = f"{self.base_url}/salesinvoice/SalesInvoices"

        response = requests.post(
            url,
            headers=self._get_headers(),
            json=invoice_data
        )

        if response.status_code not in [200, 201]:
            raise Exception(f"Failed to create invoice: {response.text}")

        return response.json()['d']

    def get_all_invoices_paginated(self, filter_expr=None):
        """Fetch all invoices with automatic pagination."""
        all_invoices = []
        skip = 0

        while True:
            batch = self.get_invoices(top=60, skip=skip, filter_expr=filter_expr)

            if not batch:
                break

            all_invoices.extend(batch)

            # Exact Online returns exactly $top results if more exist
            if len(batch) < 60:
                break

            skip += 60

        return all_invoices

Creating an Invoice with Line Items

def create_complete_invoice(client, customer_id):
    """Create an invoice with line items."""

    invoice_data = {
        'InvoiceTo': customer_id,  # GUID of the customer account
        'OrderDate': '2025-01-30',
        'Description': 'Professional Services - January 2025',
        'PaymentCondition': '30',  # Net 30 payment terms
        'Currency': 'EUR',
        'SalesInvoiceLines': [
            {
                'Item': 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',  # Item GUID
                'Description': 'Consulting Services',
                'Quantity': 40,
                'UnitPrice': 150.00,
                'VATCode': '1'  # Standard VAT
            },
            {
                'Item': 'b2c3d4e5-f6a7-8901-bcde-f12345678901',
                'Description': 'Implementation Support',
                'Quantity': 20,
                'UnitPrice': 125.00,
                'VATCode': '1'
            }
        ]
    }

    return client.create_invoice(invoice_data)

Rate Limits: Understanding the Constraints

Exact Online applies rate limiting at two levels—per minute and per day—for each app-company combination:

Limit Type	Threshold	Reset
Per Minute	60 calls	Resets every minute
Per Day	5,000 calls	Resets at midnight (company timezone)

Note: While some partners may negotiate higher limits for specific use cases, there is no publicly documented tiered pricing structure. Plan your integration around the standard limits.

Rate Limit Headers

When you hit a limit, you'll receive HTTP 429. Exact Online uses a dual-header system for minutely and daily limits:

Minutely limit headers (sent when minutely limit is exhausted):

X-RateLimit-Minutely-Remaining: 0
X-RateLimit-Minutely-Reset: 1706648460

Daily limit headers:

X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1706684400

Important: When you have no more minutely calls available, Exact only sends the minutely headers. Your error handling should check for both header variants.

Rate Limit Handler:

import time

class RateLimitError(Exception):
    def __init__(self, message, headers):
        self.message = message
        self.headers = headers
        # Check for minutely-specific headers first
        self.minutely_remaining = headers.get('X-RateLimit-Minutely-Remaining')
        self.minutely_reset = headers.get('X-RateLimit-Minutely-Reset')
        # Fall back to daily headers
        self.daily_remaining = headers.get('X-RateLimit-Remaining')
        self.daily_reset = headers.get('X-RateLimit-Reset')
        super().__init__(message)

    @property
    def is_minutely_limit(self):
        return self.minutely_remaining is not None

    @property
    def reset_time(self):
        if self.is_minutely_limit:
            return int(self.minutely_reset) if self.minutely_reset else 0
        return int(self.daily_reset) if self.daily_reset else 0

class RateLimitedClient:
    def __init__(self, client):
        self.client = client

    def execute_with_retry(self, func, *args, max_retries=3, **kwargs):
        """Execute API call with automatic rate limit handling."""
        retries = 0

        while retries < max_retries:
            try:
                return func(*args, **kwargs)
            except RateLimitError as e:
                retries += 1

                if not e.is_minutely_limit:
                    # Daily limit - can't retry today
                    raise Exception(
                        "Daily rate limit exceeded. "
                        f"Resets at {time.ctime(e.reset_time)}"
                    )

                # Minutely limit - wait and retry
                wait_time = max(60, e.reset_time - int(time.time()))
                print(f"Minutely rate limited. Waiting {wait_time}s...")
                time.sleep(wait_time)

        raise Exception("Max retries exceeded")

Common Pitfalls and Gotchas

1. The Reconciliation Problem

One of the most requested features—automatically matching payments to invoices—has no REST API endpoint. You can:

Create invoices via API
Create payments via API
But you cannot programmatically reconcile them via API

The only workaround is uploading XML files with matching information through the Exact Online web interface—not through an API call. This requires manual intervention and breaks many automated accounting workflows.

2. No $expand Support

Unlike standard OData implementations, Exact Online does not support $expand. This means you cannot retrieve an invoice with its line items in a single request. Instead, you must:

# Fetch invoice
invoice = client.get_invoice_by_id(invoice_id)

# Fetch line items separately
lines = client.get_invoice_lines(invoice_id)

This doubles your API calls for any operation requiring related data.

3. Division Selection is Mandatory

Every request needs the division ID. If you hardcode it, your integration breaks when users switch divisions or have multiple. Always:

# On initial connection
divisions = client.get_user_divisions()
selected_division = prompt_user_to_select(divisions)
store_division_preference(user_id, selected_division)

4. App Approval Bottleneck

Your app won't work with external customers until Exact approves it. This process can take weeks, during which:

You can only test with your own instance
Beta customers can't connect
You're blocked on external validation

Plan for this in your launch timeline.

5. Regional Endpoint Complexity

Unlike most APIs with a single global endpoint, Exact Online requires you to:

Know which region the customer is in
Route to the correct regional endpoint
Handle token refresh per region

REGIONS = {
    'nl': 'https://start.exactonline.nl',
    'be': 'https://start.exactonline.be',
    'uk': 'https://start.exactonline.co.uk',
    'de': 'https://start.exactonline.de',
    'us': 'https://start.exactonline.com',
    'es': 'https://start.exactonline.es',
    'fr': 'https://start.exactonline.fr'
}

def get_client_for_region(region):
    if region not in REGIONS:
        raise ValueError(f"Unsupported region: {region}")
    return ExactOnlineAuth(
        client_id=CLIENT_ID,
        client_secret=CLIENT_SECRET,
        redirect_uri=REDIRECT_URI,
        region=region
    )

The Simpler Path: Unified Accounting APIs

Building and maintaining direct Exact Online integrations requires:

~500 lines of authentication and API client code
Rate limit handling with dual header support
Multi-region endpoint management
Division selection UI
Separate calls for related entities (no $expand)
Ongoing maintenance as Exact updates their API

For teams building multi-platform accounting integrations, this complexity multiplies. Add Xero, QuickBooks, Sage, and FreshBooks, and you're maintaining 5 separate integrations with different auth flows, data models, and quirks.

Before: Native Exact Online Integration

# Authentication setup
auth = ExactOnlineAuth(
    client_id=os.environ['EXACT_CLIENT_ID'],
    client_secret=os.environ['EXACT_CLIENT_SECRET'],
    redirect_uri='https://app.example.com/callback',
    region='nl'
)

# OAuth flow
auth_url = auth.get_authorization_url()
# ... redirect user, handle callback ...
auth.exchange_code_for_token(code)

# Get division
division_id = auth.get_current_division()

# Create client
client = ExactOnlineClient(auth, division_id)

# Fetch invoices with pagination and rate limiting
rate_limited_client = RateLimitedClient(client)
invoices = rate_limited_client.execute_with_retry(
    client.get_all_invoices_paginated,
    filter_expr="InvoiceDate gt datetime'2025-01-01'"
)

# Fetch line items separately for each invoice (no $expand)
for invoice in invoices:
    invoice['lines'] = client.get_invoice_lines(invoice['InvoiceID'])

# Transform to your data model
normalized_invoices = [
    {
        'id': inv['InvoiceID'],
        'number': inv['InvoiceNumber'],
        'customer_id': inv['InvoiceTo'],
        'amount': inv['AmountDC'],
        'currency': inv['Currency'],
        'status': map_exact_status(inv['Status']),
        'date': parse_odata_date(inv['InvoiceDate']),
        'line_items': inv['lines']
    }
    for inv in invoices
]

Total: ~600 lines of code across authentication, client, rate limiting, and data transformation.

After: Apideck Unified API

import apideck

client = apideck.Apideck(
    api_key=os.environ['APIDECK_API_KEY'],
    app_id=os.environ['APIDECK_APP_ID'],
    consumer_id='user-123'
)

# Fetch invoices - works identically for Exact Online, Xero, QuickBooks, etc.
invoices = client.accounting.invoices.list(
    service_id='exact-online',
    filter={'updated_since': '2025-01-01T00:00:00Z'}
)

# Data is already normalized with line items included
for invoice in invoices.data:
    print(f"Invoice {invoice.number}: {invoice.total} {invoice.currency}")

Total: 15 lines of code. Authentication, rate limiting, pagination, and data normalization handled automatically.

Feature Comparison

Capability	Native Integration	Apideck Unified API
Authentication	Build OAuth flow, handle refresh, manage per-region	Handled via Vault UI
Rate Limiting	Implement dual-header logic	Normalized
Data Normalization	Map each field manually	Pre-normalized to unified schema
Related Entities	Separate API calls (no $expand)	Included automatically
Pagination	Implement cursor/offset logic	Automatic
Error Handling	Parse OData errors	Standardized error format
Multi-region	Route to correct endpoint	Automatic
Division Selection	Build selection UI	Handled in connection flow
Add QuickBooks	Build second integration	Change `service_id` parameter
Maintenance	Monitor Exact API changes	We handle updates

Supported Exact Online Resources

Apideck's unified Accounting API supports these Exact Online resources:

Invoices (Sales Invoices) - Full CRUD
Bills (Purchase Invoices) - Read, Create
Payments - Read
Customers - Read with filtering
Suppliers - Read with filtering
Ledger Accounts - Read
Journal Entries - Read, Create
Tax Rates (VAT Codes) - Read
Invoice Items - Read
Credit Notes - Read

When to Use Native vs. Unified APIs

Choose Native Exact Online API When:

You only need Exact Online (no other accounting platforms)
You need Exact-specific features not in unified models
You're building for a single tenant/region
You have dedicated engineering resources for maintenance

Choose Unified API When:

You need to support multiple accounting platforms
You want faster time-to-market (days vs. weeks)
You prefer normalized data models
You want to avoid authentication complexity
You don't want to maintain integrations long-term

Getting Started

Option 1: Native Integration

Register at Exact Online App Center
Create your OAuth application
Implement the authentication flow above
Build API client with rate limiting
Map responses to your data model
Submit for Exact review (required for production)

Option 2: Apideck Unified API

Step 1: Create Your Exact Online OAuth App

Even with Apideck, you need OAuth credentials. Here's the streamlined process:

Visit apps.exactonline.com and sign in
Click "Register a test app" (can be promoted to production later)
Configure your app:
- App Name: Your application name
- Redirect URI: https://unify.apideck.com/vault/callback
Save your Client ID and Client Secret immediately

Important: The Client Secret is only shown once when you create the app. Copy it before closing the dialog.

For detailed instructions with screenshots, see our Exact Online OAuth Setup Guide.

Step 2: Configure Apideck

Sign up at apideck.com
Navigate to the Exact Online connector settings
Select "Use your Exact Online client credentials"
Enter your Client ID and Client Secret
Click "Save settings"

Step 3: Connect Your Users

Use Apideck Vault to let your users authenticate:

Open the Test Vault in your dashboard
Select your API domain (nl, be, uk, etc.)
Click "Authorize"
Your users sign in at Exact Online
Connection status shows "Connected"

Step 4: Start Making API Calls

# Test with curl
curl -X GET "https://unify.apideck.com/accounting/invoices" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "x-apideck-app-id: YOUR_APP_ID" \
  -H "x-apideck-consumer-id: user-123" \
  -H "x-apideck-service-id: exact-online"

Or use our SDKs:

import apideck

client = apideck.Apideck(
    api_key=os.environ['APIDECK_API_KEY'],
    app_id=os.environ['APIDECK_APP_ID'],
    consumer_id='user-123'
)

# List all invoices
invoices = client.accounting.invoices.list(service_id='exact-online')

# Create an invoice
new_invoice = client.accounting.invoices.create(
    service_id='exact-online',
    invoice={
        'type': 'service',
        'customer': {'id': 'customer-guid'},
        'line_items': [
            {
                'description': 'Consulting Services',
                'quantity': 40,
                'unit_price': 150.00,
                'tax_rate': {'id': 'vat-standard'}
            }
        ]
    }
)

Conclusion

The Exact Online API is powerful but complex. Between OAuth flows, multi-division architecture, regional endpoints, rate limiting, the lack of $expand support, and the app approval process, building a production-ready integration takes significant effort.

For teams focused on delivering value rather than maintaining integrations, unified APIs offer a compelling alternative—same data, fraction of the code, and the flexibility to add other accounting platforms without rebuilding from scratch.

Whether you choose native or unified, the key is understanding Exact Online's unique requirements upfront. The division system, rate limits, regional endpoints, and OData limitations aren't optional—they're fundamental to how the API works.

Resources

NetSuite Integration Guide

Kate Apideck — Sat, 09 May 2026 20:51:43 +0000

1. What NetSuite Integration Actually Means

NetSuite integration establishes bidirectional data flow between NetSuite and external systems: orders, customers, inventory, transactions, invoices, and financial data. The objective is to eliminate manual entry, reduce errors, and establish a single source of truth for financial and operational data.

Synchronous integrations process data in near real time. The calling system waits for NetSuite's response before continuing. Use this pattern for low-volume, high-priority transactions requiring immediate confirmation: inventory availability checks, credit limit validation, and payment authorization.

Asynchronous integrations use batch processing. Records accumulate in a queue and sync at scheduled intervals or when thresholds are met. This pattern handles high volume better and provides resilience against temporary API failures, but introduces latency between systems. Most production integrations use asynchronous patterns for the bulk of their traffic.

Common integration scenarios include CRM-to-finance flows in which customer records and sales orders move from Salesforce or HubSpot into NetSuite for invoicing and revenue recognition. The e-commerce-to-ERP sync keeps product catalogs, orders, and inventory aligned between Shopify, Magento, or custom storefronts and NetSuite. Billing system integrations push invoices, payments, and subscription events from Stripe, Chargebee, or Zuora into NetSuite for revenue management. Data warehouse pipelines extract financial and operational data from NetSuite and load it into Snowflake, BigQuery, or Redshift for analytics and reporting.

2. Why Teams Build NetSuite Integrations

Manual data entry between systems introduces errors at every touchpoint. A mistyped SKU, an incorrectly applied discount, or a transposed digit in a quantity field cascades into fulfillment problems, billing disputes, and accounting reconciliation nightmares. Integration removes these human error vectors entirely.

Integration enforces data ownership rules and synchronization patterns that establish which system is the single source of truth for each data domain. When customer records exist in both CRM and NetSuite with variations, integration defines which is authoritative.

A well-designed integration enables business logic execution at scale: automatic credit checks before order approval, dynamic pricing based on customer tier and volume, inventory allocation across multiple warehouses, and tax calculation for multi-jurisdiction transactions. These workflows become possible when systems communicate reliably.

For CTOs and engineering leaders, a clear integration architecture prevents the accumulation of tribal knowledge and reduces key person dependencies. It provides leverage for future system migrations since well-defined integration contracts are easier to redirect to new endpoints.

3. NetSuite Integration Mechanisms

Mechanism	Best For	Tradeoffs
REST Web Services	New projects, standard CRUD, microservices	Industry standard, wide record coverage. Requires OAuth setup.
SOAP (SuiteTalk)	Legacy stacks, typed schemas	Mature but heavy XML overhead, being phased out.
RESTlets	Custom logic, performance optimization, batch operations	Maximum flexibility. Requires SuiteScript expertise, consumes governance.
iPaaS/Middleware	Standard patterns, rapid deployment	Fast delivery. Less control, ongoing platform costs.

Architecture Decision: REST API vs RESTlets

Use the Standard REST API when: you need standard CRUD operations, your business logic runs externally, you want Oracle's maintained endpoints, or you prioritize standardization and ease of onboarding new developers.
Use RESTlets when: you need to combine multiple operations in one call to reduce round-trips, business logic must execute within NetSuite's transaction context for atomicity, you need custom response formats, or you're optimizing for governance unit consumption. A RESTlet can validate 50 line items server-side in one call instead of making 50 external validation requests.

Oracle is actively pushing REST forward and has stopped adding new SOAP endpoints. REST should be the default for new projects unless you have specific legacy constraints requiring SOAP.

4. Architecture and Design Principles

Source of Truth Decisions: Define which system owns each data domain. Customer master data might live in your CRM, with NetSuite as the consumer. Product information might originate in your PIM, sync to NetSuite for pricing and inventory. Financial transactions and journal entries are almost always owned by NetSuite. Document these decisions explicitly. When conflicts arise, the source of truth system wins.

Data Modeling and Transformation: NetSuite's record model rarely maps one-to-one with source systems. A Salesforce opportunity might become a NetSuite estimate, then a salesOrder, then an invoice. A single ecommerce order might create multiple NetSuite transactions if it spans subsidiaries. Build a canonical data model between systems to isolate each connector from changes in the others.

Sync Patterns: Use synchronous patterns when you need immediate confirmation: inventory checks before order confirmation, credit validation before quote acceptance. Use asynchronous patterns for everything else, especially batch jobs processing hundreds of records.

Architecture Warning: Multi-Subsidiary Complexity

Many NetSuite accounts serve multiple subsidiaries, currencies, and legal entities. Orders must be created in the correct subsidiary based on the customer location or ship from a warehouse. Intercompany transactions require automatic journal entries. Currency conversion rules vary by transaction type. Map these scenarios during design, not testing.

5. Deep Dive into NetSuite APIs

REST Web Services

NetSuite's REST API follows standard JSON conventions. Standard records include customer, vendor, salesOrder, invoice, purchaseOrder, inventoryItem, and hundreds of others. Custom records defined in NetSuite are also accessible via the REST API. Lists provide reference data like terms, currencies, and custom lists.

CRUD operations: POST creates records, GET retrieves by internal or external ID, PATCH performs partial updates, PUT performs full replacement or upsert, DELETE removes records. All operations return standard HTTP status codes.

Pro Tip: The Upsert Pattern

Use PUT with an external ID to perform upserts in a single call. If the record exists, it updates. If not, it creates. This eliminates the lookup call before every write operation.


PUT /services/rest/record/v1/customer/eid:SF-12345

Where eid:SF-12345 references the external ID. This reduces API calls by 50% compared to the GET then POST/PATCH pattern and simplifies error handling.

The REST API supports query parameters for filtering record lists by field values, date ranges, and formula conditions. For complex queries, saved searches defined in NetSuite can be executed via API and return results as JSON.

Search Limitations and Pagination

Architecture Warning: 1,000 Row Limit

Standard REST queries return a maximum of 1,000 rows per request. For larger datasets, implement pagination using offset or pageIndex parameters:

GET /services/rest/record/v1/customer?limit=1000&offset=1000

For bulk extraction exceeding 100K records, saved searches via SuiteQL are more efficient, supporting up to 5,000 rows per page. For very large datasets, consider scheduled MapReduce scripts that export to SFTP.

Code Examples

Create salesOrder with idempotency and proper headers:

POST /services/rest/record/v1/salesOrder HTTP/1.1
Host: 1234567.suitetalk.api.netsuite.com
Authorization: Bearer <access_token>
Content-Type: application/json
Prefer: respond-async
NetSuite-Idempotency-Key: ord-2024-001-abc123

{
  "externalId": "SHOP-ORD-98765",
  "entity": {"id": "12345"},
  "item": {
    "items": [
      {"item": {"id": "789"}, "quantity": 10, "rate": 25.00}
    ]
  }
}

The NetSuite-Idempotency-Key header prevents duplicate records from being created during retries after network failures. Always include externalId for future upsert operations and cross-system traceability.

RESTlets and SuiteScript

RESTlets are custom endpoints built inside NetSuite using SuiteScript. They encapsulate complex business logic: accept a simplified payload, validate it, apply custom pricing rules, create the sales order, trigger related workflows, and return a response tailored to your needs.

Use RESTlets when standard API operations do not meet requirements, when you want to reduce round-trips by combining multiple operations into a single call, or when business logic must execute within NetSuite's transaction context for atomicity. RESTlet execution consumes governance units, but a single RESTlet processing 100 records uses fewer units than 100 individual REST API calls.

6. Concurrency, Scaling, and Costs

Concurrency Limits and Licensing

NetSuite limits concurrent requests per integration. Exceeding limits returns 429 Too Many Requests errors and can temporarily block your integration.

License Type	Concurrent Request Limit	Notes
Standard	5 concurrent requests	Included with NetSuite license
SuiteCloud Plus	10+ concurrent requests	Additional licensing cost

Cost Factor: SuiteCloud Plus Licensing

High-throughput integrations processing more than 10K transactions daily typically require SuiteCloud Plus licensing for increased concurrency. Budget for this during project planning. SOAP (SuiteTalk) calls within standard limits are included in base licensing. REST calls count against governance limits regardless of license tier.

Worker Pool Architecture

To maximize throughput without triggering 429 errors, implement a worker pool pattern:

Set worker count to license concurrency limit minus one (buffer for manual operations)
Use a message queue (SQS, RabbitMQ, Kafka) to decouple event production from API consumption
Implement exponential backoff with jitter on 429 responses
Monitor queue depth to detect backpressure early

Max Workers = License Concurrency Limit - 1
Backoff = min(base_delay * 2^attempt + random_jitter, max_delay)

This architecture provides natural rate limiting while maximizing throughput within your license constraints.

7. Authentication and Security

OAuth 2.0 is the required authentication mechanism for NetSuite REST APIs. Create an integration record in NetSuite, generate client credentials, and exchange them for access tokens.

Least Privilege Roles: Create a dedicated integration role with minimum required permissions. For salesOrder creation: create permission on salesOrder, read permission on customer and item records. Never use Full Access or administrator accounts for API operations.

Token Management: Store OAuth tokens in a secrets management system like HashiCorp Vault or AWS Secrets Manager. Never commit tokens to source control or log them in application logs. Automate token refresh before expiration.

Environment Separation: Maintain separate credentials for sandbox and production environments. Configure deployment pipelines to inject the correct credentials based on the target environment.

Pre API Configuration Checklist

Enable REST Web Services: Setup > Company > Enable Features > SuiteCloud
Create integration record: Setup > Integration > Manage Integrations
Create a role with the required permissions
Generate OAuth credentials and store them in Secrets Manager
Test authentication in the sandbox before writing application code

8. Record Mapping and Data Contracts

Source Entity	NetSuite Record	Sublist Details	Key Linkages
CRM Contact/Account	Customer	Address Book (addresses), Contact (contacts)	External ID links to CRM ID
Product/SKU	Inventory Item, Service Item, Non-Inventory Item	Pricing Sublist, Bin Numbers	Matrix items for variants
Commerce Order	SalesOrder	Item Sublist (line items)	Entity field links to Customer
Order Line	Item Sublist Row	Inventory Detail (serial/lot)	Item field links to the Item record
Invoice	Invoice	Item Sublist, Apply Sublist	Created From links to SalesOrder
Payment	Customer Payment	Apply Sublist	Links to open Invoices

Custom Fields and Custom Records: Most NetSuite implementations include custom fields for business-specific data. Internal IDs for custom fields differ between sandbox and production environments. Externalize these mappings in configuration rather than hardcoding them.

Referential Integrity: NetSuite enforces referential integrity. You cannot create a salesOrder for a customer that does not exist. Plan sync order carefully: customers before orders, items before order lines, parent records before child records.

External IDs: NetSuite supports external IDs on most record types. Store source system identifiers as external IDs. This enables the upsert pattern and prevents duplicate records when the same source record syncs multiple times.

9. Real World Friction Points

The Sandbox Refresh Problem

Architecture Warning: Sandbox Refresh Breaks Integrations

When NetSuite refreshes a sandbox from production:

OAuth tokens are invalidated and require re-authentication
Integration records may be overwritten with production values
Internal IDs change if the sandbox has different test data
Custom field internal IDs may shift

Mitigation: Use external IDs exclusively instead of internal IDs. Store integration credentials in an external secrets manager, not in code. Build a sandbox reset runbook that re-authenticates, validates field mappings, and runs smoke tests before development resumes.

Search and Data Extraction Limits

Standard REST queries enforce a 1,000 row limit per request. Implement offset pagination for larger result sets.

Saved searches via SuiteQL are more efficient for bulk extraction, supporting up to 5,000 rows per page with proper pagination tokens.

For datasets exceeding 100K records, standard API pagination becomes inefficient. Consider scheduled MapReduce scripts that export data to SFTP, then pull from the export files. This approach handles millions of records without hitting API limits.

10. High Volume Performance Strategies

Beyond concurrency management, high-volume integrations require additional optimization strategies.

Batching: Instead of creating records one at a time, batch multiple records into a single API call where supported. The REST API supports creating multiple records in one request for certain record types. Batching reduces API call counts and significantly improves throughput.

Queue Systems: Implement a message queue between your source system and the NetSuite integration layer. Events enter the queue and are processed at controlled rates. This decouples event production from API consumption and provides natural backpressure when NetSuite is slow or rate-limited.

Retry with Exponential Backoff: Implement exponential backoff with jitter for transient errors. If a request fails with a 429 or 5xx error, wait progressively longer before retrying. Include random jitter to prevent thundering herd problems when multiple retry timers fire simultaneously.

Pro Tip: Governance Unit Optimization

RESTlets consume governance units per execution, not per record processed. A RESTlet that processes 100 records in one call uses fewer total units than 100 individual REST API calls. For high-volume write operations, consider a RESTlet that accepts batched payloads and processes them within a single execution context.

Saved Searches for Bulk Retrieval: When extracting data from NetSuite, saved searches are more efficient than individual record GETs. Create a saved search that returns all records modified since the last sync, selecting only the fields your integration needs. Execute via API and paginate through results.

11. Common Pitfalls

Hardcoding Internal IDs: Internal IDs differ between sandbox and production. Use external IDs or configuration files to map identifiers across environments.

Distributed Business Logic: When logic spreads across NetSuite scripts, middleware, and external code, no one owns the complete picture. A change in one place breaks another. Centralize business logic in one layer.

Ignoring Governance Limits: Development never stresses limits. Load test against realistic volumes before production deployment.

Insufficient Testing: Test validation errors, network failures, rate limit responses, partial batch successes, and concurrent requests. Production will encounter all of these.

Missing Error Recovery: Build automatic retry with exponential backoff. Build dead letter queues for records that fail repeatedly. Build tooling to review and reprocess failed records.

12. Alternatives to Building In-House

The Integration Multiplication Problem

NetSuite is rarely the only system requiring integration. Most B2B SaaS products eventually need multiple accounting systems: NetSuite for enterprise customers, QuickBooks for small businesses, Xero for international markets, and Sage for specific verticals. Each system has its own API, authentication mechanism, data model, and operational quirks. Building and maintaining separate integrations multiplies engineering investment.

Unified API Approach

Unified APIs provide a single integration surface connecting to multiple downstream systems. Instead of building separate NetSuite, QuickBooks, and Xero integrations, you build one integration to the unified API. The unified API handles mapping your canonical data model to each accounting system's format.

Platforms like Apideck offer pre-built connectors across accounting, CRM, HRIS, and other categories with standardized data models and authentication flows. This approach abstracts the complexity of maintaining individual API connections.

Advantages: faster time to value (days instead of months for new systems), reduced maintenance burden (provider handles API changes and version updates), consistent data models across all connected systems, shared authentication patterns, and engineering time focused on core product differentiation rather than integration plumbing.

When Each Approach Fits

Consider a unified API when your product needs to support multiple accounting or ERP systems to serve different customer segments, when you want to accelerate time-to-market for new integrations, when your engineering team lacks deep expertise in each target API, or when you want to reduce ongoing maintenance costs.

Build direct when you need extremely deep NetSuite functionality that unified APIs do not expose, when your integration requirements are highly specialized, or when you have an existing team with NetSuite expertise and available capacity.

The choice is ultimately an engineering resource allocation decision. Both approaches work. The right answer depends on your constraints, timeline, and long-term product strategy.

Accounting Integration

Kate Apideck — Tue, 28 Apr 2026 17:05:47 +0000

Your finance team didn't sign up to be data-entry clerks. Neither did your customers.

Yet every day, thousands of businesses manually export transactions from QuickBooks, copy invoice data from Xero, or reconcile payments between three different spreadsheets. It's slow, error-prone, and a waste of skilled people's time.

Accounting integrations fix this. They connect your software directly to your customers' general ledger, automatically syncing invoices, expenses, payments, and journal entries. No CSV exports. No copy-paste errors. No "we'll reconcile it at month-end."

This guide covers what accounting integrations actually do, the most common use cases, and how companies like Ramp, Airbase, and BILL have leveraged them to gain a competitive advantage.

The open accounting movement is driving demand for standardized data access across accounting platforms, making integration capabilities a competitive requirement for B2B SaaS products.

What Is an Accounting Integration?

An accounting integration is a connection between your application and an accounting platform like QuickBooks, Xero, NetSuite, or Sage Intacct. It allows data to flow between systems, either one-way or bidirectionally, without manual intervention.

A quick definition, if you're new to this: A general ledger (GL) is the master record of all financial transactions in a business. Every transaction gets tagged with a GL code, which is essentially a label that categorizes where the money went: "Travel," "Software Subscriptions," "Office Supplies," and so on. When we talk about syncing to the GL, we mean getting your data into that master record with the right labels attached.

At a practical level, accounting integrations mean:

Invoices created in your billing system appear automatically in your customer's accounting software
Expenses logged in your app push directly to the general ledger with the correct GL codes
Payments recorded in one system update the other in real time
Bank transactions reconcile automatically instead of requiring manual matching

The alternative is what most businesses still do: export a CSV, open Excel, clean the data, reformat it for the accounting system, import it, and hope nothing gets lost in translation. Multiply that by hundreds of transactions per month, and you've created busywork that produces no value.

Why Accounting Integrations Matter for Your Product

If you're building software that touches money (invoicing, expense management, payroll, procurement, lending, payments), your customers will eventually ask: "Does this connect to our accounting system?"

The answer determines whether you're a tool they'll actually adopt or one they'll abandon after the free trial.

The business case is straightforward:

Faster sales cycles. Enterprise buyers have procurement checklists. "Integrates with NetSuite" is often a required line item. Without it, you don't make the shortlist.
Lower churn. Customers who integrate your product into their financial workflows don't leave easily. The switching cost is too high when your app is integrated into their month-end close process.
Higher contract values. Integration features justify premium pricing. Ramp charges more for deeper ERP connections. So does BILL. Customers pay for the time savings.
Reduced support burden. Every "how do I export this to QuickBooks?" ticket is a symptom of a missing integration. Build it once, eliminate the ticket category.
Market expansion. Companies across specific regions, industries, and sizes use certain accounting tools. SMBs gravitate toward QuickBooks and Xero. Mid-market and enterprise prefer NetSuite, Sage Intacct, and Microsoft Dynamics. Offering integrations with the tools your target markets rely on opens doors that would otherwise stay closed.

Two Types of Accounting Integrations

Before diving into use cases, it's worth distinguishing between two categories:

Customer-Facing (Product) Integrations

These connect your product to your customers' accounting systems. They're what this guide focuses on—the integrations that become product features, drive sales conversations, and require supporting hundreds of different customer configurations.

The rest of this guide addresses customer-facing integrations, which present unique challenges around multi-tenancy, authorization, and scale.

Internal Integrations

These connect your company's own systems. For example:

CRM → Accounting: When an opportunity closes in Salesforce, automatically create the customer in NetSuite for invoicing
Accounting → BI: Sync financial data from Xero to Tableau for executive dashboards
Accounting → Slack: Alert the finance channel when invoices are overdue

These are typically built with iPaaS tools (Workato, Tray) or custom scripts. They're one-off connections serving your internal workflows.

6 Common Use Cases for Accounting Integrations

1. Expense Management → General Ledger Sync

The problem: Employees submit expenses. Finance approves them. Then someone manually enters each line item into QuickBooks with the correct GL code, department, and tax treatment.

The integration: Approved expenses push automatically to the accounting system. GL codes mapped by expense category. The finance team reviews exceptions, not every transaction.

Who does this well: Brex, Expend, ExpenseOnDemand, Ramp, and Airbase all sync expenses directly to QuickBooks, Xero, NetSuite, and Sage Intacct. For corporate card products, this is now table stakes. Invoice2go by BILL used Apideck's Unified API to speed up accounting integrations across multiple platforms, enabling support for major systems without custom builds. This helped them scale expense and reporting features quickly across over 220,000 customers worldwide.

Below is what the QuickBooks Online integration looks like on Ramp after you set it up.

2. Invoicing and Billing → Accounts Receivable

The problem: Your product generates invoices. Your customer's accounting team needs those invoices in their accounts receivable ledger. Right now, they're downloading PDFs and manually creating entries.

The integration: Invoices created in your system automatically appear in the customer's accounting platform. Payment status syncs back. When the invoice is paid, both systems reflect it without anyone having to touch a keyboard.

Who does this well: Stripe's invoicing connects to QuickBooks and Xero. Chargebee syncs subscription invoices to major accounting platforms. Any serious billing tool offers this now. For example, Roopairs used Apideck's Unified API to launch a QuickBooks Online integration quickly, saving roughly 40 developer hours and supporting 30 active customers from day one. The team is now planning expansions to Sage Intacct and NetSuite due to the speed and simplicity of the implementation.

Stripe QuickBooks Online integration guide

3. Procurement and AP Automation → Purchase Order Matching

The problem: A company issues a purchase order. Goods arrive. An invoice comes in. Someone has to manually match the PO, receipt, and invoice (the "three-way match") before approving payment.

The integration: Your procurement system shares PO data with the accounting platform. When invoices arrive, matching happens automatically. Exceptions flag for review; clean matches process straight through.

Who does this well: Coupa, SAP Ariba, and newer players like Zip connect procurement workflows directly to ERPs for automated matching and approval routing. For example, Derive used Apideck's Unified API to reduce development time by about 70 percent. They went from sign-up to a live Xero integration in just three weeks and later launched a Workday connection in under 90 days, which helped accelerate sales cycles and expand into enterprise markets more quickly.

Coupa Invoice Matching Explained

4. Revenue Recognition → Compliance with Accounting Standards

The problem: SaaS companies with usage-based pricing or multi-element contracts can't just recognize revenue when cash hits the bank. Accounting standards like ASC 606 require recognizing revenue over the service period. In plain English: you have to follow specific rules about when you're allowed to say you've "earned" money. Calculating this manually across thousands of subscriptions is an audit nightmare.

The integration: Your billing system sends contract and usage data to the accounting platform. Revenue schedules are generated automatically based on the rules. Auditors get clean documentation without your team building spreadsheets.

Who does this well: Stripe Revenue Recognition, Chargebee's RevRec module, and dedicated tools like Leapfin pull transaction data and push compliant journal entries to NetSuite or Sage Intacct.

Chargebee RevRec Features

5. Embedded Fintech → Real-Time Cash Flow Visibility

The problem: Lending platforms, cash flow tools, and financial dashboards need to see a business's real financial position. Bank feeds show cash movement, but not the full picture: receivables, payables, revenue trends, and outstanding invoices.

The integration: Pull chart of accounts, invoices, bills, and journal entries from the customer's accounting system. Display real-time financial health. Underwrite loans based on actual accounting data, not uploaded bank statements from three months ago.

Who does this well: Plaid handles banking data; accounting integrations from providers like Codat and Apideck fill in the rest. Lenders like Clearco and Pipe use accounting data to underwrite in hours instead of weeks.

For a technical deep-dive on this pattern, see Using Accounting APIs for Smart Lending Decisions.

Plaid API Docs

6. AI and Machine Learning → Financial Intelligence

The problem: You want to offer AI-powered features: budget predictions, anomaly detection, and cash flow forecasting, but your models need comprehensive financial data from each customer.

The integration: Pull balance sheets, income statements, transaction histories, and accounts receivable aging from customers' accounting systems. Feed this data to your ML models for personalized insights. As new transactions flow in, models update automatically.

Who does this well: Runway, Jirav, and Mosaic pull accounting data to power FP&A automation. Fintech platforms use it to build credit models that outperform traditional underwriting.

Runway Fintech Platform

How Companies Build Accounting Integrations

This is where product decisions become engineering reality. You have three paths:

Option 1: Build Direct Integrations

Connect to each accounting platform's API individually. QuickBooks Online has a REST API. Xero uses OAuth 2.0. NetSuite offers both SOAP and REST. Sage has several APIs, depending on which Sage product you're targeting.

Pros: Full control over the integration. Access to every feature the platform offers.

Cons: Each integration is a significant investment. Industry estimates indicate that a single integration requires 150+ engineering hours to build and 300+ hours annually to maintain, with total costs ranging from $10,000 to $50,000 per integration per year, including engineering time, customer success support, and ongoing maintenance. Supporting 10 accounting systems means multiplying that investment tenfold. Teams routinely estimate six weeks and ship in three months, as auth flows alone can derail timelines.

The maintenance reality: Accounting APIs change. QuickBooks pushes updates. Xero deprecates endpoints. NetSuite releases new versions. When a sync breaks on the first of the month (the worst possible timing for any finance team), someone on your team is firefighting instead of building features. Direct integrations require ongoing "on-call" capacity that most teams underestimate.

Option 2: Use a Unified API

A unified API provider normalizes multiple accounting platforms into a single integration. Think of it as a universal translator: your system speaks one language, and the provider handles the dialects of QuickBooks, Xero, NetSuite, and the rest.

You build once; they maintain the connections.

Pros: Launch in weeks instead of months. One data model to learn. One auth flow to implement. Coverage across platforms without multiplying your engineering investment. Unified API approaches typically deliver 3-5x faster implementation with significantly lower total cost of ownership over multi-year periods.

Cons: You're dependent on the provider's coverage depth and data model. Some edge cases or advanced features may still require direct API work for specific platforms.

Providers in this space: Apideck, Merge, Codat, Railz, and Rutter all offer unified accounting APIs with varying coverage, pricing models, and approaches to data normalization. For a detailed comparison, see Top Merge API Alternatives for SaaS Teams in 2025.

Not sure whether to build or buy? Read Build vs Buy Accounting Integrations.

Option 3: Hybrid Approach

Use a unified API for 80% of your coverage (common platforms and standard use cases), then build direct integrations for strategic accounts that require deep customization. This typically means NetSuite or SAP for enterprise deals that require custom fields, advanced workflows, or specific ERP modules.

How to Prioritize Which Integrations to Build

As you can't build everything at once. Use this framework to prioritize and insert the Accounting integrations that are relevant:

Criteria	Weight	QuickBooks	NetSuite	Xero	Sage Intacct
% of pipeline requesting	25%	?	?	?	?
Expected close rate lift	20%	?	?	?	?
Retention impact	20%	?	?	?	?
New market access	15%	?	?	?	?
Engineering effort	10%	?	?	?	?
Maintenance burden	10%	?	?	?	?
Weighted Score	100%	?	?	?	?

Integration Prioritization Scorecard

How to use it:

Survey your sales team: which integrations come up most in deals?
Analyze lost deals: how many cited missing integrations?
Segment by customer size: SMB skews QuickBooks/Xero, enterprise skews NetSuite/Sage
Score each integration, calculate weighted totals, and stack-rank

This prevents the common mistake of building integrations based on engineering interest rather than business impact.

Common Pitfalls: What Goes Wrong with Accounting Integrations

Most integration guides tell you what to build. Few tell you what breaks. Here are the failure modes that create support tickets, churn, and 2 AM pages:

1. Auth Token Expiry and Refresh Failures

OAuth tokens expire. Refresh tokens have their own lifespans. QuickBooks tokens last 100 days; if a customer doesn't use the integration for three months, it silently breaks. Your sync stops, but no one notices until month-end close—when the finance team is already stressed.

The fix: Proactive token health monitoring. Alert customers before re-authentication is needed, not after data stops flowing.

2. Schema Drift and API Changes

Accounting platforms don't freeze their APIs. QuickBooks pushed breaking changes to their invoice endpoints in 2023. Xero periodically deprecates fields. NetSuite's SuiteTalk versions introduce incompatibilities.

The fix: Version your integrations. Monitor API changelogs. Build regression tests that catch schema changes before customers do.

3. Rate Limit Hell

QuickBooks allows 500 requests per minute. Sounds generous until you're syncing 10,000 invoices for a new customer. Hit the limit, and your sync backs up. Customers see stale data. Support tickets pile up.

The fix: Implement exponential backoff. Queue and batch requests. Design for burst limits from day one, not after you hit them in production.

4. Multi-Entity and Multi-Currency Complications

Enterprise customers don't have one QuickBooks company. They often manage twelve subsidiaries across three currencies. Your integration works perfectly for single-entity SMBs, then breaks spectacularly when an enterprise customer connects their consolidated NetSuite instance.

The fix: Design for multi-entity from the start. Ask during onboarding: "How many entities will you connect?" If the answer is more than one, adjust your data model accordingly.

5. GL Code Mapping Mismatches

Your expense categories don't match your customer's chart of accounts. "Travel" in your system needs to map to "6200 - Employee Travel & Entertainment" in theirs. Get it wrong, and transactions land in the wrong accounts or fail to sync entirely.

The fix: Build a mapping interface. Let customers configure how your categories translate to their GL codes. Don't assume your defaults work for everyone.

6. Partnership Agreement Delays

Many enterprise accounting vendors (especially Sage, Xero, Intuit, and SAP) require formal partnership agreements before you can access sandbox environments or API documentation. These agreements can take months, sometimes over a year, and cost tens of thousands annually.

The fix: Start partnership applications early, before you need the integration. If the timeline is critical, consider unified API providers who already have these partnerships in place.

What to Look for in an Accounting Integration Solution

Whether you're evaluating unified API providers or scoping direct builds, here's what actually matters:

Platform coverage. Does it support the accounting systems your customers use? QuickBooks and Xero dominate SMB. NetSuite, Sage Intacct, and Microsoft Dynamics serve the mid-market and enterprise. Know your customer base before choosing. Need a full breakdown? See Top 15 Accounting APIs to Integrate with in 2025.
Data model depth. Can you access invoices, payments, journal entries, tracking categories, tax rates, and custom fields? Or just the basics? Shallow integrations create support tickets later.
Write access. Reading data is the easy part. Pushing invoices, expenses, or journal entries back to the accounting system is harder but more valuable. Confirm bidirectional sync works if you need it.
Auth experience. Your customers connect to your accounting system via an OAuth flow. If that flow is clunky, confusing, or breaks frequently, your support team will hear about it.
Webhooks and real-time sync. Polling for changes is slow and burns API quota. Webhooks let you react to new invoices or payments the moment they happen.
Security and compliance. You're touching general ledger data. Customers will ask about SOC 2 compliance, data encryption, and where their credentials are stored. Have answers ready, or choose a provider who does.
Integration observability. When syncs fail, can you see why? Look for logging, error categorization, and alerting that help your support team diagnose issues without escalating to engineering.

The Bottom Line

Accounting integrations aren't optional anymore. If your product touches financial data, your customers expect it to connect to their accounting system.

You can spend engineering years building and maintaining direct connections. Or you can use a unified API to launch in weeks and expand coverage as you grow.

The days of "export to CSV" are ending. Give customers the integration, or watch them find a product that does.

Frequently Asked Questions

How long does an accounting integration take to build in-house?

It depends on the platform and your requirements. Simple read-only integrations might take 4-6 weeks. Bidirectional sync with error handling, rate limiting, and multi-entity support typically takes 3-6 months. If the vendor requires a partnership agreement (NetSuite, SAP), add 3-12 months for paperwork alone.

How much do accounting integrations cost?

Direct builds run $10,000-$50,000 per integration annually when you factor in engineering time, maintenance, and support. Unified API providers typically charge $500-$2,000/month for access to dozens of integrations. The break-even point is usually 2-3 integrations.

What are the most popular accounting systems to integrate with?

Varies by segment:

SMB: QuickBooks Online, Xero, FreshBooks, Wave
Mid-market: Sage Intacct, NetSuite, Microsoft Dynamics 365 Business Central
Enterprise: NetSuite, SAP, Oracle, Microsoft Dynamics 365 Finance

What data typically gets synced?

Common objects include: invoices, bills, payments, journal entries, chart of accounts, customers/vendors, tax rates, tracking categories, purchase orders, and bank transactions. Advanced use cases add balance sheets, income statements, and aged receivables/payables.

Can I start with one integration and add more later?

Yes, but plan your data model carefully. If you build for QuickBooks first with a QuickBooks-specific schema, adding Xero later means refactoring. Starting with a normalized data model (or using a unified API) avoids this trap.

Go Deeper: Related Guides

Building your first integration?

Evaluating build vs. buy?

Designing for scale and reliability?

Understanding the Sage ecosystem?

Specific use cases?

Ready to add accounting integrations to your product? Explore Apideck's Unified Accounting API: one integration, 35+ accounting platforms, live in days.