Summary and recommendation
Bill.com user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Bill.com user management lives entirely in Settings > Manage Users and is administered by anyone holding the Administrator role. Like every app in a finance stack, the permission model shapes what your team can and cannot automate later. The model is role-based with six predefined roles: Administrator, Controller, Accountant, Approver, Clerk, and Payer.
No custom roles or granular permission editing outside these presets is documented. The one configurable exception is the Approver role, where per-user dollar thresholds can be set by an Administrator.
Quick facts
| Admin console path | Settings > Manage Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to all settings, users, approvals, payments, and accounting sync configuration. Can add/remove users and assign roles. | Cannot be restricted to a subset of functionality without changing role. | All plans | Counts as a paid user seat | At least one Administrator must exist on the account at all times; the last admin cannot be deactivated. |
| Controller | Access to all AP/AR functions, chart of accounts, and accounting sync. Cannot manage users or account-level settings. | Cannot add or remove users; cannot change billing or subscription settings. | All plans | Counts as a paid user seat | |
| Accountant | Access to bills, invoices, and accounting sync. Typically used for external bookkeepers or accountants. | Cannot manage users, approve payments above their approval limit, or change account settings. | All plans | Counts as a paid user seat | Accountant role access may vary depending on whether the user is an internal employee or an external accounting firm user connected via the BILL Accountant portal. |
| Approver | Can approve or deny bills and payments up to a configured dollar threshold. Read access to relevant records. | Cannot create or send payments, cannot manage users or settings. | All plans | Counts as a paid user seat | Approval limits must be configured per user by an Administrator. |
| Clerk | Can enter and edit bills and invoices. Cannot approve or send payments. | Cannot approve payments, cannot access settings or user management. | All plans | Counts as a paid user seat | |
| Payer | Can initiate and send payments. Typically combined with Approver role. | Cannot manage users or account settings. | All plans | Counts as a paid user seat |
Permission model
- Model type: role-based
- Description: Bill.com uses a predefined set of roles (Administrator, Controller, Accountant, Approver, Clerk, Payer). Each role maps to a fixed permission set. Approval dollar limits can be configured per user within the Approver role. There is no documented support for fully custom roles or granular permission-set editing outside of these predefined roles.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level only; per-user approval dollar thresholds are configurable within the Approver role. No field-level or object-level permission customization is documented.
How to add users
- Log in as an Administrator.
- Navigate to Settings > Manage Users.
- Click 'Add User' or 'Invite User'.
- Enter the user's first name, last name, and email address.
- Select the appropriate role from the predefined list.
- If assigning the Approver role, configure the approval limit.
- Click 'Send Invitation'. The user receives an email to set up their password and complete registration.
Required fields: First name, Last name, Email address, Role
Watch out for:
- Each invited user must accept the email invitation and create a Bill.com account before they can log in; pending invitations do not grant access.
- A user's email address must be unique across Bill.com; if the email is already associated with another Bill.com organization, the user will be prompted to link accounts.
- Users added to multiple Bill.com organizations use the same login credentials but must switch between organizations manually.
- Invitations expire if not accepted; an admin must resend the invitation.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Bill.com does not permanently delete user accounts. Administrators can only deactivate users, which revokes login access and removes the user from active workflows. The user's historical records, audit trail entries, and transaction history are retained for compliance purposes.
- Log in as an Administrator.
- Navigate to Settings > Manage Users.
- Locate the user in the active users list.
- Click on the user's name or the action menu next to their record.
- Select 'Deactivate User'.
- Confirm the deactivation in the prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Bills, invoices, and payment records created by the deactivated user are retained and remain visible in the system. Ownership of records is not automatically reassigned. |
| Shared content | The deactivated user is removed from any approval workflows they were part of. Pending approvals assigned to the deactivated user may stall and require reassignment by an Administrator. |
| Integrations | If the deactivated user was the connected user for an accounting sync (e.g., QuickBooks, Xero), the sync connection may need to be re-authenticated by an active Administrator. |
| License freed | Deactivating a user frees the paid seat, which reduces the billable user count at the next billing cycle. |
Watch out for:
- Pending bills or invoices in an approval workflow assigned to a deactivated user will be blocked until an Administrator reassigns the approval step.
- The last Administrator on an account cannot be deactivated.
- Deactivated users can be reactivated by an Administrator; their historical data and role assignment are restored upon reactivation.
- If the deactivated user was the sole approver in a multi-step approval policy, that policy must be updated manually.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| AP/AR User Seat | Access to Accounts Payable and/or Accounts Receivable features based on the subscribed plan (Essentials, Team, Corporate, or Enterprise). Each active named user consumes one seat. | Essentials: $45/user/month; Team: $55/user/month; Corporate: $79/user/month; Enterprise: custom pricing |
| Spend & Expense User | Access to BILL Spend & Expense (corporate card and expense management). Available at no additional per-user cost when paired with eligible corporate card program. | $0/user/month when using BILL corporate cards; standalone pricing not publicly documented |
- Where to check usage: Settings > Manage Users (shows list of active users and their roles; seat count visible in subscription/billing settings)
- How to identify unused seats: Administrators can review the active user list under Settings > Manage Users and check last login dates to identify inactive users. No automated unused-seat report is documented in the help center.
- Billing notes: Billing is per active named user per month. Deactivating a user removes them from the billable count. Bill.com bills monthly based on the number of active users at the time of billing. Annual plan discounts may apply; contact sales for Enterprise pricing. Transaction fees (e.g., 2.9% for card payments) are separate from seat fees.
The cost of manual management
Every app in a finance stack that lacks automated provisioning creates a recurring manual tax on IT and accounting ops teams.
In Bill.com, every new hire must be invited individually - there is no bulk CSV import - and each invitation must be accepted before access is granted, meaning a second follow-up step is often required.
Deactivating a departing user is a separate manual action, and if that user was an approver, any in-flight bills assigned to them will stall silently until an Administrator manually reassigns the approval step. Seat billing is per active named user, so missed deactivations translate directly into wasted spend.
What IT admins are saying
The most consistent friction reported by Bill.com admins centers on provisioning opacity and workflow fragility. SCIM is not publicly documented, making IdP integration with Okta or Entra ID difficult without direct vendor support.
SSO via SAML is gated to the Enterprise plan, which requires custom pricing negotiation. Approval workflows are a known operational risk: deactivating an approver without reassigning pending items causes silent stalls with no automated alert.
Users who belong to multiple Bill.com organizations must switch between orgs manually, with no unified view.
Common complaints:
- SSO (SAML) is only available on the Enterprise plan, which requires custom pricing negotiation.
- SCIM provisioning is not publicly documented and appears limited to Enterprise customers working directly with Bill.com support.
- No bulk CSV import for users; each user must be invited individually.
- Approval workflows can stall silently when an approver is deactivated without reassigning pending items.
- Users belonging to multiple Bill.com organizations must manually switch between orgs with no unified dashboard.
- Limited provisioning documentation makes IdP integration setup (Okta, Entra ID) difficult without direct vendor support.
- No granular custom role creation; administrators must work within the fixed predefined role set.
- Last-login visibility is limited, making it difficult to audit inactive seats without manual review.
The decision
Every app with a fixed role model will eventually hit a ceiling, and Bill.com is no exception - if your org needs granular, object-level permissions, the six predefined roles will be that ceiling.
Bill.com is a reasonable fit for finance teams that can absorb manual provisioning overhead or are willing to negotiate Enterprise terms for SCIM and SSO. Key operational constraints to evaluate before rollout:
- The last Administrator cannot be deactivated; plan your admin coverage accordingly.
- Approval policies tied to a single approver must be manually updated when that user is offboarded.
- Invited users who have not accepted their invitation do not have access, but the seat may still appear in your active user list until the invitation expires.
- Reactivating a former user restores their previous role and historical data, which may be desirable or a compliance concern depending on your policies.
Bottom line
Bill.com's user management is functional for small finance teams comfortable with manual, one-at-a-time provisioning, but it creates compounding operational risk at scale.
The absence of publicly documented SCIM, the Enterprise-only SSO gate, and the silent approval-stall behavior on deactivation are the three issues most likely to cause real incidents.
Teams managing more than a handful of users should pressure-test the offboarding workflow specifically before relying on it in production.
Automate Bill.com workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
