What is on the Orders surface?
Every order the store has taken, with its lines, the discounts allocated to them, the refunds that came back against them, the fulfilment events that moved them, and the tax lines they carried. The order's customer, location and channel sit alongside, so a single view answers what was sold, to whom, from where, for how much, and what happened afterwards.
It is the record layer under every other surface. The product analyst's profit figures, the net-sales bridge, the sales tax report and the returns analytics are all aggregations of these rows, which is why they always reconcile: there is one set of orders underneath them.
- The lines: product, variant, quantity, price and the discount allocated to each.
- The refunds: what came back against which line, when, and with what reason where the source records one.
- The fulfilment events: what shipped, from where, and when, against the promise made at checkout.
- The tax lines exactly as the store recorded them, which is what the sales tax report is built from.
- The customer, the location and the channel, so any order can be read in the context it happened in.
Why backfilled history matters on day one
A store that connects on a Monday does not want analytics that start on Monday. The engine backfills years of order history from the store platform, so the first Dashboard has comparisons, the first product analyst has sell-through, and the first Foresight view has enough history to compute cover and seasonality from.
The backfill is logged like any other run, so the owner can see how far back it reached and when it completed. Until it has, the surfaces say what range they cover rather than presenting a partial history as a full one.
How do search and filter answer a question in one go?
Filters cover the things an owner actually asks about: date range, location, channel, status, fulfilment state, discount code, product, customer, and whether a refund exists. Combining them answers questions like which orders from the Manchester store used the launch code and were later refunded, without exporting anything.
Because the query runs against the engine's own database rather than the store's API, the answer arrives in milliseconds over millions of rows, and running it does not consume the store's API budget or slow the storefront.
Does every alert drill to the order?
An alert about an unusual discount, a stuck fulfilment, a refund spike or a suspicious sequence of orders is a claim about specific transactions. On the Morning Brief and in the discount monitor, those claims link into Orders with the filter already applied, so the owner reads the actual rows rather than trusting a count.
This is the honest-data promise applied to alerts: a number that cannot be drilled into is a number that cannot be checked, so every number that appears in an alert carries its path back to the orders that produced it.
Export is one-way, and the store stays read-only
Orders exports to a spreadsheet for an accountant, an auditor or an analyst who wants to work outside the platform. The export carries the same fields the surface shows, including the coverage notes where a field was not reported by the source.
Nothing is ever written back. The engine cannot change an order's status, issue a refund or edit a line, because the store connection is read-only by design. Anything that needs to change in the store is done in the store, by a person.
Which roles read Orders on ftes.ai?
The Order Support FTE works the exceptions: stuck fulfilments, orders waiting on a decision, refunds that need a reason. The Disputes & Fraud FTE reads the order sequence behind a chargeback. The Controller FTE reconciles the period's orders to the net-sales bridge. Each role reads the same rows and shows them as evidence in its proposals.
For a brand starting out, Orders is the surface to open first after connecting, because seeing a familiar order with its discounts, refunds and tax lines correctly assembled is the quickest proof that the sync and the model are right.