SaaS Billing System Development: Metering, Entitlements, Revenue Recognition and Cost

SaaS billing system development costs $25,000 to $400,000. A flat-rate subscription MVP runs $25,000 to $45,000, a system with tiers, proration and tax runs $45,000 to $95,000, usage-based billing with metering and entitlements runs $95,000 to $200,000, and a multi-entity platform with ASC 606 revenue recognition runs $200,000 to $400,000 or more.

Four modules decide whether the project lands: metering, proration, entitlements and revenue recognition. Everything else on a billing requirements list, invoices, payments, reminders, reports, is ordinary software that a competent team estimates accurately.

Those four are where projects go over, and three of the four are missing from almost every guide written on this topic. This one prices all four and explains why each is hard.

SaaS billing development cost at a glance

Entitlements: the module nobody writes about

Entitlements are what the customer is allowed to use, and the billing system has to tell the product in real time. Budget $9,000 to $20,000 and 4 to 6 weeks. Skipping it is the most common architectural mistake in SaaS billing.

Here is the failure. Billing knows a customer downgraded from Pro to Starter. The product does not. The customer keeps the Pro feature for another six weeks until somebody notices. Run that in reverse and it is worse: a customer upgrades, pays immediately, and cannot use what they bought until a nightly job runs.

An entitlement service sits between billing and the product and answers one question: can this account use this thing right now, and up to what limit. It needs to handle:

• Feature flags per plan, so the product checks entitlement rather than plan name
• Quota limits with current consumption, since “10,000 API calls” needs a live counter
• Immediate propagation on upgrade, downgrade, cancellation, payment failure and reactivation
• Grace behaviour, because cutting access the second a card fails loses customers who would have paid
• Overage policy, deciding per plan whether exceeding a quota blocks, throttles or bills

The reason this gets missed is that billing and product are usually built by different teams, and entitlement is the thing in between. Decide who owns it in week one.

Usage metering: where the engineering actually is

Metering costs $14,000 to $35,000 and takes 6 to 10 weeks, more than any other module. The hard part is not counting events. It is counting them exactly once, in the right period, when they arrive out of order.

A meter event carries an event name, a customer identifier, a numeric value, an optional timestamp and an optional unique identifier for idempotency, per Stripe’s usage-based billing documentation. Those last two optional fields are where billing bugs come from.

Idempotency

Your service retries a failed request. Without a unique event identifier, the customer gets billed twice. At volume this is not an edge case, it is a weekly occurrence.

Event timestamps

If the timestamp defaults to arrival time rather than the time the usage happened, an event delayed past midnight on the last day of the cycle lands in the wrong invoice. Send the real usage timestamp, always.

Late and backdated events

A mobile client offline for three days sends its usage on reconnection. If the invoice has already been generated, you need a documented policy: credit note, next-cycle adjustment, or drop. Pick one before launch, not after a customer complains.

Aggregation windows

Sum, count, last-value and maximum produce very different bills from the same events. “Peak concurrent users” and “total user-hours” are both reasonable metrics and are not interchangeable.

Worth knowing that even Stripe’s own basic meters reconcile usage at invoice time rather than continuously, which means no live balance for the customer mid-cycle. If the product promises real-time credit burndown or a usage dashboard, that is a separate real-time aggregation layer, and it is a build decision rather than a configuration one.

Proration and mid-cycle changes

Proration costs $7,000 to $16,000 and 3 to 5 weeks. It looks trivial and generates more support tickets than any other part of a billing system.

The cases that need deciding explicitly:

• Upgrade mid-cycle: charge the difference now, or add it to the next invoice
• Downgrade mid-cycle: credit the unused portion, or let it run to period end
• Upgrade where metered usage has already accrued on the old plan’s rate
• Plan change on the same day as renewal
• Cancellation mid-cycle with a partial refund policy
• Annual plan changed to monthly, with unused annual value outstanding
• Quantity change on a per-seat plan, mid-cycle, several times in one period

Each of those is a product and finance decision before it is an engineering one. Get them written down and signed off by whoever owns revenue, because changing proration logic after launch means reissuing invoices.

Revenue recognition: the module that arrives late and costs most

ASC 606 revenue recognition costs $15,000 to $38,000 and 6 to 10 weeks. It is almost always scoped after the fact, usually when an audit or a funding round is six weeks away.

Cash collected and revenue earned are not the same number. An annual plan paid upfront is cash today and revenue spread across twelve months. Under the five-step model in Deloitte’s Roadmap on Revenue Recognition, a company identifies the contract, identifies the performance obligations in it, determines the transaction price, allocates that price across the obligations, and recognises revenue as each obligation is satisfied.

