Tutorial
Track your purchase spend, product by product
Narrow the purchase ledger to one product, read its price history and weekly spend, and tell the measured parts of that figure from the inferred ones.
About 9 minutes. Last reviewed against the product on .
By the end of this you will have one product's price history and a weekly spend figure you can put in front of a supplier, and you will know which parts of that figure were read from your files and which were worked out from them.
1. Narrow the ledger before you read it
Open My purchases. Every row is accepted purchasing evidence from a file you imported, newest first. Three filters sit above the table: product name, supplier and currency.
The currency filter selects; it does not convert. Nothing on this page turns one currency into another, and a row whose file carried no valid three-letter code is filed as UNSPECIFIED rather than guessed at.
2. Open one product
Click a product name. That opens the investigation view for one exact series, and the word exact is doing the work: four things must match before two purchases are treated as the same product.
| Part of the boundary | A difference here means |
|---|---|
| Supplier | Two separate series, never averaged together |
| Item name as recorded | Two separate series, until the names are reconciled |
| Purchase unit | Two separate series; a case is not a kilogram |
| Currency | Two separate series; nothing is converted |
Measured from the purchasing intelligence module at src/lib/purchasing/intelligence.ts.
This is why the same tomatoes from two suppliers never blend into one average, and why a supplier moving you from per-case to per-kilogram pricing starts a new series rather than appearing as a price cut.
3. Read the history, then read its limits
The investigation view gives you the current unit price, the previous one, the movement between them, and what that movement costs per week at your observed quantity. Underneath sit the figures worth quoting: weekly quantity, weekly spend, an annualised run rate, and how many days of purchases they were drawn from.
- Ledger query limit
- 10,000 rows
- the page warns you when it is reached
- Rows shown after filters
- 500
- filter harder to reach the rest
- Price history points
- 52 dates
- one per purchase date, most recent kept
- Usage window
- 56 days
- ending at your latest purchase, not at today
Measured from app/app/purchasing/page.tsx and src/lib/purchasing/intelligence.ts.
4. Check where the window ends
The weekly figures end at the most recent purchase date in your own data, not at today. If imports stopped three weeks ago, the weekly spend does not fall; it keeps describing the last window that had rows in it. Check the usage window on the product page before treating the number as current.
5. Leave with one supplier conversation
Pick the product with the largest weekly impact that you understand the cause of, and take two numbers to the supplier: the previous unit price and the current one, with their dates. That is a question about their pricing, which they can answer. A percentage on its own invites a discussion about your data instead.
What is measured and what is inferred
Measured: the date, supplier, item name, quantity, unit, currency and price on each row, exactly as the imported file carried them.
Inferred: a unit price where your file gave only a total and a quantity, which is division and is only as sound as the quantity. Weekly quantity and weekly spend are run rates over an observed window rather than budgets. The annualised run rate multiplies one observed week by 52 and assumes the next 51 resemble it.
Not known at all: pack weights, brand, grade, preparation, delivery charges and contract terms. None of these are in your purchase rows, so no comparison built from this page has accounted for them.