Where does supplier spend actually live in each ledger? Not all of it is in the bill object. QuickBooks splits accrual bills from immediate card and cash purchases into two entirely different entities, and a vendor-spend figure that reads only Bill under-reports — often dramatically.
Xero
GET /Invoices?where=Type=="ACCPAY"
Plus /BankTransactions for direct spend
QBO
SELECT * FROM Bill
Plus Purchase for card and cash spend
NetSuite
SuiteQL: FROM transaction WHERE type IN ('VendBill','Check')
Plus expense reports
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 vendor invoice you will pay later is a Bill. A card swipe is a Purchase, which posts no accounts payable and does not appear in any Bill query. Companies that run most spend on cards can have the majority of their expenses invisible to a Bill-only integration.
Do — Every spend aggregate reads Bill and Purchase — in Xero, Invoice ACCPAY and BankTransaction SPEND. Name the metric for what it contains.
A vendor bill carries an expense sublist (account, amount, segments) and an item sublist (item, quantity, rate, receipt matching). Item lines participate in three-way match and inventory costing; expense lines do not. Flattening both into one lines array loses the distinction, and the loss shows up the moment someone asks why a bill will not match its receipt.
Do — Carry a lineKind discriminator of 'account' | 'item' in the canonical model. QBO needs it too, for its two DetailTypes.
Xero's SUBMITTED status is a flag any user can set. QBO's API has no approval concept whatsoever. NetSuite has server-enforced multi-step routing that your write may enter and not clear — a successful API call does not mean an approved bill.
Do — Approval state is ours for Xero and QBO, mirrored from NetSuite. Write-back is capability-gated and hidden where the capability is false.
Only NetSuite models goods receipt as a record and reconciles quantity and price across PO, receipt and bill. QBO offers a link between a bill and a purchase order, with no receipt and no variance; Xero's API exposes no bill-to-PO link at all, only a purchase order whose Status has moved to BILLED.
Do — The match component computes the variance itself for QBO, from whatever quantities the linked documents carry, and labels it as our calculation rather than the ledger's. For Xero there is no link to compute from: any PO-to-bill pairing is ours, proposed and confirmed by the user.
Stacked rather than tabbed — a reader comparing two shapes should not have to hold one of them in memory.
QBO — account-based expense line on a Bill
{
"VendorRef": { "value": "41" },
"TxnDate": "2026-09-07",
"DueDate": "2026-10-07",
"APAccountRef": { "value": "33" },
"Line": [{
"DetailType": "AccountBasedExpenseLineDetail",
"Amount": 4500,
"AccountBasedExpenseLineDetail": {
"AccountRef": { "value": "62" },
"ClassRef": { "value": "3" },
"BillableStatus": "NotBillable",
"TaxCodeRef": { "value": "NON" }
}
}]
}NetSuite — expense sublist and item sublist on one bill
{
"entity": { "id": "41" },
"trandate": "2026-09-07",
"duedate": "2026-10-07",
"subsidiary": { "id": "2" },
"expense": { "items": [{
"account": { "id": "62" }, "amount": 4500,
"department": { "id": "7" }, "memo": "September rent"
}] },
"item": { "items": [{
"item": { "id": "310" }, "quantity": 100, "rate": 12
}] }
}type DocumentLine = {
id: string;
/** NetSuite expense vs item sublist; QBO's two DetailTypes; Xero's one shape. */
kind: "account" | "item";
description?: string;
quantity?: string;
unitAmount?: Money;
accountId?: string; // resolved even when the source only stored an item
itemId?: string;
net: Money;
tax: TaxBreakdown; // never a bare scalar
dimensions: LineDimension[];
billable?: { customerId: string; status: "billable" | "billed" | "not_billable" };
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