What Is a Billing Run? A Practical Review Checklist
Understand how a billing run turns due contracts into invoices, where exceptions arise, and what to check before posting, delivery and collection.
A billing run processes the contracts or charges due for a defined period and creates the corresponding invoices. It may cover one customer, a group of customers or a wider billing population. The run can be scheduled or started by an authorized operator.
For example, Zuora describes bill runs as scheduled or ad hoc invoice generation. The exact boundaries vary by system: invoice approval, ledger posting, delivery and payment collection may be separate steps.
That distinction matters when someone asks whether billing is finished. An invoice can exist without having been sent. A delivered invoice can remain unpaid. A run can finish with some customers billed and others waiting on an exception.
What to establish before the run
Start with a named population: the legal entity issuing the invoices, the contracts in scope, the service periods being billed and the currencies involved. Keep the service period separate from the invoice date, due date and date the run is started.
A monthly subscription billed in advance and a usage contract billed in arrears can require different selections. A contract amendment may change the amount due for one period without changing an earlier invoice. Decide the treatment from the agreed terms and accounting policy before executing the run.
The preparation checklist should include these inputs:
| Input | Review question | Evidence to retain |
|---|---|---|
| Contract population | Which active contracts are due, and which are excluded? | Contract references and exclusion reasons |
| Prices and quantities | Do the stored terms match the agreed terms for this period? | Terms, effective dates and approved changes |
| Usage | Is the data complete for the service period? | Source export, cutoff and missing-data checks |
| Customer details | Is the invoice addressed to the correct entity and recipient? | Customer record and required references |
| Accounting treatment | Which accounts, dimensions and tax treatment apply? | Configured mappings and unresolved decisions |
| Previous billing | Has this contract and period already been billed? | Existing invoices, credits and run results |
An empty usage file needs an explanation. It could mean zero consumption, an incomplete export or a failed collection job. Those cases should not produce the same decision automatically.
A small example of reviewing the population
Consider this synthetic run for three contracts. All amounts are illustrative net amounts in EUR; tax and posting treatment must be determined separately.
| Contract | Expected charge | Finding before execution | Proposed treatment |
|---|---|---|---|
| Sample A | €100 fixed monthly fee | Terms and period agree; no earlier invoice found | Include in the reviewed run |
| Sample B | 200 units × €0.50 = €100 | Usage export is missing its final day | Hold until completeness is resolved |
| Sample C | €150 fixed monthly fee | An invoice already covers the same service period | Investigate the existing invoice; avoid a second charge |
The amount ready for this illustrative run is €100 before tax. Counting all three rows as billable would produce €350 and hide two different problems.
After execution, compare the actual result with the reviewed population. If Sample A failed, the expected €100 is still unbilled. If it succeeded but delivery failed, the invoice exists and the next action concerns delivery. Rerunning invoice creation would be the wrong recovery step.
Keep a separate result for each stage
An operational report should let someone answer each of these questions independently:
- Selection: Which contracts and service periods were included or held?
- Invoice creation and posting: Which documents were saved, and what is their actual posting status?
- Delivery: Which invoices were submitted for sending, and what delivery evidence is available?
- Collection: Which payments were requested, settled or left unresolved?
- Reconciliation: Do the saved invoices and payments agree with the relevant accounts and source records?
Salesforce's payment-run documentation describes a separate process for collecting outstanding invoices. The same distinction is useful when designing your own billing checklist: generating a receivable and collecting it are different events.
Revenue recognition also needs its own accounting basis. An invoice for a future service period does not, by itself, establish that all of the amount is revenue for the invoice month. Keep the billing result connected to the appropriate revenue or deferred-revenue treatment.
Where an assistant can help
An assistant can prepare comparisons that an accountant would otherwise assemble manually: contract terms against billing records, a usage export against the expected service period, or the proposed population against invoices already created.
Give it a defined output. For each exception, ask for the source references, the conflicting values and the decision needed. A note saying “customer data looks wrong” is difficult to act on. A row identifying a missing purchase-order reference on one customer's invoice is useful.
Keep the calculations reproducible. Quantities, rates and totals should come from the configured calculation or a checked script. The assistant can explain the result and investigate discrepancies. It should not silently invent missing usage or choose a new price to make the run complete.
Start with synthetic data and an explicit preparation-only instruction. Once the proposal is reviewed, use the accounting system's supported workflow for financial changes. Required approvals still apply; instructions in a chat do not replace them.
How this maps to Arfiti
Arfiti has shared operations for recurring contracts, recorded usage, billing previews and billing execution. Supported contract charges can produce AR invoices through its governed accounting infrastructure. Its built-in Billing Run agent is one way to orchestrate that work; an external assistant can use the supported tools under the applicable access and approval controls.
A preview is a proposal based on the data observed at that point. Execution must check the current state again. Review the saved result per contract, particularly when a run is only partially completed. Preserve the existing run and invoice references when investigating a retry.
Invoice delivery and payment collection have their own configuration and outcomes. Confirm the exact contract terms and downstream services needed for your workflow before assuming that the complete cycle is supported. The finance infrastructure overview and controls overview explain the underlying separation.
Measure the complete billing cycle
For a first evaluation, record the time spent preparing the population, resolving exceptions, reviewing invoices and correcting the result. Also record invoices left unbilled, delivery failures and credits caused by billing errors.
Keep collection performance separate. A customer paying late is a different problem from an invoice sent to the wrong recipient. Combining both into one “automation success” number makes the next improvement harder to identify.
Use the same ordinary and difficult cases when comparing the existing process with the assisted one. Faster preparation is useful only if the final invoices and remaining work are understood.
Describe your billing workflow, including the contract types, usage source and first exception you want to test. We are preparing to open access on 25 November. The form sends an enquiry for a personal reply; it does not create an account.
Related reading: Claude for AR teams, reviewing finance work as a controller, and building a journal proposal from multiple reports.