Most accounting integrations are built for a single company with a single set of books. You read invoices, write journal entries, sync payments. The chart of accounts has a few dozen line items. Everything maps cleanly to one general ledger.

Then your customer has two subsidiaries. Or five. Or forty, spread across three currencies and two continents. Suddenly you're dealing with subsidiary hierarchies, intercompany eliminations, and consolidation logic that varies by platform. The GL integration you built for a single-entity QuickBooks user doesn't translate to a NetSuite OneWorld customer running twelve legal entities.

This is the part of accounting software integration that most teams underestimate. And it's the part that matters most for the customers with real money on the line.

How multi-entity accounting changes the general ledger

A multi-entity setup means a business operates multiple legal entities that each maintain their own financial records but ultimately roll up into a consolidated view. These entities might be subsidiaries in different countries, regional branches, or distinct business divisions. Each entity has its own general ledger. Each general ledger is organized around a chart of accounts. In simple setups, all entities share the same chart of accounts. In more complex ones, entities have their own accounts tailored to local tax or regulatory requirements, with a mapping layer that connects them for consolidation.

The general ledger is the backbone. Every transaction in an accounting system, whether it originates from AP, AR, or any other module, ultimately generates journal entries with offsetting debits and credits in the GL. Approve a vendor bill and the system records an expense and a liability. Process the payment and it reduces both the liability and cash. In a well-integrated ERP, none of this requires manual posting.

Multi-entity complicates things in ways that compound quickly.

The most obvious challenge is intercompany transactions. When subsidiary A sells goods to subsidiary B, both entities record the transaction in their own books. But from a consolidated perspective, that revenue and cost need to be eliminated so the group financials reflect only external activity. If subsidiary A lent $500,000 to subsidiary B, the receivable on one side and the payable on the other need to cancel out during consolidation. Miss these eliminations and you inflate your consolidated numbers.

Currency translation adds another layer. A subsidiary operating in EUR while the parent reports in USD needs its financials translated at appropriate exchange rates: current rates for monetary items, average rates for income statement items, historical rates for equity. Unrealized gains and losses from open foreign-currency positions need revaluation journal entries at each reporting period.

Then there's dimensional reporting. Beyond the basic account structure, enterprises need to slice financial data by department, location, project, or other custom segments. Each accounting platform handles these "tracking categories" differently, and the way they interact with entity structures varies considerably.

Finance teams at multi-entity companies spend an average of six days per month manually consolidating financial data across entities, according to SoftLedger. NetSuite OneWorld carries a $10,000 to $30,000 annual premium over standard NetSuite specifically because multi-subsidiary management is that complex.

How NetSuite, QuickBooks, Xero, and Sage Intacct model entities

This is where it gets painful for anyone building integrations.

NetSuite OneWorld treats each legal entity as a subsidiary record in a hierarchical tree. All subsidiaries can share a chart of accounts (with optional country-specific accounts), and the system supports up to 250 subsidiaries per account. Intercompany journal entries are a distinct transaction type. NetSuite automatically generates elimination entries during the period close process through its Automated Intercompany Management feature, posting them to dedicated "elimination subsidiaries" that exist solely for consolidation. Advanced Intercompany Journal Entries allow debits and credits across multiple subsidiaries in a single balanced entry.

QuickBooks, by contrast, was built for single-entity accounting. Multi-entity businesses running QuickBooks typically operate separate company files for each entity. There's no native subsidiary hierarchy, no built-in intercompany elimination, no consolidated reporting. A biotech firm called Aviva Biology found that QuickBooks couldn't meet its multi-subsidiary needs after an acquisition, and switched to NetSuite OneWorld to consolidate finances across entities. This is a common migration pattern.

Xero supports multiple organizations under a single user login, but each organization is an isolated instance with its own chart of accounts and data. Consolidation happens outside the system, either through reporting tools like Fathom or through manual spreadsheet work.

Sage Intacct takes a dimensional approach. Rather than rigid subsidiary hierarchies, it uses entities as one of several dimensions (alongside departments and locations) that can be applied to transactions and used for reporting. It supports multiple books per entity for parallel reporting under different accounting standards.

