Green Button Alliance Logo

Accuracy and Reading Quality

Data readings are typically thought-of as being accurate or not accurate — one or the other, with no gray area.  In reality, however, there are shades of accuracy and a vetting process to give weight to the accuracy of any given reading. 

Accuracy is related to the correctness of the data provided:  Do data truly reflect the usage?

There are three potential Green Button areas that can be defined with a reading-quality flag (of “ QualityOfReading ” type):

     

Reading Type

<ReadingType>(from ESPI) instances can include a <defaultQuality> that represents the general quality of all readings; when a quality is not specifically defined.  This default can be set to being a low-quality, a raw-quality, or an unknown-quality of reading.  Conversely, a default quality of “valid” could be used and a different quality specified when the interval reading differs from the norm.

Each <IntervalReading> is associated with a specific <ReadingType>(from ESPI) and this “<ReadingType><defaultQuality>” would apply to each of the <IntervalReading> instances.

     

Interval Reading

<IntervalReading>(from ESPI) instances can specify a specific <ReadingQuality> for that reading’s <value>.  That means, each interval (e.g., hourly) can have its own reading quality specified.  This should reflect the actual accuracy of the reading.  For readings with poor accuracy, or accuracy of an estimated or unknown nature, the Data Custodian (Utility) should update the reading-quality flag upon final measurement and verification (M&V) of the data: to change a “questionable” reading (or raw or estimated, for other examples) to an actual, “revenue-quality” reading (or a similar, vetted accuracy).

An interesting aspect of the <IntervalReading> is that multiple <ReadingQuality> flags can be provided for that reading’s <value>.  Normally, this is not necessary; however, the ability is a part of the <IntervalReading> in case it is desired.  An example of multiple flags might be to denote a reading as being normalized for weather as well as being revenue-quality, at the same time.  That would look like this 1 :

   

… 
<!-- Atom “entry” element -->
<entry>
    <id>urn:uuid:12c6aaeb-b7f2-5932-88ee-31488059a952</id>
    <title>Natural Gas Reading starting at 2026-01-01 00:00:00Z</title>
    <published>2026-01-01T01:00:00Z</published>
    <updated>2026-01-31T23:59:59Z</updated>
    <link rel="self" type="espi-entry/IntervalBlock" href="https://data.imaginary-power-and-light.com/espi/1_1/resource/Subscription/987654321/UsagePoint/123456789"/>
    <link rel="up" type="espi-feed/IntervalBlock" href="https://data.imaginary-power-and-light.com/espi/1_1/resource/Subscription/987654321/UsagePoint"/>
    <link rel="related" type="espi-entry/MeterReading" href="https://data.imaginary-power-and-light.com/espi/1_1/resource/Subscription/987654321/UsagePoint/123456789/MeterReading/102030405060"/>
    <content>
        <espi:IntervalBlock>
            <espi:interval>
                <espi:duration>3600</espi:duration>
                <espi:start>1767225600</espi:start>
            </espi:interval>
            <espi:IntervalReading>
                <espi:ReadingQuality>19</espi:ReadingQuality>  <!-- “revenue-quality” flag -->
                <espi:ReadingQuality>15</espi:ReadingQuality>  <!-- “normalized for weather” flag -->
                <espi:timePeriod>
                    <espi:duration>3600</espi:duration>
                    <espi:start>1767225600</espi:start>
                </espi:timePeriod>
                <espi:value>12345</espi:value>
            </espi:IntervalReading>
        </espi:IntervalBlock>
    </content>
</entry>
…

     

The order of multiple <ReadingQuality> flags is not important but the interpretation of their stage of vetting might be important.  See the table, below, for an example of a ranking or hierarchy of quality vetting.

It is also important to note:  Each <IntervalBlock> that is updated should maintain the same <id>(from Atom) under-which it had previously been reported — allowing a Third Party to use the <id>(from Atom) UUID to match the updated interval to that initial reporting of the interval when it was under a less-accurate (or less-known) quality value.

For more about the <id>(from Atom) UUID persistence, see our Developer Resources on the topic of Generating Persistent UUIDs. 

     

Usage Summary

<UsageSummary>(from ESPI) instances can also specify a <qualityOfReading> covering the span of a billing period.  Naturally, this is a summation of a larger period and therefore, the reading-quality flag could be used by the Third Party to know that the <UsageSummary> truly covers the revenue-quality readings — that is it not still in flux as a draft of something more-final to come.  Like the <IntervalReading>, this can (and should) be updated to reflect the vetting-process finality, when those data updates are ready.  The same <id>(from Atom) UUID rules noted above also apply here.

     

Reading-Quality Flag Options

     

QualityOfReading Validity (Representation) Description Enumeration
revenue-quality Bill-Quality Data, Final data that is valid and acceptable for billing purposes. 19
valid Potentially Bill-Quality Data, Final data that has gone through all required validation checks and either passed them all or has been verified. 0
manually edited

Vetted manually, Final

 Replaced or approved by a human. 7
normalized for weather Vetted, Final the values have been adjusted to account for weather. 15
validated Vetted, Final data that has been validated and possibly edited and/or estimated in accordance with approved procedures. 17
verified Vetted, intended to be Final data that failed at least one of the required validation checks but was determined to represent actual usage. 18
projected (forecast) Vetted, could be Revised data that has been calculated as a projection or forecast of future readings. 12
estimated using linear interpolation Vetted, could be Revised data value was computed using linear interpolation based on the readings before and after it. 9
estimated using reference day Vetted, could be Revised data value was replaced by a machine computed value based on analysis of historical data using the same type of measurement. 8
derived Not vetted, could be Revised data that has been calculated (using logic or mathematical operations). 11
mixed Unknown, could be Revised indicates that the quality of this reading has mixed characteristics. 13
raw As-Read from Source data that has not gone through the validation. 14
questionable Data Issues, should be Revised data that has failed one or more checks. 10
other Undefined, should be Revised specifies that a characteristic applies other than those defined. 16

     

Need more help with this?  Check-out our Technical Education offerings.

  1. ^  See the page on Atom & ESPI to understand the “espi:” notation herein.