The Invoice You Raise Every Month by Hand
Corporate accounts, monthly retainers and long-stay guests all need the same thing: the same invoice, to the same customer, on the same day of every month. Everything around that invoice is built. The generating of it is not, and that is worth knowing before you sign the contract.
A hotel's most valuable customers are the ones who never queue at the front desk. The bank that keeps four rooms permanently. The NGO that runs a training every month and settles on account. The consultant on a three-month posting. None of them pay at checkout, all of them are invoiced, and every one of them turns your revenue from a thousand small cash events into a handful of large receivables that have to be raised on time and chased when they are not.
That shift is where hotel accounts departments get into trouble, and it is worth being clear about which parts of it this system carries for you and which part it does not.
What a corporate account actually needs
Six things, and it is worth separating them because they are not equally hard and they are not equally built.
A customer record with a credit limit
A limit set per customer, with a typed balance carried against it. This is the account, and it is a real record rather than a note in a diary.
A stop at the limit
Exposure is checked against the limit and puts the account on credit hold when it is breached. An override is possible and the override is recorded — who allowed it, against which account.
An invoice per period
Raised by a person, every month, from scratch or by duplicating last month's. This is the gap and it is the subject of most of this article.
A statement on demand
Any date range, running balance, emailable with your own subject and message. The single most useful document in a collections conversation.
Automatic overdue reminders
Sent on a cadence you set, switchable per organization, with a reminder gate so nobody is emailed daily forever.
Payment matched back to the invoice
An M-Pesa payment quoting the invoice number attaches itself to that invoice and moves the balance, idempotently. Unreferenced receipts still land, unattached, for somebody to allocate.
Five of the six are built or configurable. The one marked yours is the recurring one, which is an unfortunate distribution — the manual step is the step you repeat every month rather than once.
The gap, stated plainly
Nothing here bills a set of customers on a schedule. There is no recurring invoice, no invoice template that fires on a date, no subscription or contract that generates a document. Every invoice in the system exists because a person created it.
For a hotel taking walk-in guests that is barely a limitation, because each stay is its own event. For one carrying twelve corporate accounts and eight long-stay guests, it is twenty documents to raise by hand on the first working day of every month, forever, and the failure mode is not a wrong invoice. It is an invoice nobody raised — which produces no error, no warning and no aged receivable, because as far as the system is concerned no revenue was ever due.
A wrong invoice gets queried within a week. An invoice nobody raised is silent until somebody notices the cash never came, and by then it is three months old and the contact has moved on.
A month-end routine that actually holds
Since the control has to be procedural, it should be a real procedure with a list and an owner, not an intention.
-
Keep a written billing register, outside the invoice list
One row per recurring account: customer, what they are billed for, the amount, the day of the month, the contract end date. This is your source of truth for what should exist, and the whole point is that the invoice list cannot tell you about an invoice that was never raised.
-
Make it one person's recurring task, by name
Not the accounts department's. A named person, with a task that recurs, on a date. Anything shared between three people on the first of the month is raised by none of them in December.
-
Raise from last month rather than from blank
Duplicating the previous invoice preserves the lines, the rates and the customer, and reduces the job to changing a period and a couple of quantities. It also makes an accidental omission visible, because last month's document is right there.
-
Reconcile the count before you send anything
Twenty rows in the register means twenty invoices this month. Count them. This single check is what converts the register from a document into a control.
-
Check the credit position while you are there
A customer approaching their limit is a conversation to have when you are raising the invoice, not when the account is on hold and their delegates are at reception.
-
Let the reminders do the chasing
Automatic overdue reminders are configurable per organization with a real cadence. Turn them on once and stop writing chase emails by hand.
-
Send statements monthly to anyone with a balance
A statement over a date range with a running balance settles more disputes than an invoice copy, because it shows the payments as well as the charges.
The part that surprises hotels: the restaurant bill
Here is a scenario that will happen. A long-stay guest on a corporate account eats in the restaurant and signs for it. At month end, the corporate contact receives the room invoice and asks where the food is.
The answer is that the restaurant sale went through the point of sale, and a point-of-sale sale never reaches a customer statement. Statements are built from customer invoices and payments received. Counter transactions sit outside them entirely. Worse, a POS sale must be settled in full at the till in cash, M-Pesa or card — the till cannot sell on credit at all — so "sign for it and put it on the room" is not a transaction this system can represent.
Two systems, one guest
The till
Settled in full, at the moment of sale, in cash, M-Pesa or card.
- A restaurant or bar sale, which appears in point-of-sale reporting.
- A walk-in guest paying for anything at all.
- Never a customer statement line, whoever the customer was.
- Never a credit sale — the till has no credit tender and will refuse the transaction.
The account
Charged now, settled later, chased if it is not.
- A room charge as a customer invoice line.
- A conference or banqueting package, invoiced or run as a project.
- Appears on statements, ages into receivables, triggers automatic reminders.
- Counts towards the credit limit, and can put the account on hold.
What has to cross by hand
- A signed-for meal, captured on a docket and typed as a line on the month's invoice.
- Anything a guest charged to their room, because the till could not have taken it on credit.
- The reconciliation between the two, which nobody in the system performs for you.
The practical rule for a hotel with corporate accounts: anything that will be billed later must never touch the till. Capture it on a docket and add it as an invoice line. The moment a signed meal goes through as a completed POS sale, you have either recognised revenue you are about to invoice a second time, or revenue you will never invoice at all.
Working an account through a month
The invoice, the limit, the hold, the matching and the chasing all work. The 1st-of-the-month act of creation is the only manual link — and the conference lines are the reason duplicating last month is a starting point rather than the whole job.
What this is not
Worth saying directly, because a hotel evaluating software will be comparing against products that do these things. There is no property management system here — no room, no rate plan, no booking, no availability calendar, no folio and no night audit. There is no guest record distinct from a customer, and no deposit or advance-payment entity for a booking.
What there is: a customer ledger with limits and holds, invoices, statements, matched payments, automatic reminders, and the inventory, procurement and payroll modules the rest of the hotel runs on. If you have a PMS for the rooms and need the back office to be honest, that is a sensible fit. If you are looking for the PMS itself, this is not it, and no amount of configuration makes it one.
| Capability | Built here | Needs a PMS |
|---|---|---|
| Customer with a credit limit and hold | Yes | No |
| Invoice, statement, aged receivable | Yes | No |
| Automatic overdue reminders on a cadence | Yes | No |
| M-Pesa payment matched to an invoice | Yes | No |
| Recurring invoice generated on a schedule | No | Partly — configurable by you |
| Room, rate plan, availability | No | Yes |
| Booking, folio, night audit | No | Yes |
| Charge posted from an outlet to a room | No | Yes |
| Deposit or advance held against a booking | No | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The one marked part on the right is a caution: plenty of PMS products bill a folio at checkout without generating a recurring monthly invoice either. If monthly corporate billing matters to you, ask that question specifically of whatever you evaluate rather than assuming a PMS covers it.
What we do and do not do
What AWRA OpsHub does today
- Customers with credit limits and a carried balance, checked as exposure before more credit is extended.
- Credit hold when the limit is breached, with an override that records who allowed it.
- Statements over any date range with a running balance, emailable with your own subject and message.
- Automatic overdue reminders, switchable per organization with a configurable cadence and a gate that stops repeat mail.
- M-Pesa payments auto-matched to an invoice by reference, idempotently, with unreferenced receipts still recorded for manual allocation.
- Part payments and aged receivables, so a partly paid invoice is visible as exactly that.
What it does not do
- No recurring invoice generation. Nothing bills a set of customers on a schedule — every invoice is created by a person, every month.
- No property management. No room, rate plan, availability, booking, folio or night audit, and no guest record separate from a customer.
- No charge posting from an outlet to a room or an account. A POS sale must be settled in full at the till in cash, M-Pesa or card; the till cannot sell on credit.
- A POS sale never appears on a customer statement, so anything billed later must be kept off the till and raised as an invoice line.
- No deposit or advance-payment entity to hold money received against a future booking.
- No bank statement matching. M-Pesa matches at the callback; a bank transfer is allocated by hand.
The missing recurring invoice is the highest-leverage single absence in this product, and it is not specific to hotels — it blocks rent, retainers, subscriptions and school fees in exactly the same way. Until it exists, a written billing register with a named owner is not a nice-to-have; it is the only thing standing between you and unbilled revenue.
Related reading
- Costing an event: conferences, banqueting and the function sheet — the other half of corporate revenue, and how to cost it before you quote.
- Selling on credit in retail: accounts, limits and getting paid — the same credit machinery, described from the counter's side.
- Three tills, one store: outlets inside one property — why the restaurant till and the account are two different systems.
- Stock that leaves without a sale — the cost side of the same departmental picture.
See invoices, statements and credit control
Customer accounts with limits and recorded overrides, statements over any range, reminders on a cadence you set, and M-Pesa payments that match themselves to the invoice.
Explore customer managementFrequently asked questions
Can the system raise a corporate invoice automatically every month?
No. There is no recurring invoice generation anywhere in the product — no template that fires on a date, no subscription or contract that produces a document. Every invoice exists because a person created it. The practical answer is a written billing register listing each recurring account, its amount and its billing day, owned by a named person as a recurring task, with the invoice count reconciled against the register before anything is sent.
What happens if we simply forget to raise an invoice one month?
Nothing happens, which is exactly the danger. There is no error, no warning and no aged receivable, because as far as the system is concerned no revenue was ever due. That is why the register has to live outside the invoice list — the invoice list can only show you invoices that exist, and the failure mode here is an invoice that does not.
Can a guest sign for a restaurant meal and have it billed to their account?
No. A POS sale must be settled in full at the till in cash, M-Pesa or card, so the till cannot sell on credit, and a POS sale never appears on a customer statement in any case. The working rule for a hotel with corporate accounts is that anything to be billed later must never touch the till: capture it on a docket and add it as a line on the customer's invoice.
Does anything stop us extending more credit than we agreed?
Yes. Each customer carries a credit limit, exposure is checked against it, and breaching it puts the account on credit hold. An override is possible — commercially it has to be — and the override is recorded against the person who allowed it and the account it applied to, so the decision is visible afterwards rather than being a conversation nobody wrote down.
Will overdue accounts be chased without somebody writing emails?
Yes. Automatic overdue reminders are switchable per organization with a configurable cadence, and there is a gate that prevents the same contact being mailed repeatedly. Turn them on once. This is the part of collections most worth automating, because the manual version stops the first week anybody is busy.
Do payments match themselves to the right invoice?
An M-Pesa payment quoting the invoice number attaches to that invoice and moves the balance automatically, and it does so idempotently, so a repeated callback cannot double-credit. A payment arriving with no reference is still recorded, sitting unattached for somebody to allocate. Bank transfers are allocated by hand — there is no bank statement feed to match against.
Is this a property management system?
No, and it is worth being unambiguous. There is no room, rate plan, availability calendar, booking, folio or night audit, no guest record distinct from a customer, and no deposit entity to hold money against a future booking. It is a back office — customer accounts, invoicing, inventory, procurement, payroll and finance — and it fits a hotel that has a PMS for the rooms and wants the accounts to be right.
