Support  ›  Settlements & posting  ›  How classification works

How TrueBooks classifies lines

A settlement file is essentially a stream of low-level events. TrueBooks turns that stream into accounting categories you can post — here's how.

The three signals every line carries

Every transaction row in a settlement report has three columns we lean on heavily:

• transaction-type — the broad category, e.g. Order, Refund, Liquidations, FBA Storage Fees, Order_Retrocharge.
• amount-type — the subdivision within that type, e.g. ItemPrice, ItemFees, ItemWithheldTax, Promotion.
• amount-description — the most specific label, e.g. Principal, Tax, Shipping, Commission, FBAPerUnitFulfillmentFee, MarketplaceFacilitatorVAT-Principal.

The classifier reads them most-specific-first: amount-description wins, then amount-type, then transaction-type as a fallback. That ordering is deliberate — it lets us special-case the rows that need special handling without breaking the broad rules.

The accounts we route to

Every classified line ends up in one of the following Xero-side buckets. The internal codes (AMZ1, AMZ2, …) are how TrueBooks's mapping table addresses them; the right-hand column is what you'll typically see them mapped to in your chart of accounts.

Worked examples

A standard UK sale

An ordinary order produces three rows in the settlement: principal, tax, and Amazon's commission. They classify like this:

Order / ItemPrice / Principal       →  AMZ1, OUTPUT2 (20% income)
Order / ItemPrice / Tax             →  AMZ7, NONE
Order / ItemFees / Commission       →  AMZ3, INPUT2 (20% expense)

Net effect on Xero: a sales line at 20%, a VAT-collected liability line, and a deductible commission expense.

An FBA fulfilment fee

Order / ItemFees / FBAPerUnitFulfillmentFee  →  AMZ4, INPUT2

Domestic UK orders use the standard input rate. International orders fulfilled from a UK warehouse use REVERSECHARGES — see UK VAT & MF orders for the details.

An FBA Customer Returns Fee

This one's a regularly-confused pair. Each FBA customer return generates two rows on the settlement, one for the per-order fee and one for the per-unit fee, and they're labelled subtly differently:

Refund(?) / FBACustomerReturnFee / Base fee     →  Per-order fee (AMZ4, INPUT2)
Refund(?) / FBACustomerReturnFee / Tax on fee   →  Per-unit fee  (AMZ4, INPUT2)

The split is verified against authoritative settlement files; if you ever see them swapped on a posted invoice, that's a bug worth flagging — drop us a line.

A storage renewal charge

other-transaction / other-transaction / StorageRenewalBilling  →  AMZ5, INPUT2

The classifier matches any amount-description that contains the word "storage" — covers the standard monthly storage fee, long-term storage surcharges, and the renewal billing variant Amazon emits a few times a year.

A retrocharge

Order_Retrocharge / ItemPrice / Tax (or ShippingTax)  →  AMZ1, OUTPUT2 (Retrocharged VAT)

Amazon issues these when it discovers a tax adjustment after the original settlement. They're income-side and treated as standard-rated UK output VAT.

What about Marketplace Facilitator orders?

Orders shipped to jurisdictions where Amazon is the VAT-collector behave differently — Amazon withholds the VAT and remits it on your behalf. These orders need separate classification logic, covered in UK VAT & MF orders.

What if something gets misclassified?

The classifier runs against a regression suite of pinned settlement fixtures — every change is replayed against several known-good settlements before it ships, so misclassification regressions are caught before release. If a line ever lands in the wrong bucket on your books, email support with the settlement ID and the offending line — we add it to the regression suite as part of the fix, so once a bug is patched it can't quietly come back.