Billing Run
What It Is
A billing run organizes a defined piece of membership renewal work. It selects terms ending within a date range for one program, classifies candidates and records the actions proposed for them. The administrator reviews that plan before execution, rather than discovering its scope only after orders or notices have been requested.
A run can copy a reusable template or use directly supplied filters and action choices. Its own stored settings preserve the selected work independently of later template changes. The planning date determines whether a candidate is still renewing or has passed grace and lapsed. Execution then tracks each action and its outcome through a durable background job.
What It Is Not
The run does not own invoices, prices or payments. Membership prepares the renewal offer; Commerce and Accounting perform their parts of order and financial processing. A notice action is a request to Platform communications rather than proof that a message reached a member. The run therefore coordinates renewal work without making every external seam operational by itself.
How It Is Used
An administrator creates the run, selects its ending-date range and plans it against a business date. They review candidate and action counts before asking for execution. Replanning inserts newly identified actions without discarding the existing action record. Readers can inspect the run without permission to perform these changes.
Execution prepares renewal orders through the same membership preparation path used by checkout. Drops use the term-termination behavior, and communication actions request the configured messages. A changed term makes its planned action stale. External order placement is currently unwired, organization notice recipients are unresolved and communication purposes do not yet produce sent notices. These delivery limits remain visible even when the run and its plan exist.
Its Facets
Billing template. Program, filters, requested actions and the closing reason form a reusable definition. A run that drops members requires an applicable termination reason.
Filters and actions. The run copies its selections. Do-not-renew and do-not-drop affect action planning rather than necessarily removing the term from the candidate list.
Candidates and classes. Ending committed periods from principal holdings are considered. Configuration filters, later periods, suspension and open-ended terms affect eligibility; grace distinguishes renewing candidates from lapsed candidates.
Planned actions. Term references, planned versions, action kinds and reminder numbers identify the work. Outcomes retain whether execution completed, skipped, encountered stale facts or failed.
Statistics. Counts summarize candidates, exclusions and selected actions, allowing review of both the intended workload and recorded result.
Status. The run’s state limits planning, cancellation and execution. Executed is not an irrevocable terminal state: another execution request can create a job while settled actions remain settled.
Execution job. Background processing retains progress and uses a failure consequence to return the matching executing run to planned. A job that never starts still needs reconciliation, which is not deployed for this module.
Recurring run. A scheduled definition derives an occurrence’s ending-date range from configured offsets and can request execution after planning. It uses the association’s time zone for the occurrence.
How It Relates
Terms supply candidates, and member settings influence planned actions. Checkout preparation supplies renewal eligibility and purchase details. Termination supplies the closing action. Commerce, Platform communications and durable jobs provide the external services required for execution; expiry attention separately highlights members whose renewal still needs action.
What It Could Become
The product should choose an organizational notice recipient and use actual card expiry before issuing card warnings. It should complete the external ports and reconcile execution jobs that fail to start. A reviewable file of planned actions could also help administrators assess a season’s work before committing to execution.