Expensify User Management Guide

• Model type: role-based
• Description: Expensify uses a fixed set of roles at two levels: domain-level (Domain Admin) and policy-level (Policy Admin, Auditor, Employee). Roles are assigned per policy; a user can be an Employee on one policy and a Policy Admin on another. There are no custom role definitions or granular permission toggles beyond these fixed roles.
• Custom roles: No
• Custom roles plan: Not documented
• Granularity: Coarse - four fixed roles with no per-permission customization. Approval workflow rules (multi-level, random, or manual approval) provide some behavioral customization within the Employee role but do not constitute custom permissions.

1. Log in to expensify.com as a Policy Admin or Domain Admin.
2. Navigate to Settings > Policies > [Policy Name] > Members.
3. Click 'Invite' in the Members tab.
4. Enter the user's email address (or multiple addresses separated by commas).
5. Select the role to assign: Employee, Policy Admin, or Auditor (Auditor only on Control plan).
6. Optionally set a custom approval workflow for the new member.
7. Click 'Invite'. The user receives an email invitation to join Expensify and the policy.
8. If the user does not yet have an Expensify account, they are prompted to create one upon accepting the invitation.

Required fields: Email address of the invitee, Role selection (defaults to Employee if not changed)

Watch out for:

• Users must accept the invitation to become active; pending invitations still appear in the Members list.
• If domain control is enforced, users with the verified domain email are automatically added to the domain and may be auto-assigned to a default policy.
• Adding a user to a policy does not automatically grant them an Expensify Card; card issuance is a separate step.
• On the Control plan with SAML SSO enforced, new domain members may be auto-provisioned on first SSO login without a manual invite.
• Billing begins when a member becomes 'active' (submits a report, uses SmartScan, etc.) within the billing period, not at the moment of invitation.

• Can delete users: No
• Delete/deactivate behavior: Expensify does not allow deletion of user accounts from the admin console. Admins can remove a member from a policy (which revokes their access to that policy's reports and settings) but the user's Expensify account itself persists. At the domain level, a Domain Admin can remove a user from the domain, which enforces SSO restrictions and removes domain group membership, but does not delete the account. Account deletion must be requested by the account holder directly through Expensify support.

1. Log in as a Policy Admin or Domain Admin.
2. Navigate to Settings > Policies > [Policy Name] > Members.
3. Locate the member to remove.
4. Click the remove/delete icon (trash icon) next to the member's name.
5. Confirm the removal. The user loses access to the policy immediately.
6. For domain-level removal: navigate to Settings > Domains > [Domain Name] > Members, locate the user, and click 'Remove'.
7. If SAML SSO is enforced, also deprovision the user in the IdP (Okta or Entra ID) to prevent re-provisioning on next login.

Watch out for:

• Removing a user from a policy does not close or delete their Expensify account; they can still log in and use Expensify independently.
• If the user has open, unsubmitted, or unapproved reports at the time of removal, those reports remain in a pending state and must be handled by an admin.
• Under an annual subscription, the seat count is based on the number of active members at the subscription start; removing members mid-year does not reduce the committed seat count until renewal.
• If SAML SSO is enforced at the domain level, failing to also deprovision in the IdP may allow the user to re-authenticate and regain domain membership.
• Domain Admins cannot remove themselves from the domain without first assigning another Domain Admin.

• Where to check usage: Settings > Policies > [Policy Name] > Members (shows current member count); Settings > Account > Billing (shows active member count and current invoice)
• How to identify unused seats: Policy Admins can review the Members list and filter by last activity date. Members with no report submissions or activity in the current billing period may not be counted as 'active' for billing, but Expensify does not provide a built-in 'inactive member' report in the UI. Admins must manually cross-reference member list against submitted reports.
• Billing notes: Expensify bills based on 'active members' - users who take a billable action (submit a report, SmartScan a receipt, use the Expensify Card) within the billing period. Invited but inactive members are not billed. Annual subscriptions lock in a committed member count; exceeding that count results in overage charges at the per-member rate. Monthly subscriptions are billed at a higher per-member rate with no commitment. As of April 2025, Expensify moved to flat per-member pricing; bundling with the Expensify Card reduces the per-member cost. UK pricing: £5/member/month; Australia: A$8/member/month.

Expensify bills on active members - users who submit a report, SmartScan a receipt, or use the Expensify Card within the billing period. Invited but inactive members are not billed.

Annual subscriptions lock in a committed member count at the start of the term; removing members mid-year does not reduce that committed count or generate a prorated credit until renewal.

There is no built-in inactive member report in the UI. Admins must manually cross-reference the Members list against submitted reports to identify unused seats.

Expensify does not allow admins to delete user accounts - account deletion must be requested by the account holder directly through Expensify support, which creates a hard dependency on the departing employee during offboarding.

The most consistent friction point reported by admins is SCIM activation: it requires a manual email to concierge@expensify.com and is not self-serve even on the Control plan. Teams expecting to configure automated provisioning at contract signing should factor in activation lead time.

SSO enforcement without SCIM creates a deprovisioning gap. Removing a user from the IdP does not automatically remove them from Expensify policies; a manual removal step in the Expensify admin console is still required unless SCIM is also active.

Admins who miss this step risk leaving former employees with residual policy access.

The absence of a prorated refund on annual seat reductions and the lack of an inactive member report are the two billing complaints that appear most frequently in community threads.

Common complaints:

• SCIM requires manual activation request via concierge@expensify.com and is not self-serve even on the Control plan.
• Account deletion is not available to admins; users must request deletion themselves, creating offboarding friction.
• No built-in inactive member report makes it difficult to identify and remove unused seats before billing cycles.
• Removing a member mid-year under an annual subscription does not reduce the committed seat count or provide a prorated refund.
• SAML SSO enforcement does not automatically deprovision users when removed from the IdP unless SCIM is also configured; manual removal in Expensify is still required.
• The Auditor role is restricted to the Control plan, meaning Collect plan customers have no read-only access option for finance reviewers.
• CSV import for bulk member invites requires a specific column format that is not prominently documented, leading to import errors.
• Domain verification is a prerequisite for SSO and SCIM, but the verification process can be slow if DNS propagation is delayed.

Manual administration is viable for teams under roughly 25–50 members with low turnover, or for organizations that cannot yet meet the Control plan and SAML prerequisites required for SCIM. The invite flow is straightforward, and bulk invites via comma-separated email addresses reduce per-user effort at onboarding.

Every app that handles expense data carries offboarding risk proportional to how long former employees retain access, and Expensify's architecture makes that window longer than most admins expect.

For any team where offboarding speed matters, the manual path carries real risk. The inability to delete accounts from the admin console, combined with the SSO-without-SCIM deprovisioning gap, means offboarding requires coordinated steps across Expensify, the IdP, and potentially Expensify support.

Teams on the Control plan with Okta already deployed should prioritize SCIM activation over manual workflows. The manual path remains a fallback for Collect plan customers and for organizations using an IdP other than Okta, where SCIM support is not confirmed.

Bottom line

Expensify's manual admin experience is functional but requires deliberate process design around two gaps: there is no admin-initiated account deletion, and SSO enforcement alone does not deprovision users from policies.

Every app that handles expense data carries offboarding risk proportional to how long former employees retain access, and Expensify's architecture makes that window longer than most admins expect.

Teams on the Control plan with Okta should treat SCIM activation as a prerequisite for any automated provisioning workflow - but they should also plan for the activation lead time, since it is not self-serve.