Every once in a while, customers seem to ask common questions. Whenever this happens, I try to share a proper explanation or technical breakdown of the solution to share in the community. This is another example. Users are unclear as to when to export Index values versus Interval values. So, my hope is that this document will explain the differences and help users decide which values are best for their needs.
In Temetra, the wording is easier to understand if you separate what the meter knows from what the billing system needs.
Itron’s CRF, Common Reading Format, is an XML interchange format used to move meter-reading and consumption information between Itron applications and other systems. (Itron Total Docs)
The fundamental difference
Suppose a water meter looks like this:
| Time | Meter index/register | Water used since previous reading |
|---|---|---|
| 8:00 AM | 12,500.0 m³ | |
| 9:00 AM | 12,500.6 m³ | 0.6 m³ |
| 10:00 AM | 12,501.4 m³ | 0.8 m³ |
| 11:00 AM | 12,502.1 m³ | 0.7 m³ |
There are two valid ways of describing this data.
Index values are the actual cumulative meter register:
8:00 = 12,500.0
9:00 = 12,500.6
10:00 = 12,501.4
11:00 = 12,502.1
Interval values are the amount consumed during each period:
8:00–9:00 = 0.6 m³
9:00–10:00 = 0.8 m³
10:00–11:00 = 0.7 m³
Itron’s Temetra documentation defines an index reading as the current state of the meter at a particular point in time. By contrast, a consumption reading represents the amount consumed during a defined period. (Itron Total Docs)
1. “Interval values will be added as consumption”
This means Temetra takes the usage for each interval and places those incremental consumption quantities into the CRF.
For example:
10:00–11:00 = 0.7 m³
The CRF essentially communicates:
During this interval, this customer consumed 0.7 m³.
It is not saying the meter register is 0.7.
This distinction matters enormously.
If you had 24 hourly intervals, the CRF could contain 24 individual consumption values. Adding them together gives the total consumption for the day.
For example:
24 hourly intervals = 1.2 + 0.8 + 0.5 + … = 14.7 m³/day
Temetra Analysis itself treats interval information this way, displaying interval water-consumption data against time. (Itron Total Docs)
When would you use Interval Values?
This is appropriate when the receiving application needs time-series consumption.
Typical examples are:
AMI analytics, hourly consumption analysis, leak detection, demand analysis, load profiling, DMA analysis, customer portals showing hourly usage, and applications that want to know how much was consumed during each interval.
For a water utility doing advanced AMI analytics, interval consumption is extremely useful.
2. “Index values will be added as an index read with time”
This is much closer to traditional meter reading.
Temetra exports the actual cumulative register value together with the timestamp associated with that reading.
For example:
Meter 123456
Index = 12,502.1 m³
Read time = August 20, 2026, 11:00 AM
Itron’s CRF documentation shows register readings in precisely this general structure: a reading contains a Value and a ReadingTime. (Itron Total Docs)
The receiving CIS can then compare this index to the previous billing index.
For example:
Previous billing read: 12,213.4 m³
Current billing read: 12,502.1 m³
Therefore:
Billing consumption = 12,502.1 − 12,213.4 = 288.7 m³
That is essentially the traditional meter-reading model that utilities have used for decades.
Why does Temetra give you this choice?
Because modern AMI systems collect much richer information than traditional billing systems were designed to accept.
Think of the meter register as the odometer in a car.
If your odometer reads:
83,542 km
that is an index.
If you drove:
37 km between 8:00 AM and 9:00 AM
that is an interval consumption.
You can derive the 37 km from two odometer readings:
8:00 AM = 83,505 km
9:00 AM = 83,542 km
Difference:
83,542 − 83,505 = 37 km
Water metering works essentially the same way.
Which should you use?
This is where the practical integration question becomes important.
If you are exporting Temetra data into a municipal CIS for conventional billing, I would normally favour:
Index Values → Index read with time
provided the CIS expects a normal meter register reading.
That gives the CIS something resembling:
Account
Meter ID
Reading = 12502.1
Reading date/time = 2026-08-20 11:00
The CIS can then perform the billing calculation itself.
This has several advantages. It maintains continuity with historic meter-reading practices, lets the CIS calculate consumption, makes register auditing straightforward, and makes it easy for staff to compare the transmitted value against the physical meter register.
Interval should normally serve a different purpose
If the receiving system is an MDM, analytics platform, data warehouse, customer portal, or other AMI application, then:
Interval Values → Consumption
is generally more appropriate.
You might send:
| Interval | Consumption |
|---|---|
| 08:00–09:00 | 0.60 m³ |
| 09:00–10:00 | 0.80 m³ |
| 10:00–11:00 | 0.70 m³ |
rather than simply telling it:
Meter register at 11:00 = 12,502.1 m³
The interval data tells you when the water was consumed, which is where much of the value of AMI resides.
One important point
The two choices are not different measurements of water. They are different representations of the same underlying consumption.
Using the example:
Index method
12,500.0 → 12,500.6 → 12,501.4 → 12,502.1
Interval method
0.6 → 0.8 → 0.7
And:
0.6 + 0.8 + 0.7 = 2.1 m³
while:
12,502.1 − 12,500.0 = 2.1 m³
They reconcile.
That reconciliation is also an excellent data-integrity check during a Temetra implementation.
For your Temetra implementation
I would think about the architecture this way:
Meter/ERT → Temetra
Temetra should retain the richest meter-reading information available.
Temetra → CIS/Billing
Send an index/register read with its timestamp if the CIS is designed around conventional billing reads.
Temetra → Analytics/AMI systems
Send interval consumption where the receiving application needs granular usage information.
Itron’s CRF specification is deliberately capable of carrying both types of information. In fact, Itron specifically notes that a use case can include interval readings as well as an ending register read, reinforcing that register and interval data are complementary rather than mutually exclusive concepts. (Itron Total Docs)
My recommendation
For a typical Canadian municipal water utility migrating from FCS to Temetra, I would not automatically select “Interval values” simply because AMI data is available.
First determine exactly what the municipality’s CIS import interface expects. If the legacy FCS process provided a conventional billing register read, then configuring the CRF export as Index Values → index read with time is likely the closest functional replacement and carries the lowest integration risk.
The interval data can remain available in Temetra for the much more sophisticated operational purposes of AMI.
About the Author:
Michael Martin is the Vice President of Technology with Metercor Inc., a Smart Meter, IoT, and Smart City systems integrator based in Canada. He has more than 40 years of experience in systems design for applications that use broadband networks, optical fibre, wireless, and digital communications technologies. He is a business and technology consultant. He was a senior executive consultant for 15 years with IBM, where he worked in the GBS Global Center of Competency for Energy and Utilities and the GTS Global Center of Excellence for Energy and Utilities. He is a founding partner and President of MICAN Communications and before that was President of Comlink Systems Limited and Ensat Broadcast Services, Inc., both divisions of Cygnal Technologies Corporation (CYN: TSX).
Martin served on the Board of Directors for TeraGo Inc (TGO: TSX) and on the Board of Directors for Avante Logixx Inc. (XX: TSX.V). He has served as a Member, SCC ISO-IEC JTC 1/SC-41 – Internet of Things and related technologies, ISO – International Organization for Standardization, and as a member of the NIST SP 500-325 Fog Computing Conceptual Model, National Institute of Standards and Technology. He served on the Board of Governors of the University of Ontario Institute of Technology (UOIT) [now Ontario Tech University] and on the Board of Advisers of five different Colleges in Ontario – Centennial College, Humber College, George Brown College, Durham College, Ryerson Polytechnic University [now Toronto Metropolitan University]. For 16 years he served on the Board of the Society of Motion Picture and Television Engineers (SMPTE), Toronto Section.
He holds three master’s degrees – in business (MBA), communication (MA), and education (MEd). As well, he has three undergraduate diplomas and seven major certifications in business, computer programming, internetworking, project management, media, photography, and communication technology. He has completed over 80 next generation MOOC (Massive Open Online Courses) [aka Micro Learning] continuous education programs in a wide variety of topics, including: Economics, Python Programming, Internet of Things, Cloud, Artificial Intelligence and Cognitive systems, Blockchain, Agile, Power BI, Big Data, Design Thinking, Security, Indigenous Canada awareness, and more.
Martin is a volunteer, a photographer, a learner, a technologist, a philosophizer, and a romantic optimist.