Every NetSuite instance is different. That is the first thing any integration team learns, usually the hard way. But the single biggest source of variation across NetSuite accounts has nothing to do with custom fields or SuiteScript extensions. It comes down to one question: is the account running OneWorld or not?

The answer changes the database schema your integration queries and the currency logic it has to handle. If you build a NetSuite connector that only works against Standard accounts, it will break the moment a OneWorld customer connects. If you only test against OneWorld, you will throw fatal errors on Standard instances that lack subsidiary tables entirely.

This post covers what actually differs between the two editions, where the API diverges, and what it means if you are building or buying a NetSuite integration.

How OneWorld and Standard editions differ at the schema level

NetSuite Standard runs a single legal entity. One set of books, one base currency. The subsidiary record does not exist. There is no subsidiary table to query, no subsidiary field on transactions, and no intercompany elimination logic.

NetSuite OneWorld adds multi-subsidiary support. Each subsidiary is a separate legal entity with its own base currency and tax schedules. The chart of accounts can be shared with the parent or customized per subsidiary. Subsidiaries are arranged in a parent-child hierarchy, and financial data rolls up through that hierarchy into consolidated reports.

Oracle prices OneWorld as a licensing upgrade on top of Standard, typically adding $10,000 to $30,000 per year depending on subsidiary count. Once enabled, the upgrade is permanent and cannot be reversed. Every edition of NetSuite (Light, Mid-Market, Enterprise) can be upgraded to OneWorld.

The practical difference for integration teams: OneWorld accounts have tables and fields that Standard accounts do not. And querying those missing tables on a Standard account does not return empty results. It throws a fatal error.

How the NetSuite OneWorld subsidiary field affects API queries

On a OneWorld account, nearly every transactional and master data record gains a subsidiary field. Invoices, bills, journal entries, customers, vendors, items, and GL accounts all carry subsidiary references. Some records, like customerSubsidiaryRelationship and vendorSubsidiaryRelationship, only exist on OneWorld accounts. Oracle's own REST API documentation states: "You must either use NetSuite OneWorld or have the Subsidiaries hidden feature enabled before you can use this record through REST web services."

On a Standard account, none of these fields or records exist. A SuiteQL query that JOINs the subsidiary table will fail with a "Record not found" error. A REST API call to the subsidiary endpoint returns nothing useful.

This creates a branching problem. For every resource you want to read from NetSuite (accounts, contacts, transactions, invoices, journal entries), you need at least two query variants: one that includes subsidiary JOINs and filters, and one that does not. Add multi-currency into the mix (which is a separate feature that may or may not be enabled, even on OneWorld accounts), and you need to JOIN the currency table conditionally too. For an accounting integration covering 15 or more resources, the Truto engineering team calculated this produces 60+ query variants that need to be managed at runtime.

Runtime feature detection for NetSuite OneWorld vs Standard

You cannot ask a NetSuite customer "are you on OneWorld?" and hard-code the answer. Accounts get upgraded. Modules get enabled. The only reliable approach is to probe the account programmatically at connection time.

The detection pattern is straightforward in concept: attempt to query the subsidiary table, and if the query fails, the account is not running OneWorld. Then cache that result and use it to select the right query templates for every subsequent API call.

In practice this means your integration layer needs a query routing engine. Every SuiteQL query template exists in at least two forms (with and without subsidiary JOINs), and the correct form gets selected based on the feature flags detected during the initial connection probe. This is architectural work that has to happen before you write a single line of business logic. For a deeper look at the full scope of NetSuite integration complexity, including governance limits and concurrency constraints, see our separate guide.

The same pattern applies to multi-currency. If the account uses multiple currencies, the currency table is available and transactions carry currency fields with exchange rate data. If not, querying that table fails. You need to detect and branch for this independently of the OneWorld check, because Standard accounts can enable multi-currency without upgrading to OneWorld.

Multi-currency handling across NetSuite editions

Standard NetSuite with multi-currency enabled supports transactions in foreign currencies against a single base currency. The system converts and posts to the GL in the base currency using the exchange rate at the transaction date.

OneWorld takes this further. Each subsidiary has its own base currency. A US subsidiary posts in USD, a UK subsidiary in GBP, a Japanese subsidiary in JPY. Transactions record in their original currency and convert to the subsidiary's base currency for GL posting. Consolidated reporting then translates subsidiary financials into the parent's reporting currency using separate consolidated exchange rate tables.

