When SCADA and Your ERP Disagree on Tonnes

Three Systems, Three Numbers, One Truth

At month end the plant metallurgist reads 48,200 tonnes off the historian. The SCADA HMI shows a running total closer to 49,000. Finance closes the period in the ERP at 47,600 against a sales and inventory movement. Three systems that are all supposed to be measuring the same material report three different answers, and the gap is wide enough to change a royalty payment, a Safeguard Mechanism emissions intensity number, and the confidence a board has in its own operating figures.

If you run a processing plant, a mine, a sugar mill, a smelter or any continuous production asset in Australia, you have almost certainly seen this. The reconciliation happens by hand, in a spreadsheet, a few days after the fact, and the person who does it is the only one who understands why the numbers move. That person is a single point of failure sitting on top of the most important operational figure the business produces.

This article is written for plant managers, metallurgists, production accountants and the finance leaders who sign off the monthly numbers. Having worked on production and group reporting systems for BHP, Rio Tinto and Senex Energy across an 18 year career in industrial data, the pattern is always the same: the tonnes do not disagree because someone is wrong. They disagree because three systems were designed to answer three different questions, and nobody built the layer that reconciles them.

Why the Numbers Diverge in the First Place

The divergence is structural, not accidental. Each system was engineered for a purpose that has nothing to do with monthly reporting, and each makes a defensible measurement choice that produces a different total.

SCADA exists to run the plant right now. Its totals are running counters on flow meters and weightometers, sampled at the scan rate, and they were never designed to be a system of record. A weightometer drifts between calibrations. A running total resets when a PLC is power cycled. The number on the HMI is correct for its job, which is to tell the operator what is happening this shift, and it is the wrong number to close a month on.

The historian, whether it is OSIsoft PI, AVEVA Historian, Citect Historian or an open platform, stores time series at whatever compression and exception settings were configured when it was commissioned. Ask the historian for last month's tonnes and you get an integral of a flow tag over time, and that integral depends entirely on the compression deadband, the interpolation method and how gaps in the data were backfilled. Two engineers querying the same historian tag with different summary settings will get different tonnages, and both will be defensible.

The ERP holds the financial and inventory truth. It knows what was despatched, what was invoiced, and what the stockpile survey said. It does not know what happened between the sensors and the stockpile, so it infers production from movements and adjustments. When the ERP number and the plant number diverge, the ERP is usually reconciled to the physical stock count, which is itself only as good as the last survey.

None of these is the liar. The problem is that no single one of them is the answer, and the business keeps asking each of them the question in isolation.

The Discipline That Already Exists for This

Mining and minerals processing solved the measurement half of this problem two decades ago, and most sites have simply never applied the discipline to their reporting stack. The reference is the AMIRA P754 Code of Practice for Metal Accounting, developed under AMIRA Project P754 and first published in 2004. It is not law. It is the industry standard for how metal production should be measured, reconciled and reported, and it sets out ten principles covering mass measurement, sampling, analysis, data management, and the balancing and reconciliation methods that turn many measured sources into one reported figure.

The principle that matters most for the SCADA-versus-ERP problem is this: every reported production figure should carry a known level of accuracy, be based on the best measurement available at each point, and be reconciled through a documented mass balance rather than picked from whichever system is closest to hand. A weightometer with a stated uncertainty is worth more than an uncalibrated running total, and the reconciliation should weight each measurement by how much you trust it.

That is the intellectual model. The operational reality on most Australian sites is that the model lives in one metallurgist's spreadsheet, rebuilt every month by hand, with the SCADA and historian data pasted in and the ERP figure typed at the bottom. The discipline is sound. The plumbing is missing.

What a Reconciliation Layer Actually Does

The fix is a defined layer that sits between the operational systems and the reporting systems, does the mass balance the same way every period, and shows its working. It does not replace SCADA, the historian or the ERP. It reconciles them.

The collection step matters more than it looks. Pulling a monthly tonnage out of a historian is not a matter of reading a tag. It means querying the flow tag as a time-weighted total over the exact reporting period, handling the hours when the instrument was in calibration or the data quality was bad, and applying the same summary method every month so the number is comparable period to period. Do that once, in code, and you have removed the largest single source of unexplained variance: two people querying the same historian two different ways.

The balance step is where the AMIRA discipline lives. Measured inputs, measured outputs and measured stockpile changes rarely close to zero on the first pass. A proper reconciliation distributes that residual across the measured streams in proportion to their uncertainty, so a trusted despatch weighbridge moves very little and a drifting in-plant weightometer absorbs more of the correction. The output is a single figure that everyone has agreed the method for, with the residual visible rather than buried.

