ERP for SaaS: How to Choose an Accounting System Built for Subscription and Usage Revenue

Pricing changes, a usage component gets added, a second entity opens, and the books start living in spreadsheets around the ERP. Most SaaS finance teams can point to the month this happened. The revenue schedule moved to a workbook, the usage file started arriving from the data team as a CSV, and the close picked up a few extra days of tying everything back together.

That moment usually means the accounting system was built around a different kind of business. Numeric's ERP replacement, the Financial Data Platform, was built for this one. It produces the accounting directly from the business events a SaaS company already generates, so contracts, usage, billing, and revenue stay connected from the deal to the financial statements. Most of the strain traces back to five accounting requirements, and the right system handles all five from the same records.

Key Takeaways

• SaaS companies feel ERP strain because of how they make money. Subscriptions, usage-based pricing, and multi-element contracts all push ASC 606 work into spreadsheets when the ERP has nowhere to hold the contract.
• A strong ERP for SaaS runs billing and revenue recognition on the same contract record, so the team stops reconciling one system against another every month.
• Reporting should come from the data itself, without adding a new chart of accounts segment for every cut leadership asks for.
• Numeric's Financial Data Platform derives journal entries from business events and keeps the full detail behind every number, and teams can adopt it in stages.

What Is an ERP for SaaS?

The phrase gets used two ways. A "SaaS ERP" usually means an ERP delivered as software as a service, hosted by the vendor and accessed through a browser on a subscription. That describes how the software is delivered, and nearly every modern ERP qualifies. The more useful question for a finance leader is whether the ERP is built for how a SaaS company makes money, because that decides how much of the close still happens in spreadsheets.

For a SaaS company, the accounting system carries core jobs. The first is the general ledger and the financial statements that come out of it. Billing comes next, turning contracts and usage into invoices. Revenue recognition under ASC 606 builds the schedules that move deferred revenue into earned revenue over time. As the company expands, consolidation pulls results together across entities and currencies. Reporting rounds it out, cut by the dimensions the business runs on, like customer, product, plan, and cohort.

A traditional ERP is strongest at the first job. The other four tend to get spread across add-on modules, a separate billing tool, and a set of spreadsheets the revenue accountant maintains by hand. The right ERP for a SaaS company keeps every one of those jobs connected.

The Accounting Requirements That Make SaaS Different

ASC 606 Revenue Recognition for Subscriptions

ASC 606 asks SaaS companies to identify each performance obligation in a contract, allocate the transaction price across those obligations using standalone selling prices (SSP), and recognize revenue as each obligation is satisfied. A customer who prepays for a year creates a deferred revenue balance on day one, and the team earns it down month by month as the subscription is delivered.

A plain monthly subscription is easy to handle. The work gets heavier when a single contract bundles a platform subscription, an implementation project, and a usage component. Each piece has its own SSP and its own pattern of recognition, so the revenue accountant has to split the price correctly and then track each element on its own schedule.

Contract modifications add another layer. When a customer upgrades mid-term, renews early, adds seats, or cancels, the team decides whether the change is a separate contract, a prospective change treated as a termination and replacement, or a cumulative catch-up adjustment. In many setups, the contract lives in the billing system or the CRM while the revenue schedule lives in a spreadsheet, so every modification means updating both and posting a manual entry to bring the ledger in line. Auditors then want to see how each treatment was decided. For a deeper walkthrough, see our guide on revenue recognition for SaaS.

Usage-Based and Hybrid Pricing

Usage-based pricing is now common across SaaS, either as the main pricing model or as a component layered onto a subscription. AI companies that bill per token or per API call are the clearest example, and plenty of traditional subscription businesses are adding usage tiers on top of their seat pricing.

The usage data itself usually lives in a data warehouse like Snowflake or in the product database, well outside the billing and accounting systems. Before anything can be invoiced, someone has to pull the usage, match each customer's activity to the right contract and rate, and confirm the totals. After invoicing, the revenue accountant checks that the revenue recognized lines up with what was billed. Each month that cycle repeats, and the workload climbs with every new customer and every new pricing rule.

Hybrid contracts are where this gets especially detailed. A customer with a subscription fee and a committed usage component needs both tracked against the same agreement, with revenue allocated across them correctly. When usage, billing, and revenue each sit in a different place, getting that right depends on careful handoffs every single month.

Multi-Entity and Multi-Currency Operations

