# COGS & Inventory Costing — Standard Equations Reference

## 1. The core idea

COGS (Cost of Goods Sold) answers one question: **"What did the units I just sold actually cost me?"**

To answer that, the system needs to know the **cost per unit** at the moment of the sale. How that cost per unit is calculated depends on which **costing method** the system uses. The four standard methods are:

1. **Weighted Average Cost (WAC)** — also called "Moving Average Cost" (most common in ERPs like Odoo, SAP, NetSuite)
2. **FIFO** (First In, First Out)
3. **LIFO** (Last In, First Out) — banned under IFRS, still allowed under US GAAP
4. **Standard Cost** — a fixed predetermined cost, with variances tracked separately
5. **Specific Identification** — used for unique/serialized items (cars, real estate, custom jewelry)

Your example uses averaging, so let's start there — and fix the one part of your formula that isn't quite right.

---

## 2. Weighted Average Cost — the correct formula

Your proposed formula was:

> Average cost = Σ(buying prices) / number of warehouses

**This is incorrect for accounting purposes.** It ignores quantity. If Warehouse 1 has 100 units at $30 and Warehouse 3 has 400 units at $100, a simple average of $30 and $100 (=$65) misrepresents your actual cost — because you own far more of the expensive stock.

### The correct (quantity-weighted) formula:

```
WAC = Σ(Price_i × Qty_i) / Σ(Qty_i)
```

This is true whether you're averaging across warehouses, across purchase batches, or across time.

---

## 3. Two architectural choices: per-warehouse cost vs. global cost

Before applying the formula, the system must decide **at what level cost is tracked**. This is a real design decision in every inventory system:

### Option A — Per-warehouse (per-location) costing
Each warehouse keeps its **own** independent average cost, updated only by purchases/receipts *into that warehouse*. A purchase in Warehouse 1 does NOT affect Warehouse 3's cost.

