Subscription and renewal revenue in a product-company ERP

Many ERPs, including the core of NetSuite as most mid-market companies configure it, were built around a transactional model of revenue: an order, a shipment, an invoice, a single recognition event closely tied to a single delivery. This model handles a product sale cleanly. It does not naturally handle a subscription that bills monthly, recognises revenue over a service period, allows mid-term upgrades and downgrades, and needs to answer questions — monthly recurring revenue, churn, net revenue retention — that a transactional model was never designed to answer.

Companies that have added a subscription or recurring element to a historically transactional business — a software add-on to a hardware product, a service contract alongside a one-time sale, a genuine shift toward subscription as the core model — frequently discover that their ERP, entirely capable in principle of handling this, has never actually been configured to, and the resulting gap gets filled with spreadsheets that quietly become the real system of record for exactly the numbers investors and boards care about most.

Why this matters

Subscription and recurring revenue businesses are evaluated on a specific set of metrics — monthly recurring revenue, annual recurring revenue, net revenue retention, churn, customer lifetime value — and if these are calculated in a spreadsheet outside the ERP, they carry two compounding risks. They are not reconciled to the general ledger, meaning the metric investors see and the revenue finance reports can, and often do, disagree. And they are fragile to the departure of whoever built and maintains the spreadsheet, which is the same single-person dependency problem discussed elsewhere in this series, applied specifically to the numbers a board most scrutinises.

There is a revenue recognition compliance dimension too. Recognising subscription revenue correctly — over the service period, handling upgrades, downgrades, cancellations and multi-element arrangements appropriately — is a genuine accounting standard requirement, not just an operational nicety, and a spreadsheet-based approach is considerably harder to audit and substantiate than logic encoded and enforced in the system of record. This article describes recognition principles generally; specific treatment should be confirmed with a qualified accountant against current IFRS or applicable local standards for your structure.

And there is an operational cost that compounds over time: every manual step in calculating recurring revenue metrics is a step that has to be repeated every single period, forever, for a business model that by definition continues indefinitely. Unlike a one-time data migration problem, an unconfigured recurring revenue process is a recurring cost that never resolves itself.

At a glance: what a transactional ERP configuration misses

The pattern across every row is the same: transactional logic treats each sale as a discrete, complete event. Subscription revenue is inherently about an ongoing relationship with its own lifecycle, and forcing it through transactional logic either produces wrong numbers or requires the workaround spreadsheet this article is arguing against.

What works, and what to be honest about

What works:

Configuring genuine subscription billing and recognition logic within the ERP, rather than layering it on top with spreadsheets. Most capable ERPs, including NetSuite, have native or extendable functionality for recurring billing and ratable revenue recognition. The work is in configuring it correctly for your specific contract structures, not in accepting that the system cannot do this and working around it.

Defining MRR, ARR and related metrics with a single, documented calculation methodology, computed from the system of record. These metrics have enough definitional variation across companies — how annual contracts are normalised, how one-time fees are excluded, how multi-year deals are handled — that the specific methodology matters less than having exactly one, documented, and applied consistently, ideally computed directly from billing data rather than reconstructed manually each period.

Modelling the subscription lifecycle explicitly — start, upgrade, downgrade, pause, cancellation — as distinct, trackable events. This is what makes churn and retention analysis possible without manual reconstruction, and it requires the ERP or a closely integrated system to treat a subscription as a persistent entity with a history, not a series of unrelated transactions.

Reconciling deferred revenue as an active, monitored balance sheet item, not a residual plug. Deferred revenue in a subscription business is often material, and it should be reconciled with the same discipline as any other balance sheet account — traceable to the specific subscriptions and periods it represents, not a number that only balances because it was forced to.

Treating the transition from transactional to recurring revenue configuration as a genuine project, with accounting input from the start. This is not a configuration afterthought bolted onto an existing implementation — it involves real decisions about recognition policy that should be made with a qualified accountant, then encoded into the system, not decided informally by whoever is available.

What to be honest about:

This is genuinely more complex to configure correctly than transactional revenue, and shortcuts taken early tend to surface as painful rework later. Companies that add subscription elements incrementally, configuring just enough to get the first few contracts billed, frequently find that the shortcut does not generalise to the tenth or hundredth contract's variations, and by then the workaround is embedded in real customer relationships that are harder to unwind than a spreadsheet.

Multi-element and bundled arrangements are a genuine accounting complexity, not just a systems configuration question. If your contracts bundle a one-time implementation fee with ongoing subscription revenue, or hardware with a software subscription, the recognition treatment requires real accounting judgement about allocation, and this should be resolved as an accounting policy question before it is encoded as system logic, not the other way around.

Metric definitions genuinely vary across companies and even across investors' expectations, and there is no single universally correct definition of MRR or churn. The discipline is internal consistency and clear documentation of your specific methodology, not chasing an external standard that does not fully exist in the way people sometimes assume it does.

