Designing trust in digital retail weighing systems

Abstract

Retail weighing systems are evolving from stand-alone measuring instruments into distributed digital transaction systems. A modern non-automatic weighing instrument may be connected to point-of-sale software, self-checkout terminals, product databases, scanners, shared displays, remote services, payment systems and electronic receipt platforms. The legally relevant result may therefore no longer be generated entirely within a single physical instrument. This development challenges traditional conformity assessment, verification and market surveillance practice. Metrological trust now depends not only on the weighing performance of the instrument, but also on the controlled transformation, transmission, indication, storage and reconstruction of legally relevant data throughout the complete transaction chain. This article analyses the application of WELMEC Guides 2.2, 2.10 and 7.2, together with OIML R 76 and OIML D 31, to contemporary POS–NAWI architectures. It proposes a technology-neutral, risk-based framework for transaction-chain assurance and transaction-process software validation.

“Trust in policy begins with trust in measurement.”

1  Introduction: Trust is the regulated product

Legal metrology creates confidence in transactions in which a measured value determines an economic result. A consumer purchasing goods by weight does not normally inspect the construction of the scale, review its software or examine the price-calculation algorithm. The consumer relies on a regulatory system that ensures that the indicated weight, unit price and price to pay are correct, transparent and protected against inadmissible influence.

For traditional retail weighing instruments, the trust model was comparatively easy to understand. A counter scale was a clearly identifiable physical instrument. Its weighing, price-calculation, indication and printing functions were normally integrated into one device, with a defined manufacturer, identifiable seals and a short data path from the load receptor to the customer indication.

That model is changing. Retailers increasingly deploy digital technologies to improve operational efficiency and customer experience while operating under sustained margin pressure [11].

The legal-metrology framework must therefore remain effective without unnecessarily constraining technical development.

2  From a scale to a distributed transaction system

A contemporary retail installation may combine the legally controlled weighing instrument with components that were previously external or absent. Typical examples include:

• a non-automatic weighing instrument (NAWI), including its indicator and legally relevant software;
• operator and customer displays, which may be shared with non-metrological information;
• barcode scanners, product-recognition applications or AI-assisted product selection;
• POS and self-checkout applications;
• local or remotely managed product and price databases;
• store servers, cloud services and application programming interfaces (APIs);
• anti-fraud and loss-prevention software;
• payment terminals and transaction-totalisation functions;
• printed or electronic receipt services; and
• remote maintenance, configuration and software-update services.

The final commercial result is derived from several elements: the measured weight, product identity, unit price, price calculation, customer indication, transaction total and receipt. These elements may be processed by different software modules, devices or service providers. The metrological question is therefore not limited to the accuracy of the scale; it also concerns whether legally relevant data remain authentic, complete, consistent and traceable throughout every transformation.

Figure 1. High complexity of contemporary retail systems

Figure 2. Conceptual legally relevant transaction chain in a distributed POS–NAWI system

3 Field experience: what does subsequent verification prove?

Consider a recent practical example: a POS–NAWI system placed in service in 2024, operating without reported metrological problems and later presented for subsequent verification [1]. Conventional subsequent verification can establish that the weighing instrument responds correctly to test loads, that its errors remain within the applicable limits and that visible securing measures are intact. It can also include confirmation that the POS configuration is covered by the relevant certificate and an end-to-end test purchase. These checks were completed in 2024, and the system was successfully verified.

During an inspection of a large retail chain in 2026, the following behaviour was observed:

1. A 5 kg standard weight was placed on the scale; the scale indicated correctly.
2. The cashier selected an item.
3. The POS system displayed a weight and corresponding price ten times the actual values and processed these values as valid transaction data.

The reported cause of the demonstrated error was the replacement of the product barcode scanner by a newer model running different firmware. In this case, neither the replacement scanner nor its firmware had been included in the scope of the original POS-system evaluation because the component had been treated as legally non-relevant.

This example shows that approval or evaluation of the defined POS configuration, together with conventional subsequent verification, does not by itself demonstrate the integrity of the complete digital transaction chain after changes to connected components. Verification and inspection methods that focus only on the weighing instrument and the nominally approved POS configuration may therefore leave system-level failure modes undetected, with direct implications for consumer protection.

Relevant questions include:

• Is it sufficient to verify the system as an isolated point-of-sale terminal?
• Is it sufficient to check only the validity and scope of the POS certificate if the installed configuration differs from the evaluated configuration?
• Can scanner firmware, product-recognition software or database logic alter the product identity or unit price used in the transaction?
• How can it be demonstrated that updates and changes to connected devices do not inadmissibly influence legally relevant transaction data?
• Can a remote service modify data after primary indication or after customer acceptance?
• Which software versions and configurations are installed, and can they be confirmed during verification?
• Were updates carried out through an approved and traceable process?
• Which economic operator is responsible for each legally relevant component and interface?

The weakness need not lie in the scale itself. It may arise in the POS application, an interface, a configuration file, a price database, a shared display, a receipt service or the update process. Such weaknesses need not result from deliberate fraud; they may be architectural or procedural. Undefined boundaries, incomplete documentation, inconsistent configurations and unclear allocation of responsibility can be sufficient to undermine confidence.

