A workshop run produces one table and six stools. The invoice for the run says $910. There is no SKU for "table from this run" and no recipe that says a stool always costs a sixth of a table — there is just a total, and seven pieces that came out of it. COGS per batch is the answer to one question: what did each of those seven pieces actually cost, given what the whole run cost?
The short version
A batch's real cost is what you paid the workshop plus whatever else was spent getting that run made — freight, hardware, finishing — counted once each, not twice. Splitting that total evenly across the pieces it produced is the easy mistake; splitting it in proportion to what each piece was already estimated to cost is the one that survives contact with a table and six stools in the same run.
What COGS per batch means when nothing is a SKU
Cost of goods sold, in a shop that holds stock, is a lookup: this product has a cost, it sold, book the cost. Made-to-order production doesn't give you that lookup, because the thing that has a cost isn't the product — it's the run. Two orders for what looks like the same chair can come out of two different batches, at two different actual costs, because materials moved, the workshop's fee moved, or the run was a different size.
So COGS per batch works one level up. You don't cost the chair; you cost the run that produced the chair, then divide that cost across whatever the run produced. The chair's cost of goods sold is its share of the batch, not a number sitting permanently on a catalogue page.
This is the step before the one most pricing conversations start at. Quoted price vs. actual cost is about whether the number you quoted survived contact with reality. This article is about getting that "reality" number right in the first place — what the run cost, and what one piece of it cost — before you ever compare it to a quote.
What belongs in a batch's cost, and the one line that gets counted twice
Three things belong in what a run actually cost, and the first two are obvious:
- What you paid the workshop or contractor. Usually in two instalments — something before the run starts, something on completion — and both are real production cost, not overhead.
- Everything else spent getting that specific run made. Freight to get the pieces to you, hardware, finishing, anything bought because of this run rather than in general.
The third thing is a rule, not an expense: don't count the workshop payments twice. It's an easy trap because of how these numbers usually get recorded. The two workshop instalments are naturally the two most important lines to see when you're looking at a run — so it's common for them to also get logged as ordinary expenses tagged to that run, purely so they show up in an expenses view alongside the freight and the hardware. That's fine for visibility. It's a real problem the moment you total "everything tagged to this run" and then separately add "what I paid the workshop" — because now the workshop fee is in your total twice, and the batch looks like it cost more than it did.
The fix isn't remembering not to double-count by eye. It's marking those two specific rows, at the point they're created, as the payment itself rather than an extra cost layered on top of it — so a total can exclude them by that mark, every time, without anyone having to recognise a workshop invoice by its wording. Get this one rule wrong and every other number downstream — the per-piece cost, the margin, the next quote — inherits the error before you've even started dividing anything.
Why flat per-unit is the wrong split
Once you have a clean total — payments plus extras, counted once — the obvious next move is total ÷ number of pieces. It's the calculation almost everyone reaches for first, and it is wrong for the same reason a batch is worth costing separately in the first place: a run of genuinely different pieces did not put an equal amount of materials, time and workshop attention into each one.
A run of one table and six stools is the clearest version of this. A flat split says the table and a stool cost the same to make. Nobody who has built either believes that for a second, but the flat number is what you get if you don't weight the split by anything — it treats "seven pieces" as seven equal claims on the total, when what you actually have is one large piece and six small ones sharing a bill.
There is a second way the denominator goes wrong, and it has nothing to do with weighting: dividing by what went into the run rather than by what came out of it whole. A kiln run in a ceramics studio is the plainest case — the pieces that cracked are still on the invoice — but any run with a reject rate has it, and a costing that counts them as delivered pieces is quietly understating every one that was.
What to weight by instead
The fix doesn't require inventing a new costing system. You already have an estimate on every line in the run — the cost each piece was expected to carry before the run happened, usually seeded from whatever that product normally costs. Split the actual total in proportion to those estimates instead of evenly, and the ratio between a table and a stool survives; only the level moves, up or down, by however much the run as a whole came in over or under what was expected.
There's one edge case worth naming: if every line in a run happened to have no estimate at all — nothing to weight by — there is nothing left to do except split flat, as a fallback rather than a decision. It's the same arithmetic either way; the difference is that flat becomes the deliberate exception instead of the default.
Two ways to be wrong on the same run
Flat splitting doesn't produce one wrong number, it produces two: the cheap piece looks too expensive, and the expensive piece looks too cheap. On a run of similar items the error is small. On a run of a table and six stools, it's large enough to break the next quote in both directions at once — see the numbers below.
A worked example: one table, six stools, $910
The run: one table and six stools, from the same workshop invoice. The workshop was paid $500 before the run and $360 on completion — $860 in payments. Freight and hardware for the run added $50, tagged to the batch as ordinary expenses. Total actual cost of the run: $910. Nothing here double-counts the $860, because the $50 is genuinely separate spend, not a second copy of the workshop fee.
The table's line was estimated at $340. Each stool's line was estimated at $60. Seven pieces in total, so the flat split is $910 ÷ 7 = $130.00 per piece, table and stool alike.
The weighted split works from the estimates instead. The basis is $340 (one table) plus $360 (six stools at $60) = $700 in estimated cost. The run actually cost $910 against $700 estimated, a scale of 910 ÷ 700 = 1.3 — the run came in 30% over what the estimates said. Apply that same 1.3 to each line: the table's actual cost is $340 × 1.3 = $442.00, and each stool's actual cost is $60 × 1.3 = $78.00. Check it against the total: $442 plus six stools at $78 is $442 + $468 = $910 — every cent of the run accounted for, none of it double-counted, none of it assumed equal.
| Table (1 piece) | Stool (6 pieces, per piece) | |
|---|---|---|
| Estimate on the line (the weight) | $340 | $60 |
| Flat share of $910 (910 ÷ 7) | $130.00 | $130.00 |
| Weighted share of $910 (estimate × 1.3) | $442.00 | $78.00 |
| Next quote at 2.2x, priced off the flat number | $286.00 | $286.00 |
| Next quote at 2.2x, priced off the weighted number | $972.40 | $171.60 |
What each split does to the next stool you quote
The flat number and the weighted number aren't just academically different — they price the next order differently, in opposite directions. Say you quote at a 2.2x markup on cost, the middle of the range most furniture makers land in.
Off the flat $130.00, the next stool gets quoted at $130.00 × 2.2 = $286.00. Off the weighted $78.00, it gets quoted at $78.00 × 2.2 = $171.60. That's a $114.40 gap on a single stool, and it runs the wrong way for winning the order — you'd be quoting stools as if they cost nearly double what this run showed they actually cost, against every competitor pricing off a real number.
Run the same markup on the table and the flat number does the opposite kind of damage. Off the flat $130.00, the next table gets quoted at $286.00 — a table that this run just showed costs $442.00 to make. Off the weighted $442.00, it's quoted at $442.00 × 2.2 = $972.40. Quote the table at $286 and you are not pricing thin, you are pricing at a loss the moment materials or the workshop fee move at all. Flat splitting doesn't average out to something roughly fine — it overprices the small piece and underprices the large one, on the same run, every time.
See what one run actually cost, per piece, the moment it's marked received — not a flat average across everything in it.
See how it worksCarrying the number back onto the product
A per-piece figure that stays inside a spreadsheet for this one run is only half useful. The point of working it out is that the next order for a stool should be priced off what a stool actually cost last time, not off the estimate the product card has been carrying since it was first set up. That means writing the new figure back onto the product — and, where an open order for that product is still sitting at the old estimate, onto that order too.
Two things are worth being deliberate about when you do that. First, an order that has already been delivered is closed history — its margin already happened, and rewriting the cost on it after the fact changes a number nobody is going to look at again for the right reasons. Second, if someone already typed a different cost onto an open order by hand, that was a decision, and a batch write-back shouldn't silently overwrite a person's judgment call with an average. Only the lines still carrying the untouched estimate should move.
That is the shape Ordamo implements, and cost per batch and real margin per order walks one run through it with the figures on screen: the total, the split, what it writes onto the products, and which open orders move with it.
This is the mechanism the margin-gap article assumes exists when it talks about pricing the next quote from what the run actually cost rather than from a guess. Getting the batch total right, splitting it correctly, and carrying it back onto the product are the three steps that make that sentence true instead of aspirational.
This is one input into a bigger pricing job
A batch's actual cost is one number in a pricing formula that also has to account for labor beyond what the workshop invoice covers, overhead, and the markup you decide is fair. How to price a custom furniture piece when no two orders are the same covers the rest of that formula in detail. What this article gives you is the input that formula is usually weakest on: a real, per-piece actual cost from the run that just finished, instead of an estimate that was never checked against what happened.
What to give the accountant
Your accountant doesn't need the workshop's line-item invoice, the freight receipt and your estimates all handed over separately for them to reassemble. They need two things: what each batch actually cost in total, and how that total maps to the orders it produced — which, once you've done the split above, is the same thing as each delivered order's cost of goods sold.
Handed a batch total and a per-order mapping, an accountant can book cost of goods sold against revenue for delivered orders without reconstructing your production process from receipts. What you're actually handing them is a decision that's already been made — how the run's cost was split — not raw material for them to make it.
When COGM matters, and when it mostly doesn't here
Cost of goods manufactured is a period total: everything spent on production across a month or a quarter, regardless of which specific job any of it belonged to. It's the right number for a factory running a continuous line, where output isn't cleanly divided into discrete, separately-costed runs and finished goods sit in a warehouse waiting to be sold.
Made-to-order production is closer to the opposite shape. There usually is no standing production line and no shelf of finished goods between runs — there's a batch, it gets made, it gets sold, and the next batch is its own separate event with its own cost. COGS per batch already answers the question COGM exists for, at the level that's actually meaningful here: not "what did this month's production cost in aggregate," but "what did this run cost, and what does each piece from it need to sell for." Track it batch by batch and a monthly COGM figure, if you ever need one, is nothing more than adding up the batches that fell in that month.
Where inventory-costing tools stop
Most costing software built for makers is built around a recipe: a product has a fixed bill of materials, and cost is calculated by multiplying that recipe by whatever raw materials currently cost. That's the model Craftybase (now Stocksmith) is built on, and it's a good fit for a maker producing the same item the same way every time.
It's a poor fit for a run that mixes one table and six stools under a single invoice, because there is no single recipe to scale — there are several different line items sharing one actual bill, in proportions that only that specific run can tell you. The batch is the unit of cost here, not the recipe, and a per-batch split is what a recipe-based tool has no native way to express.
The bottom line
A batch's real cost is what you paid to have it made, counted once, not twice. Splitting that cost evenly across everything the run produced is the fast way to get it wrong on any run that isn't genuinely uniform. Splitting it in proportion to what each piece was already estimated to cost keeps the ratio between a table and a stool intact while correcting the level to what the run actually cost — and that corrected number is the one worth writing back onto the product, so the next quote starts from what happened last time instead of a guess nobody has checked in months.
One table and six stools from the same invoice do not cost the same to make, and a split that assumes they do gets both numbers wrong at once.
Cost a batch once, split it correctly, and carry the number onto every product it touched.
See how it worksFrequently asked questions
What does COGS per batch mean if I don't have SKUs or a bill of materials?
It means the same thing it means anywhere else — the cost of what you actually sold — worked out one level higher than the piece. You total what a production run cost, then split that total across the pieces the run produced. You never need a standing recipe for a product; you only need to know what this specific run cost and how many things came out of it.
Is COGS per batch the same as COGM?
No, and the difference matters less than it sounds. Cost of goods manufactured (COGM) is a period figure — everything spent on production in a month or a quarter, whether or not it shipped. COGS per batch is a run figure — what one specific production run cost, spread across the pieces it produced. For a business with no ongoing production line and no finished-goods stock sitting between runs, the batch figure is the useful one; COGM mostly answers a question made-to-order sellers don't have, which is what a whole factory floor cost this month regardless of which jobs it belonged to.
Do I include what I paid the workshop, or just materials?
Both, and that's usually most of the number. What you paid the workshop or contractor to actually build the run is a production cost the same way materials are. Freight to get pieces to you, hardware, finishing, anything bought specifically for that run belongs in the total too — it just needs adding once, not twice, which is the part people get wrong.
Why would the same cost get counted twice?
Because a workshop payment often gets logged in two places without anyone meaning it to: once as the payment itself, and again as a general expense tagged to the same run because someone (or some automation) recorded it that way for visibility. If you then total 'everything tagged to this batch' and separately add 'what I paid the workshop,' the workshop fee is now in the total twice. The fix is a flag on those two rows saying they are the payment, not an extra cost on top of it, so a total can exclude them by rule rather than by someone remembering which rows are which.
Why is splitting the batch cost evenly across every piece wrong?
Because an even split assumes every piece in the run cost the same to make, and that's rarely true. A run of one table and six stools does not put an equal share of materials, finishing time and workshop fee into a stool as it does into a table. An even split overprices the cheap pieces, underprices the expensive ones, and gets more wrong the further apart your line items are in size.
What should I weight the split by, if not evenly?
The estimate you already have on each line — the cost you expected that item to carry before the run happened. You're not inventing a new weighting scheme; you're using the number you already quoted from, scaled up or down by however much the whole run actually cost against what you expected it to cost. A table estimated at several times a stool's cost still carries several times the share of the actual total, it's just the level that gets corrected, not the ratio.
What do I actually hand my accountant at the end of the year?
One number per batch — what it actually cost — multiplied out to whatever each delivered order's share of it was, which is the same thing as that order's cost of goods sold. Your accountant doesn't need your estimates, your workshop's invoice line items, or your freight receipts individually; they need the total that batch cost and how it maps to the orders it produced. If you can produce that mapping, the rest is bookkeeping they already know how to do.