The Invoice That Does Not Repeat Itself
There is no recurring invoice in this product. No schedule, no template, no next-run date. A monthly retainer for forty clients is forty invoices somebody creates by hand, every month, forever — and the failure mode is not that one is wrong. It is that one is missing.
Some absences cost you accuracy. This one costs you revenue, and it does so silently, because nothing anywhere notices an invoice that was never raised.
The position, up front
Invoices are created individually. There is no recurrence of any kind, and no template that fires on a date. If a material part of your revenue is contracted and repeating, you need a monthly checklist owned by a named person and reconciled against your client list — because the system will not tell you that client thirty-seven was missed, and neither will client thirty-seven.
The asymmetry that makes this expensive
Consider the two ways a manual invoicing process fails.
An invoice raised wrongly gets found. The client reads it, disagrees, and calls. The correction is annoying and it happens.
An invoice not raised at all is found by nobody. Your client does not chase an invoice they never received. Your ageing report cannot show a receivable that was never created. Your revenue for the month is simply smaller, and it looks like a smaller month.
Every other error in invoicing has somebody on the other side who wants it corrected. A missing invoice has nobody at all.
That asymmetry is why recurring billing exists as a feature category, and it is why a manual process for repeating revenue needs a control that a manual process for one-off revenue does not.
What the product gives you to work with
Numbering is handled properly, which matters more than it sounds. Invoice numbers come from a sequence held per organisation, per document type, per prefix and per year, zero-padded. So creating forty invoices by hand on the first of the month produces forty correctly ordered numbers with no gaps and no collisions, even if two people are doing it at once.
Everything else about the repetition is yours. The customer list, the amounts, the dates, and the discipline.
Why a Canadian services business hits this hardest
Because so much of the market here runs on contracted recurring revenue rather than transactional sales — managed services, retainers, maintenance agreements, monthly support contracts, subscription arrangements of every kind.
For that shape of business the invoice run is the revenue process. It is not an administrative task that follows the work; it is the moment the work becomes money, and it happens on the same day every month for the same list of people.
It is also, precisely because it is routine, the task most likely to be done in a hurry by whoever is available. Which is where the missing one comes from.
The control that closes it
A monthly billing run without a billing feature
- Keep the recurring client list outside the system, and treat it as the source of truth. Not a mental list, not a folder of last month's invoices. One list, with the amount and the day of the month, owned by one person.
- Reconcile count against count, not amount against amount. After the run, count the invoices raised in that period and compare to the length of the list. A total that looks about right is exactly how a missing invoice survives.
- Do the run on a fixed date and make it somebody's named job. A task that belongs to whoever is free is a task that gets done inconsistently, and inconsistency is the failure mode here rather than error.
- Add and remove clients from the list at the moment the contract changes. The commonest cause of a missed invoice is not forgetfulness; it is a client who started in the middle of a month and was never added.
- Use the workflow engine for the reminder, even though it cannot do the billing. It can raise a task on a date. A prompt is not a billing run and it is better than a calendar entry nobody sees.
Recurring billing is a well-understood build
The pieces it needs mostly exist: a scheduling engine runs daily jobs across the product, invoices have every field they would need, and numbering is already sequential and safe under concurrency. What is missing is the recurrence itself and the decisions around it.
A recurring invoice template
A customer, lines, a frequency, a start and an end. The core, and the smaller half.
A run with a review step
The half that matters. Generating drafts for review beats posting invoices unattended — the first time an unattended run bills a cancelled client, the feature has cost more than it saved.
A missed-run exception
A template that should have produced an invoice and did not. This is the control the whole feature exists for, and it is the part most implementations leave out.
No dates on a public page. Tell us how many recurring clients you bill and how often the amounts change, and we will come back with a written scope, timeline and cost.
Scope recurring billingFour questions about recurring billing, for any vendor
Show me a template that generated an invoice last month.
A good answer sounds like
A template, a history of runs, and the resulting invoices.
What it actually means
Ours has none. Asking to see the history rather than the feature separates a working recurrence from a duplicate button.
What happens if a run fails halfway?
A good answer sounds like
A recorded state and a resumable run.
What it actually means
Half a billing run is worse than none, because nobody can tell which half.
Are invoices posted automatically or created as drafts?
A good answer sounds like
A choice, or a clear default.
What it actually means
Unattended posting is the option everybody asks for and regrets the first time a cancelled client is billed.
What tells me a recurring invoice was missed?
A good answer sounds like
An exception list.
What it actually means
The only part of the feature that addresses the actual risk, and the part most often absent.
What AWRA OpsHub does today
- Invoices with lines, tax per line, a currency, a due date, terms, and a snapshot of the financial context at the time.
- Sequential document numbering per organisation, per type, per prefix and per year, safe when several people invoice at once.
- Credit limits enforced at invoice creation and update, with a real hold and a snapshotted record of the decision.
- Payments applied against invoices, with ageing on receivables.
- A scheduling engine elsewhere in the product — daily jobs, report schedules and workflow rules — that can at least raise a reminder.
What it does not do
- Any recurring invoice, template, schedule or series.
- Any missed-invoice exception, because there is no expectation for one to be missed against.
- Subscription or contract entities with a term and a renewal.
- Automatic proration for a client who starts or stops mid-period.
- A sales order, so a repeating commitment has no document either.
Not ours, by choice
- The numbering is genuinely well built and it is the part of a manual run most likely to go wrong elsewhere. It does not go wrong here.
- The absence costs revenue rather than accuracy, and it does so invisibly. That is why the mitigation is a count rather than a review.
- Nothing here is Canadian. It is what a manual run does to repeating revenue; this is a market where repeating revenue is the dominant model.
Count your invoices against your client list this month
One comparison, five minutes, and most organisations doing manual recurring billing find something the first time they try it. We will set up the reconciliation with you.
Set up the checkFrequently asked questions
Can I duplicate last month's invoice?
Working from a previous invoice is the usual approach and the numbering will handle it correctly, producing a properly sequenced new document. What it will not do is remind you that a client exists, which is where the risk actually is.
Can the workflow engine raise the invoices?
It can raise a task on a schedule and notify somebody, which is a prompt rather than a billing run. Creating the invoice, with the right lines and the right amounts, is still a person at a keyboard.
What is the single most valuable habit here?
Counting. After each run, compare the number of invoices raised in the period against the number of clients on your recurring list. Reviewing amounts finds errors; counting finds omissions, and omissions are the expensive half.
