Reporting

Reporting turns the history the app already writes into reports you can read, chart, filter and export. There are three families — five manufacturing reports built from your work orders, five bill of materials reports built from what your orders demanded of your bills, and two sales reports built from a copy of your Shopify orders — and two summaries beside them that answer a whole period in five figures each. Nothing here is a second set of numbers. Every figure is recomputed from the same build runs, quality-control reviews, inventory movements and order executions the rest of the app shows, so a report and the page it came from can never disagree.

The catalogue

Open Reporting from the app navigation. The first page is the catalogue: every report, what it answers, and any views you have saved.

The table has three columns: the report’s name, its Category, and What it answers. Two things can appear beside a category:

A Summary badge marks the two reports that answer a whole period in five figures instead of listing rows.
A caption under the description says when that report’s history begins, where it begins later than your shop does: “History starts when demand tracking was switched on” for the five bill of materials reports, “History starts when order syncing was switched on” for the two sales reports.

Search narrows the catalogue by name, and Category narrows it to one of four values:

Category	What it lists
Manufacturing	The five reports built from your work orders
Bill of materials	The five reports built from what your orders demanded
Sales	The two reports built from your Shopify orders
Saved	Your own saved views

Saved views are rows in the same catalogue, not entries hidden behind the report they belong to: a monthly review you saved is one selection from here. Select any row to open it.

The three families, and the two summaries

The five manufacturing reports

Report	The question it answers
Build output	What did we build in this period? Units built, reworked and disassembled per item, with the work orders and build runs behind them.
Scrap and quality	What did quality control approve, fail, scrap and send back for rework, per item, and which failure category costs us the most?
Cost per build	What did each completed work order actually cost against what it was planned to cost, and what is that per unit?
Manufacturing consumption	What did manufacturing pick, consume and return, per material and location, and what did it cost at the moment it was consumed?
Throughput	How long did work orders take from creation to completion, and how many met their due date?

The five bill of materials reports

The manufacturing reports answer what you built. These five answer what your orders demanded of your bills: every time an order is executed, the app records what each bill, assembly bill and raw material was asked for, and these reports read that record.

Reporting calls these sub-assemblies — in the report’s name, its columns and its filters. They are the same thing you create on the Assembly Bills page.

Report	The question it answers
Finished goods demand	What did orders demand of each finished good in this period, how much came back through refunds and cancellations, and how much of the demand was met off the pre-assembled shelf instead of out of components?
Sub-assembly demand	What was demanded of each sub-assembly, and where did it come from: the shelf, its own components, or nowhere (a shortfall)?
Raw material demand	What did executions consume of each raw material, what did refunds put back, and what is that demand worth at today’s costs?
Pre-assembled usage	How much of everything the app assembled came off the pre-assembled shelf rather than being built at the moment of the order?
Execution health	How many order executions ran in each period, how many failed, how many needed no bill at all, and how long they took?

The two sales reports

The manufacturing and bill of materials reports read what the app did. The sales reports read what your shop sold, whether or not the app was involved.

Report	The question it answers
Unmodelled sales	What did we sell that has no bill of materials behind it? One row per variant, with units, orders and revenue. This is the list of things you might want to model.
Orders without execution	Which orders contained something we do model, but never had a bill executed against them? One row per order, newest first.

The two summaries

Two reports in the catalogue answer a period rather than break it down, and carry a Summary badge beside their category.

Report	The five figures it answers with
Manufacturing summary	Units built, scrap rate, cost per unit, on time, and consumption cost.
Sales summary	Net units sold, revenue (net of refunds and edits), orders, unmodelled units and orders without execution.

A summary has no rows, so it has no Group by, no filters, no column picker and no export. It carries the period control, a view switcher once you have saved more than one view of it, and — on Manufacturing summary only — the location scope. Sales summary has no location control, because an order is counted for the whole shop and only its shipments have a location.

Each figure is the same number the report behind it would total for the same period, so a summary and the report it summarises can never disagree.

Under the five figures, Compared with the previous period puts each one beside the same figure for the window of equal length immediately before it, with the difference as a signed number and a percentage. A figure that is itself a percentage — a scrap rate, an on-time rate — has its difference written in percentage points (pp), because the gap between two percentages is points and not a percentage of its own. The dates of that earlier window are named under the table, so there is never a doubt about what “previous” means.

