Raising prices in WHMCS is easy to do and hard to do safely. Editing recurring amounts service by service leaves no preview, no record of who was supposed to be affected, and no answer when a customer disputes the invoice three months later. Better Bulk Price turns that job into a campaign with a beginning, a middle and an end.

How a campaign works

1. Filter the population — product, currency, billing cycle, service status, current amount range, next due date range, client group, or an explicit list of services to exclude.
2. Preview before committing — the affected services are read live from WHMCS, each row shows the current amount, the new amount and the delta, and a financial summary estimates the MRR and ARR impact, counts how many targets apply immediately versus later, and flags the campaign when it is broad or the average change is large.
3. Approve to freeze the snapshot — approval stores one row per target with its own baseline and new amount. Changing the service list afterwards does not alter an approved campaign.
4. Announce, then execute — the announcement date and the effective date are independent. Client notices and email notifications are generated per target from a reusable template with merge tokens.
5. Let the daily cron apply the change — when a service reaches its billing window, its recurring amount is updated through the WHMCS API. A service that already has an invoice generated, or whose effective date falls after its next due date, is deferred with a typed reason instead of being repriced mid-cycle.
6. Keep the record — every target keeps its own outcome, every run keeps its own result, and every operator and runtime action is written to an append-only audit log.

What version 2.3 adds

• A campaign always reaches an end. Deferred targets are retried when their billing window opens, with the next attempt derived from the earliest eligible date. Twelve unsuccessful evaluations resolve a target as an explicit exception instead of retrying forever.
• Waiting costs nothing. A target parked until its window consumes no attempt, so a yearly service deferred for eleven months is still there when the window opens.
• Interrupted runs are recovered. A run left behind by a dead process is marked and the campaign continues, instead of blocking every future attempt.
• Nothing applied behind your back. Approval requires an effective date, excluded services are never announced, and manual dispatch is refused when no target can be processed yet.
• Every screen answers what happens next: unresolved targets, next automatic attempt, attempts used per target, and deferral reasons in words rather than codes.

Features

• Price rules in three modes: absolute new amount, percentage change, or fixed delta, with rounding, floor and ceiling constraints applied per service.
• Billing-window protection with explicit deferred reasons (no_next_due_date, renewal_invoice_generated, effective_after_next_due_date) and the next eligible date.
• Phased rollout: batch size, pause between batches, and a dry-run mode that records what would have happened without touching a single service.
• Idempotent execution: a target that already succeeded is never applied twice.
• Client-area notices and email notifications from reusable templates, with resend and failure tracking.
• Per-service acknowledgement records and administrator overrides.
• Reusable campaign templates and campaign cloning.
• Server-side paginated, sortable and searchable admin tables.
• The addon owns its tables and only adds columns, so it can be removed without leaving the WHMCS core touched.

Requirements

• WHMCS 8.13 or later, including WHMCS 9.x.
• PHP 8.0 or later (8.1 to 8.3 tested).
• The WHMCS daily cron must be running: scheduled execution and notification delivery depend on it.

Pricing

Licensed per WHMCS installation, either as a monthly subscription or as a one-time licence. Both include support and updates. Current pricing is on the checkout page linked from this listing.

Support

Support and documentation are included with every licence. Installation is uploading the addon folder into modules/addons/ and activating it in Addon Modules; activation creates the addon tables and applies every schema migration, so new and upgraded installations end up identical.