- Used when: warehouses are separate legal entities, separate cost centers, or goods are bought locally at different prices (imports vs local, different suppliers per region).
- Transferring stock between warehouses requires a transfer cost/journal entry (often at the sending warehouse's current average cost).

### Option B — Global (company-wide) costing
All warehouses share **one single** average cost for the product. A purchase into any warehouse recalculates the same global average.

- Used when: warehouses are just physical storage locations for the same legal inventory pool.
- Simpler, but less accurate if buying prices genuinely differ by region (e.g., import duties).

**Most modern ERPs default to Option B (global) unless you explicitly enable multi-location costing.**

---

## 4. Applying it to your example

Let's use your numbers, assuming (correcting the likely typo) three *different* warehouses:

| Warehouse | Buying Price | Quantity |
|-----------|-------------|----------|
| 1 | $30 | 100 |
| 2 | $50 | 300 |
| 3 | $100 | 400 |

### Case A — Global weighted average (Option B)

```
WAC = (30×100 + 50×300 + 100×400) / (100+300+400)
    = (3,000 + 15,000 + 40,000) / 800
    = 58,000 / 800
    = $72.50 per unit
```

This $72.50 is the single cost used for **any** sale from **any** warehouse, and total inventory value = 800 × $72.50 = $58,000 (which naturally equals the sum of what you actually paid — this is the whole point of weighted averaging: it always reconciles to real cash spent).

### Case B — Per-warehouse average (Option A)

Each warehouse's average cost is **just its own price**, because in your example each warehouse only received one purchase so far:

- Warehouse 1 avg cost = $30 (100 units)
- Warehouse 2 avg cost = $50 (300 units)
- Warehouse 3 avg cost = $100 (400 units)

There is no "dividing quantity into price" step — a warehouse's average cost only becomes a blend once it receives a **second** purchase at a **different** price. That's the next section.

---

## 5. What happens after a new Purchase Bill (the moving average update)

This is the actual formula your system runs every time stock is received. It's the same formula whether at warehouse-level or global-level — just plug in the right existing quantity/cost.

```
New Avg Cost = (Existing Qty × Existing Avg Cost + New Qty × New Purchase Price)
               ─────────────────────────────────────────────────────────────────
                          (Existing Qty + New Qty)

New Total Qty = Existing Qty + New Qty
```

### Worked example
Say Warehouse 1 (100 units @ $30) receives a new purchase bill: **50 units @ $40**.

```
New Avg Cost = (100×30 + 50×40) / (100+50)
             = (3,000 + 2,000) / 150
             = 5,000 / 150
             = $33.33
New Qty = 150
```

**Important cases within "purchase bill" handling:**

| Case | Effect on Average Cost |
|---|---|
| Purchase at a price **higher** than current avg | Avg cost rises |
| Purchase at a price **lower** than current avg | Avg cost falls |
| Purchase includes **landed costs** (freight, customs, insurance) | These are added into the "purchase value" numerator before dividing — i.e., true unit cost = (invoice price + allocated landed cost) per unit |
| Purchase has a **discount** | Net price after discount is what's used, not list price |
| Purchase **return** (vendor credit) | Treated as a *negative* purchase — quantity and value both subtract out at the *cost they were received at*, not current avg (this can cause small rounding drift, which systems usually absorb into a cost-adjustment account) |

---

## 6. What happens on a Sales Invoice (COGS calculation)

This is the part with the most common misconception, so let's be precise:

> **A sale never changes the average cost.** It only consumes it.

The average cost is only ever recalculated on **purchases/receipts**, never on sales. A sale just does two independent things:

```
COGS = Qty Sold × Average Cost (at the moment of sale)
Revenue = Qty Sold × Selling Price
```

These are two completely separate numbers that only meet on the P&L (Revenue − COGS = Gross Profit). They are **not** derived from each other.

### Taxed vs. non-taxed invoices — the key rule

**Sales tax / VAT charged to the customer is never part of COGS.** It's a liability (money you collect and owe to the government), not a cost or revenue item.

```
Invoice Total = (Qty × Selling Price) + Tax
Revenue booked = Qty × Selling Price      (tax excluded)
Tax Payable    = Qty × Selling Price × Tax Rate
COGS           = Qty × Average Cost       (completely unaffected by tax)
```

So whether the invoice is taxed or not, **COGS is calculated identically** — tax only affects what's on the *revenue* side of the ledger, never the cost side.

**The one exception:** if the tax paid on the *original purchase* was **non-recoverable** (some jurisdictions, some VAT schemes, or purchases from non-registered suppliers), then that non-recoverable input tax gets *added into the unit cost* at the purchase stage — meaning it flows into the average cost calculation in Section 5, not the sale calculation. Once it's baked into average cost, sales treat it the same as any other cost — no special handling needed at sale time.

### FIFO/LIFO variant (if that's the method instead of WAC)

Under FIFO/LIFO there's no single "average" — instead the system tracks cost **layers** (batches) and consumes them in order:

```
COGS = Σ (Qty taken from each layer × that layer's cost)
```

Example — FIFO sale of 350 units from Warehouse 3 layers: [200 units @ $95], [200 units @ $100]:
```
Take 200 @ $95 = $19,000
Take 150 @ $100 = $15,000
COGS = $34,000  (remaining layer: 50 units @ $100)
```

---

## 7. Negative inventory (selling more than you have)

This happens when a sale is invoiced before the corresponding stock/purchase is recorded (backorders, system lag, or intentionally allowing oversell). There is no universally "correct" accounting answer here — different systems handle it differently, but the standard approaches are:

### Approach 1 — Value at last known average cost (most common)
```
COGS (for the negative portion) = Qty × Last Known Avg Cost
```
The system lets quantity go negative, and values it using whatever the average cost was *before* it went negative. Inventory value on the balance sheet also goes negative temporarily — which is a red flag your accountant should be aware of, but it lets operations keep moving.

### Approach 2 — Retroactive correction on next purchase
When the next purchase bill arrives and brings quantity back to zero/positive, some systems **recalculate backward**: they revalue the negative-stock sale using the cost of the purchase that just arrived, and post a correcting journal entry (a "cost of goods sold adjustment") to fix the earlier COGS entry.

```
Corrected COGS = (units originally oversold) × (new purchase's actual cost)
Adjustment = Corrected COGS − Originally Posted COGS
```

### Approach 3 — Block it
Some systems simply refuse to post a sale that would take stock negative (strict lot/serial tracking, strict WAC/FIFO systems). This avoids the valuation problem entirely by preventing the situation.

**Practical note:** negative inventory is a known weak point in almost every ERP's costing engine — WAC and FIFO systems especially can produce cost distortions that need periodic manual reconciliation if negative stock is allowed to happen often.

---

## 8. Quick reference — all formulas in one place

| Event | Formula |
|---|---|
| Weighted avg cost (initial, multiple sources) | `Σ(Price_i × Qty_i) / Σ(Qty_i)` |
| New avg cost after purchase | `(OldQty×OldAvgCost + NewQty×NewPrice) / (OldQty+NewQty)` |
| COGS on sale (WAC method) | `QtySold × CurrentAvgCost` |
| COGS on sale (FIFO/LIFO) | `Σ (Qty from each layer × that layer's cost)` |
| Revenue (excl. tax) | `QtySold × SellingPrice` |
| Tax payable | `QtySold × SellingPrice × TaxRate` |
| Negative inventory COGS | `QtySold × LastKnownAvgCost` (then optionally corrected on next purchase) |
| Gross Profit | `Revenue − COGS` |