Preparing Your ERP for Modern Revenue Models

Most ERP environments were implemented around a business model the organization has since outgrown. The chart of accounts, the billing schedules, the revenue recognition rules: all of it was configured for how the company sold five or ten years ago. Since then, pricing moved toward subscriptions, usage, services, and hybrid combinations of all three, and the ERP is still running the playbook from the old deal.

Preparing your ERP for modern revenue models means deciding, deliberately, what stays inside the ERP core, what gets handled around it, and when it's worth extending the platform rather than customizing it or falling back on manual work. Get that decision wrong and you end up either over-customizing a system that becomes unmaintainable at the next upgrade, or under-supporting it and pushing the gap onto spreadsheets and tribal knowledge.

This article lays out that decision framework for finance and IT leaders running NetSuite or any ERP, using it as a practical guide rather than a sales pitch for any particular tool.

Why do ERPs struggle to support modern revenue models?

ERPs struggle with modern revenue models because they were architected around a stable, transactional view of revenue: an order, an invoice, a payment. Subscriptions, usage, and hybrid pricing introduce variability the core financial ledger was never designed to absorb on its own, so every new pricing pattern shows up as a request to add fields, add scripts, or add a workaround.

A traditional ERP core is built to be a system of record: accurate, auditable, and stable. That stability is the point. General ledgers, financial statements, tax calculations, and multi-entity consolidation all depend on a data model that doesn't shift shape every time the business tries something new commercially.

Modern revenue models do the opposite. A usage-based contract might generate hundreds of thousands of billable events in a single month. A hybrid deal might combine a flat subscription fee with metered overages and a mid-term upgrade. A services engagement might bill milestones that don't map cleanly to a fixed schedule. None of that is inherently incompatible with an ERP, but none of it looks like the orders and invoices the system was tuned for either.

The result is a familiar pattern: finance teams start adding custom fields to capture what the ERP doesn't natively track, IT starts writing scripts to reconcile the gaps, and the "revenue model" quietly becomes a set of spreadsheets and institutional knowledge sitting next to the ERP rather than inside it. For a closer look at where this pattern shows up in consumption billing specifically, see how commercial logic ends up in the wrong place when pricing moves to consumption.

What are the signs your ERP has outgrown its original business model?

The clearest sign your ERP has outgrown its original business model is that closing the books has become an exercise in manual reconciliation rather than confirmation. If finance is rebuilding numbers by hand every month instead of validating what the system already produced, the ERP is no longer keeping pace with how the business sells.

A few other signs tend to show up together:

• Every new pricing idea becomes an IT project. A sales or product leader wants to test a usage tier, a credit pool, or a ramped multi-year deal, and the answer is "let's scope that with engineering" instead of "let's configure that this week."
• Revenue recognition runs on a side calculation. Finance keeps a parallel schedule outside the ERP because the system can't allocate revenue correctly across a hybrid contract, then manually posts journal entries to true it up.
• Contract amendments trigger cancel-and-rebill cycles. A renewal, a seat change, or a mid-term upgrade doesn't flow through cleanly, so the team cancels the original transaction and rebuilds it, losing the audit trail in the process. The downstream effect on billing accuracy is covered in more detail in why booking and billing numbers never agree.
• Custom code has become the real system of record. Nobody fully understands what the integration scripts do anymore, and changing them feels riskier than leaving them alone.
• Headcount is scaling faster than deal volume. RevOps or billing operations keeps growing to manually cover a process that should scale on its own.

Any one of these is a nuisance. Several of them together mean the ERP's original configuration and the business's current revenue model have drifted apart, and closing that gap with more people is a temporary fix, not a structural one.

Should you extend, customize, or work around your ERP?

You generally have three options when your ERP can't natively support a revenue model: customize the ERP core to fit the new process, extend the platform with a purpose-built layer for that specific function, or keep the process manual outside the system. Each has a real cost, and the right choice depends on how core the capability is to the ERP's job versus how specialized and fast-changing it is.

Customizing the core means writing scripts, workflows, or custom objects directly inside the ERP to handle something it wasn't built for — a usage rating engine bolted onto the general ledger, for example. It can work in the short term, but customization inside the financial core compounds. Every platform upgrade has to be re-tested against the custom logic, every departure of the person who wrote it is a knowledge loss, and every new pricing wrinkle adds another layer on top of the last one. Independent research on ERP implementations bears this out: in one 2026 survey of ERP buyers, roughly 21% pursued heavy customization at implementation, and that group is the one most associated with accumulated technical debt and upgrade burden, versus the 45% who chose a moderate approach balancing fit against long-term maintainability.

Extending the platform means adding a dedicated, purpose-built capability around the ERP for the function that's causing the strain — usage metering, complex quoting, credit and wallet management — while keeping the ERP as the system of record for the financial outcome. The ERP still closes the books and holds the ledger; it just isn't asked to also be a high-volume event processor or a real-time rating engine.

Working around it manually means spreadsheets, side calculations, and people who remember how last quarter's exception was handled. It's the default option because it requires no decision at all, and it's also the option that scales worst. Manual work grows in direct proportion to deal volume and pricing complexity, so the same fix that covers this quarter's exceptions becomes untenable at twice the volume.

None of the three options is universally wrong. The mistake is defaulting into one of them — usually customization or manual workarounds — without weighing it against the others for the specific capability in question.

What belongs inside the ERP, and what belongs around it?

What belongs inside the ERP is anything that defines the financial system of record: the general ledger, final revenue recognition schedules, tax treatment, multi-entity and multi-currency consolidation, and financial reporting. What belongs around the ERP is anything specialized, high-volume, or fast-changing: raw usage event capture, real-time rating and metering, complex quote configuration, and credit or prepaid balance tracking.