The structural differences run deep. NetSuite has a dedicated subsidiary object type with a parent-child hierarchy. QuickBooks has no entity concept at all in its API. Xero and Sage Intacct each take their own approach: Xero with isolated organizations, Sage with entities as a reporting dimension. These are not cosmetic differences in naming. They represent different data models with different assumptions about how financial information is organized.

How multi-entity affects accounting API integrations

When you're building a product that needs to read from or write to your customers' general ledgers, multi-entity support changes the integration surface area dramatically.

Consider journal entries. In a single-entity QuickBooks integration, you POST a journal entry with line items that include account references and amounts. The QuickBooks API call looks something like this:

POST /v3/company/{realmId}/journalentry

{
  "Line": [
    {
      "Amount": 1000.00,
      "DetailType": "JournalEntryLineDetail",
      "JournalEntryLineDetail": {
        "PostingType": "Debit",
        "AccountRef": { "value": "36", "name": "Checking" }
      }
    },
    {
      "Amount": 1000.00,
      "DetailType": "JournalEntryLineDetail",
      "JournalEntryLineDetail": {
        "PostingType": "Credit",
        "AccountRef": { "value": "96", "name": "Consulting Revenue" }
      }
    }
  ]
}

Straightforward. One company, one set of accounts, one journal entry.

In NetSuite OneWorld, that same journal entry needs to be scoped to a specific subsidiary. If it's an intercompany transaction, you need to use the Advanced Intercompany Journal Entry, specifying both the originating subsidiary and the receiving subsidiary. The payload gets more complex:

// Simplified for illustration
POST /services/rest/record/v1/advInterCompanyJournalEntry

{
  "subsidiary": { "id": "2" },
  "toSubsidiary": { "id": "5" },
  "line": {
    "items": [
      {
        "account": { "id": "210" },
        "debit": 50000.00,
        "subsidiary": { "id": "2" },
        "eliminate": true
      },
      {
        "account": { "id": "315" },
        "credit": 50000.00,
        "subsidiary": { "id": "5" },
        "eliminate": true
      }
    ]
  }
}

Notice the differences: subsidiary scoping on the transaction and on each line item, a toSubsidiary field, and an eliminate flag that tells NetSuite to reverse these entries during consolidation. Your integration code needs to know whether the customer is on standard NetSuite or OneWorld, whether the journal crosses entity boundaries, and which clearing accounts the system expects.

Consider the chart of accounts. In QuickBooks, you call the Account endpoint and get a flat list. In NetSuite, accounts exist in a hierarchy and may be shared across subsidiaries or scoped to specific ones. Sage Intacct combines accounts with dimensional attributes like department and location that determine how transactions are categorized for reporting. Each platform's version of what Xero calls "tracking categories" has a different name and a different data shape, and your integration has to normalize these into a consistent structure or handle each one separately. (For a deeper look at how tracking dimensions vary across platforms, see our guide to tracking dimensions in accounting integrations.)

Consider reporting. A trial balance in a single-entity system is one set of account balances. In a multi-entity system, you need trial balances per entity, a consolidated trial balance with intercompany eliminations applied, and potentially a currency-translated view. The API surface for these reports differs across every platform.

Each integration ends up being its own project. QuickBooks is one data model. Xero is another. NetSuite is a third, substantially more complex model with subsidiary scoping on nearly every API call. Building and maintaining these individually means engineering teams spend a disproportionate amount of time on connector logic rather than core product work. Individual accounting integrations typically cost $3,000 to $15,000 each when you factor in engineering time, infrastructure, and the normalization work required to make financial data consistent across sources.

Using a unified accounting API for multi-entity integrations

Unified accounting APIs attempt to solve this by providing a single normalized interface across multiple platforms. You make one API call for journal entries, one for chart of accounts, one for invoices, and the unified layer translates your request into the native format of whatever platform your customer uses.

This works well for the common case. Standard transactional objects like invoices and payments follow broadly similar patterns across platforms (though the field names and nesting structures differ). A unified API normalizes these into a consistent schema and manages the ongoing maintenance when providers ship breaking changes. It also handles authentication, which varies widely: QuickBooks uses OAuth 2.0 with strict refresh token rotation. NetSuite requires token-based authentication with HMAC-SHA256 signature generation on every request.

Here's what the same journal entry looks like through the Apideck Accounting API:

import { Apideck } from '@apideck/node'

