Manage Subscriptions and Recurring Billing in Your Core Business System

Your team sells a subscription. Every month someone opens a spreadsheet, copies plan names, guesses at who is still paying, and hopes the total matches the bank. By the time you notice a customer left, the revenue has been gone for weeks. Recurring billing should be the most predictable part of your business, yet for many subscription teams it is the messiest.

The global subscription billing management market was valued at 8.47 billion dollars in 2025 and is forecast to reach 37.36 billion by 2035, roughly a 4.4x expansion. That growth is not hype. It reflects how many businesses now run on recurring revenue, and how badly they need to track it inside a single ERP instead of a patchwork of tools. This article explains what changes when subscription and plan management live inside your core business system, and how to scope that capability honestly.

The Problem: Recurring Revenue That No One Can See

Most subscription teams do not have a revenue problem. They have a visibility problem. A typical month produces a familiar list of failures:

Plan tiers tracked by hand, so no one is sure which customers are on the starter, pro, or enterprise plan.
Renewal dates scattered across calendars and email, meaning a customer can quietly lapse before anyone notices.
Upgrades, downgrades, and discounts handled as one-off edits, so the billed amount drifts from what was agreed.
Monthly recurring revenue (MRR) and annual recurring revenue (ARR) computed in a spreadsheet that breaks the moment a plan changes.
Churn discovered in arrears, often after a full billing cycle has already been lost.

Research on subscription businesses is blunt about the cost. About 65% of churn happens within the first 45 days, and a monthly churn rate of just 5% can erase roughly 46% of a customer base over a single year. When you cannot see the lifecycle in real time, you cannot intervene in time. The damage compounds because every lapsed subscription also distorts your forecast, your financial close, and the decisions you make from those numbers.

Spreadsheets and standalone billing add-ons do not solve this. They were never built to model a subscription lifecycle end to end, and they do not connect that lifecycle to your financial close. What you need is subscription management that is part of your core business system, not bolted onto it.

What Changes: Subscription and Plan Lifecycle Inside Your ERP

When subscription management is built into your ERP, the lifecycle stops being a series of manual events and becomes structured data your finance team can rely on. In the Kikan System platform, this is implemented as a first-class subscription engine that tracks every account on a plan. Here is what that looks like in practice, grounded in the actual code.

Plan Tiers and Pricing as Structured Records

Each subscription carries a plan name, a price per billing cycle, and a billing cadence. The system supports monthly, quarterly, and yearly cycles, so you can model the way your customers actually buy. A separate plan catalog holds the tier definitions, including a display name, a description, a price, the features included, a maximum user count, and a storage limit. This is the difference between a free text field that says "pro" and a real plan record that finance can reconcile.

Every subscription also records its current billing period start and end dates. Access and renewal are evaluated at that boundary, which is how recurring billing stays anchored to a calendar instead of to whoever remembered to send an invoice.

A Real Subscription Lifecycle, Not Just Active or Inactive

A mature subscription engine needs more than an on or off flag. The platform models a full set of lifecycle states, including active, trialing, past due, and canceled, alongside additional states for incomplete and unpaid scenarios. This matters because each state tells your team a different story:

A trialing subscription has not converted yet, so it belongs in a different forecast bucket than a paying one.
A past due subscription means a payment failed, and a recovery workflow should start now, not next month.
A canceled subscription may still have access until the period ends, which is a billing nuance, not a binary switch.

The platform supports scheduled cancellation through a cancel at period end flag, so a customer who cancels today keeps access through the cycle they paid for. It also supports immediate cancellation and reactivation, which resets the period boundaries and the next payment date. One active subscription is allowed per account, enforced at creation, so you never bill the same customer twice or carry a ghost plan.

Trials, Discounts, and Expiry Handled as Data

A trial is not a comment in a notes field. When a trial end date is set, the subscription enters the trialing state and the next payment date shifts to align with it. Discounts are recorded as a code and a discount amount on the subscription itself, so finance can see exactly why a customer pays what they pay. An expiring soon filter surfaces any active or trialing subscription whose period ends within a 30 day window, which turns renewal risk into a proactive list rather than a surprise.

An automated expiry job reviews active and trialing subscriptions whose period has ended and moves them to past due, while any subscription flagged for scheduled cancellation is finalized. This is the kind of routine work that should never require a human to open a spreadsheet.

Revenue Metrics Computed From the Source of Truth

