The volumes a facility produces and consumes end up mattering to finance, not just to operations, because they drive inventory, cost, and revenue in the ERP. Getting those figures from SCADA into the ERP is production posting, and it is deliberately more careful than a normal data feed. Raw SCADA readings are operational estimates, and posting them straight into a financial system would put unvalidated numbers onto the books. Production posting therefore runs the numbers through validation and allocation gates first, then posts the trusted result as a confirmation or goods movement. This guide covers the batch and event flows, the unit conversions, the validation gates that stand between raw data and a financial posting, and why that separation matters.
SCADA to ERP Production Posting in one line: SCADA to ERP production posting is the process of sending validated production and consumption figures from SCADA into an ERP system as confirmations or goods movements, so that operational volumes update inventory, cost, and financial records. It typically runs as a daily batch aligned to an operational or accounting day, converts SCADA engineering units into the ERP's units of measure, and passes the figures through validation and allocation gates before they post. The key discipline is that raw SCADA data must be validated, estimated, and allocated first, because unchecked operational readings are not accurate enough to place directly onto financial records.
In an ERP, the arrival of produced or consumed material is recorded through specific transaction types, and production posting maps the SCADA figures onto those. Produced volume is commonly recorded as a production confirmation, which tells the ERP that a certain quantity was made against an order or a process, and as a goods movement that brings the finished quantity into inventory. Consumed material - a feedstock, a fuel, a utility - is recorded as the corresponding consumption or issue movement that takes it out of inventory. The posting is therefore not just a number landing in a table; it is a business transaction that updates inventory balances and, through them, cost and valuation, which is why it has to be right.
Because these are real financial transactions, the timing and grouping of postings follow the accounting rhythm rather than the SCADA sampling rate. SCADA measures continuously, but the ERP does not want a posting every few seconds; it wants a figure for a defined period, most often a production day, aligned to how the plant and the accountants close their books. So production posting typically totals the day's measured volumes and posts one figure per material per period, at a cut-off time that matches the operational day boundary. This alignment is important because financial reporting and period close depend on volumes being attributed to the correct day, and a posting that straddles a day boundary or uses the wrong cut-off distorts the numbers finance relies on.
The choice between a daily batch and a more event-driven flow depends on the business need. Most production posting is done as a daily batch, because financial records generally work at the level of a day and a single reconciled daily figure is cleaner than a stream of partial postings. Some situations warrant a more frequent or event-based posting, such as recording each completed batch in a batch process, or posting a tank movement when a transfer occurs. Even then, the discipline is the same: the figure posted is a defined, validated quantity for a defined event or period, not a raw continuous reading, because the ERP is keeping books, not watching a live signal.
Before any figure can post, it usually has to be converted into the ERP's unit of measure, and this is more than a multiplication. SCADA reports in engineering units chosen by instrumentation - a flow rate, a totaliser count, a level - while the ERP holds material in its own units, and the conversion has to account for how the material is actually measured and valued. For gases and liquids that can mean correcting a volume to standard conditions of temperature and pressure, converting a metered volume to mass or to energy content, or applying a factor that reflects composition. Getting the conversion right is essential because the number that posts becomes an inventory and financial quantity, and a conversion error is a financial error, not just a display glitch.
The validation gates are the heart of what makes production posting different from an ordinary data feed. Raw SCADA readings contain gaps, spikes, frozen values, and meter errors, and posting them unchecked would carry all of that straight onto the books. So the figures are put through a validation and estimation step that identifies bad or missing data and replaces it with a defensible estimate, and often through an allocation step that reconciles individual measured volumes against a more trusted total, distributing any difference back across the sources. Only after the data has passed these gates is it considered good enough to post, and a figure that fails validation is held rather than posted, so an operator or accountant can review it before it reaches the financial system.
This is why validation, estimation, and allocation sit deliberately between SCADA and the ERP rather than being skipped for speed. Operational monitoring can tolerate a noisy or briefly wrong reading because it is watching trends and reacting; financial posting cannot, because the number becomes a permanent record that inventory valuation and revenue depend on. The gates enforce a clear boundary: SCADA provides the raw measurement, the validation and allocation layer turns it into a trusted quantity, and only that trusted quantity is allowed to post. Holding a suspect figure at the gate, rather than letting it flow through, is what protects the integrity of the period close and keeps operational noise out of the financial record.
Reconciliation against measurement is the ongoing check that keeps posted figures honest over time. Even validated daily postings are estimates until they are reconciled against more authoritative measurement, such as a custody-transfer meter, a tank gauge, or an independent sales figure, and the difference between what was posted and what the reference says has to be understood and, where needed, corrected. Building reconciliation into the process means discrepancies are caught and adjusted rather than accumulating quietly on the books, and it gives finance confidence that the volumes flowing from operations are being checked against reality rather than taken on trust. This closing of the loop is a normal and expected part of a sound production-posting process.
It is worth being explicit about the boundary this whole workflow maintains, because it is the reason the process is structured as it is. On one side sits operational data: high-frequency, real-time, tolerant of noise, owned by operations and used to run the plant. On the other side sits financial data: periodic, validated, permanent, owned by finance and used to keep the books. Production posting is the controlled gateway between them, and the validation, conversion, allocation, and reconciliation steps are the toll every figure pays to cross from the operational world into the financial one. Respecting that boundary is what keeps a bad reading from becoming a bad number on a financial statement.
A cloud SCADA platform such as Merobix supports this by being a clean, reliable source on the operational side of that boundary. It captures and stores the measured volumes with their timestamps and quality, which is exactly what a validation and allocation layer needs as its input, and it can expose those figures for the daily batch that feeds the ERP. The platform does not replace the validation, estimation, and allocation gates, which are their own discipline, but by providing trustworthy, well-timestamped measurement data it gives those gates something dependable to work from. For field operations, that means the volumes their instruments record flow toward the ERP through a proper validation path, so the numbers that finally post as confirmations and goods movements are ones finance can rely on.
Because raw SCADA readings are operational estimates that contain gaps, spikes, frozen values, and meter errors, and posting them unchecked would carry all of that onto the financial books as permanent records. Operational monitoring tolerates noisy readings because it is watching trends, but a figure posted to the ERP becomes an inventory and financial quantity that valuation and revenue depend on. That is why production posting runs the numbers through validation, estimation, and allocation gates first, and holds any figure that fails rather than letting it reach the financial system.
Most commonly as a daily batch aligned to the operational or accounting day, because financial records generally work at the level of a day and a single reconciled daily figure is cleaner than a stream of partial postings. Some cases warrant more frequent or event-based posting, such as recording each completed batch in a batch process or posting a tank movement when a transfer occurs. In every case the posted figure is a defined, validated quantity for a defined period or event, aligned to the correct day boundary so period close is accurate, rather than a raw continuous reading.
A production confirmation tells the ERP that a certain quantity was produced against an order or process, recording the output of the work, while a goods movement records the physical change in inventory, such as bringing the finished quantity into stock or issuing a consumed material out of it. Producing something typically generates both a confirmation and an accompanying goods movement, and consuming a feedstock or utility generates a consumption movement. Together they update inventory balances and, through them, cost and valuation, which is why the figures behind them must be validated before posting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.