const apideck = new Apideck({
  apiKey: process.env.APIDECK_API_KEY,
  appId: process.env.APIDECK_APP_ID,
  consumerId: 'user-123'
})

const { data } = await apideck.accounting.journalEntriesAdd({
  journalEntry: {
    title: 'Intercompany transfer',
    line_items: [
      {
        type: 'debit',
        ledger_account: { id: '210' },
        total_amount: 50000.00,
        tracking_categories: [{ id: 'subsidiary-2' }]
      },
      {
        type: 'credit',
        ledger_account: { id: '315' },
        total_amount: 50000.00,
        tracking_categories: [{ id: 'subsidiary-5' }]
      }
    ]
  }
})

One call, one data model. The unified layer resolves which downstream platform the customer uses and translates the request into the native format, whether that's QuickBooks, NetSuite, Xero, or any of the 30+ supported connectors.

For multi-entity scenarios, the unified layer needs to do more. It needs to surface entity and subsidiary context on relevant endpoints. It needs to handle tracking categories and dimensional reporting consistently, even when each platform implements them differently. It needs to support journal entries that span entities where the underlying platform allows it, and degrade gracefully where it doesn't.

The Apideck Accounting API handles this through a unified tracking categories endpoint that abstracts the differences between each platform's implementation into a single interface. Rather than learning four different tracking systems with four different names and four different data shapes, developers use one API that works identically across all supported platforms. For subsidiary and entity context, the unified model includes company and organization-level scoping that maps to the native entity model of each downstream provider.

This doesn't eliminate all complexity. A deep NetSuite OneWorld integration with custom intercompany allocation schedules will always require some platform-specific configuration. But for the 80% of use cases where you need to move GL data and transactional records across multiple entities and multiple platforms, the unified approach compresses months of integration work into weeks.

What's next for multi-entity accounting APIs

The multi-entity problem is growing, not shrinking. Cross-border commerce is expanding. Vertical SaaS platforms serving franchise operators and multi-location businesses need to connect with the accounting systems of customers who may operate dozens of entities. Fintech products offering embedded lending or working capital need reliable consolidated financial data to underwrite risk accurately.

At the same time, accounting platforms are investing heavily in their multi-entity capabilities. Intuit launched its Enterprise Suite with multi-entity features aimed at mid-market companies. New entrants like Campfire are building AI-native ERPs with multi-entity consolidation as a first-class feature. NetSuite continues expanding OneWorld's automated intercompany management capabilities.

For integration builders, this means the bar keeps rising. It's no longer sufficient to connect to a single QuickBooks company and call it done. Customers expect their software to understand that they run multiple entities, that those entities have relationships with each other, and that the financial data flowing through the integration reflects the consolidated reality of their business. The GL is not just a list of accounts. It's a hierarchical, multi-dimensional, entity-scoped structure that changes shape depending on which accounting platform you're looking at. Building integrations that handle this well is hard. Using a unified API that has already mapped these differences is the faster path to getting it right.

FAQ

What is multi-entity accounting?

Multi-entity accounting is the practice of maintaining separate financial records for multiple legal entities (subsidiaries, branches, or divisions) within a single organization, while consolidating them into unified financial statements. Each entity has its own general ledger and chart of accounts, and the consolidation process requires eliminating intercompany transactions and translating foreign currencies.

How do accounting APIs handle subsidiaries?

Each accounting platform handles subsidiaries differently at the API level. NetSuite OneWorld requires subsidiary scoping on most API calls and has dedicated intercompany journal entry endpoints. QuickBooks has no subsidiary concept in its API, so multi-entity businesses use separate company files. Xero treats each entity as an isolated organization. A unified accounting API normalizes these differences into a single data model.

What are intercompany eliminations?

Intercompany eliminations are accounting adjustments that remove the effect of transactions between entities within the same corporate group during financial consolidation. If subsidiary A sold $100,000 of services to subsidiary B, that revenue and expense need to be eliminated so consolidated financials only reflect transactions with external parties.

What is a unified accounting API?

A unified accounting API provides a single, normalized interface for integrating with multiple accounting platforms. Instead of building separate connectors for QuickBooks, Xero, NetSuite, and Sage Intacct, developers build once against the unified API, which translates requests into each platform's native format and handles authentication, pagination, and data normalization.