Incorrect invoice date for subscription

[Lionel Debauge]

Hi,

We run a real estate business which uses Stripe to bill rent to tenants. We do that by using subscriptions that invoice at the beginning of each month.

While using Stripe API we observed the following weird case with a subscription (sub_1JchFcJqdnuxzIUf2YLjf17E). Here is what happened:

1. 07/01/2022: subscription cancel_at attribute was set to 31/01/2022
2. 24/01/2022: subscription cancel_at attribute was set to ""
3. 31/01/2022: subscription was correctly invoiced from 31/01/2022 until 28/02/2022. However subscription has now an upcoming invoice from 28/02/2021 until 28/03/2022.

We are a bit surprised by this behavior as we would expect the upcoming invoice to be from 28/02/2021 until 31/03/2022. We assumed that setting the subscription attribute cancel_at to the end of the month and then setting it to "" would allow the subscription to always be billed on the 1st of each month. Can you confirm us if it is indeed not the case ?

We tried to reproduce this behavior in the test environment with the subscription below but were not able to reproduce the same behavior hence our question above.

https://dashboard.stripe.com/test/subscriptions/sub_1K3iOHEqnnYTeijJJevjurHq

We are really scratching our heads on that one so thanks in advance for any help you can give us.

Best regards,

Lionel

[Remi J.]

Hello Lionel,

Thanks for reaching out. This issue seems identical to a recent email you sent on list here where the Subscription incorrectly ends up with a different `billing_cycle_anchor` compared to the subscription current period start/end. It seems to be happening here too where the Subscription is anchored on the first of the month at 00:00 UTC but the period itself was shifted to be the last day of the month instead and so in February it kind of stuck the subscription to incorrectly be anchored to the 28th of the month, instead of the last day. This is unfortunately something that is quite tricky to fix and calculate correctly on our end but I'll add this case to your original report as something we need to take into account when we find a reliable way to fix this.

Unfortunately this won't be an easy fix and it's unlikely to improve in the short term. My recommendation is to avoid using `cancel_at` in your case if you're assuming the subscription can be re-activated. Instead, rely on `cancel_at_period_end` as a parameter and let the subscription follow its course, where undoing this change wouldn't touch the billing cycle in any way.

Best,

Remi

--
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Lionel Debauge]

Hello Remi,

Indeed it is related to this previous question as our business requires us to always bill at the beginning of the month. 

From what I can gather from your message this happens because we set cancel_at to be at 23:59:59 whereas we should set it to 00:00::00 UTC. If we would do that our issue would be solved ?

Sadly we cannot use cancel_at_period_end in our context. We need to set the next billing cycle end to be the end of the month. This allows us to set future billing cycles to start at the beginning of the month.

For full clarity I have written below the edge case which forces us to do that and a detailed description on how we solve it. Let us know if you need more details.

Thanks for your help. It's really appreciated.

Best regards,

Lionel

-----------------------------------

Edge case

A subscription is planned to be cancelled during a billing cycle already invoiced. We need to delete that planned cancellation.

Issue

Stripe behavior default is to set the current billing cycle end as new billing cycle start for all future cycles

Our solution

1. Set cancel_at attribute to be at the end of the month

2. Wait for the current billing cycle to end 

3. Webhook informs us of the billing cycle end and of the start of a new cycle finishing at the end of the month

4. We set cancel_at to be nil or any other relevant date

5. At beginning of month new billing cycle starts at the beginning of the month

To unsubscribe from this topic, visit https://groups.google.com/a/lists.stripe.com/d/topic/api-discuss/tMANx-8LhUY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-discuss...@lists.stripe.com.

--

Lionel Debauge

Web developer

livecolonies.com | LinkedIn | Jobs

[Remi J.]

I think setting `cancel_at` to 00:00::00 UTC should alleviate the problem but overall I think it's still a bit of a hack. You mentioned not being able to use `cancel_at_period_end` but I don't get why. If you always bill on the 1st of the month, then the end of the period is already 00:00::00 UTC anyway and I don't really see why using `cancel_at` is a better option for you. Unfortunately, this current ask is related to the other email thread you had where you raised that bug. It's something we're aware of but that is not easy to fix since it's a breaking change overall as too many businesses are likely relying on the unexpected behaviour at this point. 

I would recommend working directly with our support team to go deep into your process and expectations so that they can suggest alternative workarounds instead. You can contact them here directly here: https://support.stripe.com/contact

Best,

Remi