Consolidated invoicing
One invoice covering many finished repairs for a single business account.
A business account — a school with thirty iPads in for repair, a fleet company running handsets through your bench every week — does not want thirty separate invoices. From Invoicing, pick the customer, see their finished repairs that have not yet been billed or paid, tick the ones to cover, and generate one invoice with one line per repair. Each line reads ticket id — device — work done, and its price is computed on the server from the ticket — the browser only ever sends the customer and the repair ids, never a price.
Which repairs are offered
Only finished work that has not already been settled shows up in the picker:
| Ticket status | On a consolidated invoice? |
|---|---|
| Ready | Yes — finished and waiting on the customer |
| Collected | Yes — handed back, but not yet billed |
| Paid | No — already rung up and paid at the till, so it is excluded to avoid billing the customer twice |
A ticket that already had a deposit taken is billed only for the remaining balance, and the invoice line notes how much was already paid.
What you get
The result is a completely normal invoice, created as a draft so it can be checked or edited before it goes out. Nothing downstream needs to know it was built this way — normal numbering, normal GST, the same payment link and emailing as any other invoice, the same automatic reminder sequence if it goes unpaid, and part payments and credit notes both work on it exactly as they would on an invoice raised by hand.
Guard rails
- Every repair on one invoice must belong to the same customer — mixing customers is refused.
- A repair already sitting on a live invoice cannot be picked again. If that invoice is later voided or archived, the repair becomes billable again.
- Prices are never taken from what the browser sends. They are recomputed on the server from the Repairs tickets themselves.
- Up to 200 repairs can go on one consolidated invoice.
Consolidated invoicing is a Growth and Multi Store feature. Creating one also requires the invoicing.create permission, which supervisors and admins hold by default — staff do not.