Metallurgical Accounting Software: Why Does the Mill Mass Balance Only Close a Month After the Metal Went Missing?

The month end balance is a post mortem, not a control

The mill superintendent opens the metal accounting workbook on the fifth of the month. Feed tonnes come off the weightometer totaliser. Feed grade comes from the composite sampler, assayed by the lab, and three of the daily assays are still outstanding because the fire assay queue backed up over the weekend. Concentrate tonnes come from the shipment weights, adjusted for a moisture result that arrived four days after the truck left. Tailings grade comes from the tails sampler, which everyone privately admits has been reading low since the launder was modified. The balance does not close. The gap goes into a row labelled unaccounted, which this month is 2.1 percent, and last month was 0.4 percent, and nobody can tell you why.

The problem is not the arithmetic. It is the delay. Whatever caused that 2.1 percent happened in the circuit five weeks ago, and the circuit has been through a grind size change, a reagent trial and two liner changes since. There is no experiment left to run. So the number gets accepted, the variance gets explained as sampling error in the monthly report, and the same conversation happens again on the fifth of next month.

What makes this expensive is who consumes the number downstream. Recovery drives your public production reporting. Concentrate grade and moisture drive offtake settlement with the smelter or trader, where a payable metal dispute is settled against assays and umpire results. Stockpile balances drive inventory on the balance sheet. A metal accounting system that produces a defensible number a day after the shift, rather than a month after the quarter, is the difference between a process control tool and a reporting chore.

What Metallurgical Intelligence and MineMarket actually leave you doing

Metallurgical Systems Metallurgical Intelligence is a serious product in this space and it does what the category name promises: a modelled plant with reconciled data on top. Where the reality bites is that the model has to be built for your flowsheet, and that build is a services engagement. Once it exists, changing it because you added a scavenger row or moved a sample point goes back through the same channel. Plants that modify circuits often find they are paying for a model that trails their actual plant by a few months.

Hexagon MineMarket comes at it from the other end. Its strength is the commercial side: stockpiles, shipments, quality tracking and sales, which is genuinely useful if your problem is bulk commodity marketing and contract management. It is not a plant balancing engine around your specific nodes and sampling points, and trying to make it one produces a lot of manual input at the very step where accuracy is decided.

Both share a limit that has nothing to do with software quality. Metal accounting is only as good as the measurement regime under it, and neither product can make your weightometer honest. What we are usually called in for is the join: the historian, the laboratory system and the belt scales each hold a piece, the pieces disagree, and no product ships knowing how your circuit resolves that disagreement.

What a custom build has to include

Start with the flowsheet as data, not as a picture. Nodes, streams and measurement points defined explicitly, so a balance is computed around real nodes rather than assembled by hand in columns. Every stream carries mass, moisture and assay by element, each with a source and a timestamp, and each measured value carries an assumed error. That last part is what makes the rest work.

Then reconciliation rather than subtraction. Around any node, mass in should equal mass out and metal in should equal metal out, and in practice neither does. The right treatment is a weighted reconciliation that adjusts each measured value within its own error bounds until the balance closes, weighting a well calibrated weightometer far more heavily than a tails sample everyone distrusts. The output is not just a closed balance, it is a set of adjustments, and the size of the adjustment on a given instrument is the most useful maintenance signal your metallurgy team will get all year. When the tails sampler needs three times its usual adjustment for a fortnight, the system has told you the launder modification broke the sample before anyone loses an argument about it.

Then the parts that make it match your plant rather than a textbook. Moisture handling with the actual delay between shipping a wet tonne and receiving the oven dry result, so the number that was reported yesterday can be restated cleanly when the result lands. Stockpile accounting that distinguishes surveyed volume from calculated balance and carries the difference as an explicit adjustment rather than absorbing it. Provisional versus final assays, with an audit trail of what changed when the lab reran a composite. In circuit inventory for mills, thickeners, leach tanks and load on the carbon or resin, which is the single largest source of apparent unaccounted metal in gold plants and is routinely ignored between surveys.

Then governance. Metal accounting numbers get audited and disputed, so every published figure needs to be reproducible: which measurements, which adjustments, which version of the flowsheet model, signed off by whom. The AMIRA P754 code of practice is the reference most operations align to, and building the sign off and lock down workflow to match it costs very little at design time and is nearly impossible to retrofit. Locked periods, restatement with reason codes, and no silent edits.

The integration work that decides whether it lives

Historian first, usually AVEVA PI or a Wonderware system, which gives tonnages, densities, flows and instrument health at high frequency. The trap is aggregation: a shift tonnage is not a simple sum when the belt ran empty for 40 minutes, and getting that right needs running status logic rather than a totaliser read.

Laboratory system second, LabWare or STARLIMS or in many plants a home grown database. The joins that matter are sample identity and sample time, not result time, because a composite assayed on Thursday describes Tuesday's feed and the balance must place it on Tuesday. Any system that files results by result date produces a balance that is quietly wrong every time the lab falls behind.

Weightometers third, and here the software's job is to expose truth rather than hide it. Calibration date, check weight results, drift since calibration and an explicit trust weighting per scale, visible on the same screen as the balance. Then shipment and dispatch records for concentrate leaving site, and survey data for stockpiles.

Cost, timeline and what moves them

A first release for one circuit runs $70,000 to $150,000 and ships in 12 to 18 weeks. That is ingestion from the three sources, the node model for your flowsheet, weighted reconciliation, moisture and stockpile handling, and a daily reconciled report with the unaccounted line broken down rather than lumped.

The full build across multiple circuits with settlement reporting, restatement workflow, measurement quality monitoring and audit ready sign off runs $180,000 to $400,000 across 6 to 12 months. What pushes it up: several parallel circuits or a shared tailings and reclaim system, precious metal plants with significant in circuit inventory, and any operation where the lab data model was never designed to be read by another system. What holds it down: one circuit, one commodity and a decision to accept the first version of the error weighting and tune it with real data rather than debating it in workshops.

When you should not build this

A small single stream plant where the superintendent closes a credible weekly balance in a workbook that he understands and can hand over does not need this. Neither does an operation whose measurement regime is the real problem, and that is worth saying plainly: if your feed weightometer has not been calibrated this year and your tails sampler is known to be biased, software will produce a beautifully reconciled wrong answer. Fix the sampling and calibration first, then build. We have told clients exactly that and delayed projects by a quarter over it.

How to choose a developer

Ask how they will handle disagreement between measurements. If the answer is that the system will use the most reliable source, they have not done metal accounting. The answer you want involves error weighting and adjustment, and a developer who has built this will start talking about which instruments you trust before they talk about screens.

Ask how a result that arrives late gets placed in time. Sample time, not result time, and a restatement path for the day already reported. If they shrug at that, your recoveries will be wrong every time the lab is busy.

Ask what they have actually pulled from a historian. Tag structure, running status, aggregation over downtime and interpolation behaviour are where the accuracy is won or lost, and it is a specific skill. Ask for the plant, the historian and the tag count, not a general integration claim.

Ask who owns the code, the model definition and the cloud accounts before kickoff. At Digital Heroes the client owns all three from the first commit. Your flowsheet model and your error weightings are the plant's institutional knowledge in machine readable form, and they should never sit in a vendor account.