The reporting step is where the business finally gets its time back. Once the reconciled figure is produced by a defined process, it flows to the monthly production report, to the climate disclosure and emissions intensity calculations that increasingly depend on production data, and to the board pack, all from the same source. Finance stops arguing with the plant because they are both reading the same reconciled number.

The Compliance Stakes Have Risen

For a long time a plant could live with a rough reconciliation because the only consumer was internal management reporting. That is no longer true, and the reason is regulatory.

The reformed Safeguard Mechanism commenced on 1 July 2023 and applies to facilities emitting more than 100,000 tonnes of carbon dioxide equivalent a year, with baselines declining at 4.9 per cent annually to 2030. Many of those baselines are production-adjusted, which means the emissions your facility is allowed to produce is calculated against how much it actually produced. Your production figure is now an input to a compliance obligation with financial consequences, reported to the Clean Energy Regulator each year. A production number that cannot be defended in an audit is a Safeguard exposure, not just a management inconvenience.

The same logic runs through AASB S2 climate disclosure, where emissions intensity is production emissions divided by production output, and through any royalty or resource rent calculation tied to tonnes. When the number feeds a regulator, a spreadsheet rebuilt by one person each month is a liability. The reconciliation has to be repeatable, documented and auditable, which is precisely what a defined layer delivers and a spreadsheet does not.

Do You Have a Reconciliation Problem?

Not every site needs this, and the honest answer is that some plants reconcile well enough already. The test is not how sophisticated your systems are. It is how the monthly number gets made and how well it holds up when someone questions it.

If your answer sits in the top two rows, the figure your board and your regulator rely on is more fragile than it looks. The good news is that the fix does not require ripping out SCADA or replacing the historian. It requires building the layer between them.

How the Work Actually Sequences

A reconciliation programme is not a big-bang systems project, and treating it like one is how these efforts stall. The sequence below is deliberately incremental, because each stage produces a usable output before the next begins.

The source review in the first fortnight is the part sites are tempted to skip, and it is the part that determines whether the rest works. Until you have written down every meter, weightometer, assay and stock movement that touches the production number, and how much each one can be trusted, you cannot build a defensible balance. This is unglamorous work and it is where an outside pair of hands often pays for itself, because the people who live inside the plant have stopped seeing the assumptions they make every month.

Getting the reconciled data into a reporting tool is a related discipline in its own right, and worth reading alongside this piece: our note on getting historian data into Power BI without building a second historian covers the reporting side of the same stack.

Why This Is an Integration Problem, Not a Software Purchase

There is a market of products that promise to solve production reconciliation, and some of them are genuinely good. The trap is believing the product is the answer. A metallurgical accounting package with the wrong historian queries feeding it produces reconciled nonsense, confidently. The value is in the integration decisions: which tag, over which period, summarised how, weighted against which despatch record. Those decisions are specific to your flowsheet and your instrumentation, and no product ships them pre-made.

This is the same system integration discipline that applies whenever operational technology has to feed enterprise reporting, and it is why the reconciliation belongs to whoever understands both the plant floor and the finance ledger. For asset-heavy operators in the resources sector, the reconciliation layer sits naturally alongside the broader operational technology and analytics work that Brisbane-based resources businesses are investing in, and alongside asset health programmes that draw on the same historian data.

Data sovereignty matters here too. Production, grade and reserve data is commercially sensitive, and for critical infrastructure operators it sits inside obligations under the Security of Critical Infrastructure Act. Our guide to keeping regulated industry data onshore and the note on CIRMP obligations for critical infrastructure both bear on where a reconciliation layer should run and who should be able to see it.

Where to Start

If the monthly tonnage is made by one person in a spreadsheet, the first move is not to buy software. It is to write down how the number is made today, source by source, and to ask how it would hold up if a regulator or an auditor pulled the thread. That review usually takes a week and it tells you whether you have a reconciliation problem, a data quality problem, or a governance problem. They need different fixes, and the review is what tells them apart.

Solve8 helps Australian resources and processing operators close exactly this gap, between the plant floor and the reporting ledger, drawing on 18 years of hands-on work with historians, SCADA and production reporting on major Australian sites. If your tonnes do not reconcile and you are tired of the answer living in one person's spreadsheet, start a scoping conversation and we will map your production data sources before anyone proposes a build.

Related Reading

• Getting Historian Data Into Power BI Without a Second Historian
• Asset Health AI for Australian Mining Operations
• AASB S2 Climate Disclosure Automation for Australian Business
• Data Sovereignty for Australia's Regulated Industries
• SOCI Act and CIRMP for Critical Infrastructure Operators
• System Integration Services