For a SaaS billing system that means:

• A deferred revenue balance that moves correctly as service is delivered
• Separate treatment for subscription fees, usage charges, one-time setup fees and professional services, since they are different performance obligations
• Contract modifications handled properly when a customer upgrades mid-term
• An audit trail from each recognised amount back to the contract and the invoice

A billing system that reports only cash collected will not survive diligence. Firms that want revenue reporting alongside product analytics usually read this data into a business intelligence layer rather than building finance dashboards into the billing product.

Cost breakdown by module

Two modules worth a note

Dunning is not a reminder email. It is a sequenced recovery workflow: retry on a schedule tuned to card decline reasons, escalate messaging, apply a grace period, then restrict access through the entitlements service. Involuntary churn from failed payments is recoverable revenue, and the retry schedule is the lever.

Tax is where scope creeps. US sales tax depends on economic nexus per state, EU VAT depends on customer location and B2B versus B2C status, and GST, reverse charge and digital services rules differ again. Almost nobody should build this. Integrate a tax engine and budget for the integration, not the logic.

Build custom or use Stripe Billing, Chargebee or Maxio

Buy below roughly $10 million in annual billing volume. Build above it, or wherever the pricing model is something the platforms cannot express.

Subscription billing platforms commonly charge a percentage of billing volume, often in the 0.5% to 0.8% range, sometimes with per-seat or tier fees on top. Modelling at an illustrative 0.7%:

Verify current vendor pricing before using these figures in a business case.

Volume is only half the decision. Build when the pricing model does not fit, and that is more common than it sounds: outcome-based pricing, hybrid commit-plus-overage contracts, reseller and multi-entity billing, revenue share with partners, or per-customer negotiated enterprise terms with ramp schedules. Buy when pricing is a standard subscription with some usage on top, because that is exactly what the platforms are built for and building it yourself buys nothing.

The middle path that often wins: keep the platform for subscription management and payments, build only the metering and entitlements layer it handles poorly, and let the platform invoice from your rated output.

Running costs

• Maintenance: 15% to 20% of build cost a year
• Infrastructure: $600 to $4,000 a month, driven by metering event volume more than customer count
• Tax engine subscription: per-transaction or tiered, depending on vendor
• Payment processing: standard card rates, plus a cost per retry attempt on some processors
• Finance and support time: someone handles failed payments, disputed invoices and credit notes every week

Where SaaS billing projects overrun

Entitlements bolted on after launch: Covered above, and it is the most expensive retrofit on this list because it touches the product as well as billing.

Proration rules never signed off: Engineering picks a default, finance disagrees three months later, and invoices get reissued.

Metering built without idempotency: Duplicate billing is the single worst bug class in this domain, because customers notice and trust does not come back easily.

Revenue recognition added under deadline: Six weeks before diligence is the wrong time to discover that deferred revenue was never modelled.

Migrating active subscriptions: The hardest part of the whole project. Live subscriptions have to move mid-cycle without double-billing anyone, skipping a renewal, or losing a trial end date. Run both systems in parallel for at least one full billing cycle and reconcile invoice by invoice before switching off the old one.

How Comfygen approaches these builds

Comfygen has delivered software since 2019, with 550+ projects for 400+ clients across 30+ countries and 97% client retention, under ISO 9001:2015, ISO/IEC 20000-1:2018 and ISO 27001.

On a SaaS billing build:

• Discovery starts with the pricing page and the three most unusual customer contracts, because those define what the rating engine has to do
• Proration rules are written down and signed off by whoever owns revenue before any code is written
• Entitlement ownership is settled in week one, with a named owner on both the billing and product sides
• Metering ships with idempotency keys and real usage timestamps from the first commit, not as a later fix
• Migration runs both systems in parallel for a full cycle with invoice-level reconciliation

Companies that need general ledger and AP alongside billing usually scope accounting software development as a connected system, and those building billing for a non-subscription business are better served by custom billing platforms designed around invoicing rather than recurring revenue.

Conclusion

Most SaaS billing projects are quoted on the visible parts. Invoices, payments, reminders and dashboards are easy to describe and easy to estimate, and they are not where the money goes.

The budget is decided by metering, proration, entitlements and revenue recognition. Three of those four are usually discovered mid-project, which is why billing builds have a reputation for doubling.

Before commissioning one, write down the proration rules, name the owner of entitlements, and say out loud whether the company will need audited revenue recognition within two years. Those three answers price the project more accurately than any feature list.

Frequently asked questions