International growth brings new legal entities, new currencies, and intercompany activity. Each entity keeps its own books, and month-end consolidation involves translating balances at the right rates, booking eliminations, and making sure intercompany balances agree on both sides.

Most established ERPs support multi-entity setups, and many teams lean on consultants to configure and maintain them. The workload grows when entities run different billing systems or when a contract is billed in one currency and recognized in another. Teams expanding into new regions should map out exactly how consolidation, currency translation, and intercompany activity will run before committing to a system.

Reporting by Customer, Product, and Plan

SaaS finance teams report on ARR, net revenue retention (NRR), revenue by cohort, and margin by customer or product line. Those numbers drive board decks, renewal forecasts, and pricing decisions, so the CFO needs them quickly and needs to trust them.

In a traditional ERP, the chart of accounts and its segments are the main place to store reporting detail. Every new cut means adding a segment, a class, or a custom saved search. Over time the chart of accounts grows, journal entry coding gets more involved, and the team ends up exporting to Excel to build the view leadership actually asked for. Most NetSuite reporting tools exist to work around exactly that limit.

Audit Readiness and Traceability

Auditors want to trace each revenue number back to the contract behind it. For a SaaS company, that means connecting the revenue recognized in a period to the specific customer agreement, the invoices issued against it, the usage that drove variable charges, and the cash that came in.

When billing, revenue recognition, and the general ledger run in separate systems, audit prep becomes a project of its own. The team pulls contracts from the CRM, invoices from the billing tool, schedules from spreadsheets, and entries from the ledger, then lines them up by hand to show the auditor a complete trail. The more tightly those records are connected inside the accounting system, the faster the team can answer each request.

Signs Your SaaS Company Has Outgrown Its Current Accounting System

These patterns tend to show up at companies that started on QuickBooks or Xero and have since grown into subscription and usage revenue, multiple entities, or more detailed reporting needs. They also appear in generic setups where a core ledger has picked up several disconnected tools over the years. If you are weighing the first move up from a small business system, our comparison of NetSuite vs QuickBooks is a useful starting point.

• Revenue schedules live in spreadsheets. The team maintains ASC 606 schedules in a workbook outside the system, so every upgrade, renewal, or credit means updating the file and posting an entry to match.
• Manual reclasses happen every close. Recurring adjustments to move revenue between accounts, products, or entities suggest the system is capturing transactions in a way the team has to correct later.
• Invoicing depends on engineering. Usage invoices require a custom query or a request to the data team before billing can go out, which puts a core finance process on someone else's schedule.
• New reporting requests take days. A question about revenue by product or customer turns into an export, a few lookups, and a new spreadsheet that has to be refreshed again next month.
• The stack keeps growing. Each new need brings another point solution for billing, revenue, or reporting, along with another integration to maintain and another subscription to pay for.

One or two of these on their own may be manageable. When several show up together, the accounting system has usually become the constraint on how fast the finance team can close and report.

How to Evaluate an ERP for a SaaS Business

This checklist is built to take straight into a vendor process. Each row names a criterion, explains why it matters for a SaaS company, and gives the questions worth asking on a demo call.

On the integrations row, ask each vendor to walk through a real connection end to end, the way a NetSuite integration with Stripe or Salesforce would run in your environment today.

Your Options for SaaS ERP

Which option fits depends on the revenue model, the pace of growth, and how much of the accounting the team wants the system to produce for them. Three broad paths are available today.

Legacy Cloud ERPs (NetSuite, Sage Intacct)

NetSuite and Sage Intacct are common choices at venture-backed SaaS companies. Both are cloud-delivered, both support multiple entities, and both have large ecosystems of partners and add-on modules.

For revenue recognition, NetSuite offers Advanced Revenue Management (ARM), an add-on module that handles ASC 606 scenarios with its own configuration. Billing at many NetSuite customers runs through Stripe or a dedicated billing platform, and the accounting team reconciles that system against the revenue schedules in the ERP.

These systems serve many SaaS companies well, and the total cost reflects the full setup. That usually includes the base subscription, the revenue module, billing connections, and implementation partners. For a closer look at the numbers, see NetSuite pricing and NetSuite implementation cost.

AI-Native ERPs (Rillet, Campfire)

Rillet and Campfire are newer general ledgers aimed at SaaS and technology companies. Both offer modern interfaces and AI features designed to reduce manual work.

