Handling Common Data Scenarios and Edge Cases

Scenario	Our Recommendation	Rationale
Meter readings duplication due to `PUBLISHER` and `PASS_THROUGH` providers being present in the context of a statement i.e. multiple `meterData` objects being present for the same measurement period for the same meter.	If your use case is able to tolerate an inaccuracy of up to 1%, use the charge and usage values from the `PUBLISHER` provider and ignore those from the `PASS_THROUGH` provider. If your use case requires 100% accuracy compared to the bill issued by the provider (e.g. Bill Pay use cases), you should take into account values from both provider classifications. *⚠️ Please be aware that taking this approach requires in-depth understanding of our data model and extensive additional engineering work on your side.*	Upon validating a representative set of bills for all US providers, we conclude that whether you take into account the values from the `PASS_THROUGH` providers only contributes to a deviation from the actual values by less than 1% . Therefore, unless there is significant business value for your use case, we do not recommend using values from `PASS_THROUGH` providers.
The`usageUnit` and/or the `totalUsageUnit` being returned as `null` or `Undefined`.	Treat it as the provider did not publish these on the bill.	Upon extensive validation work, we are confident that our data extraction abilities to pick up relevant units is functioning as expected for all US providers. If you wish us to investigate a specific case further, please feel free to raise a Support ticket. However, you may experience prolonged response times for these issues as they require extensive work from our teams.
Some electric or water invoices with charges, have no usage.	(Same as above)	(Same as above)
The `statementDate` field sometimes returns `NULL`.	(Same as above)	(Same as above)
The `meterNumber` field (and subsequently the `normalizedMeterNumber` field) sometimes returns `NULL`.	(Same as above)	(Same as above)
`LIGHTING` and `ELECTRIC` are two distinct service types.	Consider both service types when calculating total usages/costs. (📑 Refer to our Supported Service Types Guide for more information)	-
The service type `SEWER` cannot exist without meters for the service type `WATER` meters	Consider both service types when calculating total usages/costs. (📑 Refer to our Supported Service Types Guide for more information)	-
"On peak charges" and "super peak charges" are not the same.	-	Please note that these are terms for distinct time of uses.
Not all multi-meter statements have synchronized reads.	When there are more than one meter on a statement, please use the `periodStart` and `periodEnd` dates at the meter-level, not the ones at the account-level.	-
A statement with many (e.g. 30+) meters is not an invoice from a `SUMMARY` account.	Whether an account is a `SUMMARY` account is determined by the provider. If the provider does not regard an account as a `SUMMARY` account, how the account is structured or the number of meters associated with the account does not change it's `Account.type` designation.	-