Maintenance plan billing: 3 settings to check first

Before a maintenance plan starts, check three billing settings: the renewal date, the billing interval, and how the first partial period is charged. A customer agrees to a set program, you send a crew out on a schedule, and the customer pays for that work. Recurring billing turns the promise into a repeated charge, and the software repeats whatever you typed, right or wrong. A bad start date or a misread interval does not cause one bad invoice. It causes the same bad invoice every cycle until someone notices, and by then the customer has usually noticed too.

This post covers three settings to check before the first plan goes live: the renewal date, the billing interval with what the price covers, and the first invoice along with any trial or discount. Each one shapes every invoice that follows, so they deserve a careful look before the first signature turns into a charge.

Key takeaways

• Write down the renewal hour and the time zone you assume.
• Match the billing interval to the invoice the customer sees.
• Confirm whether the price field holds a monthly rate or a yearly total.
• Decide whether the first invoice is full, prorated or discounted, then test it.

The examples come from public help pages for subscription billing tools, including Stripe, ERPNext and WooCommerce. Your software will use different labels, and some of these options may not exist in your tool at all. The ideas still carry over. Find the matching field in your system, and if you can't find it, ask your vendor how that case is handled before you sell the plan.

Who should check these? The owner usually knows what the agreement promises. The dispatcher usually knows what the work looks like on the calendar. Both views are needed. A setup that matches the contract but ignores the schedule will bill correctly and still produce calls from customers when the first visit is weeks away.

Every recurring plan has an anchor, the date its billing cycle is tied to. Stripe's guide on setting renewal dates is worth reading in full before you configure anything, because small details change the record. Stripe's billing cycle guide gives an example of an hour you leave out. If you create a subscription at 5 PM EST without specifying the hour, the system records the time as 10 PM UTC.

That detail looks minor until a renewal lands on a different calendar day than you planned. Your office, your customers and your billing servers may not sit in the same time zone. If a plan is supposed to bill on the first of the month, confirm the date the software will actually use, not just the date shown on screen. Set the hour when the tool lets you, and write down the time zone you assume so the next person who edits the plan doesn't have to guess.

The day of the month needs the same care. Stripe's example sets a subscription to cycle at the end of every month by setting day_of_month to 31, on a two-month interval starting in February. The next month with 31 days on that cadence is August, so the billing cycle anchor falls on August 31. Stripe's billing cycle guide A date that works in most months can skip others. If a plan should bill at the end of each month, check how your tool handles months that are shorter. If you have the choice, pick a day that exists in every month, such as the first or the fifteenth.

There are two common approaches, and each has tradeoffs. One is anchoring to the signing day, so each customer renews on the day they joined. That keeps the first invoice simple, but your office ends up with a different renewal day for every account, which is harder to scan. The other is a fixed billing day for everyone, such as the first of the month. That gives your bookkeeping and your collection calls one predictable rhythm, but a customer who signs mid-month will have a partial first period. Pick one style on purpose. Mixing both across plans without a note is how renewal dates get lost.

Stripe describes a price's recurring interval as the cycle it repeats on, such as monthly, yearly or weekly. Stripe's billing cycle guide That sounds obvious, but maintenance agreements are often written in terms that don't match a billing cycle. A contract may promise a set number of visits over a season, a year, or a list of tune-ups, while the billing system asks for a monthly amount, a yearly amount, or a charge for each visit. Decide which one the customer will see on the invoice, then set the interval to match it.

The price field needs the same scrutiny. ERPNext's subscription plan documentation says its Cost field is treated as the monthly rate, and the system calculates the charge for the covered number of months. ERPNext subscription plan documentation In other words, the number you type is not always the number the customer pays. If you enter a yearly total into a field your software reads as a monthly rate, the invoices can add up to far more than the agreement says. Read the help text for the field, then check the calculated total against the signed agreement before you go live.

Ask three questions about every price you enter:

• Is this number a monthly rate, a yearly total, or the price of one plan term?
• Does the tool multiply the price by the months it covers, or does it bill the price as entered?
• Does the invoice show the period it covers, so the customer can match it to the agreement?

The last question matters more than it seems. A charge labeled with a clear date range is easier to explain on the phone than the same amount with no period attached.

The interval also affects cash flow and how the customer sees the value. A plan billed once a year feels like one large payment, and some customers prefer that. A plan billed monthly spreads the cost out, but it keeps the account active on your books all year, including months with no scheduled visit. Neither choice is wrong. Choose the one that matches how the agreement is sold, and say it in plain words in the agreement: "billed monthly" or "billed once a year" should sit right next to the price.

The first invoice is the one customers question most. If the plan starts partway through a billing period, the software may charge a partial amount first. Stripe's proration example shows the pattern. A subscription created in February has an initial, prorated period from creation until February 28 (or 29 during a leap year), followed by a full two-month billing period. Stripe's billing cycle guide The first charge covers less time than later ones. That is normal, but it has to be visible. Put the first-invoice rule in the agreement and make sure the invoice shows its dates.

