Metallurgical Accounting Software Problems: The 7 That Cost Real Metal, and How to Avoid Them

Why does the flowsheet get scoped as a picture instead of a data model?

The first workshop almost always ends with a screenshot of the plant schematic and an agreement that the system will look like that. It is comfortable for everyone in the room, and it commits the project to the wrong architecture. A schematic is a drawing. A metal accounting system needs nodes, streams and measurement points as first class records, each carrying mass, moisture and assay by element, each with a source, a timestamp and an assumed error.

The distinction matters because the whole value of the system sits in what happens when the numbers around a node disagree. If the flowsheet is a picture, disagreement gets resolved by picking the most reliable source, which is subtraction wearing a nicer interface. If the flowsheet is data, disagreement gets resolved by a weighted reconciliation that adjusts each measured value inside its own error bounds, and the size of every adjustment becomes visible.

This is specific to mineral processing because your circuit is not static. Plants add a scavenger row, move a sample point, tie in a second thickener. When the model is a drawing maintained by a vendor, every one of those changes becomes a request and the model trails the plant by months. Build the node structure as configuration your own metallurgists can edit, version it, and require that any balance published names the model version it used. That single rule prevents the most common argument in metal accounting, which is two people quoting different recoveries for the same week.

What goes wrong when historical assays and shift data are migrated?

Every operation carries years of production history in workbooks, and everyone wants it in the new system on day one. The trap is not volume. It is that the old records were filed by the day the result arrived rather than the day the sample was cut.

A composite assayed on Thursday describes Tuesday feed. If the migration loads it against Thursday, every historical recovery is smeared across the wrong shifts, and the trend the metallurgists are about to trust is fiction. In gold plants with slow fire assay queues this shifts material by three or four days routinely, and it gets worse exactly when the lab is busy, which is when the plant was doing something unusual and the data is most interesting.

The second migration problem is moisture. Wet tonnes shipped on Monday, oven dry result Friday. Old spreadsheets almost always carry the corrected figure with no record of what was reported first, so the history has no restatements in it and the new system inherits an unrealistically clean past. When the first real restatement happens after go live, it looks like a defect rather than normal operation.

The fix is unglamorous. Migrate with sample time and result time as separate fields, accept that some historical records only have one of them, and mark those explicitly as low confidence rather than backfilling a guess. Then load one year first, reconcile it against the plant's own published monthly numbers, and only then load the rest. If the reconciled year does not reproduce what the plant reported, you have found a data problem before it becomes a credibility problem.

Why do historian and laboratory integrations break after launch?

The historian connection works beautifully in testing and starts producing nonsense in month four. The reason is almost never the connection. It is that somebody in instrumentation renamed a tag, replaced a transmitter, or changed a scaling range, and the integration kept reading happily from a tag that now means something else.

The second failure is aggregation. A shift tonnage is not a totaliser difference when the belt ran empty for forty minutes, and interpolation across a stopped conveyor invents material.

On the laboratory side, the break is usually a change in how samples are identified. A new sample naming convention, a merged composite, a rerun that creates a second result for the same sample. If the join was built on a string that people are free to edit, it will fail silently and the balance will simply stop receiving grades for one stream.

Three defences are worth building at the start. Watch the tags, not just the values: alert when a tag stops reporting, when its range changes, or when its variance collapses to zero, because a frozen instrument reads perfectly. Compute tonnage from running status rather than from totaliser arithmetic. And treat a missing grade as a visible gap rather than carrying the last known value forward, because a stale assay looks exactly like a real one on a report and is far more damaging.

What happens when sign off and restatement control are not covered?

Metal accounting numbers get audited and disputed. The AMIRA P754 code of practice is the reference most operations align to, and the parts of it that projects skip are the boring ones: locked periods, named sign off, and restatement with a reason code.

