Shopify subscription billing anchors: how they work and when to use them

By Roy · Marketing manager at Subi. Writes about subscription and loyalty growth for Shopify merchants. · Published August 12, 2026 · Last updated August 12, 2026

A billing anchor is the setting that decides which calendar dates your Shopify subscriptions charge on. Configure one and every subscriber on that plan bills on the same day, whatever day they signed up. Leave it unset and each subscriber bills on their own signup anniversary, spreading charges across all 31 days of the month.

This guide is for merchants and agencies running subscriptions on Shopify who need to decide between those two shapes. By the end you will know what each anchor type does, how the cutoff rules change a new subscriber's first delivery, what anchored billing costs you as well as what it buys, and the one operational failure that quietly undoes an anchored plan months after launch. If you want to try the settings while you read, you can start a free trial.

What is a billing anchor?

A billing anchor is a fixed calendar date, defined on a Shopify selling plan, on which the subscriptions using that plan generate their recurring order. It replaces per-subscriber signup-date billing with a shared schedule.

The exchange is straightforward. Without an anchor, a subscription's billing cycle counts forward from the moment the customer subscribed: sign up on the 7th, bill on the 7th. With an anchor, the plan declares the dates itself, and every subscriber who signs up onto that plan joins the shared schedule.

Anchors are a mechanic of the subscription model in ecommerce rather than of any one app, and they live on the selling plan's policies rather than on the individual contract. In Shopify's Admin API they appear as anchors on the recurring billing policy, the recurring delivery policy and the fixed delivery policy, and each anchor is a SellingPlanAnchor object carrying a type, a day, an optional month and an optional cutoffDay. Because they sit on the plan, every new subscriber joins the same schedule. Note the limit: Shopify detaches a subscription contract from the selling plan once it exists, so updates to the plan do not modify contracts that already exist. In Subi, changing a plan's billing day affects future subscriptions only, and moving live contracts is a support job rather than a settings change.

A concrete example: a coffee roaster runs a monthly plan anchored to the 1st. A customer who subscribes on August 19 is not billed on September 19. They are billed on September 1, along with every other subscriber on that plan, and the roastery ships one batch instead of thirty. If you are still deciding which plan shapes to offer at all, our guide to types of subscription models covers the offer side; anchors are about the clock underneath it.

Two anchors on the same plan are supported, and the changelog names plans with multiple anchors per month or quarter. The 1st and the 15th gives you two fulfilment waves a month, which is often the practical compromise between one enormous batch and thirty small ones.

What types of billing anchors does Shopify support?

Shopify's SellingPlanAnchorType has three values, and the meaning of the day field changes with each one. Getting this mapping wrong is a common configuration error.

MONTHDAY sets a day of the month, and day must be between 1 and 31. This is the workhorse for replenishment: bill the 1st, or the 15th, or both.
WEEKDAY sets a day of the week, and day must be between 1 and 7. Shopify reads those numbers per ISO 8601, so 1 is Monday and 7 is Sunday. This is the anchor for a plan a customer thinks about in weeks rather than months: a Tuesday produce box, a Friday meal delivery.
YEARDAY sets a specific date in the year, so day carries the day and month carries the month between 1 and 12. This is the anchor for a genuinely annual commitment: a membership that renews every March 1, a seasonal club that bills once before its shipping window opens.
cutoffDay is not an anchor type but a buffer that rides on one, and its unit follows the anchor type: 1 to 7 for WEEKDAY, 1 to 31 for MONTHDAY, and it must be null for YEARDAY. Do not confuse it with the recurring delivery policy's own cutoff, a plain number of days that can be 0 for no buffer; that is the field the table below varies. A cutoff answers a fulfilment question rather than a billing one, which is the next section.
preAnchorBehavior is the third piece of the same mechanism, set on the recurring delivery policy rather than on the anchor. It takes ASAP or NEXT, and it decides whether somebody who subscribes between anchors waits for the next anchor date or gets served immediately.

How cutoffs change a new subscriber's first order

The anchor decides the recurring rhythm. The cutoff and preAnchorBehavior decide what happens to the person who joins mid-cycle, and this is where anchored plans surprise their owners. Shopify documents the combinations, and they are worth reading as a table rather than as prose. Take a plan anchored to the 15th of each month:

First billing date	cutoff (days)	preAnchorBehavior	First delivery	Then recurring on
On the anchor: Jan 15	0	`ASAP`	Jan 15	Feb 15
On the anchor: Jan 15	0	`NEXT`	Jan 15	Feb 15
Before the anchor, outside the cutoff: Jan 12	0	`ASAP`	Jan 12	Jan 15
Before the anchor, outside the cutoff: Jan 12	0	`NEXT`	Jan 15	Feb 15
Before the anchor, inside the cutoff: Jan 12	5	`ASAP`	Jan 15	Feb 15
Before the anchor, inside the cutoff: Jan 12	5	`NEXT`	Feb 15	Mar 15

