COGS snapshot explained: why nouz freezes cost-of-goods at the moment of sale (and not later).

When you log a product sale in nouz, the product's current cost price is frozen onto that specific revenue entry and stored alongside the gross amount. Edit the product's cost tomorrow — because your supplier hiked prices, because you switched to a cheaper bean, because you finally re-costed accurately — and yesterday's sale stays exactly as it was. Today's and tomorrow's sales pick up the new cost. That mechanic is what we call the COGS snapshot, and it is the single most important rule that makes nouz's historical EBIT trustworthy.

TL;DR

• What it is: the product's current cost is copied onto the revenue entry the moment you save the sale. The revenue entry stores a snapshot, not a live reference.
• Why it exists: small shops do not run perpetual inventory or period-end counts. Without a snapshot, any future cost edit would silently rewrite the past.
• What it solves: the retroactive-COGS trap — where adjusting today's product cost rewrites last quarter's EBIT and makes historical numbers untrustworthy.
• How it compares: FIFO and weighted-average both require ongoing inventory tracking. Snapshot-at-sale requires only that the product cost is correct on the day the sale happens.
• The one limit: manual revenue entries (typed gross numbers) do not carry a COGS snapshot. Only product sales do.

The problem the snapshot solves

Imagine you run a café. In January your wholesale flour is €0.42/kg and a croissant's ingredient cost works out to €0.85. You sell 1,240 croissants that month at €3.20 each — €3,968 gross, €1,054 of COGS, €2,914 of contribution before the rest of the P&L. That number lands on your January close-out, your accountant sees it, you make staffing decisions based on it. January is done.

February arrives. Your flour supplier hikes prices by 30%. The new croissant ingredient cost is €1.10. You update the product in your system to reflect the new reality. In a naive tool — one that holds a live reference to the product cost rather than a snapshot — every single croissant sale you ever logged silently retroactively re-costs at €1.10. January's 1,240 croissants now show €1,364 of COGS instead of €1,054. Your January contribution drops by €310 overnight. The number your accountant signed off on last month is no longer the number in the dashboard. You did nothing wrong. The tool just rewrote history because a future cost changed.

Multiply that across every product you sell, every supplier price change across a year, every menu re-costing exercise. By December, the early months of the year look nothing like what you saw at the time. You stop trusting the dashboard. You go back to spreadsheets. The whole point of a daily P&L — a trustworthy historical record you can refer back to — is gone.

The snapshot fixes this with one rule: at the moment a sale is saved, the product's cost is copied onto the revenue entry as a value, not a link. From that moment on, the entry is immutable. Tomorrow's edits, next month's edits, next year's edits — none of them touch it. January stays January.

What COGS means in a small shop

Before going deeper on the mechanic, get the term straight. COGS — Cost of Goods Sold — is the cost of the things that left your shop today, valued at what you paid for them. Not your rent. Not your salaries. Not Stripe fees. Not your accountant. COGS is the raw cost of the inventory or ingredients that physically moved out the door because a sale happened.

• For a café: the beans, milk, flour, butter, sugar, syrup and packaging that went into the drinks and food you sold today. Not the espresso machine — that is depreciation. Not the barista — that is payroll. Just the consumables.
• For a retail boutique: the wholesale cost of the dresses, jumpers and accessories that left the shop with customers today. Not the hangtags or tissue paper — those are variable costs, but conventionally not COGS.
• For a salon: the colour, foils, developer, treatment products actually used on today's clients. Not the towels (laundry is variable). Not the stylist's hour (payroll).
• For an e-commerce shop: the landed wholesale cost of products shipped today. Shipping cost itself is usually a separate variable line, though some operators bundle it.

The clean test: would I have paid this if I hadn't made the sale? If the answer is no, it is probably COGS. If the answer is yes (rent, salary, software), it is not COGS — it lives in the fixed or variable buckets, but on a different line of the P&L. The COGS vs COGS percentage explainer goes deeper on the ratio side; this article is about the underlying mechanic of how that cost gets captured. The help-center article on what COGS means in nouz covers exactly which entries get classified as COGS and where they surface on the daily P&L.

Three ways to value COGS

There are three common ways to assign a cost to a sale. All three answer the same question — what did this item cost me? — and all three give defensible numbers if applied consistently. They differ in what they require from your system and what they assume about how you actually run.

1. FIFO (First In, First Out)

FIFO assumes the oldest stock you bought is the first stock you sold. When you sell ten units, the system looks up the cost of your oldest ten units in stock and uses those costs as COGS. The remaining inventory carries the newer (typically higher) cost.

