How to Set Up a SaaS Pricing Plan Table That Billing Can Run

Start with a table that has one row per plan per billing period, so a Team plan billed monthly and the same plan billed yearly are two rows. Each row gets a plan ID that never changes, even when marketing renames the Business plan to Scale and every integration still holds the old label. Names break reports and coupons.

Fill these columns: plan ID, display name, currency, fixed fee, billing interval, included seats, included usage and status, and nothing else until those eight are agreed. Mark retired plans as closed to new sign-ups rather than deleting them, because existing customers still sit on them and their invoices must keep resolving to a row.

Every subscription, invoice and revenue report points back to this ID, which is why it must never be reused for another plan.

A seat is more than a number. State whether seats are named or concurrent, the minimum count, the step size and whether removed seats are credited, because each choice changes the invoice. A concurrent licence for fifty users and a named licence for fifty users look identical on the pricing page and very different on the invoice.

For usage, record the unit, the included amount, the overage rate and the tier boundaries, and add a column naming the meter that supplies the reading each month. Say whether tiers are graduated, where each band is priced separately, or volume based, where the whole quantity takes one price, and the totals differ.

Write one worked example per rule. Use real numbers from a sample customer, such as eleven seats on a plan that includes ten, so that the expected invoice total is not in dispute. If finance and product compute different totals from the same example, you have found a bug before a customer has, and the fix costs one edit to the table.

Add-ons such as single sign-on, extra storage, a sandbox environment or premium support should be catalogue items with their own IDs, not a note on the plan. Customers can add one without switching plans.

Define which plans each add-on may attach to, because some are free on top-tier plans and chargeable below, and the table should hold that rule. Reps stop improvising quotes. When the rule lives only in a rep’s head, two customers on the same plan end up with different add-on prices, and the discrepancy surfaces at renewal.

Keep one-time fees, such as onboarding or data migration, in the same catalogue with a flag marking them as non-recurring, so renewals never repeat them.

Record the trial length, whether a card is taken up front and what happens when the last trial day passes, because the engine needs one answer for each case. Convert, downgrade or lock?

Decide what the first invoice says. If the customer picked seats during the trial, bill from conversion day rather than sign-up, and send a reminder email before conversion and log when it went out. Without that log, a chargeback dispute from a customer who says they never knew the trial had ended is hard to answer.

Extensions given by a rep belong in the system as a dated override with the rep’s name and the new end date, not as a note in the CRM.

Upgrades, downgrades, added seats and mid-cycle cancellations each need a rule that answers whether to prorate by day or by second, charge an upgrade at once or at renewal. Credit or refund a downgrade?

Pick one rule per event. Hold it in the table. Test sample customers against a hand-calculated invoice. Include a leap day, a customer in a different time zone and a downgrade made as the cycle closes, since those cases break most proration code.

Finish by loading the table into a test environment, generating invoices for ten sample accounts, and comparing each total with the hand-calculated figure from the worked examples. Fix every mismatch first.