4  Applicable framework

In the European Union, NAWIs are regulated by Directive 2014/31/EU (NAWID) [4]. EN 45501:2015 provides the harmonized technical framework for the metrological and technical requirements of NAWIs [5]. WELMEC guidance supports consistent interpretation and application of this framework [2]. At international level, OIML R 76 provides requirements and test procedures for NAWIs [9], while OIML D 31 provides general requirements for software-controlled measuring instruments [10].

4.1  WELMEC Guide 2.2: POS-specific requirements

WELMEC Guide 2.2 specifies requirements for electronic POS devices connected to NAWIs intended for direct sales to the public. It follows the modular approach and treats the POS as a device performing functions subject to the relevant requirements of EN 45501 [6]. The guide is practical and test-oriented and covers both free-programmable and non-free-programmable POS devices.

WELMEC Guide 2.2 is based on the evaluation of a defined POS configuration and its interfaces. In practice, however, deployed retail systems evolve: hardware treated as legally non-relevant may be replaced, and operating systems may receive upgrades or patches. The metrological question is whether such changes can influence legally relevant functions or data and, if so, whether that influence remains controlled within the approved or evaluated configuration.

4.2  WELMEC Guides 2.10 and 7.2

WELMEC Guide 2.10 provides the current technical implementation of modular evaluation for non-automatic and automatic weighing instruments [7]. Modular evaluation is essential for avoiding unnecessary duplication of tests and for enabling specialized suppliers to provide reusable evaluated modules. Its effectiveness depends on clear module definitions, compatibility conditions, certificate scopes and responsibility for the completed instrument.

WELMEC Guide 7.2:2026 provides the current generic, risk-based software framework and explicitly addresses instruments under the MID. It covers, among other matters, the identification and protection of legally relevant assets, software and system documentation, software identification, protection against inadmissible influence through interfaces, and controls for software changes. The recast work presented in 2024 [12] has now resulted in the 2026 WELMEC software-guide framework, reflecting the continuing adaptation of legal-metrology software assurance to contemporary digital architectures.

4.3  OIML R 76 and OIML D 31

OIML R 76 includes additional requirements for software-controlled electronic devices. For embedded software, it requires a description of legally relevant functions, software identification assigned to those functions and securing measures that provide evidence of intervention [9]. It also provides for separate testing of modules such as digital data-processing devices, terminals, digital displays and weighing modules under defined conditions.

OIML D 31:2023 broadens the software-assurance framework. It requires legally relevant components to be identified, defined and documented, and requires communication interfaces to be protected against inadmissible influence [10]. Its examples expressly include a networked system consisting of a digital sensor that calculates weight, a universal device that calculates price and a printer that prints the measurement result and price to pay. OIML D 31 also addresses the completeness and protection of stored data, software identification, operating-system configuration, software-update mechanisms, audit trails and remote verification [10].

This raises a practical question: to what extent can all relevant interactions, change scenarios and failure modes realistically be assessed within a complex retail system?

5 System architecture as evidence for conformity assessment

Effective conformity assessment requires an architecture description that is sufficiently detailed to define what is being assessed. The technical documentation should identify:

• the physical and logical boundary of the legally controlled instrument;
• all legally relevant hardware and software components;
• the legally relevant functions and data allocated to each component;
• the sequence of data transformations and the point of primary indication;
• interfaces, protocols, commands, data structures and error responses;
• software identifiers and legally relevant configuration identifiers;
• security, integrity and authentication mechanisms;
• storage locations, retention conditions and transaction identifiers;
• update, rollback, recovery and incident-response procedures;
• compatibility conditions between separately evaluated modules; and
• the allocation of responsibility among manufacturers, integrators, service providers and users.

OIML D 31 requires topology and software documentation and explicitly addresses interfaces, separated components, networks and stored data [10]. These requirements provide a sound basis for a formal architecture description of POS–NAWI systems.

6 Software validation should follow the data

Figure 3. Proposed V-model for validation of a POS–NAWI system

A POS–NAWI system validation model should follow legally relevant functions and data rather than organisational ownership or the physical location of the code. A module should be treated as legally relevant where it performs or controls a legally relevant function, or where it can inadmissibly influence such a function. Depending on the architecture, this may include software that:

• acquires or processes the weight value or stability and validity status;
• selects or confirms the product where that selection determines the price;
• retrieves or assigns the unit price used for the weighing transaction;
• calculates or rounds the price to pay;
• controls the primary customer indication or legal printout;
• constructs, transmits or stores the legally relevant transaction record;
• authorizes changes to legally relevant parameters or configuration;
• implements software identification, integrity checking or audit trails; or
• manages updates to legally relevant modules.

Validation should demonstrate both correct intended behaviour and resistance to inadmissible or unintended data paths. Negative testing is therefore as important as positive functional testing. Examples include attempts to use an unstable or invalid weight, substitute a different unit price after customer confirmation, display one value while recording another, bypass the approved calculation through an external service, modify a protected parameter through an undocumented command, install an unauthorized software version or detach an electronic receipt from the original measurement event.

