Shopify confirms a cycle-timestamp fix for balanceUsed resetting early

What changed: a calendar date is not the cycle’s end time

On October 13 at 13:32 UTC, Donal-Shopify, identified as Shopify Staff in the official developer community, said the billing team had shipped a fix. That is when staff confirmed the change; the post gives neither an exact deployment date nor a list of covered API versions.

Staff explained that the usage balance had been rolling over on the billing cycle’s calendar date rather than its full timestamp. On the last day, balanceUsed could therefore show the new cycle’s zero even though currentPeriodEnd still pointed to a later time that day.

According to the reply, usage charges now roll over at the full cycle timestamp. This concerns the cycle-boundary calculation. It does not establish that every account has been tested, or announce new fees, allowance or refund arrangements.

Keep the three field meanings separate

The Shopify Admin GraphQL 2026-07 AppUsagePricing documentation defines balanceUsed as the total usage-record amount for the interval. Zero should not automatically be read as a full remaining allowance or proof that earlier usage was never charged.

AppSubscription.currentPeriodEnd gives the specific date and time when the current period ends. Preserve the full timestamp and time zone. Do not compare dates alone or combine it with an amount from another subscription or response.

cappedAmount is the maximum usage-charge amount the merchant can be charged for the interval, while interval describes the billing frequency. These fields serve different purposes. The fix does not announce a change to the cap or billing authorization. The documentation version explains the fields; it is not evidence that the fix applies only to 2026-07.

The actual earlier example: a 07:43 query, an 18:01 cycle end

In an October 1 follow-up, staff checked the reported request: it ran at 07:43 UTC, while currentPeriodEnd was 18:01 UTC that day. The period already had USD 19.99 in usage charges, yet balanceUsed returned zero. That amount belongs to the reported example; it is not a new price or plan.

Staff confirmed HTTP 200 with no GraphQL operation errors, but still escalated the inconsistent boundary to the billing team. On October 13, staff clarified that the October 1 request predated the fix, so its old response would not show the later change.

A displayed zero and the actual charge records are separate observations. Reconcile existing records and business state for the same usage line item first. Do not create duplicate charges to correct a display, or treat zero as newly available allowance.

Check one consistent set of evidence at the next boundary

First, use existing queries or records you are authorized to inspect to identify the subscription, usage line item and actual currentPeriodEnd. Record the complete UTC timestamp. If the business interface shows local time, convert to one time zone before comparing the sequence.

Next, compare balanceUsed from the same response with existing usageRecords or equivalent records for that usage line item. Check whether the request preceded currentPeriodEnd and whether the records belong to that interval. Avoid mixing different items or periods.

If the boundary still disagrees, retain that response x-request-id for Shopify support to trace. Include the query time, period end and actual observation. Use existing authorized access; there is no need to create a new usage charge to validate this report.

An unexecuted example: what a date-only comparison misses

Consider a hypothetical example with no live query performed: a subscription’s currentPeriodEnd is October 15 at 18:00 UTC. At 17:50 UTC, the same usage line item has records for that period, but balanceUsed shows zero. Both dates say October 15, yet the request still precedes 18:00. Matching dates alone cannot establish that the old cycle ended.

If currentPeriodEnd in the actual response has already advanced to the next period’s end, first establish which period the response represents, then compare zero with records for that interval. Align the time, subscription and usage line item rather than creating another charge because the value is zero.

What the staff confirmation and user follow-up establish

On October 14 at 08:26 UTC, the original reporter, sinuhe, said they had not experienced the problem since October 9. This adds one user’s subsequent observation. It does not establish October 9 as the official deployment date or replace checks at another account’s own cycle boundary.

The public conclusion is that staff confirmed a fix to use the full cycle timestamp and asked the user to check before the next period ended. If a mismatch persists, use the request-tracing route. The post does not direct developers to charge again or provide a generally applicable refund or compensation procedure.