The same module that owns the subscriptions also computes the metrics your leadership team asks for every Monday: total revenue, MRR, ARR, active and trial subscription counts, average revenue per user (ARPU), and churn rate. Because these numbers roll up from the subscription records rather than from a separate export, they are internally consistent. ARPU and MRR cannot disagree with each other, because they are derived from the same source.

A Real-World Scenario: A SaaS Firm in Tokyo

Consider a 40 person SaaS company in Tokyo running a project management tool on three plan tiers. They started with a billing spreadsheet maintained by one operations manager. For two years it worked, until it did not.

When the company crossed 200 paying accounts, the spreadsheet stopped being trustworthy. Quarterly and yearly plans were especially painful, because the next renewal date had to be calculated by hand for each cycle. A discount negotiated for one enterprise customer lived only in an email thread. By the time the finance team closed the quarter, MRR was off by roughly 12 million yen against the bank, and no one could explain the gap quickly enough for the financial close deadline.

After moving subscription management into their core business system, the change was structural. Plan tiers became records, not opinions. The billing cycle on each subscription drove the period end date automatically, so renewals no longer depended on memory. The expiring soon view gave the customer success team a 30 day lead time on every renewal. Churn showed up as a computed number rather than as a feeling, and the ARPU figure finally matched what finance recognized as revenue.

In their first close after the switch, the gap to the bank dropped to under 500,000 yen, and the reconciliation that used to take three days took under a day. For a firm of that size, that is real runway recovered, and it came from structure, not from hiring another analyst.

Why This Matters for Japan Businesses

For Japanese businesses, subscription management inside the ERP touches three pressures that matter right now. The first is DX. Digital transformation initiatives are judged on whether they make recurring operations measurable, and recurring billing is one of the clearest places to prove that value. The second is the financial close. Subscription revenue is recognized over time, and a clean lifecycle with explicit period boundaries makes period end far less painful for your accounting team.

The third is the broader shift to recurring billing. More Japanese companies, from media to manufacturing services, are moving from one-time sales to recurring models, and that transition exposes every weakness in how they track plans. A core business system that models the lifecycle, the tiers, and the revenue metrics in one place is what makes that transition safe.

There is also a scope point worth stating directly. The subscription engine described here is how the platform itself manages plans, pricing, and renewals for the accounts it serves. If your business needs to bill your own end customers on a recurring basis, that is a related but distinct capability, and your vendor should be able to tell you exactly where the line is. Honest scoping now prevents an expensive integration later.

Is This Right for Your Business?

Subscription management in your core business system is a strong fit when any of these is true:

You run more than one plan tier and you cannot reconcile them to revenue without manual effort.
You offer monthly, quarterly, and yearly cycles and the renewal calendar is breaking down.
You need MRR, ARR, ARPU, and churn as live numbers, not as a quarterly spreadsheet project.
Your finance close depends on subscription data that currently lives outside the ERP.

It is a weaker fit if you sell only one fixed price product with no renewals, or if your billing is so custom that no plan catalog could represent it. In those cases, a lighter tool may be enough, and an ERP-first approach would be overkill.

Frequently Asked Questions

What lifecycle states should a subscription engine support?

Look for at least active, trialing, past due, and canceled, with support for scheduled cancellation at period end. States like incomplete and unpaid matter for payment failures. The platform models all of these, plus a one active subscription per account rule that prevents duplicate billing.

How are MRR and churn computed?

They should roll up from the subscription records, not from an export. The platform computes MRR from active monthly subscriptions, ARR from yearly subscriptions plus MRR annualized, ARPU as revenue per active subscription, and churn as canceled subscriptions over the total. One source means the numbers always agree.

Can I use this to bill my own customers on subscription?

The subscription engine described here manages the plans and renewals for accounts on the platform itself. A separate customer facing recurring billing feature is a different scope. Confirm with your vendor what is included so you do not assume a capability that is not there. Kikan System is transparent about this distinction.

The Takeaway

Recurring revenue is only predictable when the lifecycle that produces it is structured. Plan tiers, billing cycles, period boundaries, trials, discounts, and revenue metrics belong inside your core business system, where finance can trust them and where churn becomes a number you can act on instead of a surprise you explain. If your subscription data still lives in a spreadsheet, that is the first thing to fix.

When you are ready to model subscriptions and recurring revenue the way they should be modeled, Kikan System gives you a platform with subscription and plan management built in, including lifecycle states, plan tiers, and computed MRR and churn. Start with the free plan for up to 2 users, no credit card required, at /en#get-started.