WooCommerce Subscriptions + NetSuite at a Glance
- Double-billing happens when NetSuite’s recurring invoice schedule and WooCommerce Subscriptions’ renewal engine both try to own the charge.
- Pick one system as the billing trigger — the other becomes a read-only mirror.
- Failed renewal payments need a single retry owner, or customers get charged twice on recovery.
- Proration on upgrade/downgrade must be calculated once and passed as a fixed amount, never recalculated on both sides.
WooCommerce Subscriptions and NetSuite both ship with their own idea of a billing schedule. WooCommerce Subscriptions fires a renewal order and charges the stored payment method on its own clock. NetSuite, if you’re using recurring billing or a subscription management bundle, generates its own invoice on its own clock. Wire both into the same integration without a clear owner, and you will eventually double-charge a customer — usually during a plan change, a failed-then-recovered payment, or a timezone edge case around midnight renewals.
Pick the Trigger System, Not Just the System of Record
Most sync guides talk about “system of record” for product and inventory data. Subscriptions need a sharper distinction: which system is allowed to initiate a charge. Everything else must be a passive follower.
Let WooCommerce Subscriptions trigger the charge.
It already owns the customer’s payment method, gateway tokens, and renewal UI. NetSuite receives the resulting invoice as a fait accompli via your integration, rather than trying to independently decide when to bill.
The alternative — NetSuite as trigger — only makes sense if your subscription terms are negotiated per-account (enterprise contracts, custom billing cycles) and WooCommerce is just the storefront shell. If that’s your model, disable WooCommerce Subscriptions’ own renewal cron entirely rather than running both in parallel “just in case.”
The Failed-Payment Retry Trap
This is where most double-billing bugs actually live. WooCommerce Subscriptions has its own dunning/retry schedule for failed renewal payments. If your NetSuite integration also has a retry job — reprocessing invoices stuck in a “payment failed” status — you now have two independent retry loops racing each other. The customer’s card gets charged the moment either loop succeeds, and the other loop, unaware, tries again on its own schedule.
| Failure scenario | Single-owner behavior | Dual-owner behavior (bug) |
|---|---|---|
| Card declined on renewal | WooCommerce retries per its schedule; NetSuite invoice stays draft until synced status flips | Both systems retry independently; card gets charged twice on recovery |
| Customer updates card mid-dunning | Retry owner picks up new card next attempt | Non-owner system may still hold stale card token and retry with it |
| Subscription cancelled during dunning | Owner halts retries immediately | Non-owner system unaware of cancellation continues billing attempts |
Cancellation must propagate before the next retry window, not after.
If your sync runs on a 15-minute interval and dunning retries every 24 hours, that’s plenty of margin. If your sync is daily and dunning retries hourly, you have a real race condition — tighten the sync interval for subscription status specifically, even if product/inventory sync stays on a slower cadence.
Proration: Calculate Once, Pass as a Fixed Number
Upgrades and downgrades mid-cycle require proration math. The failure mode here isn’t double-billing so much as double-calculating — WooCommerce Subscriptions computes a prorated amount for the upgrade, and if NetSuite’s billing bundle also has its own proration logic active, you get two different numbers, and whichever system posts last wins, silently overriding the other’s math with no reconciliation flag raised.
Calculate proration in exactly one place — ideally WooCommerce, since it has the accurate mid-cycle timestamp and existing line items — and pass the resulting dollar amount to NetSuite as a fixed adjustment line, not as “recalculate this subscription’s proration.” NetSuite should record what happened, not decide what should happen.
The Reconciliation Check You Need From Day One
Whatever direction you choose, build one scheduled report that lists: every subscription charged in WooCommerce in the last 24 hours, cross-referenced against every invoice created in NetSuite in the same window, flagging any subscription ID that appears twice on either side or is missing entirely on the other. This is a 20-line query, and it will catch a double-billing bug in hours instead of the 72-hour+ window where these usually surface as a support ticket or a chargeback.
Sources
- WooCommerce Subscriptions DocumentationWooCommerce.com — renewal, dunning, and proration behavior reference.
- Oracle NetSuite DocumentationNetSuite recurring billing and invoice generation reference.
- Stripe Billing Webhooks GuideStripe Docs — event-driven pattern for confirming which system actually captured payment.
Leave a Reply