When Does a Unit's Cost Stop Changing?
A January purchase order gets received at the PO price. The invoice comes in February and it’s $10 a unit higher. In SKU.io, out of the box, that $10 is booked in February. January doesn’t move.
That is not how I keep my own books. On a call on August 31st I said it plainly: “Always restate past unless it’s triggering an accounting lock date.” If the stock cost $10 more, then whatever I sold in January was costed $10 low and whatever was left on the shelf was valued $10 low, and I want January’s report to say so. The default we shipped does the opposite, and I’m the one who chose it.
The call was a go-live check with a brand about to move its inventory onto us. Their outside accountant was on it, so I used the time. I described the January PO and the February invoice and asked him whether January should change, whether it should show up in February, or whether he’d want the choice.
“I want the choice,” he said. It goes in at what they ordered it at, the invoice comes in $10 off, and “if any of those items sold, you’re going to want to update those cogs.”
I told him I’d always wanted to change the past in my business, but I’d had customers complain about exactly that. Why is my January inventory valuation changing? He got there before I finished: “How did my COGS go up and why did my inventory?”
Then he told me my example didn’t fit them. They prepay their vendors, so they know what the goods cost when they ship. The bill that shows up after the fact is the shipping one. I said that was the second case I’d been thinking about, because freight goes into the cost of the units too, and he agreed it should: “You want the actual landed cost in there to increase the inventory value, increase the cost of goods.”
So the one brand on the call needed restating for a bill I hadn’t led with, and didn’t care about the one I had. That’s most of why the choice is set per kind of bill and not with one switch.
The default still had to be one of them. I picked carry forward because restating rewrites a month someone may already have handed to a bank or a partner, and the person it surprises is usually not the one who set the software up. Carrying forward is less accurate for January. It also doesn’t move anything anybody has already looked at.
We built a third option first and pulled it before it shipped. Every late cost would sit in a queue until a person decided which month it belonged to. It sounded like the careful one. What it did was keep every landed cost off the stock until somebody got to the queue, so the cost on the shelf was wrong in a different way, and for longer.
The part I got wrong on the call was the word “open.” I’d suggested restating only while the month is still open and then couldn’t say what open meant. Is January closed on February 1st, or when you set the lock date? He said the lock date. We didn’t do that. In what shipped, closing a month and locking it are separate steps, and a month that’s been closed counts as not open even if it isn’t locked yet. So for a team that closes every month on the 5th, any freight bill for last month’s stock that turns up after the 5th carries forward, even with restate-only-while-open switched on. A person can still go in and restate a closed month by hand. Nobody can restate behind the lock without lifting it first.
I’m not sure that’s the line he’d draw. I’d rather a setting that runs unattended be cautious and the person sitting in front of it be able to override.
His last question on it was whether the change would carry the original order number so he could find it later. It does. Each change is its own dated entry against the PO it came from, and it notes whether a rule or a person decided the month.
A bought unit’s cost can move after the fact. A built one has a different problem: two units of the same SKU can use different parts and cost different amounts.
If you have a February bill for January stock, book a demo and bring it.