Payment runs and batches: recurring collection you can audit
Recurring collection in the Billing Engine is organised around payment runs and batches. Runs define per-site collection schedules with Direct Debit notice-day arithmetic (including bank-holiday adjustment); the next and subsequent batches are calculated automatically and kept current as memberships change, and each can be compared against the last batch so the movement in the total is explained before the money moves.
What does the capability do?
It turns “collect this month’s Direct Debits” from a spreadsheet-and-deadline exercise into a structured, inspectable process.
- Runs define the schedule. A payment run carries its site, its collection cadence, and the notice arithmetic Bacs collection actually requires: mandate notice days, payment request lead days, and whether notice days include weekends, with bank-holiday adjustment applied to the resulting dates.
- Batches group the work. Each cycle, the billing job generates recurring charges (from the live membership, freeze, and plan-change data) and groups them into payment request batches per run and per site.
- Ready means complete. A batch is marked ready on final commit of its generation, so downstream processing never picks up a half-built batch.
- Next and subsequent, always current. The platform automatically calculates the next batch and the one after it, and keeps both up to date as memberships change. A joiner, a cancellation, or a plan change is reflected in the forward batches the moment it happens, so the forecast is live, not a month-end surprise.
- Movement you can explain. The last collected batch can be compared with the next and the subsequent: new joiners, leavers, freezes and unfreezes, and plan changes are broken out per batch. Finance sees why the total moved before the collection runs, rather than reverse-engineering it afterwards.
- Charges reflect reality. Because charge generation reads the same records that drive freezes and scheduled price changes, a frozen member is charged their freeze fee and a due price change is already applied. There is no reconciliation step between membership state and billing state.
Why batch structure matters
Batches are the unit finance teams actually work with: this run, this site, this cycle. Structuring collection that way gives every question a place to be answered (which batch was this charge in, when was its cut-off, what state is it in) and gives failures a bounded blast radius. It is the same auditable, evidence-first design the Billing Engine applies across payments, refunds, and adjustments.
Why it matters commercially
Recurring revenue lives or dies on collection discipline. Notice periods miscounted around a bank holiday mean failed collections; half-generated runs mean missing revenue that surfaces as member complaints. Encoding the arithmetic and the batch lifecycle in the platform removes the two most common causes of both, and keeps the audit trail that regulated and multi-site operators need.
Frequently asked questions
What is a payment run?
How are Direct Debit notice periods handled?
Can each site have its own billing schedule?
Can I see how the next collection compares to the last?
More Billing Engine capabilities
Direct Debit mandates and the Bacs cycle: collected on time, every time
How the Billing Engine runs the full Bacs cycle: AUDDIS lodgement, advance notice, automated submission, ARUDD returns, ADDACS amendments, and cut-off arithmetic that maximises every collection.
Refunds and write-offs: money out, with guardrails
How the Billing Engine handles refunds and write-offs: refundable-balance validation, mandatory reasons, guarded status transitions, and a full audit trail.
See this working in a demo
Book a consultation and we will demonstrate this capability on the Billing Engine accelerator, against your own scenarios.
Book a demo