Most of us learned purchasing the same way. You agree a price with the vendor, you create the purchase order, you receive the goods, you match the invoice. Done. The price flows downstream: purchase price plus cost plus margin equals sales price.
Now flip it.
What if you don’t know the purchase price when you receive the goods? What if the deal with the vendor is: “We’ll pay you what the market pays us, minus our costs. We’ll settle when it’s sold.”
That’s top-down pricing. Some people call it netback pricing. The sales price is the foundation, and the purchase price is what’s left after you walk back down the stairs.
Sounds easy? It is. Until you try to put it in an ERP system.
A punnet of strawberries to explain it
Picture a modern greenhouse. Glass, LED lights, berries on hanging gutters, harvest almost every day of the year. The grower is brilliant at growing strawberries. Selling them to hundreds of stores is a different job, so the grower delivers to a packing and marketing company.
Nobody knows next week’s strawberry price. It depends on the weather, on imports, on whether the big chains run a campaign. So the deal is simple: the packer grades, packs, sells and distributes the berries, and pays the grower what the berries actually fetched, minus the packer’s costs.
And strawberries are not one product. They come in sizes, and size drives price. Large berries go in premium punnets. Medium and small go in standard punnets. Class 2 (odd shapes, small marks) goes to discount packs. The soft ones go to the jam kitchen. Some go in the bin.
Here’s one delivery with made-up numbers. The grower delivers 10,000 kg. After grading:
| Grade | Kg | Price per kg | Sales value |
| Class 1 large | 3,500 | 6.00 | 21,000 |
| Class 1 medium (150 kg lost, 2,850 sold) | 3,000 | 4.50 | 12,825 |
| Class 1 small | 1,000 | 3.20 | 3,200 |
| Class 2 | 1,200 | 2.40 | 2,880 |
| To jam (1,000 kg berries become 1,800 kg jam) | 1,000 | 3.00 per kg jam | 5,400 |
| Waste at grading | 300 | 0.00 | 0 |
| Total | 10,000 | 45,305 |
Then the packer walks back down the stairs:
| Line | Amount |
| Sales value | 45,305 |
| Transport greenhouse to packhouse (0.15 per kg delivered) | −1,500 |
| Grading and packing (0.60 per kg packed fresh) | −5,220 |
| Terminal and cross-docking (0.20 per kg packed fresh) | −1,740 |
| Distribution to stores (0.35 per kg sold fresh) | −2,993 |
| Jam making, sugar and jars (1.80 per kg jam) | −3,240 |
| Packer’s marketing fee (8 % of sales) | −3,624 |
| Netback to the grower | 26,988 |
| Price per kg delivered | 2.70 |
The grower got an advance of 1.50 per kg on delivery (15,000 in total). So the final settlement is a payment of 11,988.
That’s the whole idea in two tables. Now let’s make it messy, because real life is messy.
Why it gets complicated
The berries don’t stay berries. You buy item A (strawberries, ungraded) and you sell item B, C, D and a jar of jam. Grading is a transformation with a yield, and the yield is never exactly what you planned. Was the 300 kg of waste caused by the grower or by rough handling at the packhouse? Someone will ask. Probably loudly.
Size is a price, not a detail. If five percent of the berries come out medium instead of large, the grower loses roughly 700. That’s more than the whole missed-truck loss below. The grower controls size (climate, light, plant care). The packer controls grading accuracy. Both will have an opinion.
Time is very much not your friend. A fresh strawberry has a shelf life of a few days. Notice those 150 kg of medium berries that were lost? They missed a truck, sat too long at the cross-dock and had to be dumped. Meanwhile the jam keeps for a year and sells slowly. So one delivery settles in two speeds: the fresh part within a week, the jam part over months.
Costs come late. Freight invoices and store claims arrive weeks after the sales invoice. And batches get mixed: one grading line, several growers, forty stores.
And accounting wants a stock value from day one. “We don’t know yet” is not an inventory valuation method.
The real question: who takes the risk?
Before you open D365, sit down with the business and agree who carries what. The system can calculate any model. It cannot decide what’s fair.
I usually present three options.
Pure netback. The grower gets exactly what the sale produced, minus actual costs. The packer is basically an agent. Simple, but the grower carries everything, including the packer’s missed truck. That’s the 26,988 above. Growers don’t love this for long.
Netback with norms. The grower carries the market price and the size mix. The packer carries what the packer controls: grading waste above an agreed norm, internal delays, damage in handling. In our example the agreement says berries lost to internal delay are credited at the price their size achieved. That adds 675 (150 kg × 4.50), so the netback becomes 27,663, or 2.77 per kg. This is the one I recommend in most cases, because it puts each risk where someone can actually influence it.
Shared risk. Deviations split 50/50, maybe with a floor price and a cap. Harder to explain.
Whatever you pick, write it down. Then make sure every write-off in the system has a reason code. “Missed transport” and “grower quality” lead to very different settlements, and you don’t want to argue about it from memory three weeks later.
So how do you build this in D365?
Here’s the good news. Most of it is standard. The trick is to stop thinking “special purchase process” and start thinking “normal purchase process with a price we don’t know yet”.
Take ownership at receipt. You need to grade, pack, sell and trace the berries freely. Vendor consignment sounds tempting, but if I’ve understood it right, ownership has to change before the goods can be consumed in production. So it doesn’t solve anything here. Own the goods, and keep the price open.
Receive at an estimated price. Create a normal purchase order with an estimated price (a trade agreement works fine). The product receipt posts against accrued purchases at that estimate. Inventory has a sensible value from day one.
Pay an advance if the deal says so. Purchase order prepayment is standard. Post the advance, and it gets applied when the final invoice comes in. No advance? Skip the step. Same flow, one step shorter.
Let batch numbers do the heavy lifting. One batch per grower, greenhouse and picking day. Grading is a batch order: ungraded berries in, each size and class out as co-products, jam berries and waste as by-products. Now item tracing can follow the grower’s batch all the way to the sales invoice lines. You need that tracing for food safety and recalls anyway. Here it does double duty.
Build one small engine. This is the only real extension. A netback agreement per vendor holds the deduction rates, norms, advance %, cut-off days and risk model. A batch job traces each raw-material batch forward, allocates sales value back by consumed quantity, applies the deductions and calculates a price per kg received. It runs daily as an estimate, and becomes final when the batch is sold or hits its cut-off date.
Let the engine create the vendor invoice. The final price lands as a pending vendor invoice on the original purchase order line, through your normal approval workflow. The advance is applied. The grower gets a settlement statement (Electronic Reporting does this nicely) showing the trace from sales to their batch, size by size. Transparency builds trust. Opaque spreadsheets do not.
Let inventory close do the boring part. The difference between the estimated and final price flows through inventory close to the packed goods and to cost of goods sold. If you run standard cost, it lands in purchase price variance instead. Either way, you didn’t write a line of code for it.
If you already use Unified pricing with price components on the sales side, there’s a bonus. Your delivered store price is built bottom-up from components like distribution, terminal handling and transport. The netback engine can walk the same staircase top-down, using the same components. One pricing logic, both directions. That’s the elegant bit. I’m challenging Microsoft and the GUP team allow for a price tree to do Top-down, instead of Bottom up. (Not a easy task )
A few things to decide up front
Cut-off. Nothing stays unsold forever. For fresh berries that’s days, for jam it’s months. Decide when the packer buys out the remaining stock at a reference price, and stop the clock.
Late claims. A store complains after settlement. Agree a claim window and correct it in the next settlement, not by reopening the old one.
Legal. Producer organisations and first-hand sales can have their own rules. Check before you build a beautiful engine nobody is allowed to use.
Honest limits
This is not out-of-the-box. The agreement, the engine and a settlement workspace are an extension. Not huge, but real work, touching purchasing, production, sales and finance at once. The tracing logic gets tricky when batches split and merge several times. Test with ugly data, not happy-path data.
And no system will fix a vague agreement. If the business can’t explain the risk model on a whiteboard, D365 won’t explain it either.
But once it’s in place, something nice happens. The grower sees why they got the price they got. Finance sees a stock value that makes sense. And the person who used to run the settlement in a 47-tab spreadsheet gets their Friday afternoons back. Maybe with strawberries.
PS: AI helped me structure and polish this post, but the ideas, the opinions and any mistakes are mine.