Under the hood, they run on the same traditional model as every ERP before them, built on the general ledger, journal entries, and a chart of accounts. Teams evaluating them should apply the same revenue recognition and usage questions from the checklist above. For a side-by-side look, see Rillet vs Campfire.

An ERP Replacement Built on Data-Centric Accounting

The third path changes where the accounting starts. With data-centric accounting, the system takes in the business events themselves, such as a signed contract, a usage record, an invoice, or a payment, and derives the accounting from them. Because each event keeps its full detail, reporting and traceability come from the same records the accounting was produced from.

How Numeric's ERP Replacement Handles SaaS Accounting

Numeric's ERP replacement, the Financial Data Platform, is a data lakehouse with accounting intelligence built on top. It connects to the systems a SaaS company already runs on, including Stripe, HubSpot, Salesforce, Ramp, Brex, bank feeds, and data warehouses like Snowflake, and produces the accounting from the business events those systems send. It does the job of the ERP, with the general ledger as one output of the system.

For the accounting team, the day-to-day work looks different in a few concrete ways. Journal entries are derived for you from each business event, so the team spends its time reviewing and approving the accounting. The team defines its policies as rules and lets the system run from there, and it can configure treatments, mappings, and reports without an admin or engineer. Revenue schedules build from the contract and the usage behind it. Reporting slices directly from the data, without an Excel export or a new chart of accounts segment. And each number carries its lineage back to the source record, which gives auditors a clear trail from the financial statements to the contract.

Billing and Revenue on One Contract Record

Billing and Revenue is included in the Financial Data Platform, so billing and ASC 606 revenue recognition run on the same contract record. Deal terms come in from Salesforce or HubSpot. The platform matches each usage event from the warehouse to the right contract and flags any usage that matches no contract before month-end, so it gets billed. It also allocates bundled deals across subscription, services, and usage based on SSP. When a customer upgrades, renews early, cancels, or receives a credit, billing and revenue update together. Our guide to revenue recognition automation goes deeper on how this works.

How the Financial Data Platform Covers All Five Requirements

All five requirements covered earlier trace back to one root cause. A traditional ERP records each business event as a journal entry, so the contract terms, usage, and customer detail behind it get flattened in the GL and end up in the billing tool, the warehouse, or a spreadsheet. The Financial Data Platform resolves all five the same way, by producing the accounting from the business events themselves.

• ASC 606 revenue recognition runs from the contract itself, with SSP allocation, variable consideration, and contract modifications handled on the same record the invoices come from.
• Usage-based and hybrid pricing draws on warehouse usage that is matched to each contract and turned into invoice lines and revenue, with unmatched usage flagged for review.
• Multi-entity and multi-currency operations are supported natively, with consolidation produced from the same data. Intercompany and transfer pricing arrangements at the most complex level are outside what the platform supports today, so teams with heavy intercompany activity should walk through those scenarios during evaluation.
• Reporting by customer, product, and plan comes straight from the underlying records, so a new reporting cut leaves the chart of accounts as it is.
• Audit readiness improves because each revenue figure keeps its lineage to the contract, invoice, and usage behind it.

The platform also fits how finance teams are starting to work with AI. The Numeric MCP connects AI assistants to the platform so they can read reports and help with tasks, working from the same governed data the accounting team uses.

Built Technologies on the Financial Data Platform

Built Technologies, the real estate finance platform used by more than 340 lenders, shows what this looks like in practice. In early 2026, Built moved its accounting onto Numeric's Financial Data Platform, and the platform now takes in full transaction records straight from Built's own product. The team freed two FTEs' worth of bandwidth from billing and revenue work and delivers invoices to customers four business days earlier. Controller Asia McKnight put it this way: "We're almost operating in a different century, it feels like, from a data perspective." The full story is in the Built case study.

Who It Fits and How Teams Get Started

The strongest fits are SaaS, fintech, and usage-based revenue businesses, especially teams whose contracts change often or who operate across several entities and currencies. On cost, the Financial Data Platform usually comes in at about the same as, or less than, what teams pay today for NetSuite plus the point solutions layered on top, with more functionality.

Adoption is staged, and teams run it in parallel with their current setup before moving over. For a team wary of being early on a new system, that parallel run is the safeguard, since the books stay where they are until the new numbers tie out. A team can start on one Numeric product, such as Billing and Revenue, Cash Management, or Close & Analytics, and bring the rest of its financial data onto the full Financial Data Platform when the case is clear. Billing and Revenue on its own runs alongside NetSuite, which it requires as the accounting system today.