Why permissions exist
An organization's data -- donor records, receipts, templates, billing -- is shared by everyone with access to it. Roles and permissions let you control who can do what without giving every teammate the same level of access. A volunteer entering donations doesn't need to touch billing; an auditor reviewing receipts doesn't need to send them. TaxReceipt.app models this with five roles, each mapped to a fixed set of twelve granular permissions, plus a Custom role for cases the presets don't fit.
The five roles
| Role | View receipts & analytics | Create / edit receipts | Delete receipts | Manage templates | Manage integrations | Invite / remove members, manage team | Update organization | Manage billing | |------|-----|-----|-----|-----|-----|-----|-----|-----| | Owner | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Admin | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Member | Yes | Yes | No | No | Yes | No | No | No | | Viewer | Yes | No | No | No | No | No | No | No | | Custom | Configurable | Configurable | Configurable | Configurable | Configurable | Configurable | Configurable | Configurable |
- Owner -- every permission is granted, plus protections no other role has: the owner can't be removed or demoted by anyone else, and only the owner can transfer ownership or delete the organization.
- Admin -- holds the same twelve permissions as Owner by default. The difference from Owner is enforced separately from the permission system: an Admin can't remove or demote the Owner, can't transfer ownership, can't delete the organization, and can't promote another member to Admin (only the Owner can).
- Member -- day-to-day work: view receipts and analytics, create and edit receipts, and manage integrations. Can't delete receipts, manage templates, manage the team, or touch billing.
- Viewer -- read-only. Can view receipts and analytics; every other permission is off. Useful for auditors or oversight-only stakeholders.
- Custom -- starts with all twelve permissions off. An Owner or Admin turns on exactly the ones this member needs, one at a time, instead of relying on a preset. Use it when someone needs, say, template access without receipt-deletion rights.
Permissions are enforced on the server
Every sensitive action -- generating or deleting a receipt, editing a template, inviting a member, changing billing -- is checked against the member's role and permissions on the backend before it runs, not just hidden in the interface. If a button is missing or disabled because a role lacks a permission, that's a convenience, not the actual protection: the underlying API call is rejected regardless of what the browser shows. This matters because it means permissions can't be bypassed by calling the API directly or manipulating the page -- the server is the single source of truth, and the interface simply reflects it.
Changing a member's role
From Organization Settings > Team Members, open the member's detail page and click Edit Member to change their role or, for Custom, toggle individual permissions. Only Owners and Admins can change roles, with a few guardrails: nobody can change their own role, the Owner's role can only be changed via ownership transfer (not a regular role edit), and an Admin can't promote another member to Admin -- only the Owner can do that. See Team Members for the full walkthrough, including inviting members and managing access across multiple organizations.
How roles interact with approval rules
Compliance approvals (configured per run, not per organization) name specific people as approvers for the Import, PDF, and Email steps -- and that list isn't restricted by role. Any active team member can be added as an approver, whether they're an Owner, Admin, Member, or Viewer. Role and permissions control what a member can do day to day in the app; being named an approver is a separate, per-run assignment layered on top. See Approval Settings for how to configure approvers and requirements.