For API consumers, this means the same invoice can have three currency amounts that matter: the transaction currency (what the customer was billed in), the subsidiary base currency (what hits the local GL), and the consolidated currency (what appears on the parent's P&L). Your integration needs to know which one it is reading and which one it needs. The transactionLine records in SuiteQL carry fields like fxamount (foreign currency amount) and amount (base currency amount), and which "base" that refers to depends on the subsidiary context of the transaction.

If you are pulling a trial balance or balance sheet through the API, OneWorld accounts require you to specify a subsidiary context for the report. A consolidated trial balance rolls up child subsidiary data through the hierarchy with currency translation at each level. Getting this wrong does not produce an error. It produces wrong numbers, which is worse.

NetSuite also handles tracking dimensions (departments, locations, classes) differently across editions. On OneWorld accounts, departments and locations are scoped to specific subsidiaries, which means your integration needs to validate that a given dimension ID is valid for the subsidiary context of the transaction you are creating.

NetSuite SOAP deprecation and the REST API migration timeline

NetSuite does not have one API. It has at least three: SuiteTalk SOAP (being deprecated), SuiteTalk REST, and SuiteQL (accessed through the REST query endpoint). Each has different strengths and gaps.

SuiteQL is the most capable for read-heavy workloads. It supports JOINs, aggregations, and server-side filtering through SQL-like syntax. The REST Record API is better for individual CRUD operations. And for some operations (generating transaction PDFs, accessing dynamic form metadata), you still need custom SuiteScript RESTlets deployed into the customer's account.

Oracle is actively winding down SOAP. The 2025.2 release is the last planned SOAP endpoint. Starting with 2026.1, no new SOAP endpoints ship by default. By 2028.2, SOAP will be fully removed. Any integration still running on SOAP at that point will stop working. If you have not started your migration, our NetSuite API key guide covers the authentication setup for both REST and OAuth 2.0.

The SOAP deprecation interacts with the OneWorld complexity in a specific way: many older integrations handled subsidiary context through SOAP's search and record operations, where the subsidiary field was just another XML element to include or exclude. Migrating those integrations to REST and SuiteQL means rebuilding the query logic from scratch, and the OneWorld branching has to be redesigned at the same time. You cannot simply swap XML payloads for JSON payloads and call it done.

REST also has known gaps. The subsidiary record itself is read-only through REST (GET only, no POST/PATCH/DELETE). Legacy tax engine features are not exposed through REST at all, which matters because each OneWorld subsidiary can have different tax configurations. SuiteTax is the path forward, but not every NetSuite customer has migrated to it.

What this means for unified API platforms and ERP integrations

If you are a SaaS company building a NetSuite integration in-house, you need to handle all of this yourself. That means runtime feature detection and conditional query routing, plus currency normalization and subsidiary-aware data scoping on top. Add ongoing maintenance as Oracle evolves the API surface, and the effort compounds quickly. This is one of the reasons ERP API integration is consistently cited as the most engineering-intensive category of SaaS connectivity.

If you are using a unified API platform like Apideck, the platform should be handling these differences for you. The value proposition is that you call a single GET /accounting/invoices endpoint and get a normalized response regardless of whether the underlying NetSuite account is Standard or OneWorld, single-currency or multi-currency, using SuiteTax or the legacy tax engine.

The quality of a unified API's NetSuite connector comes down to how well it handles this matrix. A connector that only works against Standard accounts, or only against OneWorld accounts, is not production-ready. The feature detection, query branching, and currency normalization have to work across the full range of NetSuite configurations that exist in the wild.

For Apideck specifically, our NetSuite Accounting API connector handles OneWorld and Standard accounts through automated feature detection at connection time. The SuiteQL queries adapt based on the detected configuration, and the response schema stays consistent regardless of the underlying edition. Subsidiary data surfaces as a standard field when present and is omitted cleanly when it is not.

Practical checklist for NetSuite API integration teams

If you are building or maintaining a NetSuite integration, here is what the OneWorld vs Standard split requires:

Detect OneWorld and multi-currency status at connection time by probing for table availability. Cache those flags and use them for query routing throughout the integration lifecycle.

Maintain parallel SuiteQL query templates for every resource: one with subsidiary JOINs and one without. Do the same for currency JOINs where relevant.

Scope data reads by subsidiary when working with OneWorld accounts. Pulling all data across all subsidiaries without filtering will return a superset that may not match what the customer expects for a given legal entity.

Handle currency fields explicitly. Know the difference between transaction currency, subsidiary base currency, and consolidated reporting currency. Map each to the correct field in your normalized schema.

Test against both editions. If your test environment only has OneWorld enabled, you are missing half the failure modes. Spin up a Standard test account and run your full test suite against it.

Plan for the SOAP sunset. If any part of your NetSuite integration still uses SOAP, the 2028.2 removal deadline is fixed. Build new integrations on REST and SuiteQL with OAuth 2.0 authentication.

Track REST API gaps. Some OneWorld-specific features (subsidiary record writes, legacy tax fields) are not available through REST. Know where you need SuiteScript RESTlets to fill the gaps, and plan for Oracle to close those gaps over time as REST reaches parity.

NetSuite is one of the most widely deployed ERPs in the world, and the OneWorld vs Standard split is one of its most consequential integration variables. Getting this right is the difference between an integration that works for your first three customers and one that works for your next three hundred.

Frequently asked questions

How do I detect whether a NetSuite account is running OneWorld or Standard via the API?

Probe the subsidiary table at connection time using a SuiteQL query like SELECT id FROM subsidiary LIMIT 1. If the query returns results, the account is running OneWorld. If it throws a "Record not found" error, the account is Standard. Cache this result and use it to select the correct query templates for all subsequent API calls.

Does the NetSuite REST API behave differently on OneWorld vs Standard accounts?

Yes. On OneWorld accounts, records like invoices, customers, and vendors carry a subsidiary field, and records like customerSubsidiaryRelationship become available. On Standard accounts, these fields and records do not exist. The subsidiary REST record itself is read-only (GET only). Your integration needs conditional logic to include or exclude subsidiary-related fields depending on the edition.

Can a Standard NetSuite account use multi-currency without upgrading to OneWorld?

Yes. Multi-currency is a separate feature that can be enabled on Standard accounts. When enabled, transactions can be created in foreign currencies and converted to the single base currency at the exchange rate on the transaction date. OneWorld adds the ability for each subsidiary to have its own base currency, which introduces additional currency translation layers for consolidated reporting.

What happens to my NetSuite SOAP integration when Oracle removes SOAP in 2028?

The 2025.2 SOAP endpoint is the last planned release. Starting with 2026.1, no new SOAP endpoints ship. By 2028.2, all SOAP endpoints will be removed and existing SOAP integrations will stop working. Oracle recommends migrating to REST web services with OAuth 2.0 authentication. For OneWorld accounts, this migration also requires rebuilding subsidiary-aware query logic in SuiteQL.