How many ways can a company slice its profit and loss? Two in Xero, named by the user. Two in QuickBooks, named by Intuit. Unlimited in NetSuite, named by the user and discovered at runtime. This is why a dimensional filter bar cannot be a static component.
Xero
GET /TrackingCategories
Categories with options
QBO
SELECT * FROM Class / Department
Two fixed entities
NetSuite
customsegment metadata + cseg_* fields
Field keys are discovered per account
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.
A custom segment creates a field whose key is defined by the customer — cseg_product, cseg_channel, cseg_whatever. Two NetSuite accounts have different dimension schemas. No type literal in your code can name them.
Do — Fetch the customsegment metadata at connection time, store it as a Dimension[], and drive every filter, group-by and column from that list.
A client who wants department and project and location on Xero cannot have all three. There is no plan, no setting and no workaround inside Xero's tracking model.
Do — Say so, rather than offering a control that cannot be saved. A third dimension lives in our system, applied at the reporting layer and marked as ours.
QBO's Department is a header field. Fanning it down to lines at normalisation makes reporting uniform, but writing per-line values back is impossible — the write silently keeps only one.
Do — Record appliesTo on each dimension. An edit UI shows a header control where the source stores it at the header, and a per-line control only where the source supports one.
Components take Dimension[] and render n of them. The number of dimensions is data, and zero is a valid answer.
type DimensionOption = {
id: string;
label: string;
parentId?: string; // Xero options are flat; QBO and NetSuite nest
active: boolean;
};
type Dimension = {
/** "tracking.0" | "class" | "department" | "cseg_product" — the source's key. */
key: string;
/** The user's own name for it. Never a label we invented. */
label: string;
options: DimensionOption[];
appliesTo: "line" | "header" | "both";
required: boolean;
source: SourceRef;
};
type LineDimension = { key: string; optionId: string; label: string };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