A field meter reading process should record the measured value, compare it with the relevant prior value, and route an illogical entry for review. The process should not automatically turn a reading into billing. A field worker records a fact from the site, while an accountable person or separate billing process decides how to apply that fact.
A number displayed on a meter or entered in a field application is not, by itself, a sufficient business record. Without meter identification, reading time, the prior confirmed value, and the person who made the entry, an organisation cannot reliably distinguish a measured fact from an entry error, a meter replacement, or an unusual event at the site.
Illogical reading control does not mean treating every deviation as an error. Its purpose is to isolate entries that need an explanation before confirmation. Possible reasons can include meter replacement, an incorrectly read identifier, an incorrect digit count, transposed digits, a stopped device, or a real change in consumption. The organisation must decide which reasons are permitted and who confirms them.
It is important to separate two control layers:
This separation avoids a common mistake: attempting to resolve a business decision solely through a technical rule in the database.
The process can operate as a standalone mini application or as part of a wider system. ERP integration is useful when official transactions, locations, contracts, or billing already exist in the ERP. Standalone operation does not remove the need for data ownership and exception control.
Before field work begins, prepare a work list containing at least:
An owner of the location and meter master data should be named. Depending on the organisation, this may be an operations function, a technical service, or another business role. The field worker does not necessarily own this data, but should work from its confirmed version.
At entry, record the new value, reading date and time, the identity of the person performing the work, and the meter identifier. Where the process requires evidence, define the evidence type in advance, such as a meter photograph or a field note. Do not assume that a photograph is always available or sufficient without an agreed rule.
The reading record should remain separate from the billing value. A reading is a measured or reported fact. Consumption, correction, estimation, and billing line items belong to a separate process with its own rules and accountable role.
The system or work procedure compares the new value with the last confirmed value for the same meter. The rule can cover at least these questions:
A threshold is not a universal fact. It depends on meter type, reading frequency, the business contract, and process tolerance. It should therefore be managed as a business parameter with a named owner, rather than as a hidden assumption in a form.
Meter replacement is not a note attached to a reading. It is an event that affects the continuity of comparison. A replacement record should link the old and new meter, include the event date, the old meter's final value where available, the new meter's initial value where known, and the person who confirmed the information.
After replacement, a new reading should not be compared with the removed device's counter as if there were an uninterrupted sequence. A billing process may use final and initial values according to a business rule, but field records must first show clearly what was measured on which device.
When illogical reading control finds a deviation, the field worker should see the reason for review and available actions. A useful minimum flow is:
Hypothetical scenario: a field worker enters a value lower than the prior confirmed value. Rather than deleting it automatically, the procedure marks an exception. The worker can report a meter replacement or request a repeat visit. If replacement is not confirmed, the accountable person decides whether to reject the entry, correct it after review, or accept it with a recorded explanation.
Automated validation can reduce obvious errors, but it cannot establish the actual condition at a site. A rule alone cannot establish whether a meter was physically replaced, whether a photograph belongs to the correct device, or whether an unusual consumption change is justified. Those decisions still require context, evidence, and accountability.
An overly strict rule can block a valid reading. An overly loose rule can allow an entry that needs review. A sensible approach distinguishes rejection for missing required data from an exception requiring human decision.
Where the process connects to an ERP, define which system holds the official meter identifier, when reading status is transferred, and whether an unconfirmed reading may enter billing. ORKA approaches these questions through business process and accountability. Business process screening can help structure the decisions before selecting an integration or application.
Before building a form, integration, or rule, confirm the following:
The next step does not necessarily require buying a system. First map the current field form, the source of the prior value, and the route from every exception to a decision. If these points are unclear, talk to the ORKA team about the process and responsibilities before technical implementation.