Inventory Reports

Where to Find Them

Menu → Reports → Reports Dashboard, then the Inventory pill.

Inventory reports are available to staff with inventory or reporting access; the Item History / Stock Card requires inventory access specifically. Each report runs in the browser — set the filters, click Run, sort or search the table, and export the current view with Download CSV. Large result sets are capped (each report notes its limit); add filters to bring the rest into view.

General Reports

Inventory List

What it shows: A filterable list of the item master. Code and description always show; you choose which extra columns to add — category, type, cost/price fields, SOH, allocated/on-order, supplier, GL accounts and more.

How to use it: Pick the columns you want under Show columns, then narrow the list by category (tick Include sub-categories to pull in every descendant), code, description, type (Product / Service), status and tracked flag. Click any code to open the item, sort any column, or Download CSV. Large catalogues are capped at 2,000 rows — add filters to see the rest. Replaces the old Inventory List Report – Customizable.

Stock on Hand

What it shows: Current stock-on-hand quantity and value across the business, valued at raw cost. A single report that replaces the previous separate SOH by Branch, SOH by Product Category and SOH by Product reports.

How to use it: Set Group by to roll the same figures up to Product (one row per item), Category, or Branch. Filter by branch and one or more categories (tick Include sub-categories to pull in every descendant category), and use the Exclude box to drop items whose code or description contains any of the terms you list. Only items with a non-zero balance are shown by default — tick Include zero / negative SOH to see the rest. In Product view, click an item code to open the item. Sort any column, and use Download CSV for the current view. The Product view is capped at 10,000 rows; narrow by category or the exclude filter if you hit it.

Manufacturing

Raw Material (BOM) Restocking Report

What it shows: Raw-material (component) requirements for a branch, exploded from the bills of material of the finished goods on active projects, netted against branch stock and costed into a purchasing-spend forecast. For each component it shows stock on hand, on order, allocated, a projected balance (what stock will be left once the outstanding demand is consumed) and a Suggested Order Qty that covers the shortfall and tops stock back up to the branch reorder minimum, rounded to the item's minimum order quantity. Each line carries a unit cost and an estimated purchase spend, and a status badge (OK / Order / Short / Critical) for at-a-glance triage. KPI tiles across the top total the items needing restock, the estimated purchase spend, the demand value and the stock-on-hand value. Click a component to expand a per-job demand breakdown (with customer and dollar value).

How to use it:

• Choose the branch and optionally narrow by category or supplier (start typing to search), then click Run. By default the supplier filter shows every item that supplier can supply — both items where they are the preferred supplier and items they stock under their supplier codes. Tick Limit to preferred supplier only to restrict the list to items whose preferred supplier is the one selected.
• Tick Only items needing restock to hide anything already covered by stock, or set a minimum estimated spend to focus on the material lines that matter to the budget.
• Tick Group by supplier to cluster items under their preferred supplier with an estimated-spend subtotal — ready to raise one purchase order per supplier.
• Use Download CSV for an analysis-ready export of every column, and use the report ahead of a production run to raise the right raw-material purchasing.

info BOM explosion follows Evolution's override hierarchy — a job-level BOM overrides a quote-level BOM, which overrides the item's master BOM — and includes manufacturing (mfbom) components, so the requirements reflect what each project will actually consume rather than a generic parts list. Unit cost prefers the branch moving-average, falling back to the master cost then the last purchase cost.

Bill of Material Detail Report

