Admin, Member, or Accountant: Agency Billing Roles

Most agencies don't think about billing permissions until something goes wrong. A bookkeeper who only needed to pull a payment report ends up with full account access by default. A new account manager gets added the same way as the founder, so they can suddenly see every client's financial reports instead of just the ones they manage. Nobody set out to over-share access — it just happened because there was no obvious middle ground between "give them everything" and "don't give them an account at all."

Invoice Generator's workspace roles exist to close that gap. There are three: admin, member, and accountant. Each one maps to a real job function rather than a level of seniority, and understanding the difference is what lets a small agency assign access deliberately instead of by default.

What a Workspace Actually Is

Before getting into roles, it's worth being precise about what they apply to. A workspace in Invoice Generator is a fully isolated billing account — its own clients, invoices, business profile and branding, payments, and expenses. Nothing in one workspace is visible from another by default. If your agency runs one workspace for the whole team, every role you assign is scoped to that single shared pool of clients and financial data. There's no such thing as a role that only applies to a subset of clients or a single project — access is granted at the workspace level, full stop.

That matters for how you think about roles, because it means the real design decision isn't "who should see this one client's invoices" — it's "who should see this category of information across the whole workspace." Once you frame it that way, the three roles map cleanly onto three different jobs an agency actually has.

The Three Roles, Broken Down

Admin

Admin is full access. That includes everything a member or accountant can do, plus two things neither of them can touch:

• Inviting new people into the workspace
• Managing developer API keys and webhooks

Admin is the role you give to someone who needs to be able to run the account itself, not just use it. In practice that's the founder or owner, and maybe one operations lead if the agency is big enough that the founder isn't the one handling day-to-day account administration. It should not be the default role you hand out just because someone's been with the agency a while or because it's easier than thinking about what they actually need.

Member

A member can view and work with the day-to-day operational side of the account — clients, invoices, the business profile, time entries, and services. They can create invoices, send them, and manage client records. What they cannot do is see payments, expenses, or any of the financial reports: the accountant report, the aging report, or the tax summary report.

This is the role for anyone whose job is client-facing invoicing work without a financial oversight component. An account manager who sends invoices to their own clients and tracks time against active projects is a textbook member. They don't need to see how much the agency spent on software subscriptions last month, and they don't need to see which other account managers' clients are overdue.

Accountant

Accountant has access to payments, expenses, client statements, and the financial reports — accountant report, aging report, and tax summary report — plus the same day-to-day invoice and client visibility a member has. What it doesn't include is admin-level account management: an accountant cannot invite or remove members, and cannot manage API keys or webhooks.

This role exists for exactly the situation its name suggests: someone handling the financial side of the business without needing to run the account itself. A bookkeeper reconciling payments against invoices, or someone preparing quarterly numbers for tax filing, needs the accountant role and nothing more.

Here's the same breakdown side by side, since this is the part worth having in front of you when you're actually assigning roles:

• Admin — clients, invoices, business profile, time entries, services, payments, expenses, client statements, all financial reports, member invitations, API keys and webhooks
• Member — clients, invoices, business profile, time entries, services. No payments, no expenses, no financial reports, no admin controls
• Accountant — clients, invoices, business profile, time entries, services, payments, expenses, client statements, all financial reports. No member invitations, no API key or webhook management

If you're setting up a workspace for the first time, it helps to have already worked out who on the team is actually going to touch invoices day to day versus who's only there for the numbers — our guide on running team billing with workspaces, reports, and the developer API covers what each of those pieces looks like in practice once a team is sharing one account.

The Bookkeeper Scenario

This is the case that makes the accountant role worth having rather than just defaulting everyone to admin or member. Say your agency brings on a part-time or outside bookkeeper — someone who logs in once a week or once a month to reconcile payments, check the aging report for anything overdue, and pull numbers for tax prep. They are not an employee in the day-to-day sense. They didn't hire the account manager sitting next to them and shouldn't be the one deciding who else gets added to the workspace.