Trials and discounts follow the same logic. Stripe's trial guide gives the example of a customer on a basic plan who gets a 7-day trial to access premium features at the basic rate. Stripe's trial guide The same guide shows how the first full charge after a trial is built: for a recurring price of 20 USD, Stripe generates an invoice for the full 20 USD recurring price for the period of Jan 8–Feb 8. Stripe's trial guide Maintenance plans don't always include a trial, but a first-month discount or a similar offer may be set up in a comparable way, depending on your tool. Before you launch, decide whether the first invoice is full, prorated or discounted, and test that the software does what the agreement says.

Renewal is where the software does real work. WooCommerce's renewal documentation describes a subscription as one with a recurring payment, meaning a payment due at a regular interval over time, such as monthly. WooCommerce renewal documentation At renewal, it says, the subscription generates an order to record payment, emails you and the customer about the renewal, and sometimes processes the payment. WooCommerce renewal documentation That's three separate actions. Each one can be set differently in your tool, and each one affects your team.

Check the notice first. Who gets the renewal email? Does it come from the office account or from a person? Does it name the amount and the date? A dispatcher who never sees the renewal notice won't know to call a customer whose payment didn't go through, and a customer who never gets the notice may be surprised by the charge. Then check payment. Is the card charged automatically, or does the system only create an order that someone has to send for payment? Those two setups create very different work for your office each cycle. For the reminder side of this, see billing settings for automatic reminders.

Don't wait for a real renewal to find out the setup is wrong. Create a test customer and a test plan that matches an actual signed agreement. Use the same price, the same interval, the same start date and the same time zone. Then look at what the software produces: the first invoice, the dates printed on it, the amount, and the renewal date the system shows for the next cycle. Compare each item to the agreement, line by line. For the wider set of controls, see maintenance subscription setup controls.

If your tool has a test mode, or a way to move the clock forward, use it to run a full cycle. That is the only way to see a renewal before a customer does. If your tool has neither, walk through the dates on paper and compare them to the calendar your dispatchers use. A plan that renews on a day with no office coverage is still a problem, even if the software gets the date right.

Test at least one plan of each type you sell: a fixed-day plan, a plan signed mid-month, and a plan with a discount if you offer one. Each type exercises a different setting. Don't assume that testing one covers the others.

Then write the results down. Keep a one-page record for each plan type: the anchor rule, the interval, the price basis, the first-invoice rule, and who receives the renewal notice. When a customer calls about a charge, a dispatcher should be able to find those answers in a minute without opening three screens or asking the owner.

Most billing problems with maintenance plans come from a few habits, not from the software. The first is copying a plan. Duplicating an old plan carries over its price, interval and anchor, and nobody re-checks them. When a plan is copied, check each setting again as if it were new.

The second is editing a live plan without a note. Changing a price or a billing day on an active account can affect the next invoice, and the customer may not have agreed to that change. If the terms change, make the change in a way that matches what your customers signed, and tell them in writing before the next charge.

The third is letting one person hold the knowledge. If the only person who understands the billing setup is out during a renewal, your team has no way to answer a question. Write the settings down and share them with at least one other person.

Take a plumbing firm that sells a yearly maintenance agreement. The agreement promises two inspections a year and a discount on repairs. A customer signs in the middle of a month. The owner wants billing on the first of each month, so the dispatcher sets the plan up to match. The team picks monthly pieces, so the price field must hold a monthly rate, not the yearly total. A wrong figure here repeats on every invoice, so check it against the signed agreement twice. If the tool prorates, the first invoice covers the partial period from signing to the first of the next month. Full monthly periods follow. At renewal, the system creates an order, emails the customer and the office, and charges the card if automatic payment is on.

• Renewal date: The day and hour the software records, and the time zone you assume.
• Day of month: A date that exists in every month, or a tested rule for shorter months.
• Interval: Monthly, yearly or another cycle, matching the invoice the customer sees.
• Price basis: Whether the number is a monthly rate, a yearly total or a plan-term price, and whether the tool multiplies it.
• First invoice: Full, prorated or discounted, with the covered dates printed on the invoice.
• Trials and discounts: How the first full charge after them is calculated, and where each discount lives.
• Renewal notices: Who gets the email, what it says, and whether payment is charged automatically.
• Test run: One test plan for each plan type, checked line by line against a signed agreement.

Billing mistakes in maintenance plans rarely show up on day one. They show up on the second or third invoice, when a customer asks why an amount changed or why a bill arrived earlier than expected. An hour spent on these three settings and a short test run costs far less than explaining an error after the fact, and it protects the trust you built when the customer signed.

If you're unsure how your software handles one of these cases, check its help pages first, then ask the vendor directly. Each tool handles time zones, short months, partial periods and renewal steps differently, and the vendor can tell you exactly what yours does.

Today, pick one plan you already sell and check its renewal date, billing interval and price against the signed agreement.

What is a renewal date in a maintenance plan?

The renewal date is the anchor that a plan's billing cycle is tied to. Set the hour and time zone when the tool allows, and write them down.

Should a plan bill on the signing day or a fixed day?

Both common approaches have tradeoffs, so pick one style on purpose. Anchoring to the signing day keeps the first invoice simple, while a fixed billing day gives your office one predictable rhythm.

What does a mid-month signup's first invoice include?

If the tool prorates, the first invoice covers only the partial period from signing to the next billing date, and full periods follow. Check that the dates printed on it match the agreement.