Summary and recommendation
Spendesk 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.
Spendesk user management is entirely manual.
Admins invite members one at a time via Settings → Members, select a predefined role, and optionally assign a team or budget.
There is no SCIM provisioning, no bulk CSV import, and no automated lifecycle management available through the platform.
The permission model is role-based with five fixed roles: Account Owner, Admin, Controller, Approver, and Requester.
No custom roles can be created.
Spending limits and budget/team scope add a secondary access layer on top of roles, but these must also be configured manually per user.
Like every app managed without automation, access state in Spendesk drifts from your IdP unless admins intervene consistently.
Quick facts
| Admin console path | Settings → Members (accessible to Admin and Account Owner roles) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Custom |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Account Owner | Full access to all settings, billing, member management, and financial data across the entire account. Can assign and remove all roles. | Cannot be deactivated by other admins; only one Account Owner per account. | Account Owner role cannot be transferred via self-service in the UI; requires contacting Spendesk support. | ||
| Admin | Can invite and deactivate members, manage budgets, approve requests, configure spending policies, and access reporting. Can manage all wallets and cards. | Cannot access billing settings or change the Account Owner. | Multiple Admins can exist; each has broad access so the role should be assigned carefully. | ||
| Controller | Access to accounting and export features, transaction review, and reconciliation. Can view all spending data. | Cannot approve purchase requests, manage members, or configure spending policies. | Intended for finance/accounting team members; does not have card or wallet management rights. | ||
| Requester | Can submit purchase requests, use virtual cards (if granted), and submit expense claims. Sees only their own transactions. | Cannot approve requests, view other members' spending, or access company-wide reports. | Default role assigned to most employees. Spending limits and card access must be configured separately per user. | ||
| Approver | Can approve or reject purchase requests within assigned budget or team scope. | Cannot manage members, access accounting exports, or configure company-wide policies. | Approval scope is tied to budget/team assignment; an Approver outside a budget's scope cannot approve requests within it. |
Permission model
- Model type: role-based
- Description: Spendesk uses a fixed set of predefined roles (Account Owner, Admin, Controller, Approver, Requester). Permissions are determined by role assignment. Spending limits and budget/team scope add a secondary layer of access control on top of roles.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level with supplementary per-user spending limits and budget/team scope assignments. No granular permission toggles within a role.
How to add users
- Log in as Admin or Account Owner.
- Navigate to Settings → Members.
- Click 'Invite a member'.
- Enter the new member's email address.
- Select the appropriate role (Requester, Approver, Controller, or Admin).
- Assign the member to a team or budget if applicable.
- Click 'Send invitation'. The invitee receives an email to set up their account.
Required fields: Email address, Role
Watch out for:
- The invitee must accept the email invitation before they appear as an active member.
- Pending invitations occupy a member slot and can be resent or cancelled from the Members list.
- Team/budget assignment is optional at invite time but must be completed before the user can submit or approve requests within a specific budget.
- SSO must be configured separately; inviting a user does not automatically enroll them in SSO.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (Custom pricing); supported IdPs include Okta, Microsoft Entra ID (Azure AD), and OneLogin via SAML-based SSO. Automated provisioning/deprovisioning capability depends on IdP integration configuration. |
How to remove or deactivate users
- Can delete users: No
- Delete/deactivate behavior: Spendesk does not permanently delete member accounts. Members can be deactivated, which revokes their access to the platform. Historical transaction data, expense records, and audit trails associated with the member are retained after deactivation.
- Log in as Admin or Account Owner.
- Navigate to Settings → Members.
- Locate the member to deactivate.
- Click on the member's name or the action menu next to their entry.
- Select 'Deactivate member'.
- Confirm the deactivation in the prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Transaction history, submitted requests, and expense claims created by the deactivated member are retained and remain visible to Admins and Controllers. |
| Shared content | Budget and team memberships are removed upon deactivation. Any pending requests or approvals assigned to the member should be reassigned before deactivation. |
| Integrations | If the member was provisioned via SSO/IdP, deactivating in the IdP does not automatically deactivate them in Spendesk unless automated deprovisioning is configured. |
| License freed | Spendesk pricing includes unlimited users; deactivating a member does not reduce a per-seat license count, but removes the member's active access. |
Watch out for:
- Pending expense claims or open virtual cards belonging to the member should be resolved before deactivation to avoid orphaned transactions.
- Deactivated members cannot be reactivated via self-service in all configurations; check with Spendesk support if reactivation is needed.
- If the member holds an active physical or virtual card, the card should be blocked or cancelled separately before or during deactivation.
- IdP-side deactivation alone may not immediately revoke Spendesk access if SCIM/automated deprovisioning is not configured.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Member (all roles) | Access to Spendesk platform features according to assigned role. Spendesk pricing is described as including unlimited users under a fixed subscription fee. | Included in subscription; no per-seat charge documented publicly. Overall pricing is custom and based on company needs. |
- Where to check usage: Settings → Members (shows active and pending members with their roles and last activity where available)
- How to identify unused seats: Review the Members list in Settings → Members for members with no recent activity or pending invitation status. No dedicated 'inactive user' report is documented in official help resources.
- Billing notes: Spendesk uses a fixed monthly subscription plus variable per-transaction pricing model. Unlimited users are included in the subscription. Adding or removing members does not directly change the subscription cost. Custom pricing is negotiated; contact Spendesk sales for plan details.
The cost of manual management
Spendesk uses a fixed monthly subscription plus variable per-transaction pricing, with unlimited users included. Adding or removing members does not directly change subscription cost, so there is no per-seat financial pressure to deprovision quickly.
The real cost is operational. IdP deactivation alone does not revoke Spendesk access - a separate manual deactivation step inside the Spendesk console is always required. Pending expense claims, open virtual cards, and unresolved approvals must each be handled before deactivation to avoid orphaned transactions.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Every app in a manually managed stack creates compounding overhead, and Spendesk is no exception. SAML 2.0 SSO is available as a paid add-on or included in certain plans and works with Okta, Entra ID, and OneLogin, which covers onboarding via JIT provisioning on first login.
However, JIT provisioning does not automatically assign roles, teams, or spending limits - an admin must still complete configuration after a user's first login. Offboarding has no automation path at all. Teams that require fully automated user lifecycle management should factor this gap in before committing.
Bottom line
Spendesk gives finance and operations teams strong spend controls, but user lifecycle management is a manual process end to end.
There is no SCIM, no bulk provisioning, and no automated deprovisioning - every app in your stack that relies on Spendesk access being revoked promptly will depend on an admin completing a separate step in the Spendesk console.
For teams with high employee turnover or strict access hygiene requirements, this is a meaningful operational gap to plan around.
Automate Spendesk 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.