Worked example. A boutique buys 20 jumpers in January at €36 each (cost €720). In February, the supplier raises prices and the boutique buys another 20 at €42 each (cost €840). In March the boutique sells 25 jumpers for €120 each.

Under FIFO, those 25 sales pull cost from the older batch first: 20 jumpers at €36 + 5 jumpers at €42 = €720 + €210 = €930 of COGS. The remaining 15 jumpers in stock are valued at €42 × 15 = €630. Gross revenue is 25 × €120 = €3,000; gross profit is €2,070.

Why FIFO is the gold standard. It mirrors how perishable inventory actually moves (you sell the older yogurt first because it expires first). It produces ending-inventory values close to current market price. It is the default treatment under IFRS and acceptable under most national tax codes.

Why it is hard for small shops. FIFO requires you to track every purchase batch as a separate cost layer and consume those layers in order on every sale. That means a perpetual inventory system, batch-level cost records, and a sale-by-sale matching process. For a café selling 200 items a day across 60 SKUs, you would need to know which delivery of milk every cappuccino came from. Theoretically possible. Operationally exhausting.

2. Weighted average cost

Weighted average smooths every purchase into a single blended cost per unit. After each new purchase, the system recomputes: (existing inventory value + new purchase value) ÷ (existing units + new units) = new average cost. Every sale until the next purchase uses that average.

Worked example. Same boutique, same purchases. After January, average cost is €36/unit (20 jumpers, €720 total). After February's purchase, average is recomputed: (€720 + €840) ÷ (20 + 20) = €39/unit. The 25 March sales each cost €39, so COGS is 25 × €39 = €975. Remaining 15 units are valued at 15 × €39 = €585. Gross profit on the 25 sales is 25 × (€120 − €39) = €2,025.

Why weighted average is popular. It is simpler than FIFO — one average per SKU, recomputed on each purchase. It smooths short-term cost spikes. Many small ERPs and inventory tools default to it.

Why it still does not fit small shops. It still requires you to record every purchase batch with quantity and total cost. It still requires an ongoing inventory count. And the smoothing it offers is a feature for accounting, not a feature for operating decisions — when your flour cost jumps 30%, you want to see that signal cleanly the day it lands, not absorbed into a blended average.

