ISP Monthly Billing: 30-Day Cycle vs Calendar Month

Model 1: calendar-month billing

Everyone is billed for the 1st to the end of the month, or on a fixed date such as the 10th. The advantage is simplicity: one billing day, one list of who has paid, and easy monthly accounting.

The difficulty comes with new subscribers. If someone joins on the 20th, do you charge a full month, a part month, or give the rest of the month free? Each choice leads to questions. Late payers raise the same problem: if a subscriber pays on the 18th, are they paying for days they were already off the service? You need clear rules, and you still have to explain them to each customer.

• Good for: very small ISPs with a short subscriber list and one billing day.
• Watch out for: part-month charges, free days at the start, and arguments about days without service.

Model 2: a fixed 30-day cycle for each subscriber

Here each subscriber has their own renewal date. When a subscriber is started, their package runs for 30 days (or the validity of the package you set), and the next bill falls due when those days end. Nobody is charged for days they did not get, and new subscribers never need a part-month bill.

The cost is that renewal dates are spread across the whole month. On any given day some subscribers expire, some are due soon and some have just paid. That is hard to follow in a register, but it is easy for software that shows each subscriber’s days remaining.

• Good for: growing ISPs, and any ISP where subscribers join and renew on different days.
• Watch out for: needing a clear view of who expires today, who is overdue and who has paid in advance.

What should happen when a subscriber renews late?

Suppose a subscriber’s package ends on the 10th and they renew on the 16th. In a fixed-cycle model there are two honest options. The first, and the simplest, is that the new cycle starts on the day they renew: the six days in between are not counted, the subscriber does not get them free, and they are not charged for them. The second is to start the new cycle from the old end date, so the gap is charged. Decide which you want, tell your customers, and apply it to everyone.

Whichever you choose, record the real start date and time of each cycle. Guessing a start date later is how counters and invoices stop matching.

Previous dues, discounts and advance payments

A good billing process keeps three things apart. The package price for the new cycle, any discount you agreed for that bill only, and any unpaid balance from earlier. If the customer pays part of the bill, the remaining balance should carry into the next one and stay visible as previous dues.

Advance payments are the third case. A customer who pays next month early has not yet used that month. Record it as an advance, do not extend the running cycle, and use it when the next cycle begins.

A checklist for billing without a notebook

• One list of every subscriber with their package, area and current cycle dates.
• A bill created for every cycle, with the number, amount, discount and previous dues on it.
• Every payment recorded with the amount, the method (cash, JazzCash, EasyPaisa, bank) and who collected it.
• Reminders sent before the cycle ends and when a bill is overdue.
• A weekly look at who expires soon and who is overdue.
• One person responsible for correcting a mistaken date or amount, with a note of what was changed.

How myisphub handles this

myisphub uses the fixed-cycle model. When a subscriber is started, a 30-day cycle begins at that moment and a live counter shows the time left. When the cycle ends the subscriber shows as expired and waits for the provider to renew them, so the days between are not counted. Bills carry previous dues forward, partial and advance payments are supported, and an owner can correct a start or end date by hand when a record needs fixing. See the full list on the features page, or read about getting paid on time. If you run an ISP in Pakistan, the overview for Pakistani ISPs shows how the rest fits together.

Frequently asked questions