How does each ledger model an account? The one object all three broadly agree on, and still the one that most often breaks the profit and loss. They differ on hierarchy, on whether the account number exists at all, and on how finely the type is stated.
Xero
GET /Accounts
Full records, no paging on this endpoint
QBO
SELECT * FROM Account
Query endpoint, 1,000 rows per page
NetSuite
SuiteQL: FROM account
REST /record/v1/account returns ids only
Read across a row. Where a cell is absent, the concept has nowhere to live in that system — which is a design constraint, not a gap to paper over.
A difference stated without a response is trivia. Each of these carries the handling.
Xero's chart is a flat list: no parent field, no grouping object. The grouping in Xero's own reports comes from account type. QBO nests five levels deep in FullyQualifiedName; NetSuite nests arbitrarily.
Do — Render a flat list gracefully, with type as the only grouping. No chart-of-accounts view may assume parents exist.
They are editable in all three, optional on Xero bank accounts (Xero enforces Code as unique and requires it elsewhere), and in QBO absent entirely unless the company turned account numbers on. Unique is not the same as stable. A mapping table keyed on account code will silently break when a bookkeeper renumbers the chart.
Do — Key every mapping on the source id. Display the number, sort by it, let users search it — but never join on it.
All three separate receivables from other current assets at the type level — QBO AccountType 'Accounts Receivable' vs 'Other Current Asset', NetSuite AcctRec vs OthCurrAsset. QBO's AccountSubType (~80 values) gives the finest granularity of the three, below that. Xero's Type is coarser but carries SystemAccount, which QBO lacks. Collapsing all three onto one enum loses different information in each direction.
Do — Map to the coarsest common type for statement grouping, and keep the source type verbatim in a second field for tooltips, mapping UIs and support questions.
None of the three tells you whether an account is debit-normal. All three expect you to derive it from the class — asset and expense are debit-normal; liability, equity and revenue are credit-normal — and then invert it for contra accounts: accumulated depreciation, allowance for doubtful accounts, treasury stock, sales returns and discounts. Class alone gets every one of those wrong.
Do — Derive once, at normalisation, from class plus a contra flag taken from the source subtype (QBO AccumulatedDepreciation, DiscountsRefundsGiven…) or your own mapping — never class alone — and store it. Deriving it at render time in a component is how a revenue figure ends up with the wrong sign.
type Account = {
id: string;
number?: string; // display only — never a join key
name: string;
path?: string[]; // ["Operating expenses", "Travel"]; single element when flat
parentId?: string; // undefined on Xero, always
type: AccountType; // our taxonomy, coarsest common
sourceType: string; // theirs, verbatim: "DIRECTCOSTS" | "OtherCurrentAsset" | "COGS"
class: "asset" | "liability" | "equity" | "revenue" | "expense";
normalBalance: "debit" | "credit"; // class, inverted when isContra — at normalisation
isContra: boolean; // from source subtype or own mapping: accum. depreciation, allowance…
isSystem: boolean; // never offer as a posting target
currency?: string;
active: boolean;
entityIds: string[]; // NetSuite subsidiary scoping; [tenant] elsewhere
source: SourceRef;
};The payoff. Every difference above that reaches the surface, and what the component does about it.
The normalised object above is what the components read. These are the surfaces it feeds, the words for the concepts in it, and the document that explains the accounting.
Compared acrossXero docsQuickBooks Online docsNetSuite docs