While one person does the invoicing, permissions are a solved problem: they can do everything, and they are the only one who can. The question arrives the day a second person needs to raise an invoice because the first is on site, or a bookkeeper needs to record payments, or an office manager starts handling the monthly run. Deciding the rules at that point costs an afternoon. Deciding them after somebody voids the wrong invoice costs considerably more.
The moment it stops being a habit
A one-person billing routine is held together by memory. You know which invoices are drafts because you left them that way, which client wants a purchase order number, why that one is on hold. None of that is written down because it never needed to be.
The second person cannot see any of it. They will do something entirely reasonable that turns out to be wrong in a way nobody documented, and the instinct afterwards is to lock things down. That is usually the wrong response. What went missing was shared context, and permissions are a poor substitute for it. Get the states and their meanings written down first, which is what the invoice status workflow from draft to paid is for, then decide who can move things between them.
Four actions, not one permission
Businesses talk about "access to invoicing" as if it were a single switch. It is at least four separate abilities, and they carry very different risk.
- Create a draft: near zero risk, because nothing has left the building.
- Send an issued invoice: moderate, because the client now has a document.
- Edit or void an issued invoice: high, because it changes a record.
- Record a payment: high, because it closes a balance nobody will chase again.
That last one is consistently underrated. An invoice wrongly marked as paid disappears from every overdue report you have, which means nobody will notice it for months. It is a quieter failure than a wrong invoice going out, and a more expensive one.
Roles that match actual jobs
A small set of roles beats a detailed matrix nobody maintains. Four covers most service businesses, and the names should map to how people already describe themselves.
An owner has everything, including billing and the ability to remove other people. An administrator runs the business day to day: raise, send, correct, invite. A member does the operational work, raising and sending invoices for jobs they are responsible for without the destructive actions. A viewer sees the records and changes nothing, which suits an external accountant or somebody who only needs to answer questions.
Where a real job does not fit those four, a custom role is better than promoting somebody to administrator because it was the closest option. The common case is a site or contract manager who needs to raise invoices for their own sites and nothing else.
Resist inventing a role per person. Every role is a rule somebody has to remember and maintain, and a set of nine that nobody can describe is worse than four that everybody understands. If you cannot say in one sentence what a role is for, it should not exist.
Separate trading entities are a different problem and should not be solved with roles at all. If you run two companies, they need two workspaces with their own numbering, clients and records, rather than one shared space where access rules keep them apart. Mixing them produces exactly the sequence gaps described in invoice numbering that survives scale.
The audit trail matters more than the lock
Most billing mistakes in a small team are not malicious. They are somebody doing the reasonable thing without the context. Restriction prevents a narrow class of those and creates a new problem: work stops while people wait for permission, and someone starts sharing a login to get around it.
Recording is more useful than blocking. If you can see who created an invoice, who sent it, who edited what and when a payment was recorded, almost every question resolves in a minute without anybody being locked out of their job. Reserve hard restrictions for the two or three genuinely destructive actions and let visibility handle the rest. Corrections should leave a trail by design anyway, which is the argument in credit notes explained.
When an approval step is worth the delay
Approval workflows feel prudent and are frequently a net loss. Every invoice waits for a person who is on site, and the delay applies to all of them to catch errors in a few. Given that issuing late is one of the most reliable causes of slow payment, an approval step can cost more in delayed cash than the errors it prevents.
If you want one, put a threshold on it. Invoices under a value go straight out; larger ones wait for a second pair of eyes. That targets the review at the invoices where a mistake actually hurts, and leaves routine billing moving at the speed described in the complete guide to invoicing for UK service businesses.
Bookkeepers, accountants and other outsiders
External help needs a real seat rather than a shared password. A shared login destroys the audit trail entirely and survives long after the relationship ends, which is the worst of both outcomes.
Most bookkeeping arrangements need to see everything financial and record payments, without creating or editing invoices. Most accountants need to see and export, nothing more. If they work in their own system, the connection between the two is a separate decision covered in connecting invoicing to your accounting software.
The part everyone forgets
Access gets granted carefully and removed never. The subcontractor who needed to raise invoices for one project in spring still can. The bookkeeper you stopped using last year still has a seat. Nobody notices because nothing breaks.
Put a review in the calendar twice a year, look at who has access and ask whether the job they were given it for still exists. It takes ten minutes and it is the only maintenance any of this needs. Do the same for the customer-facing side if you use one, which is covered in client portals for invoices.