At system level, validation should also address the hardware architecture and the suitability of individual devices within the validated configuration.

7 Verification and market surveillance need digital evidence

Physical seals required markings and load tests remain necessary. For complex systems, they should be complemented by evidence that the installed software and configuration correspond to the approved architecture and that the complete transaction chain behaves correctly.

Practical field tools may include:

• a review of the overall system architecture, including the qualification and configuration status of relevant hardware and software components;
• standardized digital test transactions and reference datasets;
• accessible software and configuration identifiers;
• secure diagnostic or verification interfaces;
• transaction-record exports with defined semantics;
• automatic comparison of the customer indication, receipt and stored data;
• audit-trail inspection and update-history checks;
• cryptographic verification of software or records; and
• risk-based inspection checklists focused on legally relevant data paths.

It is not realistic for a field officer to conduct a comprehensive assessment of the entire system at every retail location following each replacement or upgrade. Such an approach would place a disproportionate burden on both retailers and metrology authorities.

One proportionate approach is to perform comprehensive system validation at a representative pilot store and to complement it with an assessed configuration-management or quality-assurance process that ensures other stores remain equivalent to the validated configuration. Field verification can then focus on confirming identity and configuration and on selected end-to-end transaction checks.

8 Priorities for future work

For future development, priorities for certification, subsequent verification and market surveillance should include:

• surveying current national approaches to POS systems;
• collecting evidence from Member States, notified bodies, manufacturers, POS suppliers, integrators and retailers before revising guidance;
• assessing whether ongoing updates to legal-metrology requirements and guidance adequately address POS systems;
• defining contemporary POS-system boundaries, including distributed and cloud-supported configurations; and
• establishing clear responsibility for the overall functionality, configuration integrity and security of the POS system.

9  Conclusion

The objective of legal metrology is not to prevent the digital development of retail systems. It is to preserve the legal meaning of weighing within that development.

The scale remains the origin of the measured weight, but trust in the commercial result depends on every component that transforms, presents, transmits and records that value.

Future requirements should combine three principles:

1. The consumer and the legally relevant result must remain protected.
2. Proportionality: controls should correspond to the actual software and architectural risk.
3. Market relevance: requirements must fit modern system architectures, cybersecurity maintenance, patching and software-release cycles.

Retail weighing is therefore moving from instrument-only compliance towards transaction-chain assurance. This does not reduce the importance of the NAWI. It extends the assurance boundary so that the complete legally relevant transaction remains authentic, transparent and verifiable.

Author’s note

This article is a formal development of the presentation “Designing trust in digital retail weighing systems: Software security and modular compliance in POS–NAWI architectures”, prepared for ICW 2026 and WELMEC Working Group 2 [1]. The proposed concept of transaction-chain assurance and the recommendations are the author’s analytical conclusions. They are intended to support technical discussion and do not replace the applicable legislation, harmonized standards, OIML Recommendations, WELMEC Guides, certificates or decisions of competent authorities.

References

[1] D. Šťastný, “Designing trust in digital retail weighing systems: Software security and modular compliance in POS–NAWI architectures,” ICW 2026 / WELMEC Working Group 2 presentation, 2026. Unpublished presentation supplied by the author.

[2] WELMEC e.V., “About WELMEC,” accessed 6 August 2026. Available online

[3] WELMEC e.V., “Building Trust in Policy Making - Celebrating World Metrology Day 2026,” 20 May 2026, accessed 6 August 2026. Available online

[4] European Parliament and Council, Directive 2014/31/EU of 26 February 2014 on the harmonisation of the laws of the Member States relating to the making available on the market of non-automatic weighing instruments (recast), OJ L 96, 29 March 2014, pp. 107–148. Available online

[5] CEN, EN 45501:2015, Metrological aspects of non-automatic weighing instruments, Brussels, 2015.

[6] WELMEC, Guide 2.2, Issue 3, Guide for Testing Point of Sale (POS) Devices (Non-Automatic Weighing Instruments), 2007. Available online

[7] WELMEC, Guide 2.10, Version 2021, Technical Implementation of the Modular Evaluation for Non-automatic Weighing and Automatic Weighing Instruments. Available online

[8] WELMEC, Guide 7.2, Software Guide, Version 2026. Available online

[9] OIML, R 76-1:2006, Non-automatic weighing instruments – Part 1: Metrological and technical requirements – Tests, Paris, 2006. Available online

[10] OIML, D 31:2023, General requirements for software-controlled measuring instruments, Paris, 2023. Available online

[11] PwC, “Are you ready for the next era of retail?”, 26 February 2026, accessed 6 August 2026. Available online

[12] M. Esche, “Recast of WELMEC Software Guides,” 3rd WELMEC Webinar on Digitalization in Legal Metrology, 27 November 2024. Available online

AI assistance statement

ChatGPT (OpenAI) was used as an editorial support tool for language refinement and text editing, and to assist in the preparation of selected illustrations. All technical content, conclusions, and final versions of the text and illustrations were reviewed and approved by the author.