Cost of Goods Sold (COGS)
A primer on how COGS is implemented in Pakk
COGS and Stock Valuation
One of the biggest advantages of having your accounting, stock management, order management, and website all running on the same platform is that stock valuation is tightly woven into the system, allowing 'live' tracking of COGS in contrast to entering COGS journal entries at the end of an accounting period as is the norm in less integrated systems.
A Quick Recap on COGS
If you’re an accountant, or especially experienced in accounting for physical product businesses, you probably don’t need to read this paragraph. Otherwise, this serves as a quick refresher and clarifier.
COGS stands for 'Cost of Goods Sold'. When thinking about business expenses, we usually imagine the simple case of buying some printer paper, for example, and logging an expense for that paper, say £20, in our accounting system.
But when you buy a big chunk of stock with the intention of selling it, you don’t normally 'expense' it in the same way. The 'proper' or 'formal' way of working is expensing the stock gradually, as you sell it. Here are some very simple examples:
I buy 10 units of stock at £10 each and sell them all for £20 each. I should record income of £200 and COGS of £100.
As above, but I sell only half of them. I would log income of £100 and COGS of £50.
In these simplified examples, the value of the COGS entry was obvious. In real life, tracking COGS is tough. It requires being able to trace back from each sale you make to how much was paid for that stock. Short of a fully serialized inventory, this is mostly practically impossible, so there are a few different accounting methods that let us get close enough.
What is 'Live' COGS Tracking?
In simple terms, whenever you make a sale, an accounting entry is created logging the COGS corresponding to that sale.
This is in heavy contrast to common accounting systems which force you to enter periodic entries by manually calculating COGS roughly according to the following formula:
COGS = Beginning Inventory + Value of Purchases During Period - Ending Inventory
How does Pakk know the COGS Value of Each Item Sold?
This is where things get somewhat complex. The problem is that stock is often acquired at different prices at different points in time, and, again, unless you serialize your stock and know exactly how much was paid for each individual piece, there is going to be some 'mixing' going on. Take this hypothetical example:
I purchase 100 units of stock at £10 each. A month later, I purchase another 100 units, but this time prices have gone up and I am forced to pay £20 each. I now have 200 units, half have a value of £10, the other half a value of £20. The average value is of course £15.
Now suppose I sell one of these units. Presuming the stock is all mixed up and I don’t know exactly which unit I’m selling, how much COGS value should the system record?
£10? This assumes I’m selling from the first lot I purchased and would correspond to a technique referred to as FIFO (first in, first out).
£20? This assumes I’m selling from the second lot I purchased and would correspond to LIFO (last in, first out).
£15? This would just be using the average value.
All techniques are valid, and there are others. Which does Pakk use?
Actually, it’s not exactly any of the above, although it is a variant of the third approach. All stock in Pakk goes through the batch system. No stock is held outside of batches. This means that given the situation described above, the system would be tracking the two batches separately and would know from which batch any sale was made. This means that it could correctly ascribe either £10 or £20 to COGS.
The situation is only really complicated if the merchant chooses to receive stock into an existing batch at a price that is different to the average unit value that already exists on the batch. Imagine the above scenario but instead of keeping the £20 value purchased lot in a separate batch on the system it was mixed with the £10 value lot. In this case, the system does need to take the average.
Therefore, our approach is hybrid and could be described as ‘batch-based average COGS`.
If you read and understand the above, you’ll have understood 90% of how the COGS system works. Everything that follows dives a bit deeper and is mainly aimed at accountants, consultants, or tenants who really want to understand how things work under the hood.
How is Batch Value Maintained?
Every batch of stock on the system has a corresponding value which is maintained constantly by the system, along with the actual stock levels like on hand, available, and committed. The average unit value is simply calculated from these numbers. For example, if a batch has 100 units and a total value of £100, the average unit value is £1.
Stock can be added to or deducted from the system via the following transactions:
Purchase Orders: the value of the incoming stock is taken from the purchase price on the order.
Stock Adjustments: the value is specified manually on each line of the adjustment (although the admin panel defaults to the average unit value of the selected lot).
Returns: the value is referenced from the average unit value on the batch to which the return is sent, the value is locked in at the point where that batch is chosen.
Sales Orders: the average unit value is locked in as soon as a batch is committed, the COGS entry in the journal is on the billing date (invoice or cash sale). This means that COGS lines up perfectly with revenue recognition. Note that this implies that COGS is not actually affected until an order is billed - the 'S' is COGS is important here: it is the 'Cost of Goods Sold' where sold specifically means 'on a billed Sales Order'. Unbilled Sales Orders don't count. It's also worth taking into account that COGS won't be impacted until the order line is committed - uncommitted lines, even on a billed Sales Order, won't appear in COGS yet.
Supplier Credits: if a lot is chosen, the system considers that the stock has been lost/broken/returned - the valuation is at the amount credited by the supplier.
Stock Valuation in Multiple Currencies
Things get a bit more complex when multiple currencies are involved, which can happen if you purchase an item in different currencies and receive them into a batch that already has stock valued in a different currency. Rather than applying exchange rates, Pakk maintains the value in each currency. Here’s a worked example:
I buy 100 widgets at £1 each = £100.
I buy another 100 widgets at $2 each = $200.
I now have 200 widgets.
The average value is £0.50 AND $1.
Note that the different currency values are not converted equivalents - they are to be summed to understand the average value of each unit.
How are COGS and Stock Levels Actually Implemented?
Sales Orders
When selecting a batch on an order line (i.e., committing the stock), the current average unit value is referenced from the batch and stamped on the line. As long as no change is made to the line (item/batch/quantity), the stamped COGS will remain the same, irrespective of when the order is billed or dispatched. In other words, the stock value of each line is locked in at the point of commitment. This is significant because it means that the stock value is recorded at the time of commitment rather than either time of billing or time of dispatch. Why is this correct? Because batch value can, and often does, change between when stock is committed and when stock is billed or dispatched (for example, new Purchase Orders could be received into the batch in the interim period).
A pair of balancing journal entry lines are created on the transaction journal entry in the amount of the total COGS value from the order lines - i.e., the total value of the committed stock on the order.
The first entry line INCREASES the value of the default ‘Stock Committed Not Dispatched’ account.
The second entry line INCREASES the value of the default COGS account.
The date of these journal entries is the billing date of the order - if the order is unbilled, these entries are not made.
When stock is dispatched, the impact is transferred from the 'Stock Committed Not Dispatched' account to the main Stock account.
Stock Adjustments
When you enter a stock adjustment, you also need to enter a value for each line.
This value can be in a single, or multiple currencies.
The system will initialise the input with the current value drawn from the selected batch, but you can override it if you need to.
Once entered, that value will not change, even if the value of the underlying batch does change.
A pair of balancing journal entry lines are created on the transaction journal entry in the amount of the total COGS value from the stock adjustment lines.
The first entry line INCREASES the value of the default Stock Asset account (assuming a positive stock adjustment).
The second entry line DECREASES the value of the chosen ‘Allocation Account’ (essentially, explaining the ‘reason’ for the adjustment, e.g., ‘Broken In the Warehouse’).
The date of these journal entries is the Stock Adjustment date.
In parallel, the actual impact on the system stock happens immediately.
Returns
When entering a return, you choose a batch for each line. The returned stock will be returned to this batch unless it is ‘discarded’.
When selecting a batch on a return line, the current average unit value is referenced from the batch and stamped on the line. As long as no change is made to the line (item/batch/quantity), the stamped COGS will remain the same, irrespective of when the order is received. A pair of balancing journal entry lines are created on the transaction journal entry in the amount of the total COGS value from the stock adjustment lines.
Accounts and stock are only actually impacted once the return is marked ‘received’.
The first entry line INCREASES the value of the default Stock Asset account.
The second entry line DECREASES the value of the default ‘Customer Returns’ expense account. This account is essentially a reverse-COGS account.
Discarded lines are accounted for separately in the default ‘Returns Discarded’ account, which is essentially a COGS account
The date of these journal entries is the Return date
In parallel, the actual impact on the system stock happens immediately
Purchase Orders and Supplier Credits
Both use the line value from the order/invoice.
Last updated