3. Snapshot-at-sale (nouz's method)

Snapshot-at-sale skips the inventory-tracking step entirely. Each product carries a single current cost that you set up once and update when reality changes. When you log a sale, the product's current cost is copied onto the revenue entry as a frozen value. Future cost edits update the product, not the past.

Worked example. Boutique sets the jumper's cost at €36 in January. Sells some jumpers in January — every sale stores cost €36. In February the supplier raises prices; the owner updates the jumper's cost to €42. January's sales stay at €36 of COGS each. February's sales record at €42. March's sales also at €42 (unless the cost is updated again). No batch tracking, no inventory layers, no perpetual count.

Why it works for small shops. It matches the operator's mental model: at the moment I made this sale, this is what it cost me. It survives product edits without rewriting history. It requires no inventory-management overhead — just the discipline to update product costs when supplier prices materially change. And it gives you an exact, auditable COGS figure for every single revenue entry — not a smoothed average, not a backed-out balance-sheet residual.

Why nouz picks snapshot-at-sale

Three reasons, in order of how strongly they drove the design.

One: it matches how the operator already thinks. Ask a café owner what their cappuccino costs and they answer something like "about €0.55 — beans, milk, cup." They don't answer "well, it depends which batch of beans we're drawing from this week." The mental model is one current cost per product. Snapshot-at-sale matches that mental model directly. FIFO and weighted average force the operator to think in batches and averages they don't actually carry in their head.

Two: it survives product edits without rewriting history. Small shops re-cost products constantly. Suppliers move prices. You discover the old recipe used more butter than you thought. You switch to a different milk brand. Every one of those edits should update future COGS while leaving the past exactly as it was. That is exactly what snapshot does, by design. There is no way to accidentally rewrite history with a product edit, because the edit only changes the product record — not the historical entries that reference it.

Three: it requires no inventory-management discipline. The owner-operators nouz is built for don't run perpetual inventory. They don't do month-end counts. They don't want to track batch costs. They want to set up their products once, log sales nightly, and see a number. Snapshot-at-sale is the only one of the three methods that delivers a defensible COGS figure under those constraints.

The trade-off is one we will defend: a tiny, predictable lag in COGS accuracy in exchange for never rewriting history, no inventory overhead, and a one-number daily P&L the owner actually checks. For shops that need batch-level precision (high-end restaurants tracking yield variance per supplier delivery, manufacturers with regulated cost-of-production reporting), a different tool is the right tool. For everyone else — cafés, boutiques, salons, small e-commerce — snapshot is the honest answer.

Why retroactive COGS edits are a trap

Some P&L tools — including some otherwise serious ones — let a product cost edit silently rewrite every historical sale that referenced that product. The vendor describes this as a feature ("your historical COGS stays up-to-date"). It is not a feature. It is a structural flaw.

Consider what "your historical COGS stays up-to-date" actually means. It means the number you saw on January 31st is not the number you see on March 1st. It means the EBIT report you sent your accountant in February no longer ties out to the EBIT report you can pull today. It means decisions you made in real time — to discount a slow-moving product, to extend opening hours, to hire a second barista — were based on contribution-margin numbers that have since silently changed.

Three concrete consequences, all of them bad:

• You stop trusting the dashboard. The first time you notice that last quarter's EBIT has shifted by 4% with no entries changed, you start cross-checking against your accountant's monthly close — and the daily P&L loses its primary purpose, which is to be the one number you can act on tonight.
• Your decisions become unauditable. If a regulator, a tax inspector, a partner or an investor ever asks "why did you raise prices in March," you cannot point to the actual February numbers you saw at the time — because those numbers no longer exist in the tool.
• Bookkeeping reconciliation breaks. Your accountant's monthly P&L is computed once and never rewritten. Your dashboard is rewritten every time a product cost changes. Within six months, the two diverge and the only way to close the gap is to manually export and freeze monthly snapshots — which is exactly what the dashboard was supposed to remove.

A historical number is only useful if you can trust it not to move. nouz's commitment is simple: nothing you save can be silently re-costed by a future edit. Update the product cost as often as you like. Yesterday's P&L stays exactly as it was yesterday.

Walk-through: how nouz freezes COGS on a sale

Concretely, here is what happens behind the scenes when you log a product sale in nouz. Five steps, all of them mechanical.

1. 01
   undefined

   You add "Croissant" to your product list. You enter a current cost of €0.85 and a current sell price of €3.20. nouz stores the product record with those two values, plus a created-at date.

2. 02
   undefined

   At close on Tuesday, you log "40 croissants sold today." nouz reads the product's current cost (€0.85) and price (€3.20) at the moment you save.

3. 03
   undefined

   nouz creates a revenue entry that stores: 40 units × €3.20 = €128.00 gross, 40 units × €0.85 = €34.00 COGS, the product name "Croissant" as a label, the date, and the location. The €0.85 and €3.20 are stored as values on the entry — not as a link to the product record.

4. 04
   undefined

   Three weeks later, your flour supplier raises prices. The new croissant cost is €0.95. You open the product, change the cost from €0.85 to €0.95, and save. nouz updates the product record. Tuesday's entry does not change. It still shows €34.00 of COGS, because the snapshot was taken on Tuesday.

5. 05
   undefined

   Tonight you log "35 croissants sold today." nouz reads the now-current cost (€0.95) and writes 35 × €0.95 = €33.25 onto the new entry. Tuesday and tonight live side by side in your history at their own correct cost.

For a full setup walkthrough, see setting up a product. For the edit case specifically — when and how to update a product cost without confusing yourself — see editing a product later.

Manual revenue vs product-sale revenue

nouz lets you log revenue two ways: manual entries (you type a gross amount, with a cash/card split) or product sales (you select a product from your catalogue and a quantity). Both feed the same daily P&L. They differ in one important way for COGS.

In practice, most shops use a mix. A café might log specialty drinks as products (so the COGS per cappuccino is tracked and supplier price changes are visible) and the general till total as a single manual entry at close. A salon might log every service as a product (so colour cost per service is tracked) and tips as a manual zero-COGS entry. An e-commerce shop typically logs every order as products because the catalogue is the system of record anyway.

The rule of thumb: if you want to see margin on it over time, log it as a product. If you just need it in the gross revenue number, manual is fine. Manual entries don't leave you blind on COGS — they just mean the COGS for that portion of revenue isn't broken down per item. You can still add COGS as a separate cost entry. The manual vs product-sale revenue help article walks through specific scenarios.

The mechanic is the same on the manual side: a manual revenue entry, once saved, stores its gross amount as a value. Editing the entry edits that day's P&L; editing nothing leaves nothing changed. There is no "live link" anywhere in the data model. Every entry is its own historical fact.

What snapshot doesn't do

The snapshot is a simple mechanic and it does one thing well. There are three things it does not do, and being honest about them is how you keep your numbers clean.

It does not handle waste or spoilage automatically. If a tray of croissants burned this morning and you binned them, those croissants never became a sale — so they never produced a COGS entry. But the flour, butter and labour that went into them was real cost. The honest fix is to log the spoilage as a separate variable cost on the day it happened (e.g., "Spoilage — €18.50, batch of croissants overproofed"). The recording spoilage help article covers the recommended categories.

It does not account for shrinkage. If items disappeared from inventory — staff snack, customer theft, miscounted delivery — the snapshot won't catch it because there's no sale to attach a cost to. Shrinkage typically only becomes visible if you do periodic physical counts and compare against expected on-hand from sales. For shops that care, a weekly or monthly shrinkage line as a variable cost is the right place to put it. For most owner-operators running tight floors, shrinkage is small enough to absorb into the general variance noise.

It does not track per-batch cost. If you bought one batch of beans at €18/kg last week and the new batch this week is €21/kg, the snapshot uses whatever the product cost is set to when the sale happens — not the cost of the specific batch the bean came from. For most small shops this is fine: you update the product cost when you notice the supplier change, and the small lag costs less than 1% of monthly COGS. If you genuinely need per-batch precision (e.g., a single-origin coffee bar tracking yield per roast), you need a different tool.

How this maps to your accountant's reporting

Accountants in most European countries compute COGS at period end using the formula:

COGS for the period = Opening inventory value
                    + Purchases during the period
                    − Closing inventory value

This is called the periodic inventory method. It computes COGS as a balance — what came in minus what is still on the shelf — rather than per sale. It is correct, it is the legal standard for most jurisdictions' annual filings, and it is what your accountant will use to prepare your annual P&L.

The snapshot mechanic produces numbers that are compatible with the periodic method, not identical. The differences and the reconciliation:

• Sum of snapshots ≈ accountant's COGS for the period, with small differences from spoilage, shrinkage, supplier-cost lag and waste — all of which the accountant absorbs into the inventory delta but the snapshot tracks (or doesn't) as separate variable lines.
• The accountant uses bank statements + inventory counts to compute the periodic figure. nouz uses sale-by-sale snapshots. Both arrive at COGS; both are defensible.
• For reconciliation: at month-end, your accountant can sum a month of nouz's snapshot COGS, compare against the periodic computation from bank purchases and inventory deltas, and the variance is normally small. Investigate variances over ~5%; ignore noise under ~2%.

