Reports

Should you build statements on the reports endpoints? No — build them on ledger data, then use the reports endpoints to prove you got the same answer. Report output is presentation, with no stable row identity to drill from.

Concepts: 7
Divergences: 2
Structural: 1

Endpoints

Xero

GET /Reports/{ProfitAndLoss,BalanceSheet,TrialBalance,AgedReceivablesByContact,…}

Row-typed output

QBO

GET /reports/{ProfitAndLoss,BalanceSheet,GeneralLedger,TrialBalance,…}

Nested Rows and Columns

NetSuite

Saved searches, SuiteQL, SuiteAnalytics

You define the query

The same concept in three vocabularies

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.

Native: — A field or object exists for it
Partial: — Exists with a caveat that changes what you can build
Derived: — Not stored — you compute it
Absent: — Nothing in the API

Reports fields compared across Xero, QuickBooks Online and NetSuite
Concept	Xero	QBO	NetSuite
Output shape	Rows[] with RowType Header, Section, Row, SummaryRow	Nested Rows / Columns with ColData[]	Whatever your query returns
Stable row identityWhether a report row can be drilled into.	Some cells carry AccountID	ColData.id, sometimes	You control it
Comparative periods	periods, timeframe parameters	date_macro, summarize_column_by	Query it
Cash vs accrual basis	paymentsOnly parameter on some reports	accounting_method parameter	Report or query setting
Dimensional breakdown	trackingCategoryID parameters Two at most	Class and Department columns	Any segment
Aging	AgedReceivablesByContact / AgedPayablesByContact One contact at a time	AgedReceivables, AgedPayables	Saved search or SuiteQL
Drill-down to transactions	—	—	Native

What actually differs, and what you do about it

A difference stated without a response is trivia. Each of these carries the handling.

Structural

Report rows are presentation, not data

Xero · QBO · NetSuite

Header, section and summary rows are interleaved with data rows, nesting depth carries meaning, and identity is inconsistent. Parsing is possible; drilling from a parsed row back to the transactions behind it generally is not.

Do — Build interactive statements from ledger data. Use the report endpoint on a schedule, assert equality, and surface a variance when it appears.

Sharp edge

Xero's aged reports are per contact

Xero

AgedReceivablesByContact takes one contact. Building a full aging report means one call per customer, against a 60-call-per-minute limit — a hundred customers is close to two full minutes of the organisation's budget, and a tenth of a Starter-tier app's 1,000-call day.

Do — Compute aging ourselves from invoices plus unapplied cash, and tie to the ledger's own report for a sample of contacts rather than all of them.

What this changes in the interface

The payoff. Every difference above that reaches the surface, and what the component does about it.

Our number and their number can differ: Statement components carry a tie-out line: the ledger's total, ours, and the variance. Zero variance is shown, not hidden — its presence is the assurance.
Report rows cannot be drilled: Drill-down is offered from ledger-derived statements only. Where a figure came from a report endpoint, the row is not clickable and says why.

Where the accounting is explained

What consumes this payload

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 docs QuickBooks Online docs NetSuite docs