The comparison is deliberately neutral. An arrow says which way a figure moved and nothing colours it: a scrap rate that rose and a revenue that rose are the same arrow and opposite news, and only you know which figure you were trying to move. If the earlier window holds nothing at all, its column reads “n/a” rather than a zero, which would read as “it was nothing before”.

Why two reports can disagree

The three families answer three different questions, so each family knows some things and not others. A report never mixes them.

The manufacturing reports and Manufacturing summary come from your work orders. They know what was built, disassembled, reworked and scrapped, and what it cost at the moment it moved. They know nothing about the order side.
The bill of materials reports come from what your executions demanded: what an order asked of each bill, sub-assembly and raw material, per location, including what the pre-assembled shelf covered. They cover only the orders the app executed, and they carry no cost, because there is no price at execution time.
The sales reports, Sales summary and the Sold basis come from the copy of your Shopify orders: net units, revenue, and the location that shipped them. They reach back only as far as that copy does, and they do not say what would actually be deducted if those orders ran.

So a sale with no bill behind it appears in Sales and nowhere else, and a build nobody ordered appears in Manufacturing and nowhere else.

Three consequences worth knowing:

Demand is recorded in full form. If a sub-assembly’s shelf covered half an order, the raw materials inside that sub-assembly still count as demanded, and the half that came off the shelf is reported separately in the From the shelf column. One row answers both questions: what the order needed, and what your stock covered.
Demand is signed. An order adds to it, a refund or a cancellation subtracts. Demanded, Restored and Net are three separate columns rather than one column whose sign you have to read.
Cost on the manufacturing side is the cost at the moment of the event, frozen when the movement was written. Changing a material’s price today does not rewrite what last month’s builds cost. Cost on the demand side is today’s cost, and is marked as an estimate for exactly that reason.

Where the manufacturing numbers come from

Units built, reworked and disassembled come from completed build runs, counted on the day the run completed.
Approved, failed, scrapped and reworked come from quality-control reviews, counted on the day the review was recorded, with the reviewer’s decision (scrap or send to rework) honoured exactly. A review that was voided leaves the figures entirely.
Consumption comes from the inventory movements a build run writes when it picks, consumes and returns a material. It is materials only: what a run produced, and what a disassembly credited back, are output and belong to Build output. Scrap is Scrap and quality’s question, so consumption has no scrap column. A run that was reversed has its consumption taken back off again, so it reads nothing consumed beside what it returned.
Lead time and on-time rate come from the work order’s own timestamps, from creation to completion, against its due date.

Two consequences. A work order that is still in progress contributes to build output and consumption for the units it has already built, but not to cost per build or throughput, which count completed work orders only. And a work order with no recorded cost at all reports nothing rather than zero, so it never drags an average down.

A deleted work order leaves the reports with it, because its history is gone.

Money and time

Money is shown in your shop’s own currency. Nothing in a report is converted: every amount is the shop-currency figure your orders and your costs were recorded in.

Days are counted in your shop’s time zone, not in your browser’s, so a report opened from another country still breaks its days where your shop does.

Reporting for an AI assistant

Every report can also be read by an AI assistant or an agent, through the same two calls the report page makes:

The catalogue lists every report with its id, what it answers, what one row of it is, which columns it carries, which of those can be sorted or filtered, and the figures it totals. It is the call to make before any other, so an assistant never has to guess a name.
The query runs one report over a period and answers a page of rows together with the same totals the strip shows. It takes the same filters, search, sort and paging as the page.

Two rules are worth knowing before you write against it. Days are always counted in your shop’s time zone: there is no time-zone argument at all, so a period cannot be shifted by the caller asking. And a period may span at most 366 days, exactly as in the app; a longer one, or a report name that does not exist, is refused with a message that says which, rather than answered with an empty table.

Export stays in the app. An assistant pages through the query instead of downloading a file.

To give an assistant access, see AI and agent access, and What the assistant can read for the full list of what it may ask for.

Where to next

Reading a report — the toolbar, the period, charts, saved views and export.
The reports — every column and every total, report by report.
Order sync — the copy of your Shopify orders the sales reports read, and how to keep it current.