Sorry if this question doesn’t belong here. But it’s a question about usage-based billing in general.
When reporting daily-aggregate usage for a subscription, what time do I consider is the start of a new day?
A) The time part of the subscription’s billing cycle anchor (i.e. the time of day when the subscription was created)
B) 00:00:00 UTC
Hello !
You may get more help from the stripe engineers on the Stripe developper discord server.
After some testing, it seems that a days starts at 0h00 on the timezone of your account. Ex: i have Europe/Paris set as my timezone, therefore it’s UTC+2 for me. Stripe replied below 
- Vasco.
Hi!
Timestamps on Stripe’s APIs, including the usage-based billing event timestamp for pre-aggregated data, are UTC. The daily pre-aggregation represents one day starting from 00:00:00 UTC.
Alternatively, you can send events as raw and just send a single event that is within the user’s day window.
Thank you so much for the clarification. Please allow me to follow up with this situation:
This invoice will contain only partial usage data for the last day of the billing period, July 24. Since we pre-aggregate daily usage data starting from 00:00:00 UTC, we’ll only have data from midnight to 5am for July 24 billed on the invoice.
Will the usage data for the rest of the day on July 24 will be counted in the next invoice?
Okay, I used the Test Clock feature to simulate this situation on a test subscription to understand Stripe’s behavior. Turns out Stripe takes a pretty simple approach that works just fine:
Stripe will only include usage data for complete days in an invoice. So the last day of the billing period, for which you may have reported partial usage data, will not show up in this invoice, but in the next one.
For example, a subscription begins at 3am UTC on Jun 24. The upcoming invoice will be generated at 3am on July 24. But it will only include usage data up to July 23. Usage data for July 24 has not finalized because the day has not yet ended.
I verified this by stopping the clock 30 minutes before the invoice is generated on July 24. Then I reported daily aggregate usage for July 24 itself. Then I forward the clock 1 hour to trigger invoice generation. I see that the generated invoice does not include the amount I just reported. Instead that amount is pending the upcoming bill.
Good question, and nice you were able to use test clocks to try this out!
Yes, daily pre-aggregation is a simple model that does not pro-rate part of the pre-aggregated usage across billing cycle boundaries.