A spreadsheet-based interim solution is sometimes a reasonable, deliberate choice for a genuinely small subscription base, provided it is treated as interim. The failure mode is not using a spreadsheet at first — it is the spreadsheet quietly becoming permanent infrastructure for a growing subscription base without anyone deciding that it should be, which is the single-person dependency and audit-fragility problem compounding silently.

This intersects directly with the manual journal entry cost problem discussed elsewhere in this series. An unconfigured subscription revenue process typically generates a disproportionate volume of manual entries — manual deferred revenue calculations, manual proration for mid-term changes — precisely the kind of recurring, rule-based manual work that should be encoded in the system rather than repeated by hand every period indefinitely.

Decision framework: assessing and fixing your configuration

Run in order. Stop at the first match.

1. Is any part of your MRR, ARR, churn or retention calculation currently done in a spreadsheet outside the ERP?
If yes, this is the priority, regardless of how small the subscription base currently is. The risk compounds with growth and with time, and it is considerably cheaper to fix while the base is small than after it has scaled on top of the workaround.

2. Does your revenue recognition for subscription contracts follow a documented policy, reviewed by a qualified accountant?
If not, establish this before configuring anything further in the system. The accounting policy should drive the system configuration, not the reverse.

3. Are mid-term changes — upgrades, downgrades, pauses — currently handled as new transactions, or within a persistent subscription record?
If handled as disconnected new transactions, this is very likely producing incorrect metrics and recognition, and is worth addressing as a configuration priority.

4. Is deferred revenue reconciled with the same rigour as other balance sheet accounts, traceable to specific subscriptions and periods?
If it is a residual figure that simply balances rather than being actively reconciled, treat this as a control gap and address it directly.

5. Do you have bundled or multi-element contracts, and has their recognition treatment been explicitly resolved as an accounting policy question?
If this has not been explicitly addressed, resolve it with a qualified accountant before building further system logic around these contract types.

6. All of the above addressed — is your metric calculation still inconsistent period to period?
At this point the issue is likely definitional drift rather than a systems gap — check whether the calculation methodology has been applied consistently, or has quietly changed as different people have maintained it over time.

7. Configuration and policy sound — still spending significant manual effort each period?
Look specifically at proration and mid-term change handling, which is where manual effort in an otherwise well-configured subscription revenue process tends to concentrate.

Indicative cost and effort

Get a quote for a scoped assessment of your current configuration.

Frequently asked questions

Can NetSuite handle subscription billing and revenue recognition natively?
NetSuite has native and extendable capability for recurring billing and ratable revenue recognition, and the specifics of what fits your contract structures should be assessed directly against current product documentation and your actual contract terms, since capability and the right configuration approach depend on the details of how your subscriptions are structured.

Should we build our own MRR calculation, or use a dedicated subscription management tool?
This depends on subscription complexity and volume. A mid-market company with relatively standard contract structures can often achieve a reliable, system-derived calculation through proper ERP configuration alone. Higher contract complexity, high transaction volume, or a business where subscription management is the core product may justify a dedicated tool integrated with the ERP, following the same integration principles discussed elsewhere in this series.

How do we transition from a spreadsheet-based metric process without disrupting board reporting?
Run both in parallel for at least one full reporting cycle, reconciling the two and understanding any discrepancy before retiring the spreadsheet, rather than switching over abruptly and discovering a gap during a board meeting.

What is the most common mistake in these implementations?
Configuring subscription billing without resolving the underlying revenue recognition and metric methodology questions first — the system will faithfully implement whatever logic it is given, and a technically correct configuration built on an unresolved or inconsistent accounting policy simply automates the inconsistency at scale.

Does this apply if we only have a small number of subscription contracts today?
Yes, and arguably it is cheaper to address now than later. A small subscription base is the easiest point to configure this correctly, before contract structures proliferate and before a workaround spreadsheet has had time to become embedded, relied upon, and difficult to unwind.

Closing — Next steps

A transactional ERP does not naturally understand a subscription business, and the workaround most companies reach for — a spreadsheet calculating the metrics the system was never configured to produce — becomes more expensive and more fragile exactly as the subscription base grows, which is precisely when the metrics matter most.

The honest starting point is auditing where your MRR, ARR, churn and retention figures actually come from today. If any part of that calculation lives outside the system of record, that is the specific, addressable gap, and it is considerably cheaper to close now than after the next funding round or board meeting depends on a number nobody can fully reconcile to the general ledger.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication. Recognition treatment should be confirmed against current IFRS 15 / applicable local standards with a qualified accountant.

• IFRS Foundation, IFRS 15 Revenue from Contracts with Customers — https://www.ifrs.org
• Oracle NetSuite, subscription billing and revenue recognition documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Atypical Tech engagement experience, subscription revenue configuration across Iberia