Billing cycle calculation uses fixed 30/90/365 day intervals — drifts for calendar month subscriptions

[Calebux]

Description

calculateNextRenewal() in the billing simulation service uses hardcoded fixed-day math:

case 'monthly': return addDays(date, 30);    // ← wrong: Feb has 28 days, July has 31
case 'quarterly': return addDays(date, 90);  // ← drifts ~3 days per year
case 'annual': return addDays(date, 365);    // ← misses leap years

For a monthly subscription starting January 31st:

• Fixed 30 days: next renewal = March 2nd (skips February entirely)
• Correct calendar month: next renewal = February 28th (end of month)

Over 12 months, a 30-day interval drifts ~5 days from the actual calendar date. Reminder notifications fire at the wrong time, and billing projections show incorrect dates.

Fix

Use date-fns calendar-aware functions (already installed):

import { addMonths, addQuarters, addYears } from 'date-fns';

function calculateNextRenewal(date: Date, billingCycle: string): Date {
  switch (billingCycle) {
    case 'monthly':   return addMonths(date, 1);
    case 'quarterly': return addQuarters(date, 1);
    case 'annual':    return addYears(date, 1);
    case 'weekly':    return addWeeks(date, 1);
    default: throw new Error(`Unknown billing cycle: ${billingCycle}`);
  }
}

addMonths correctly handles end-of-month edge cases (Jan 31 → Feb 28/29 → Mar 31).

Additional Locations to Fix

• /backend/src/services/auto-expiry-service.ts — any date arithmetic for billing cycles
• /backend/src/services/reminder-engine.ts — reminder date calculation
• /client/lib/ — any client-side date math for renewal displays

Acceptance Criteria

• All billing cycle math uses addMonths/addYears/addQuarters from date-fns
• Unit tests for end-of-month edge cases (Jan 31, Feb 28/29, Mar 31)
• Reminder dates recalculated for existing subscriptions after fix
• Billing projections show correct calendar dates

[drips-wave]

This issue has been added to the Stellar Wave Program and is worth 200 Points.

🧑‍💻 Interested in contributing? Apply to work on this issue on Drips Wave, earn points, and receive rewards.

Warning

Only applications submitted via the apply link above will be considered. Please do not apply by commenting on the issue or opening a PR directly.

🤠 Repo maintainers: You can manage this issue's Points and Complexity on your Maintainer Dashboard here. Please keep an eye on applications and respond quickly 💙

ℹ️ Learn more about Drips Wave

[Robinsonchiziterem]

@Robinsonchiziterem has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

I'm a backend developer with experience handling time-based logic and fixing date calculation issues in billing systems. I've worked with libraries like date-fns to implement accurate, calendar-aware calculations for recurring events, ensuring edge cases like end-of-month and leap years are handled correctly. I'm also comfortable updating related services and adding tests to prevent regression in billing projections and reminder scheduling. I would love to work on this issue, my ETA is 1 hour.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Robinsonchiziterem to this issue.

[drips-wave]

Congratulations, @Robinsonchiziterem! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on March 30, 2026.

🧑‍💻 @Robinsonchiziterem: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