Read the last row before you ship an anchored plan. A subscriber who signs up on January 12, on a plan with a five-day cutoff and NEXT behavior, does not receive anything until February 15. That is a month of waiting after paying, and it is the correct behavior for a curated box assembled in advance. It is a support ticket for a coffee subscription. The setting is not wrong; the mismatch between the setting and the product is.

One more behavior deserves a flag because it bites during payment trouble rather than at signup. Shopify notes that if something delays a billing attempt past an anchor date, fulfilment slides to the next anchor too. On a plan anchored to the 15th, a card that fails on the 15th and only clears on the 16th pushes that subscriber's order to the 15th of the following month unless the billing attempt carries an originTime on or before the anchor. If your plan is anchored and you have not thought about dunning, an anchor turns a one-day payment hiccup into a one-month service gap. The same mechanic makes involuntary churn more expensive on anchored plans than on rolling ones.

Anchored billing vs rolling billing

The choice resolves one question: do you want your operations predictable or your customers' schedules personal? You rarely get both, and the table below is the trade in full.

Model	Billing pattern	What it optimizes	Best for	Watch out for
Anchored	Fixed plan dates, shared by the whole cohort	Fulfilment, inventory, cash-flow predictability	Curated boxes, seasonal clubs, batch-shipped goods	Long first waits, spiky support load, one heavy billing day
Rolling	Each subscriber bills on their signup anniversary	Customer convenience, immediate first delivery	Replenishment of consumables, made-to-order goods	Demand spread thin, no batching, harder forecasting
Hybrid	Anchored delivery with a rolling first order	A fast start plus a batched steady state	Stores that need both, with the tooling to run it	Two code paths to test, two support scripts to write

The point of the comparison is that anchoring is an operations decision wearing a billing costume. Choose it when a batch is genuinely cheaper or better than a trickle.

And there is a real case for not anchoring at all. Anchors add rigidity to an offer that already asks a lot of the customer, and the SubSummit Replenishment Playbook circulates a directional figure worth sitting with: roughly four in five repeat buyers decline a standard fixed-interval subscribe-and-save offer, and practitioners including Bold Commerce co-founder Jay Myers argue that the rigid schedule is a cause rather than a natural ceiling. That figure travels without published methodology, so treat it as a direction rather than a measurement. But if a fixed 30-day loop is already the friction, a fixed calendar date on top of it is more of the same friction, not less.

Pros and cons of anchored billing

What anchoring buys you

One fulfilment event instead of thirty. Everything ships in a wave, so picking, packing and carrier handoff happen once per cycle rather than continuously.
Inventory you can actually plan. You know how many boxes you need and when, because the whole cohort bills together and the count is known before the pick starts.
Cash-flow dates you can name. Revenue lands on the 1st, or on the 1st and the 15th, rather than smeared across the month.
Cohorts that stay comparable. Every subscriber on the plan has the same billing history shape, which makes retention curves readable instead of noisy.
A deterministic handoff to the warehouse. Scentbird's former CTO Andrei Rebrov describes closing the order list at a fixed hour on billing day so the warehouse can begin shipping the next morning, treating billing and fulfilment as one synchronized system rather than two. That discipline is only available to you if billing happens on a known date. Note this is one company's operating practice at large scale, not a published benchmark, and a merchant on a third-party logistics partner inherits that partner's cutoffs instead.

What it costs you

The first-order wait. As the cutoff table shows, an anchored plan can leave a new subscriber charged and unserved for weeks. That wait lands at the single worst moment in the subscription lifecycle, right when the customer is deciding whether this was a good idea.
Payment failures get expensive. A failed charge that clears one day late can push the order a full cycle, because fulfilment follows the anchor rather than the payment.
Support load arrives in spikes. All the billing notifications go out on the same day, so all the questions, pauses and cancellations arrive on the same day too.
One heavy billing window. Thousands of charges in a few hours is a different operational profile from a steady trickle, for you and for your payment processor.
Manual entry drifts off the anchor. This is the failure nobody plans for, and it deserves its own paragraph.

The drift nobody plans for

Anchors are configured once and then quietly undermined by ordinary work. Somebody creates a subscription by hand: a support agent rescuing a failed signup, a merchant adding a wholesale account, an importer bringing legacy contracts across during a platform move. They pick a billing date, and the date they pick is the day they happen to be working. It is not an anchor day.

Historically nothing on the form objected. The contract saved, off the cohort's cadence. Multiply that by a year of manual entries and the cohort structure you designed dissolves. The merchant does not report it as a bug, because it does not look like one. They report that fulfilment has become unpredictable, and nobody connects the two facts.

