Invoicing from the finished job, not from memory

By the time a bike comes out of the stand, everything the invoice needs is already known. The lines are on the job, copied from the quote the rider approved. The checklist that says the brakes were bled and the bolts were torqued is on the visit. Retyping any of that at the counter is where mistakes and missed charges come from.

In Service the invoice is generated from the job. Open a job whose visits are all closed and press "Bill this job". Service creates a numbered invoice with the job's lines, quantities and prices already on it. If a visit is still open, billing is refused, which stops you invoicing a bike that has not had its final check.

The missed charges are the ones that hurt. The extra length of housing, the new hanger, the ten minutes of truing that turned into forty. If those go on the job as lines when they happen, the invoice includes them because the job does.

Before you send it, the invoice can take a discount as a percentage or a fixed amount, a tax rate, a due date and payment terms. There is room for a message to the customer, such as "Chain was at 0.75, replaced as agreed", and for contract or terms text you want on every invoice.

The arithmetic is the same as on the quote: whole cents, tax after discount, rounding half up. So the total the rider was quoted, the total on the job and the total on the invoice agree to the cent unless someone changed a line on purpose.

When you mark the invoice Sent, Service freezes it. The lines and totals can no longer be edited, so the invoice in the system is the one the customer was given. If it went out wrong, it can be voided, and voiding is kept to people with the payments permission.

The pictured invoice at the top of this page shows a QR code and a pay link. Those are on the roadmap, not in Service today. So is delivery: marking an invoice Sent does not email or text it, there is no PDF of the invoice, and there is no page the rider can open to see it. For now you show the total at the counter, print your own copy, or write the rider an email yourself.

Taking the money is also outside Service today. Take the card on your existing terminal or payment app, then record the payment against the invoice in Service so the balance is right. Recording a payment is an admin-only permission on purpose: saying money arrived is the one step with no work behind it to check.

For accounts such as a rental fleet or a corporate bike program, the plan adds batch invoicing across many jobs, statements for customers who carry a balance, and progress invoicing for big jobs. Overdue follow-ups will run through the erp.io CRM once Service sends it invoice events.

Service invoices do not post to erp.io Accounting yet. If you keep your books in Accounting, or anywhere else, you enter the invoice and the payment there as you do today. The planned connection posts every invoice, payment, refund and write-off to Accounting exactly once, with an idempotency key on each posting so a retry never records the same invoice twice.

What you do get today is a clean operating record. The monthly report in Service shows what was invoiced, what was collected, what is outstanding and what is overdue, which is the list you need to chase money at the end of the month even before the books are connected.