Giving that person admin access because "they need to see the financial stuff" is a mismatch. Admin gets them everything they need for the bookkeeping work, but it also hands them the ability to invite or remove team members and manage API keys and webhooks — none of which has anything to do with reconciling payments. If that bookkeeper's account is ever compromised, or if the relationship ends and offboarding gets delayed, the blast radius includes account administration they never should have had in the first place.

The accountant role is the actual fit. It gives full visibility into payments, expenses, client statements, and every financial report — everything the bookkeeping work requires — without touching account administration at all. The bookkeeper can do their job completely, and the agency hasn't handed out access it didn't need to.

The Account Manager Scenario

The mirror case is the member role, and it's just as common. An account manager or client lead spends their day sending invoices, updating client records, and logging time against active projects. They need to be fully capable inside the workspace for their own clients' invoicing — but they have no reason to see the agency's overall payment history, expense totals, or financial reports covering clients they don't even work with.

Member access covers exactly that. The account manager can create and send invoices, manage their clients, and log time, all without visibility into agency-wide financial data or any admin controls. This isn't about not trusting the account manager — it's that the financial reports simply aren't part of their job, and giving them access to information outside their actual scope doesn't help anyone. It just means one more person who could accidentally export a financial report meant for the accountant, or one more account to worry about if a laptop gets lost.

If your agency bills a mix of internal staff and outside subcontractors on the same projects, the member/accountant split gets more useful, not less — subcontractors invoicing through the workspace only need member-level access to log their time and send invoices for their portion of the work, while the financial oversight of how that rolls up into what the client owes stays with whoever holds the accountant role. Our piece on invoicing for agencies with multi-person teams and subcontractors goes deeper into how that kind of mixed team actually gets billed.

One Person, Multiple Roles Across Workspaces

Roles are assigned per workspace, and since one person can belong to more than one workspace at a time, the same individual can hold a completely different role in each one. This shows up naturally in two situations agencies run into a lot.

The first is a freelancer or contractor who runs their own solo operation and also does work inside a client's team. That person is the admin of their own workspace — full control, because it's their business — while holding only the accountant or member role inside the client's workspace, depending on what they were brought in to do. Nothing about being an admin in one place carries over to the other. Each workspace's role is set independently.

The second is a fractional bookkeeper working across several small businesses. If each business runs its own Invoice Generator workspace, that bookkeeper can be invited into each one separately with the accountant role, giving them exactly the financial access they need in every account without any single client's admin controls, client list, or invoice history leaking into another. From the bookkeeper's side, it's one login with several different scopes of access; from each business's side, the workspaces stay fully isolated from each other regardless of who's shared across them.

This is worth keeping in mind if your agency works with outside specialists who also serve other clients. You're not choosing between trusting them fully or not bringing them in at all — you're choosing the role that matches what they're actually doing inside your specific workspace, independent of what access they hold anywhere else.

Default to the Narrowest Role That Works

The practical rule for a small team is simple: default to the least access that lets someone do their actual job, and only widen it when there's a specific reason to. Before adding anyone to a workspace, ask what they actually need to touch. If the answer is "send invoices and manage their own clients," that's member. If it's "reconcile payments and pull reports," that's accountant. Admin should be reserved for the one or two people who genuinely need to manage the account itself — inviting people, removing people, and handling API integrations.

This isn't about distrust. It's the same reasoning behind giving a new employee a key to the front door but not the safe. Most people never touch the parts of a system they don't have access to anyway, so the practical cost of least-privilege thinking is close to zero. What it buys you is real: when someone leaves, when an account gets compromised, or when you're just trying to remember who can see what, the answer is already defined by the role instead of by whatever access happened to get granted when they joined.

Since only an admin can send invitations, this decision naturally funnels through whoever holds that role already — which is one more reason to keep the admin list short. A workspace with one or two admins making deliberate role decisions for every new invite stays a lot easier to reason about than one where admin access got handed out along with everything else, to everyone, because nobody thought about it at the time.