zsmorgan21

[patent oriole]

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• zsmorgan21, 7 minutes ago, 9 messages
• zsmorgan21, 3 hours ago, 3 messages

[tropic perch]

instead both period_start and period_end are november

Can you please further explain what period_start and period_end represent on an invoice obj?

[barren willow]

Happy to take a look. Can you send me the text of that invoice's ID? (in_1234)

Not having much luck typing it out or copying from the screenshot unfortunately

[tropic perch]

ya one sec

sorry

Here is an example: in_1O4RxGHmbQZtVN0XqhtbNuhH

So for this guy, in the stripe dashboard it shows:
OCT 23, 2023 - OCT 23, 2024

But we get back the same date for period_start and period_end

[barren willow]

Interesting. I am seeing accurrate timestamps on the latest event that was sent on the invoice

            end: 1729704618,
            start: 1698082218
          },```
https://dashboard.stripe.com/test/events/evt_1O4SUZHmbQZtVN0XHlTyA0hc

So when directly retrieve that invoice via the API are you seeing one of those timestamps as both the start and end?

[tropic perch]

Ya, I have another example

[barren willow]

Sounds good happy to see if that helps clarify what is happening

[tropic perch]

So this guy: in_1O9uRwHmbQZtVN0X7J7e3w7I

Dashboard:

[barren willow]

Can you send me the snippet of code where you are retrieving that invoice? I can't imagine it is much more than just calling retrieve on that ID but it may still help to see

[tropic perch]

But we get back

const stripeResponse = await this.stripe.invoices.list({
      customer: customerId,
      limit: 6,
      starting_after: startingAfter,
      expand: ['data.subscription.plan.product'],
    });

FWIW, its seems that the first invoice of the subscription is the only one with this problem?

[barren willow]

Ah so it is the list endpoint. Will see if I can repro on my side

Can you quickly also try directly retrieving a single invoice and seeing if that gets the same behavior?

[tropic perch]

yes

Ya I get the same invoice response

Which is a good thing, I would think haha

[barren willow]

Yeah, at least it is consistent. Though that is strange that this is not reflecting the data that I am seeing on those same invoices on my side

I wonder if this has to do with the test clock on these subscriptions/invoices

I am seeing the same behavior with and without a test clock. Not sure why this is happening here but am digging further

[tropic perch]

OK sounds good. Not sure if you saw this, but I only see it happening for the first invoice of the subscription

So for that clock user if you look at other invoices, the period_start and periond_end make sense

[barren willow]

Yep yep, saw that you mentioned it is the first invoice. I was partially expecting the timestamps to be correct on the first invoice when a test clock is not used, sometimes clocks can throw things off

Also interestingly, the invoice item for the subscription actually shows the correct timestamps and it is from the same API response

[tropic perch]

Ya I did notice that. I didn't know if we should be using the subscription period.end and period.start

[barren willow]

I am checking with my colleagues about this. I think this may be a bug.

[barren willow]

Ah, I was mistaken about what these fields represent. The period_start and period_end properties are for the previous billing period, the period hash on the invoice is for the next billing period.

So if you have a monthly subscription on the 1st of the month, the invoice on the 1st of November will be for the 1st of October until the 1st of November while the line item for the subscription will be for 1st of November to the 1st of December.

Because the first invoice doesn't have a previous period, we just duplicate the start date

[tropic perch]

ahhh ok GOT IT

[barren willow]

Yep, a big aha moment for me as well

[tropic perch]

haha!

So subscriptions only support billing based on previous month, not upcoming?

I guess Im confused about that first invoice. What would that payment be for then? I'd imagine the upcoming billing period, right?

It seems like, from you screenshot, these are the dates we'd actually want.

Cuz they get billed at the beginning of the period, not the end, right?

[barren willow]

Apologies, I was wrong in saying "previous billing period". More accurrately, period_start and period_end represent the time in which billables on the invoice where accrued

And the invoice item is the dates that the customer is currently paying for

For non-metered subscriptions we only support billing for the upcoming month.

[tropic perch]

right right

ok

[barren willow]

So yes, the dates on the invoice item would be the one that you want

[tropic perch]

gotchya

And for invoice subscriptions, is there any chance there'd be multiple line items?

[barren willow]

Yes, there can be:

1. Recurring items from the subscription that the invoice is for
2. One-time invoice items from being added manually or for a proration