Skipping them looks harmless because early on there is nothing to protect. The problem appears the first time a final assay lands after a period is published. Without a locked period and a restatement path, somebody edits the underlying data, the report regenerates, and last week's recovery quietly changes. Nobody did anything wrong and there is now no record of what was originally published. When the auditor asks how the figure moved, the honest answer is that nobody knows.

The same gap hurts commercially. Payable metal on a concentrate shipment is settled against weight, moisture and assays, with umpire procedures when the parties disagree. If your plant balance can be edited after the fact, the commercial team and the metallurgists will eventually quote different tonnes for the same lot, and the smelter will notice before you do.

Build the controls at design time, because retrofitting them is close to impossible. Lock a period on sign off, require a named approver, allow restatement only as a new version with a reason code, and keep every published figure reproducible against the measurements, adjustments and model version it used. This costs very little in the first release and it is the difference between a defensible number and an opinion.

Should you build custom or configure what you already own?

Some operations should not build this, and it is worth saying plainly. Metallurgical Systems Metallurgical Intelligence is a serious product for modelled plant data with reconciliation on top, and if your flowsheet is stable and conventional, configuring it is the cheaper and faster answer. Hexagon MineMarket is strong on the commercial side, stockpiles, shipments, quality tracking and sales, and if your real problem is bulk commodity marketing rather than plant balancing, that is where your money should go.

A small single stream plant where the superintendent closes a credible weekly balance in a workbook he understands and can hand over does not need a build at all. Neither does an operation whose measurement regime is the actual problem. If the feed weightometer has not been calibrated this year and the tails sampler is known to read low, software will reconcile confidently around bad inputs and give you a precise wrong answer. Fix the sampling and calibration first. We have delayed projects by a quarter over exactly this and it was the right call every time.

Building earns its place when the flowsheet changes often enough that a vendor maintained model trails the plant, when the hard part is joining a historian, a laboratory system and belt scales that disagree, or when you need the error weightings to be yours to tune. Many operations end up running a purchased commercial system alongside a custom balancing layer, and that is a sound outcome rather than a compromise.

How do hidden costs get into the quote?

The first release for one circuit runs 70,000 to 150,000 dollars over 12 to 18 weeks in Digital Heroes delivery experience, and the full build across multiple circuits with settlement reporting, restatement workflow and audit ready sign off runs 180,000 to 400,000 dollars over 6 to 12 months. The gap between a quote and an invoice usually comes from four places, none of which are visible in a demo.

The laboratory data model is the first. Many plant systems were never designed to be read by anything else, and extracting sample identity, sample time and result lineage can be a workstream rather than a connector. Ask for a sample export before anyone quotes.

In circuit inventory is the second, and it is the one that surprises gold and base metal plants alike. Load on carbon or resin, mill and thickener holdup, leach tank inventory: modelling these properly is real work and ignoring them is the single largest source of apparent unaccounted metal between surveys.

Parallel circuits are the third. Two circuits sharing a tailings and reclaim system is not twice one circuit, it is a harder problem, because the shared streams have to reconcile in both directions.

The fourth is workshop time spent debating error weightings. Accept a first version and tune it against real data over a quarter rather than litigating it in advance.

What separates a metal accounting build that works from one that fails?

The builds that work start with disagreement, not with screens. Ask any developer how the system handles two measurements that conflict. If the answer is that it 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 want to know which instruments you trust before they draw a single interface.

The builds that work also place results by sample time and treat restatement as normal. Ask how a result arriving four days late gets applied and how the already published day is corrected. A shrug there means your recoveries will be wrong every time the lab falls behind.

Ask what they have actually pulled from a historian, by plant and by tag count, not as a general integration claim. Tag structure, running status, aggregation over downtime and interpolation behaviour are where accuracy is won.

Then settle ownership before kickoff. The repository, the cloud accounts and the flowsheet model definition should be yours, and at Digital Heroes the client owns all three from the first commit. The node structure and the error weightings are your metallurgical team's judgement written down in machine readable form, and if they live in a vendor system you cannot open, every circuit modification becomes a change request instead of an afternoon.