Subscription Billing manages the full arc of recurring commerce. It holds subscription plans and pricing, including flat recurring fees, tiered and volume pricing, per-unit rates and hybrid plans that combine a fixed platform charge with metered consumption. It performs usage metering, ingesting usage records and rating them against the applicable price, and it handles the events that make recurring billing hard in practice: proration when a subscription starts, stops or changes part way through a period, and mid-term changes such as upgrades, downgrades, quantity changes and plan swaps.

On the collection side it runs invoicing across billing cycles, consolidating recurring charges, metered usage and one-off items into a single invoice, and it drives dunning for failed or late payments with configurable retry and reminder sequences. Underpinning all of this is ASC 606 revenue recognition, which produces a revenue waterfall so that cash billed and revenue earned are kept as distinct, reconcilable views of the same contract.

The model is built around a small set of durable entities. A customer, resolved from the shared customer master, holds one or more subscriptions. Each subscription is composed of subscription items, and each item references a plan and a price that themselves point back to a product in the product master. This separation matters: a plan describes what is sold and how it is charged, a price fixes the rates and currency, and the subscription item captures the specific quantity and term a given customer has agreed to.

Consumption is recorded as usage records against a meter, which are rated into billable quantities and priced at each cycle. Billing produces invoices and invoice lines, which in turn generate payments and, where collection fails, dunning states. In parallel, every charge is decomposed into one or more performance obligations, each with a revenue schedule that contributes to the revenue waterfall. Because the module runs on PostgreSQL 16 through Prisma 7, these relationships are enforced at the data layer, so a subscription change, its resulting proration and its revenue impact remain consistent rather than drifting apart in separate systems.

The central process is the lifecycle of a subscription. A customer is placed on a plan, at which point the module establishes the subscription items, the initial billing schedule and the opening revenue arrangement. As the relationship evolves, mid-term changes are applied against the live subscription: an upgrade raises entitlement and price immediately or at the next cycle, a downgrade or cancellation reduces it, and the module computes the proration credit or charge for the unused or newly used portion of the period.

On each cycle the billing run gathers recurring fees, rates accumulated usage, applies prorations and discounts, and issues invoices. Collection follows, and where a payment fails or falls late the dunning workflow steps through its retry and reminder sequence, escalating and, if configured, suspending service. Renewals extend the term, while non-renewal and cancellation close it out and settle any final proration. Each of these events is not only a billing action but a revenue event, so the module keeps the billing timeline and the recognition timeline in step throughout the contract.

The functional depth of the module is in its accounting treatment. It implements the five-step ASC 606 model: identifying the contract, separating the distinct performance obligations within it, determining the transaction price, allocating that price across obligations by their standalone selling price, and recognising revenue as each obligation is satisfied. For subscriptions this typically means recognising a recurring fee rateably over the service period while metered usage is recognised as consumed, with any upfront or one-off elements handled on their own pattern.

Mid-term changes are treated as contract modifications, so an upgrade or downgrade reallocates the remaining transaction price rather than simply changing the next invoice. The result is a revenue waterfall that shows, period by period, how deferred revenue is drawn down into recognised revenue, alongside the billed and collected position. This gives finance a clean split between cash and earnings, an auditable trail from contract to journal, and the controls needed to defend the numbers: reconciliations between billed, deferred and recognised amounts, and consistent treatment of prorations, credits and cancellations.

Subscription Billing is deliberately narrow and well connected rather than self-contained. It reads the customer master for the billing party and its commercial terms, and the product master for the underlying products that plans and prices are built on, so there is one definition of a customer and a product across the suite rather than a billing-specific copy that can fall out of date.

Its most important relationship is with Accounting & Control. Invoices raised here become accounts receivable there, payments and dunning outcomes update the same balances, and the performance obligations and revenue schedules feed revenue recognition and the general ledger directly. This means the revenue waterfall the module produces is not a standalone report but the source of the recognised and deferred revenue postings in the books. The effect is a straight line from a plan change made by a commercial user to the receivable, the recognised revenue and the audit trail, without re-keying or reconciliation between disconnected tools.

As across Nashua 360, AI Workers are first-class users of this module, operating through the same data model and permissions as people. They answer conversational queries over billing data, resolving questions such as which subscriptions are in dunning, how much usage revenue a cohort generated, or how a given upgrade was prorated, by reading the live records rather than a static extract. They also execute actions within their granted scope: applying a plan change, issuing a credit, triggering a billing run for a segment, or advancing a dunning sequence.

They add most value in oversight and preparation. AI Workers run anomaly and exception detection across metering and billing, flagging usage spikes, prices that fail to rate, invoices that diverge from the expected pattern, or revenue schedules that do not reconcile to billed amounts. They perform document and data extraction, reading order forms or negotiated contracts to propose the plans, prices and obligations that should be set up. And they provide decision support on pricing and churn while acting as an approval or review node in workflows, checking a large credit, a non-standard proration or a contract modification against policy and either clearing it or routing it to a person, with every action attributed and logged.