Building a subscription billing and entitlement system

This guide is for SaaS founders, CTOs and engineering leads scoping a first or next billing build, once the product has a pricing model to charge for. Our SaaS platform engineering guide covers the wider platform; this spoke goes deeper into the billing and entitlement system itself, after tenants are defined (multi-tenant SaaS architecture) and the MVP module list names billing as a line item (SaaS MVP architecture roadmap).

In this guide

• Billing and entitlements are two systems, not one
• How do billing state and entitlements stay in sync?
• The data model: five objects, one dependency chain
• Build vs buy: a decision framework
• Metering and usage-based pricing
• A sequencing plan for a billing and entitlement build
• Where AI fits in a billing and entitlement build
• What delivery record exists, and what does not
• Alternatives: who builds and runs the billing and entitlement layer
• Limits of this guide
• Frequently asked questions
• Next step

Billing and entitlements are two systems, not one

A billing system answers "what does this customer owe, and have they paid it": plans, prices, invoices, payment methods, taxes and refunds. An entitlement system answers a question asked far more often: "can this customer use this feature right now, and how much is left." The two must agree, but they are not the same code path. Billing runs on a monthly or annual schedule and tolerates seconds of latency; entitlement checks run on every request and need to return in milliseconds. Treating them as one tangled module is the most common reason the two drift: a plan downgrade updates the invoice but not the feature flag, or a cancelled subscription keeps access live for days.

How do billing state and entitlements stay in sync?

They stay in sync through events, not through a second system reading the first system's database. When a subscription is created, renewed, upgraded, downgraded, paused or cancelled, the billing system emits an event; an entitlement-update step consumes it and recomputes what the customer may access, independent of whatever triggered the change. Stripe's own Billing documentation describes this directly: an active subscription creates an active entitlement for each feature attached to the purchased product, and the application should check that entitlement, never the plan name, to decide what a customer can do. The practical rule follows: never let product code ask "is this customer on the Pro plan"; ask "does this customer have the export-to-CSV entitlement, and how many rows are left," because the plan can be renamed or overridden by a contract while the entitlement question stays stable.

The data model: five objects, one dependency chain

Keep the entitlement table narrow: a feature key, a limit or boolean, and the subscription it belongs to. Resist letting it carry pricing logic; pricing lives in the plan and invoice, access rules live in the entitlement. An enterprise contract that negotiates a custom limit becomes an override row on one subscription, not a new plan, so the base plan catalog stays small and readable.

Build vs buy: a decision framework

None of the three removes the need for an entitlement check in the product code; a billing platform computes what a plan should grant, but only the product knows which code path needs that answer.

Metering and usage-based pricing

Usage-based and hybrid pricing (a base fee plus metered overage) need a usage record that is idempotent and attributed to the right billing period before it reaches an invoice. Two rules keep this reliable: give every usage event a unique identifier so a retried write does not count twice, and roll usage up to the entitlement layer continuously, not only at invoice time, so a customer hits a hard limit before an invoice needs to say so. The entitlement layer, not the invoice, enforces the limit in real time; the invoice then reports what the entitlement layer already allowed.

What delivery record exists, and what does not

Netbase has built recurring, subscription-style billing inside a client product and carries financial and ERP modules inside its own and a client's SaaS platforms:

• Dey Page. A multi-state business directory where Featured Listing placements and a field-verification badge are sold as subscriptions, charged through the Paystack and Flutterwave payment gateways (Dey Page record).
• Cloodo Workspace. A Netbase Business Division digital workplace whose Cloud ERP module includes financial functions alongside CRM, HRM and AI modules in one workspace (Cloodo record).
• Cloud ERP for a US client (not named). Since 2020, offshore development and managing partner on a multi-tenant cloud ERP delivered as SaaS; its planned second phase covers financial management and reporting alongside point of sale, inventory and loyalty (cloud ERP record). This phase is described as planned, not delivered.

What does not exist. No published Netbase record describes a standalone metering or entitlement engine, a migration from one billing model to another (seat-based to usage-based, for example), or a published duration, cost or conversion figure for any billing or entitlement build. The framework above comes from general delivery practice and Stripe's and the PCI Security Standards Council's published documentation, not from one measured Netbase project.

Alternatives: who builds and runs the billing and entitlement layer

In Netbase custom development the client owns the IP created for it, and most projects run on fixed-price contracts agreed after discovery, with milestone-based, monthly team retainer or KPI-linked terms also offered where the scope fits. Netbase's own productized library includes a Cloud ERP module with financial functions, a growth-capability accelerator that can shorten the invoicing and reporting side of a build. The offer sits in SaaS development and web application development, starting from the SaaS product accelerator.

Limits of this guide

• No billing platform's plan model, pricing API or tax feature is described in full; read its own documentation before committing to it.
• No duration, cost or conversion figure is claimed; a project's real numbers depend on its pricing model, payment mix and scale.
• Tax calculation and remittance, chargebacks and revenue recognition are out of scope; each deserves its own specialist review.

Next step

Tell us your pricing model, including any usage-based or contract-override cases, and we will book a solution review to scope the billing and entitlement build in the right order. You can also see the SaaS product accelerator solution or browse more Netbase insights.

Related services and solutions