In practice, accountants who have worked with daily P&L tools accept snapshot-based COGS as a valid management-accounting figure for the periods between formal closes. The annual filing still uses periodic inventory because the law typically requires it. The snapshot is what you act on day-to-day; the periodic figure is what you file. They tie out within a few percent and any larger gap is a signal worth understanding, not a problem with either method.

For more on how nouz's daily numbers map cleanly to a monthly export your accountant can absorb, see how to read a P&L statement. For a sector-by-sector sense of what COGS percentages look like across European small shops, see COGS by sector — European SMB 2025.

The daily routine, in 90 seconds

In day-to-day operation, the snapshot is invisible. You don't see it, configure it or think about it. The routine is just:

1. At close, open nouz on your phone or laptop.
2. Log today's product sales (quantity per product) — or paste a till total as a manual revenue entry.
3. Add today's small variable spends (cleaning supplies, takeaway packaging, anything that happened today).
4. Glance at the day's EBIT figure. Compare to yesterday and to the same weekday last week.
5. Close the app. The snapshot has already happened; tomorrow's edits will not touch tonight's number.

Update product costs when supplier prices materially move — once a month is typical for a café, every quarter is fine for a boutique, weekly is sometimes right for an e-commerce shop with fast-moving SKUs. There is no penalty for updating frequently; there is also no requirement to do so daily. The only rule is: update the product going forward, and trust that the past is safe.

If you want to see what an EBIT line looks like once the snapshot has done its job, the profit margin calculator runs the math in your browser with no signup — type a few revenue and cost numbers and watch EBIT land. For the full daily routine end-to-end, the nouz home page walks through an 8-minute setup and shows the same-day close-out flow. Plans on the pricing page are monthly only — no annual lock-in for a tool you can stop using tomorrow.

And the conceptual companions, for the full picture: EBIT explained (the formula the snapshot feeds into), gross vs net revenue (why the gross number on the till is not the number that pays your rent), what fixed costs actually mean (the daily slice that sits under every EBIT calculation), and the cross-vertical daily P&L framework. For e-commerce specifically, the COGS for e-commerce glossary entry covers shipping, returns and platform fees. Together those cover the entire cost-and-revenue logic that drives every number you see in nouz.

FAQ