This is close to what Gartner described over a decade ago as postmodern ERP: rather than one monolithic system trying to do everything, a reliable financial core stays in place while specialized, often cloud-based applications handle the functions that change quickly or operate at a different scale. As one analysis of that framework put it, established core processes are "a massive bundle of reliable, bulletproof business processes" that don't need to be ripped out just because a company is modernizing elsewhere. The same logic applies to revenue models: the core doesn't need to become a usage-rating engine to support usage-based pricing. It needs to receive clean, already-rated data from something that is built for that job.

A useful test is to ask two questions about any given capability. First, does this function need to be the auditable, permanent financial record, or does it need to be fast, flexible, and iterated on constantly? Second, does the volume or shape of this data match what a general ledger is built to hold, or does it look more like an event stream?

Contract terms, final invoices, and recognized revenue belong in the ERP because they need permanence and auditability. Raw usage events, real-time rate card testing, and prepaid balance drawdowns belong around it because they need to move fast and scale independently of the close process — the architecture behind that separation is what keeping engineering out of the billing motion is really about. When teams try to force the second category into the first, that's where governance limits, transaction ceilings, and brittle custom scripts start to appear, not because the ERP is deficient, but because it's being asked to do a job it wasn't built for.

When does extending your ERP make more sense than customizing it?

Extending your ERP makes more sense than customizing it whenever the capability in question is likely to keep changing after go-live. Revenue models rarely stay static: rate cards get tested, new tiers launch, credit programs evolve. Customization freezes a specific version of that logic inside the core; extension keeps the logic configurable outside it while still feeding the core clean results.

A rough rule of thumb: if a finance or RevOps leader would need to file an IT ticket to make the next change, that's a signal the logic is sitting in the wrong place. Pricing and usage rules that live in application code require an engineer to touch every time the business wants to test something. The same rules, sitting in a configurable layer built for that purpose, let a business user make the change directly.

Extension also tends to win when volume is unpredictable or growing quickly. A capability built to handle today's usage volume in custom scripts often breaks quietly at 5x or 10x scale, right around the time the business can least afford billing errors. A purpose-built layer designed for high-volume processing doesn't need to be re-architected every time the company's usage grows.

Customization can still be the right call for genuinely one-off, stable requirements: a specific tax jurisdiction rule, a reporting dimension unique to the business, something unlikely to change again soon. The distinction is between configuring something once and stabilizing it, versus building something that has to keep flexing every quarter. The former is what ERPs are good at. The latter is what compounds into the technical debt showing up in that customization research above.

How do NetSuite and Sage Intacct compare on supporting modern revenue models?

NetSuite and Sage Intacct both offer native modules for subscription and recurring billing, and both handle straightforward subscription revenue recognition well out of the box. Where they converge is the same place every ERP converges: usage-based, consumption-based, and complex hybrid models push past what either platform's core billing and revenue modules were built to handle natively.

NetSuite offers Advanced Revenue Management for allocating and recognizing revenue across multi-element arrangements. These modules are capable for standard recurring revenue: flat subscriptions, straightforward proration, standard renewal cycles. They start to strain under high-volume usage data, because the platform's transaction-processing model is built around discrete financial records, not a continuous stream of metered events. Sending millions of raw usage records into the ERP as individual line items is not the workload the system was designed around.

Sage Intacct provides Contract and Subscription Billing along with its own revenue recognition engine, well suited to the recurring, milestone, and multi-element arrangements common in services and subscription businesses. Like NetSuite, it's built to be a strong financial system of record, not a real-time metering or rating platform, so the same friction shows up when usage volume or hybrid complexity climbs.

The comparison isn't about which platform is more capable in isolation. It's that both are, correctly, financial systems of record first. The gap they share is the same gap this whole framework addresses: usage capture, rating, and complex deal configuration are functions that work best living around a clean ERP core rather than being forced inside it, regardless of which of the two platforms is running the books.

What does a practical decision framework look like?

A practical framework starts by mapping each revenue-related function your business needs against two axes: how core it is to the financial system of record, and how frequently the underlying logic changes. Functions that are both core and stable belong in the ERP. Functions that are either specialized or fast-changing belong around it, in a layer built for that purpose.

Here's how that mapping tends to shake out in practice:

Once that mapping is done, apply the extend-versus-customize test from the previous section to anything sitting in the "around the ERP" column: is the logic likely to change again, and does the volume make sense for a general ledger to absorb directly? If either answer points away from the core, that's a candidate for a dedicated layer rather than a custom build inside the ERP.

The last step is sequencing. Not every gap needs to be closed at once. Start with whatever function is generating the most manual reconciliation work today — usually usage capture or revenue allocation on hybrid deals — and address that first. A phased approach, closing the highest-cost gap before moving to the next, tends to outperform a single large re-platforming project, both in speed to value and in how much cross-functional coordination it demands.

Key takeaways

Most ERPs weren't built for the revenue model running through them today, and that's not a flaw in the platform. It's a mismatch between a system designed for stability and a business model that keeps evolving. The fix isn't a single choice between customizing everything or accepting manual workarounds forever. It's a deliberate mapping of what belongs in the financial core and what belongs in a purpose-built layer around it, followed by a clear-eyed test of whether any given gap is worth extending, worth a one-time customization, or genuinely not worth solving yet.

NetSuite and Sage Intacct both do the core job well: closing the books, holding the ledger, recognizing standard subscription revenue. The functions that strain both platforms — usage capture, real-time rating, fast-changing deal structures — are the ones worth evaluating for a dedicated extension rather than a custom build. Get that split right, and modernizing your revenue model stops being a recurring ERP project and becomes a repeatable pattern the business can lean on every time pricing changes again.