# Production: evening-created subscriptions get BILLING\_ANCHOR\_CHANGE and COMPLETE actions one day late (start\_date now correct) **URL:** \ **Category:** Questions\ **Tags:** sandbox, subscriptions-api\ **Created:** [November 4, 2026, 4:36am UTC](https://developer.squareup.com/forums/t/production-evening-created-subscriptions-get-billing-anchor-change-and-complete-actions-one-day-late-start-date-now-correct/28456 "2026-11-04T04:36:28Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![TheSoonerGeek](https://avatars.discourse-cdn.com/v4/letter/t/a5b964/32.png) [@TheSoonerGeek](https://developer.squareup.com/forums/u/TheSoonerGeek)\ **Post date:** [November 4, 2026, 4:36am UTC](https://developer.squareup.com/forums/t/production-evening-created-subscriptions-get-billing-anchor-change-and-complete-actions-one-day-late-start-date-now-correct/28456/1 "2026-11-04T04:36:29Z")
Related: [thread 28078](https://developer.squareup.com/forums/t/sandbox-subscription-returns-november-3-for-requested-november-2-start/28078). Our start\_date is now stored correctly, but the scheduled actions still shift by one day for subscriptions created after midnight UTC. **Setup:** CreateSubscription with start\_date 2026-12-01, timezone America/Chicago, a monthly plan variation with 3 periods, billed on the 1st, STATIC pricing, card on file. Location timezone is America/Chicago. API version [fill in]. **Production example:** subscription 48048b4d-aa1e-403e-94f3-e41c7eda30d8, location LR083AESKCVMW, plan variation UGCGDYERXBV3ND7K3BPDL4YG, created 2026-11-03 at 10:03 pm Central (04:03 UTC on Nov 4). Stored: start\_date 2026-12-01 and billing anchor 1 (both correct), but the anchor action is dated 2026-12-02 and COMPLETE is 2027-03-02. A subscription created in daytime in sandbox shows 2026-12-01 and 2027-03-01. **Also shifted by a day when created in the evening (sandbox):** an explicit canceled\_date (we sent 2027-03-01, it stored 2027-03-02), an explicit monthly\_billing\_anchor\_date, and ChangeBillingAnchorDate (stored a day late, and it added a duplicate anchor action). It still happened after we set the sandbox location’s timezone to America/Chicago. **Questions:** (1) Is this the same issue as 28078, and does the fix cover actions? (2) For an affected subscription, can the late COMPLETE cause a 4th charge on Mar 1, or the late anchor action a prorated charge on Dec 2? (3) Is there a supported way to create subscriptions in the evening without the shift? (4) Will existing subscriptions be corrected? Happy to share more IDs privately. ---
**Author:** ![jaeha](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jaeha](https://developer.squareup.com/forums/u/jaeha)\ **Post date:** [November 5, 2026, 3:20am UTC](https://developer.squareup.com/forums/t/production-evening-created-subscriptions-get-billing-anchor-change-and-complete-actions-one-day-late-start-date-now-correct/28456/3 "2026-11-05T03:20:16Z")
It’s Jaeha here again to help tracking this down. The earlier fix corrected returned `start_date` values, but did not cover these action dates. Those fields still use the UTC calendar date. For your production example, the original start and anchor-change events share one timestamp: December 1 at 10:03:32 p.m. Chicago time. Original expiry is March 1 at the same local time. There is no one-day gap between start and anchor change, and COMPLETE reflects a stopping event rather than a separate billing job. These date labels alone do not establish an extra charge. Please refer to the table below how the date/time is converted from Chicago time to UTC for anchor action and COMPLETE: | **Event** | **Stored UTC instant** | **America/Chicago** | | --- | --- | --- | | Start and anchor change | December 2, 2026, 04:03:32Z | December 1, 10:03:32 p.m. | | Original expiry | March 2, 2027, 04:03:32Z | March 1, 10:03:32 p.m. | I also found a cancellation accepted about five minutes after creation, with subsequent records scheduling billing and entitlement to stop at the original start instant. That changes this example’s original schedule. ---
**Author:** ![TheSoonerGeek](https://avatars.discourse-cdn.com/v4/letter/t/a5b964/32.png) [@TheSoonerGeek](https://developer.squareup.com/forums/u/TheSoonerGeek)\ **Post date:** [November 5, 2026, 2:09pm UTC](https://developer.squareup.com/forums/t/production-evening-created-subscriptions-get-billing-anchor-change-and-complete-actions-one-day-late-start-date-now-correct/28456/4 "2026-11-05T14:09:21Z")
Thanks, Jaeha. The conversion table clears up the date labels. Our evening sign-ups store an instant that is still Dec 1 and Mar 1 in America/Chicago, and the dates only show a day later because they’re labeled by UTC date. (API version: 2026-09-16, and the cancellation you saw was our own test, cancelled on purpose.) A few follow-ups so we can plan around this: 1. **The last period.** For a 3-period monthly subscription billed on the 1st with no proration, created at 10:03 pm Chicago: can you confirm that billing stops after exactly 3 charges (Dec 1, Jan 1, Feb 1), and that no invoice is made on Mar 1 local time before the 10:03 pm stop? 2. **When the charges run.** Is each period’s invoice made at the start instant (10:03 pm Chicago in this example), or at a fixed time on the local billing day? 3. **Explicit dates.** When we sent `canceled_date` 2027-03-01 from an evening request, it was stored as 2027-03-02. Is that the same labeling, meaning the cancel takes effect on Mar 1 local time? Or does the cancel actually move a day later? 4. **Going forward.** Is there a plan to label action dates in the subscription’s timezone? And is there a supported way to create subscriptions in the evening that avoids the mismatch? For now we create evening sign-ups the next morning, when the UTC and Chicago dates match. Thanks again for digging in. ---
**Author:** ![jaeha](https://avatars.discourse-cdn.com/v4/letter/j/ebca7d/32.png) [@jaeha](https://developer.squareup.com/forums/u/jaeha)\ **Post date:** [November 6, 2026, 5:00am UTC](https://developer.squareup.com/forums/t/production-evening-created-subscriptions-get-billing-anchor-change-and-complete-actions-one-day-late-start-date-now-correct/28456/5 "2026-11-06T05:00:59Z")
Thanks for confirming the cancellation was intentional. 1. The expected recurring bills are indeed Dec 1, Jan 1, Feb 1, covering service through March 1. It will have 3 recurring base charges with no new March 1 renewal. The March 1 evening expiry does not create an extra billable day or require invoicing to wait until 10:03 p.m. to recognize the end. 2. Billing is normally scheduled around the subscription’s creation time-of-day which is 10:03 p.m. in this example, instead of a universal midnight run. Processing delays can affect invoice and payment timing, so that is not an exact card-charge time. 3. The returned March 2 date is consistent with the same UTC-date conversion where it March 2 UTC date simply represents March 1 locally. IT didn’t move a day later. 4. I don’t have a confirmed release ETA for the action/cancellation date labels. The `start_date` will display the local time where others can still default to UTC. Hope this helps!