Two numbers describe the same bar of steel, and they almost never agree. There is the theoretical weight, worked out from the section and the length. And there is the actual weight, what the bar reads on the scales. Both are real. Both end up on paperwork. The gap between them is where a stockholder's margin quietly leaks away.
This is catch-weight. Any trade that buys and sells by weight but handles discrete physical items lives with it. In steel stockholding it is not an edge case. It is every line on every order. Yet most inventory software treats weight as a single figure per stock line, which means the moment you sell steel, the software is already wrong.
This is the plain-English version of what catch-weight invoicing actually involves, and what a system has to do to get it right.
Why one weight is never enough
A length of bar has a theoretical weight the mill's own tables will tell you: so many kilograms per metre, times the length. It is a clean calculation and it is useful. It is also not what the customer receives.
Real steel varies. Rolling tolerances, mill finish, cut ends, rust and scale all move the actual weight off the theoretical figure. On a single bar the difference is small. Across a wagon load, across a month, across a year, it adds up to a number worth caring about.
So a stockholder carries both weights on purpose. The theoretical weight lets you plan, price and quote before anything is on the scales. The actual weight is what you paid for at goods-in and what you should be paid for at despatch. A system that holds only one of them forces you to choose which truth to lose.
Which weight do you invoice on?
There is no single right answer, and that is the point. The correct basis depends on the material, the customer and the deal.
Some material is sold on theoretical weight by convention, so the customer is billed on the calculated figure regardless of what the scales say. Some is sold on actual weight, so you weigh it and bill exactly that. A given customer might take one grade on theoretical and another on actual. The invoice has to follow the agreement, not a system default.
This is where generic software falls down. It holds one quantity per line, so it can invoice on one basis only, and usually the wrong one. Then the office keeps the real weights in a spreadsheet next to the system and reconciles by hand. Every order is keyed twice. The two records drift apart the first time someone is busy, and you find the divergence at the worst possible moment: a customer weight query, a credit note, an audit.
In MetlSys the choice is built in. Every batch carries a theoretical and an actual weight. Prices work per kilogram, per metre, per each or as a lump sum. Invoices raise from the delivery note on either weight basis, so the same order can bill one customer on theoretical and another on actual without a side spreadsheet keeping score.
The rule that saves the most money: unweighed stock cannot be sold
Here is the failure that costs stockholders the most, and it happens before the invoice is ever raised.
Steel arrives on a delivery note carrying a theoretical weight. The actual weight arrives later, when someone puts the material on the scales. In most systems there is nothing between those two moments. The stock exists, so it can be allocated, sold and despatched on a number nobody has confirmed. When the real weight finally lands, it does not match, and now you are issuing a credit note or swallowing the difference.
The fix is a two-stage receipt. Book the material in from the paperwork so it is visible and traceable straight away. But hold it as awaiting-weight and unsellable until someone confirms the actual weight on the scales. The stock is on the system. It just cannot leave on a guess.
That is exactly how goods-in works in MetlSys. Material books in from the delivery note, sits as awaiting-weight, and cannot be sold until the actual weight is confirmed. It is a boring rule. It removes a whole category of weight variance, margin leak and awkward credit note before it can start.
Variance: catch the outliers, ignore the noise
If you are carrying two weights on every batch, you are also generating a variance on every batch. Most of that variance is noise. A fraction of a percent either way is just steel being steel, and flagging it would train everyone to ignore the flag.
What you want is to catch the outliers. A batch that reads several percent under its theoretical weight is telling you something: a short delivery, a mis-measure, a data entry slip, or material that is not what the paperwork claims. That is worth a human decision before it reaches an invoice.
MetlSys draws the line at two percent. Variance within band passes quietly. Variance over two percent is flagged for review, so a person looks at the exception rather than every line. You get the control without the noise.
Closing the loop: despatch, proof, invoice
Catch-weight does not end when the invoice basis is chosen. The weight has to be captured cleanly at the point the material leaves, and the invoice has to follow the delivery without a week's delay.
At despatch, the scales record gross, tare and net against the load, so the actual weight going out is measured, not assumed. The delivery note, consignment label and certificate pack generate together. Then the driver or the customer signs on their phone through a single-use electronic proof of delivery link, capturing the signature on glass along with any exceptions.
A clean proof of delivery can raise the invoice automatically, on whichever weight basis the order specified. You can also raise invoices singly or in bulk if you would rather. The effect is the same: the invoice goes out the same day the signed proof comes back, not at month end when someone finally notices the paperwork returned. On thirty-day terms, every day between delivery and invoice is a day added to your debtor book for nothing. Cash flow in this trade is often not a finance problem. It is a paperwork-latency problem.
When the invoice does raise, the full allocation chain stays intact behind it, and posting runs export cleanly to Xero, Sage and QuickBooks. Credit notes for partials and returns work from the same thread rather than as a fresh guess.
What good catch-weight handling looks like
Put together, correct catch-weight invoicing is not one feature. It is a chain of small correct decisions: carry both weights on every batch, price in whatever unit the deal uses, refuse to sell what has not been weighed, flag only the variances that matter, measure the real weight at despatch, and let the signed proof of delivery raise the invoice on the agreed basis.
Miss any link and the office rebuilds it by hand in a spreadsheet, and the margin leaks through the gap. You can see how the weighing, despatch and invoicing steps join up on the features page.
See it on your own numbers
If your team keeps a shadow spreadsheet of real weights beside the system, or issues credit notes because stock got sold before it was weighed, the fix is not more discipline. It is software that treats theoretical and actual weight as two facts about the same steel, from goods-in to the signed proof of delivery.
Bring a real example: a batch with a weight variance, a customer you bill on theoretical, a delivery that went out before it was weighed. Request a demo and we will run it through in front of you.