The fix belongs at the point of entry rather than in a cleanup script: validate the chosen date against the plan's anchors before the contract is written, and name the valid days in the error so the person entering it can correct course. In Subi, creating a subscription manually now rejects an off-anchor date across all three anchor types, and the release note covers what it rejects and scopes the check to manual subscription creation. If you run anchored plans on any platform, audit your manually created contracts for off-anchor billing dates; the count is usually higher than expected.

How do you choose the right anchor for your store?

Work through these in order. The first two usually decide it.

Does batching actually make your fulfilment cheaper or better? If you assemble a curated box, buy perishable stock against a known count, or hand a single manifest to a carrier, anchoring pays for itself. If you pick from existing shelf inventory, it buys you very little and costs you the first-order wait.
How long can a new subscriber reasonably wait? Match the cutoff to the product's urgency, not to your warehouse's convenience. A supplement someone has run out of cannot wait three weeks. A seasonal club can, and the wait is part of the story.
What cadence does the customer already think in? Weeks point at WEEKDAY, months at MONTHDAY, a season or a renewal at YEARDAY. An anchor that contradicts how the customer describes their own habit will generate change requests forever.
Can you absorb a spiky support day? Anchored billing concentrates every notification, pause and cancellation into one window each cycle. Staff it deliberately, and lean on the habits in our guide to customer retention for subscription stores for the conversations that day produces.
Is your dunning strategy anchor-aware? Because a late payment can cost a full cycle of service, retries and card-update prompts matter more here. Our guide to reducing involuntary churn applies with extra force to anchored plans.
Who else can create a contract, and are they constrained? If support, ops or an importer can enter a billing date by hand, the anchor is only as strong as the validation in front of them.

If, then. If you ship a curated or perishable box, anchor with a cutoff and set preAnchorBehavior to NEXT, and say plainly on the product page when the first box arrives. If you replenish consumables, skip anchors and let subscribers bill on their own dates. If you sell an annual membership, use YEARDAY and treat the renewal date as a marketing moment rather than a silent charge.

When not to anchor at all. Anchors are the wrong answer for made-to-order goods with no batching advantage, for any product where a customer running out is an emergency, for stores whose subscriber base is small enough that a batch of eleven boxes is not a batch, and for a first subscription launch where you do not yet know your own cadence. Rolling billing is the honest default; earn your way to an anchor once you can name what batching saves you. The broader shape of that decision sits in our overview of running subscriptions on Shopify and in subscription pricing models.

Frequently asked questions

What is a billing anchor in Shopify subscriptions? A billing anchor is a fixed calendar date, set on a Shopify selling plan, on which every subscription using that plan generates its recurring order. It replaces billing from each subscriber's own signup date with a schedule shared by the whole cohort, so a plan anchored to the 1st bills all of its subscribers on the 1st regardless of when they joined. The predictability that buys is the operational half of recurring revenue.

What is the difference between a billing anchor and a delivery anchor? They are the same object applied to different policies. Shopify exposes anchors on the recurring billing policy, the recurring delivery policy and the fixed delivery policy, so you can anchor when a subscriber is charged, when their order is fulfilled, or both. Anchoring both to the same date is the simplest setup; separating them is how you charge on the 1st and ship on the 5th.

Can one plan have more than one billing anchor? Yes. Two anchors, typically the 1st and the 15th, give a store two fulfilment waves per month. That is often the right middle ground: you still batch, but a new subscriber waits at most two weeks rather than four.

How do I stop subscriptions from being created on the wrong billing date? Validate the date at the point of entry, before the contract is written, and show which anchor days are valid rather than only refusing. Off-anchor contracts almost always enter through manual creation or a migration rather than through checkout, so that is where the guard belongs. Subi enforces this check when a subscription is created manually, for day-of-month, day-of-week and year-day anchors.

Do billing anchors work with prepaid subscriptions? Yes. Anchors govern when a cycle's order is generated, which is independent of whether the customer paid per delivery or paid upfront for several. A prepaid plan can be anchored so that each of its shipments lands in the store's normal fulfilment wave.

Should a new subscription store use billing anchors? Usually not at first. Rolling billing gets a new subscriber served immediately, which protects the fragile first-order moment, and it needs no cutoff decisions. Move to anchors once you can state what batching saves you in fulfilment or inventory terms. See Shopify's own selling plans documentation for the full anchor and cutoff reference.

Getting the anchor right in Subi

Anchors are configured on the selling plan, so the practical work is choosing the dates, matching the cutoff to how urgently your product is needed, and making sure nobody can create a contract that sits outside the schedule. Subi supports all three Shopify anchor types with plan-level configuration, and validates hand-entered billing dates against the plan's anchors; the Charge on specific days guide walks through picking a weekday, a day of the month, or a month and day.

If you are choosing a subscription app and anchored billing is on your requirements list, you can start a free trial of Subi on the Shopify App Store.