What it shows: A catalogue-wide audit of assembly items and their single-level master BOM components. Each assembly is listed with its own cost and price, the rolled-up cost of its components (the sum of each component's quantity × current master cost), and the variance between the two — so an assembly whose stored cost has drifted from what its components now cost stands out immediately. Expand any row to see the full component breakdown. It is a bulk view across many items at once (not a deep recursive explosion of one assembly), so it is the quickest way to sanity-check master BOM pricing across a whole category.

How to use it:

• Filter by category, production method, an item code/description, or a component code/description, then click Run. All filters are optional; the result is capped at 2,000 assemblies per run, so narrow down if you hit the cap.
• Scan the Cost Var column: a large positive or negative variance (shown amber, then red) means the assembly's own cost no longer matches the current cost of its components — a candidate for re-costing.
• Check Margin % (the assembly's own price against its own cost) to spot thin or negative margins.
• Expand a row to review each component's quantity, unit cost and line cost, and use Download CSV for an analysis-ready export (one row per component with the parent figures repeated).

info This report shows the master (item-level) BOM only, one level deep, and is read-only. Component cost is each component's current master cost. For a project's actual as-built structure — including project and quote overrides — use the BOM Restocking report or the project's own BOM editor.

Inventory Analytics

Three rebuilt analytics reports for understanding what sells, how a single item performs, and where stock physically moves. All three share a consistent filter bar, live search-and-sort tables, and one-click CSV export. Sales figures use committed invoices only and the same per-line revenue and gross-profit basis, so the numbers reconcile across reports.

Product Sales Performance

What it shows: One row per product over a chosen date range — quantity sold, net revenue, average sell price, gross profit ($ and %), and a monthly trend sparkline. A totals row summarises the whole result set.

How to use it:

• Pick a quick period (this financial year, last FY, this month, last 12 months…) or set an explicit From/To.
• Narrow by category (multi-select) and branch, exclude products by text, or set a minimum quantity.
• Tick Include project-dispatched items to also count stock dispatched against projects that never appears as an invoice line — for example a project billed by a single text / lump-sum invoice. Those units are valued at the project item’s own sell price and shown in a separate Project Qty column (with the off-invoice net revenue and GP in its tooltip), so you can see the full product movement without double-counting anything already itemised on an invoice.
• Sort any column — e.g. by GP % to find low-margin lines, or by Net Revenue to find your best sellers.
• Click a product code to open its Item History / Stock Card.
• Download CSV — per-month quantity columns are included so the trend is analysis-ready (with Project Qty / Project Net columns added when the project option is on). Up to 5,000 products are returned per run.

Item History / Stock Card

What it shows: A single-item drill combining current stock position (on hand, on order, allocated), sales KPIs and a monthly trend, plus a unified transaction history spanning committed invoices, quotes, shop-floor orders and purchase orders — each line clickable through to the source document.

How to use it:

• Start typing a code or description to pick the item (or arrive here by clicking a code on another report).
• Set a From/To date range (up to 12 months) and click Run.
• Read the KPI tiles for position and period performance; the monthly table and sparkline show the sales trend.
• Tick Include project-dispatched items to also count stock shipped against projects that never reaches an invoice line (for example a project billed by a single text / lump-sum invoice), valued at the project item’s own sell price. The KPI tiles then show how much of Qty Sold / Net came off-invoice, the affected months are flagged, and each project dispatch appears in the transaction list (click through to the project). This uses the same logic as Product Sales Performance, so the two reports reconcile.
• Use the searchable transaction table to trace every movement; Download CSV for the full list. The transaction history shows the 2,000 most recent movements in range.

Stock Movement Ledger

What it shows: The physical stock audit trail — every inventory movement in the period with its source, quantity in/out, and the running stock-on-hand after each movement. A summary line shows total in, out, net change and the number of distinct items in view.

How to use it:

• Pick a Period preset — This month, Last month, Last 3 months, Financial year to date, Last financial year, Calendar year to date or Last 12 months — to fill the dates for you, or set From/To by hand. The two date pickers keep each other inside the 12-month limit, so you can’t build a range the report will reject; editing a date by hand switches the Period back to Custom.
• Filter by item (code or id), category, movement source and branch.
• Each row shows the movement date and time (in your standard date format) and a colour-coded source badge — Purchase, Invoice, Dispatch, Picking, Shop Floor, Credit Note, Return and Stock Adjustment — so movement types are easy to tell apart. Quantities are signed (+ in / - out).
• Use it to audit a specific movement or investigate a stock-count discrepancy — the running SOH makes it easy to see where a balance went wrong. Every column sorts (including the date, which sorts in true chronological order).
• Click an item code to jump to its Item History / Stock Card, and Download CSV (which includes the movement time) for the filtered log. Up to 5,000 movements are returned per run — narrow by item or date if you hit it.

Data Quality

Product Coding Consistency

What it shows: Your product-coding convention, worked out from the items your team has already coded — and every term that has been coded more than one way. Nothing needs to be configured first: the report reads what is already there.

It works by lining a description up against its code. Where both split into the same number of parts, each part of the description is matched to the part of the code that encodes it:

Description   Fitting - Tee - PVC - Sched80 - 2"x3/4" - Socket x Socket
Code          FIT     - TEE - PVC - S80     - 2x3/4   - SxS

Seen once that proves nothing. Seen eighty times across the catalogue it is a rule your team has been following without ever writing it down.

How to use it:

• The Inconsistencies tab lists every term coded more than one way, worst first, in three classes. Likely error means the odd code means something else in your catalogue — a material coded as a different material, for example — so the item is probably mis-keyed and worth correcting. Style drift means it is only another abbreviation, a typo or a difference in case; harmless, but worth settling on one form. Review is neither and needs a human eye.
• The Learned Dictionary tab is your house style written down: each term, the code your team settles on, how many times it has been used and how consistently. This is useful on its own for training someone new, and it is the starting point for automatic code generation. Underneath it, Stored value → how it is written shows the same thing for your item attributes: where the attribute holds Sch80 and the description writes Sched80, that pairing is learned here.
• The Attribute Mismatches tab asks the opposite question: not “how is this term coded” but “do this item’s saved attributes actually describe the item?” Every row is a value stored against an item that matches no part of that item’s own description — a flat bar whose Profile is saved as Angle, a black pipe whose coating is saved as Galvanized, a fitting described as PVC Sched80 but stored as HDPE. See below for how to read it.
• Click any row to see the items behind it, grouped by how each was coded, with the settled form and the odd ones out side by side. Every item code links straight to the item so you can correct it.
• Adjust Min. uses and Agreement to control how much evidence a term needs before it counts. Raising agreement to 100% surfaces every term with any variation at all; lowering it reports only the clearest cases.
• Set Name split and Code split to match how your own codes are punctuated, and Name source to whichever field holds your structured product name. Download CSV exports whichever tab you are on.

What it does not do: nothing is changed — this report only reads. Items whose description and code split into a different number of parts are skipped, because a shortened code can no longer be lined up without guessing; the summary line tells you how many. Terms coded a different way almost every time are also left out and counted separately: those descriptions are free text rather than structured, so there is no convention for them to be inconsistent with. If your item codes are not structured at all, this report will correctly find nothing.

Attribute Mismatches

Most items carry attributes as well as a description — material, class, diameter, grade. The two are meant to say the same thing, and on a well-kept item they do: the description reads Fitting – Tee – PVC – Sched80 – 2" and the attributes hold PVC, Sch80, 2".

This tab finds the items where they do not. For every value saved against an item, the report checks whether any part of that item’s own description accounts for it — allowing for the abbreviations and unit suffixes it learned on the Dictionary tab, so Sch80 still matches Sched80 and 10.0 still matches 10mm. What is left over is a value the description contradicts.

Which record is right? Nearly always the description. It was typed by somebody looking at the product; attributes usually arrived in a bulk import or were copied from a similar item and never revisited. So the mismatch is normally a fault in the attribute, and it is worth fixing on its own merits — those attributes drive searching, filtering and reporting, so a flat bar filed as an angle is invisible to anyone looking for flat bar.

How to read a row:

• Items is how many items in that category store that value without describing it. Work down from the top — one wrong value repeated across thirty items is usually one bad import, and one fix.
• Normally Named is the strength of the finding: how often that attribute does appear in the description elsewhere in the same category. At 90% the attribute is clearly meant to be there and its absence is a real disagreement — those rows are shown in bold red. At 30% it is only a hint, and is greyed out. Sort by this column to put the most certain findings first.
• Click a row to list the items, each linking straight to the item so you can read the description and correct the attribute against it.

Underneath the table, Attributes this category never names collects the values that are also unaccounted for but harmlessly so: no item in the category puts that attribute in its description, so it simply is not part of how you name those products. Nothing to fix — but worth knowing, because it tells you which attributes a naming or coding template should not ask for.

A note on what counts as a mismatch: the check is deliberately generous. Numbers must agree — 4.5 will not match 45 — but decimal formatting is ignored, so 10.0, 10 and 10mm are treated as the same value, and abbreviations, prefixes and word order are allowed for. An attribute is only reported when nothing in the description accounts for it at all.

RRP / Pricing Integrity

What it shows: The state of the RRP behind your catalogue. For every item the report works out the markup needed to reach its own RRP, then flags the items that cannot be priced from RRP at all, the ones whose RRP implies a markup worth questioning, and the ones nobody has looked at in years.

Why it matters: On a Cost Plus quote, a customer with no category markup and no markup of their own falls through to the house default. Where that default is set to RRP (see Cost Plus Priced From RRP), the price those customers are given is only ever as good as the item’s recorded RRP — and on most catalogues nobody has ever audited it. This report is that audit. It is worth running before switching the setting over, and it works just as well on a company still pricing on markup: a wrong RRP is a wrong discount quote too.

Three classes of finding, and they are not equally urgent:

• Cannot price — No RRP, No cost, or RRP at or below cost. These lines cannot be priced from RRP at all. A Cost Plus quote quietly falls back to your Cost+ Default Markup and warns on the line; nothing breaks, but the price is not the one you intended.
• Check the number — the RRP is usable, but what it implies is suspicious: Above maximum markup (past your Cost+ Maximum Markup ceiling), Below minimum markup (quoting at RRP would breach the item’s or its category’s floor), Far above / far below category (the markup is several times the typical markup of everything else in its category), RRP below settings price (the live RRP sits well under the price the item’s own min markup / max discount settings would generate — the last person to price it did not go through the settings), or Full discount beats floor (giving the item’s full permitted discount lands the price below its own minimum markup — the pair contradicts itself). These are nearly always a cost that was never updated rather than a deliberate price — a $1.00 placeholder cost against a $3,000 RRP reads as a 299,900% markup.
• Housekeeping — RRP not updated inside the period you chose; No min/max set, meaning neither the item nor its category holds a minimum markup or maximum discount to stop the price being moved; RRP above settings price (priced well over what its own settings would suggest); Category default not applied (the category holds a default markup the item never picked up); or 0% max discount (markup set with no discount headroom — valid, the RRP is the minimum price, but contract and price book discounts on that item are not capped, so it stays worth keeping in view). Useful to know, not urgent, and easy to have in the thousands on a catalogue that has never had guard rails set.

How to use it:

• The report runs as soon as you open it, on your whole active catalogue. Narrow it with Category, Active items only and Stocked items only, then press Run.
• Include items with no type is ticked by default. Items whose type was never set to Product or Service are invisible to most inventory screens, but they still appear on invoices — on some catalogues they carry a quarter of what actually gets sold — so this report checks them unless you untick it.
• Settings tolerance sets how far an item’s live RRP may drift from the price its own min markup / max discount settings generate before RRP below / above settings price is raised — 20% by default.
• The chips above the table are the finding filters. The list opens on Needs attention — the red and amber rows only — because on a catalogue with no minimum markups set, housekeeping alone would flag nearly every item and bury the ones that matter. Click a chip to see just that finding, or All for everything.
• Maximum markup % starts from your Cost+ Maximum Markup setting. Change it here to test a tighter or looser ceiling without changing the setting for everyone; set it to 0 to turn the check off. Tighten it until the amber list is a day’s work rather than a project.
• Outlier threshold is how far from its category’s typical markup an item has to sit before it is called out — 3× the category median by default. RRP stale after sets the age at which an untouched RRP is reported.
• Click any row to open the item and correct it, or use the Expired Pricing Tool (Inventory → Expired Pricing) to work through a whole category’s costs and RRPs in one pass. Download CSV exports exactly what is on screen, chip filter included.

Reading a row: Markup to RRP is the percentage that would price that item at its RRP — it is the number the quote screen would put in the Margin column. Category Median is the middle markup across the priceable items in the same category, which is what the outlier test compares against, and Min. Markup is the item’s own floor, or its category’s where the item sets none. Max Disc. is the item’s own maximum discount, and Settings Price is the RRP its own min markup / max discount pair would generate — the same number, to the cent, that the Bulk Category Pricing tool would write. One row can carry several findings at once; the badge colour follows the most serious.

By Category

The second tab asks a different question: where does the problem live? A category where most items need attention is not a hundred separate mistakes — it is a pricing process that was never run over that category, and it is far cheaper to fix as a batch. Sort by % Needing Attention to find them.

Median Markup per category is useful on its own: it is what your RRPs are actually worth as a markup today, category by category, which is the number to compare your Cost+ Default Markup against. Categories with fewer than eight priceable items do not get a median — there is not enough to be typical of — and their items are never reported as outliers.

Min/Max Settings

The third tab is for choosing a min markup / max discount pair, category by category, before anyone applies one. For each category it shows how many items hold a markup at all, the category’s own default pair, the most common pair across its items and the share that uses it, the effective markup that pair really works out to (a 15% markup with a 28% discount is really a 59.7% markup on cost), and the median actual markup the category’s live RRPs imply today. Matching Disc. closes the loop: it is the discount that, paired with the most common markup, reproduces where pricing actually sits — a negative number means the category is currently priced below its own floor.

Test Pair is the working part. Type any markup and discount and the row recalculates instantly against the category’s live costs and prices: Up / Down >5% is how many items would move more than 5% either way if the Bulk Category Pricing tool applied that pair, and Median Change is the typical price movement. Testing a pair with a 0% discount shows an amber reminder that the generated RRP would be the minimum price, along with the small discount that would match current pricing instead. Nothing is written from this screen — when a pair looks right, the Bulk pricing link opens the Bulk Category Pricing tool with that category already selected, and Download CSV on this tab exports the whole working — test pairs included — as the document to circulate for sign-off.

What it does not do: nothing is changed — this report only reads. It does not judge whether a price is right, only whether the RRP behind it can be trusted to produce one; a genuinely high-margin item will appear as an outlier and is correctly left for a human to confirm. Up to 3,000 flagged items are listed per run, most serious first, with a banner when there are more — filter by category to work through the rest. Throughout Evolution “markup” means markup on cost (sell = cost × (1 + markup ÷ 100)), which is the same arithmetic the Margin column on a quote uses.

Cost Price Audit

What it shows: every item whose raw cost — the supplier price before on-cost — disagrees with what you actually paid for it. The evidence is the item’s last committed supplier bill, or its last purchase order where it has never been billed. For each item it suggests the cost the evidence supports, shows which quotes, projects and invoices the current cost has already reached, and lets you correct it from the same screen.

Why it matters: the raw cost drives the landed cost, and the landed cost drives every Cost Plus price, every margin on a quote, the value of your stock and the cost a new purchase order line starts from. A cost that was imported wrong, keyed per box instead of per unit, or simply never updated is copied into all of them quietly. Because a new purchase order line takes its cost from the item, a wrong cost also repeats itself on every order raised from it — so the report ignores a purchase order line whose cost is exactly the item’s own cost, and only treats it as evidence when someone typed a different figure. Supplier bills are keyed from the supplier’s invoice and are always trusted.

1. The summary cards cover the whole run, not just the page on screen: how many items were flagged, how many are critical, how many are costed under or over what you pay, how far the stock value would move if the suggested costs were applied, and the Cost+ exposure — open Cost+ quotes, Cost+ projects not yet invoiced, and invoices already sent that were priced from a cost lower than you pay, with the amount under-charged.
2. Purchase history is how far back to look for bills and purchase orders (24 months by default; All history looks at everything), and Tolerance % is how far the cost may sit from what was paid before it is flagged (15% by default; 0 flags any difference at all).
3. Limit to item codes opens a box to paste a list of codes — one per line, or separated by commas or tabs, straight from a spreadsheet column. The report then checks only those items, and lists any code it could not find.
4. The chips filter the list without re-running it: by severity on the first row, by finding on the second. The counts are for the whole run.
5. Paid is the evidence — the unit cost on the last bill, or the last purchase order, with its date — and Var % is how far the raw cost sits from it. Red means the item is costed below what you pay, so it has been under-priced on Cost+ work.
6. Suggested raw cost is the figure that would be written: the last bill, else the last purchase order, else the item’s recorded last cost. You can type over it; the row is ticked for you and marked Typed.
7. The action bar works on the ticked rows, or on every row the current filters match.

The findings:

• Differs from last bill — the raw cost is more than the tolerance away from the last committed supplier bill. Critical when the gap is over 50%.
• Differs from last PO — never billed in the period, and the raw cost disagrees with the last purchase order.
• No cost — no cost at all on an item that is in stock or has been bought.
• Margin — the landed cost is at or above the sell price (critical), or the sell price is below the item’s minimum markup.
• Pack size? and GST? — the difference is exactly the item’s box quantity, or exactly 10%. These usually mean a per-box price or a GST-inclusive figure rather than a wrong cost, so they are held back from bulk apply; open the item, decide, and apply it there if it is right.
• Landed cost stale — the stored landed cost is not the raw cost plus the item’s on-cost. Applying recalculates it without changing the raw cost.
• Stale — the cost has not been updated in the Stale after period and newer buying disagrees with it.
• Cost method not set — the item has no cost method, so screens that read the landed cost fall back to the average cost. This is usually company-wide set-up rather than a fault with one item, so items with nothing else wrong are left out unless you tick Include cost-method-only items. Set cost method… sets them to Set Cost.
• Average cost drift — an Average Cost item whose average has drifted from what its bills average.

Checking one item: click a row to open its cost evidence: the bills and purchase orders behind the suggestion, and every open Cost+ quote, Cost+ project not yet invoiced, invoice already sent (with the amount under-charged) and draft purchase order that carries the current cost. Type a new raw cost to see the landed cost and margin it gives (1), then Apply to this item (2).

Fixing costs in bulk: tick rows and press Apply to selected, or press Apply to all matching… to apply the suggested cost to every item the current filters and chip match — across every page, not just the one on screen. Either way a confirmation shows exactly what will happen first: how many costs go up or down, how many only have their landed cost recalculated, the stock value movement, and what is left out and why.

• Only costs a finding says are wrong are moved. An item flagged only for margin keeps its cost; open it if you want to change it.
• Each change is written to the item’s history, with the old and new cost and the run’s reference, so every item changed in one run can be traced back to it.
• If someone else changes an item’s cost after you ran the report, that item is skipped rather than overwritten, and the result tells you how many were skipped.
• Existing quotes, projects, invoices and purchase orders are not changed — they keep the cost they were raised at. Use the evidence pop-up to find the open ones worth re-pricing. Nothing is sent to Xero.
• Applying needs Admin access to Inventory. Anyone who can run inventory reports can view the audit.

Working through a known list: when you already know which items are wrong — after an import, say — paste their codes into Limit to item codes, set Purchase history to All history and Tolerance to 0, and run. Review anything held (Pack size? / GST?) one at a time, then use Apply to all matching for the rest.

Limits: up to 5,000 flagged items are listed per run, most serious first, with a notice when there are more; the bulk apply and the CSV still cover every match. Download CSV exports every flagged item for the current filters and chip. An item never bought in the period has no evidence and is only checked for missing cost, margin and landed cost.