[Due for payment 2026-05-20] [$250] Expose Accounting saved searches to Auditors

[heyjennahay]

Problem:

Currently in NewDot we only display Accounting saved searches to Admins. However, these are also useful reports for users with Auditor (i.e. read only) permission. Given these users can already see all the reports on the workspace they are an Auditor for, there is no reason they cannot also see the Accounting saved searches.

Solution:

Expose Accounting saved searches to Auditors

cc @HaleyJacobson @kortneywynn @JmillsExpensify

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049466305023453954
• Upwork Job ID: 2049466305023453954
• Last Price Increase: 2026-04-29

[heyjennahay]

Link to slack thread for our internal accountants who need this: https://expensify.slack.com/archives/C01N42VHL59/p1777464459015199?thread_ts=1772703542.857379&cid=C01N42VHL59

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022049466305023453954

[KJ21-ENG]

Replaces my earlier proposal: the deferred-media placeholder ("Media not yet reviewed…") has been replaced with verified findings from the issue screenshot, which confirms the highlighted Accounting section contains five items (Awaiting export, Cash accruals, Card accruals, Card statements, Bank reconciliation). The root-cause and the proposed fix (widening the four admin-gated flags in getSuggestedSearchesVisibility) are unchanged.

Proposal

Please re-state the problem that we are trying to solve in this issue.

The Accounting tab of the Search left-hand menu shows several role-gated suggested searches. On NewDot these are only surfaced when the current user has the workspace admin role. Members with the read-only auditor role — who already have visibility into every report on the workspace — do not see these Accounting suggested searches at all, which the reporter notes is unnecessarily restrictive given Auditors' existing read access.

The issue screenshot highlights the Accounting section of the Search LHN with these five items: Awaiting export, Cash accruals, Card accruals, Card statements, Bank reconciliation. These map to CONST.SEARCH.SEARCH_KEYS.EXPORT, UNAPPROVED_CASH, UNAPPROVED_CARD, STATEMENTS, and RECONCILIATION respectively. Of those five, three (UNAPPROVED_CASH, UNAPPROVED_CARD, RECONCILIATION — where RECONCILIATION is itself the OR of the Expensify-Card and Reimbursements eligibility flags) are gated strictly on the Admin role today, so an Auditor sees an Accounting section that is empty or absent entirely.

What is the root cause of that problem?

Visibility of the Accounting section's suggested searches is computed once per policy in getSuggestedSearchesVisibility in src/libs/SearchUIUtils.ts. Each Accounting-section eligibility flag is gated strictly on isAdmin (policy.role === CONST.POLICY.ROLE.ADMIN), with no auditor allowance:

• isEligibleForUnapprovedCashSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && isPaymentEnabled
• isEligibleForUnapprovedCardSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard)
• isEligibleForExpensifyCardSuggestion = isPaidPolicy && isAdmin && isECardEnabled
• isEligibleForReimbursementsSuggestion = isPaidPolicy && isAdmin && isPaymentEnabled && hasVBBA && hasReimburser

RECONCILIATION visibility is the OR of the latter two, so it is also admin-only. isAuditor is already computed in this same loop a few lines down (and is correctly used for isEligibleForTopSpendersSuggestion), but it was never extended to the Accounting-section flags. The downstream Accounting section in createTypeMenuSections simply reads these visibility booleans, so widening them at the source is sufficient to expose the items.

STATEMENTS is gated on isPaidPolicy && areCompanyCardsEnabled && hasCardFeed — no role check, so an Auditor on a workspace with company cards configured already sees Card statements. EXPORT is gated on isExporter (the current user being the policy's exporter) and not admin — so an Auditor will see Awaiting export only if the workspace has set them as the exporter; in practice exporters are usually admins, so most Auditors will not see it. This is consistent with how EXPORT already behaves for any non-exporter member today.

App/src/libs/SearchUIUtils.ts

Lines 1029 to 1056 in c0f0d68

	const isAdmin = policy.role === CONST.POLICY.ROLE.ADMIN;
	const isExporter = policy.exporter === currentUserEmail;
	const isSubmittedTo =
	!!currentUserEmail && Object.values(policy.employeeList ?? {}).some((employee) => employee.submitsTo === currentUserEmail || employee.forwardsTo === currentUserEmail);
	const isUserApprover = !!currentUserEmail && isPolicyApprover(policy, currentUserEmail);
	const isApprovalEnabled = policy.approvalMode ? policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL : false;
	const hasExportError = (Object.keys(policy.connections ?? {}) as ConnectionName[]).some((connection) => {
	return hasSynchronizationErrorMessage(policy, connection, false);
	});
	const isPaymentEnabled = arePaymentsEnabled(policy);
	const hasVBBA = !!policy.achAccount?.bankAccountID && policy.achAccount.state === CONST.BANK_ACCOUNT.STATE.OPEN;
	const hasReimburser = !!policy.achAccount?.reimburser;
	const isECardEnabled = !!policy.areExpensifyCardsEnabled;
	const isEligibleForSubmitSuggestion = isPaidPolicy;
	const isEligibleForPaySuggestion = isPaidPolicy && isPayer;
	const isPolicyEligibleForApproveSuggestion = isPaidPolicy && isEligibleForApproveSuggestion(policy.approvalMode, isUserApprover, isSubmittedTo);
	const isEligibleForExportSuggestion = isExporter && !hasExportError;
	const isEligibleForStatementsSuggestion = isPaidPolicy && !!policy.areCompanyCardsEnabled && hasCardFeed;
	const isEligibleForUnapprovedCashSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && isPaymentEnabled;
	const isEligibleForUnapprovedCardSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard);
	const isEligibleForExpensifyCardSuggestion = isPaidPolicy && isAdmin && isECardEnabled;
	const isEligibleForReimbursementsSuggestion = isPaidPolicy && isAdmin && isPaymentEnabled && hasVBBA && hasReimburser;
	const isAuditor = policy.role === CONST.POLICY.ROLE.AUDITOR;
	const memberCount = Object.keys(policy.employeeList ?? {}).length;
	const isEligibleForTopSpendersSuggestion = isPaidPolicy && (isAdmin || isAuditor || isUserApprover) && memberCount >= 2;

What changes do you think we should make in order to solve the problem?

1. In getSuggestedSearchesVisibility (src/libs/SearchUIUtils.ts), hoist the existing isAuditor computation above the four eligibility expressions and replace isAdmin with (isAdmin || isAuditor) for the Accounting-section flags:
   • isEligibleForUnapprovedCashSuggestion
   • isEligibleForUnapprovedCardSuggestion
   • isEligibleForExpensifyCardSuggestion
   • isEligibleForReimbursementsSuggestion
2. Leave EXPORT and STATEMENTS eligibility unchanged — they are not admin-gated. STATEMENTS already shows for Auditors when the workspace is configured for company cards. EXPORT only ever shows to the configured exporter; if PM intent is for Auditors to additionally see Awaiting export regardless of the exporter assignment, that would be a separate behavioural change to the isExporter gate and should be confirmed with the issue owner before broadening.
3. Verify by signing in as a workspace Auditor with: (a) approvals enabled + payments enabled (Unapproved cash should appear), (b) approvals enabled + a card feed (Unapproved card should appear), (c) Expensify Cards enabled (Reconciliation appears), (d) VBBA + reimburser configured (Reconciliation also appears via the Reimbursements branch). The Top Spenders item, which already permits Auditors, can serve as a regression sanity check against the same workspace.
4. No backend, API, or Onyx-key changes are required — the gating is purely in the client visibility computation.

Scope boundaries:

• File touched: src/libs/SearchUIUtils.ts (the getSuggestedSearchesVisibility function only).
• Platforms affected: all (web, mWeb, desktop, iOS, Android) — the menu is built from this shared utility.
• Explicitly not touched: createTypeMenuSections body and the Accounting section rendering (no logic change needed there); the Saved user-defined-searches section at SearchUIUtils.ts line ~4327 (those aren't role-gated today); the EXPORT_TO_ACCOUNTING action-permission paths in getActions (action availability vs. menu visibility are independent and out of scope here); the isExporter gate on EXPORT (deferred to PM confirmation per change Fix spaces #2).
• API contracts: unchanged. No backend or Onyx-key changes.

What alternative solutions did you explore? (Optional)

• Introduce a new isAccountingViewer helper that wraps isAdmin || isAuditor, used at all four call sites. Slightly cleaner if more roles are added later, but adds an abstraction for one current call group; the inline (isAdmin || isAuditor) change is the minimal diff and matches the existing pattern used for isEligibleForTopSpendersSuggestion.
• Filter at render time inside the Accounting section block in createTypeMenuSections rather than at the visibility-flag layer. Rejected because it would diverge from the established pattern (every other section is gated via suggestedSearchesVisibility) and would scatter role logic across two layers.
• Open the Accounting section to all non-restricted members, not just Auditors. Out of scope and contradicts the issue, which explicitly limits the request to Auditors on the basis of their existing read-only access to all workspace reports.
• Also broaden EXPORT to (isExporter || isAuditor) in the same patch. Tempting because the issue screenshot highlights Awaiting export inside the Accounting region, but EXPORT currently surfaces only to the configured exporter (not to all admins either), so broadening just for Auditors would create asymmetric behaviour with non-exporter admins. Flagged for PM confirmation rather than bundled.

[mukhrr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

In NewDot's Search left-hand menu, the Accounting section's suggested searches (Unapproved cash, Unapproved card, Reconciliation) are shown only to workspace Admins. Members with the read-only Auditor role — who already have full visibility into every report on the workspace — see nothing in this section, despite there being no data-access reason to hide it from them.

What is the root cause of that problem?

The Accounting suggestions' visibility is decided in getSuggestedSearchesVisibility in src/libs/SearchUIUtils.ts. Each Accounting eligibility flag is gated strictly on isAdmin, with no isAuditor allowance — even though isAuditor is computed in the same loop and is correctly used a few lines down for isEligibleForTopSpendersSuggestion:

https://github.com/Expensify/App/blob/main/src/libs/SearchUIUtils.ts#L1050-L1056

So any user whose policy.role is AUDITOR falls through every Accounting eligibility check, and the section is not surfaced for them. The Accounting section in createTypeMenuSections simply reads these visibility booleans, so widening them at the source is sufficient.

Note: EXPORT is gated on isExporter and STATEMENTS is gated on company-cards being enabled — neither is admin-only today, so they're not part of the defect. Only the four admin-gated flags need to change.

What changes do you think we should make in order to solve the problem?

In getSuggestedSearchesVisibility, hoist the existing isAuditor line above the four Accounting flags and treat Auditors the same as Admins for those flags. The minimal diff:

         const isPaidPolicy = isPaidGroupPolicy(policy);
         const isPayer = isPolicyPayer(policy, currentUserEmail);
         const isAdmin = policy.role === CONST.POLICY.ROLE.ADMIN;
+        const isAuditor = policy.role === CONST.POLICY.ROLE.AUDITOR;
         const isExporter = policy.exporter === currentUserEmail;

-        const isEligibleForUnapprovedCashSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && isPaymentEnabled;
-        const isEligibleForUnapprovedCardSuggestion = isPaidPolicy && isAdmin && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard);
-        const isEligibleForExpensifyCardSuggestion = isPaidPolicy && isAdmin && isECardEnabled;
-        const isEligibleForReimbursementsSuggestion = isPaidPolicy && isAdmin && isPaymentEnabled && hasVBBA && hasReimburser;
-        const isAuditor = policy.role === CONST.POLICY.ROLE.AUDITOR;
+        const isEligibleForUnapprovedCashSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && isPaymentEnabled;
+        const isEligibleForUnapprovedCardSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard);
+        const isEligibleForExpensifyCardSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isECardEnabled;
+        const isEligibleForReimbursementsSuggestion = isPaidPolicy && (isAdmin || isAuditor) && isPaymentEnabled && hasVBBA && hasReimburser;

That's the whole fix. The downstream Reconciliation visibility is already the OR of the Expensify Card and Reimbursements branches, so it inherits the change for free. EXPORT and STATEMENTS are intentionally left alone — they are not admin-gated today.

Verification I'd run as an Auditor on a paid policy: (a) approvals + payments enabled → Unapproved cash appears, (b) approvals + a card feed → Unapproved card appears, (c) Expensify Cards enabled → Reconciliation appears, (d) VBBA + reimburser configured → Reconciliation also appears via the Reimbursements branch. Top Spenders, which already permits Auditors, doubles as a regression sanity check.

No backend, API, or Onyx-key changes are needed — this is pure client-side gating in one shared utility, so all platforms (web, mWeb, desktop, iOS, Android) pick it up at once.

What alternative solutions did you explore? (Optional)

• Introduce an isAccountingViewer = isAdmin || isAuditor helper and use it at the four call sites. Slightly cleaner if more roles get added later, but for one current call group the inline form matches the established pattern (isEligibleForTopSpendersSuggestion already does isAdmin || isAuditor || isUserApprover inline).
• Filter at render time inside the Accounting block in createTypeMenuSections. Rejected because every other section is gated via suggestedSearchesVisibility; splitting role logic across two layers would diverge from the existing pattern.
• Open the Accounting section to all non-restricted members. Out of scope — the issue specifically scopes the change to Auditors based on their existing read-only access to all workspace reports.

[KJ21-ENG]

Updated my proposal — replaced the deferred-media placeholder with verified screenshot findings (the highlighted Accounting LHN region maps to EXPORT, UNAPPROVED_CASH, UNAPPROVED_CARD, STATEMENTS, RECONCILIATION); root cause and proposed fix unchanged.

[oqildev]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The Accounting section of the Search left-hand menu surfaces Reconciliation, Unapproved cash, and Unapproved card suggested searches only to workspace Admins. Auditors — who already have read-only visibility into every report on the workspace — see nothing in this Accounting region, even though every data row those searches surface is data the Auditor is already permitted to read. The fix should align the role gate on these three Accounting suggestions with the role gate Auditors already pass on every other Accounting-adjacent surface in this same file.

What is the root cause of that problem?

The eligibility flags for the four admin-gated Accounting suggestions in getSuggestedSearchesVisibility (src/libs/SearchUIUtils.ts) gate strictly on policy.role === ADMIN, with no AUDITOR allowance:

• line 1050: isEligibleForUnapprovedCashSuggestion
• line 1051: isEligibleForUnapprovedCardSuggestion
• line 1052: isEligibleForExpensifyCardSuggestion
• line 1053: isEligibleForReimbursementsSuggestion

RECONCILIATION visibility is derived as the OR of Expensify Card and Reimbursements, so it inherits the same admin-only gate. UNAPPROVED_CASH and UNAPPROVED_CARD have their own admin-only flags. Of the five highlighted Accounting items, EXPORT is gated on isExporter and STATEMENTS is gated on company-cards-enabled — neither is admin-only and neither is part of this defect.

The getSuggestedSearchesVisibility function already computes const isAuditor = policy.role === CONST.POLICY.ROLE.AUDITOR; at line 1054, and uses it correctly for isEligibleForTopSpendersSuggestion at line 1056. So the missing piece is purely that the Accounting flags were not extended to use this already-computed value.

There are two pre-existing precedents in the same file for the role gate Auditors should pass on Accounting-class data:

• isPolicyEligibleForSpendOverTime (SearchUIUtils.ts line 992-996) gates Spend-over-time on (isAdmin || isAuditor || isPolicyApprover).
• isEligibleForTopSpendersSuggestion (line 1056) gates Top Spenders on (isAdmin || isAuditor || isUserApprover).

Both of these already include Auditors. The four Accounting flags are the only outliers.

What changes do you think we should make in order to solve the problem?

Code change — src/libs/SearchUIUtils.ts (single function, four lines):

Move the existing isAuditor line above the four Accounting flags and replace isAdmin with (isAdmin || isAuditor) on each:

• isEligibleForUnapprovedCashSuggestion → isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && isPaymentEnabled
• isEligibleForUnapprovedCardSuggestion → isPaidPolicy && (isAdmin || isAuditor) && isApprovalEnabled && (hasCardFeed || !!defaultExpensifyCard)
• isEligibleForExpensifyCardSuggestion → isPaidPolicy && (isAdmin || isAuditor) && isECardEnabled
• isEligibleForReimbursementsSuggestion → isPaidPolicy && (isAdmin || isAuditor) && isPaymentEnabled && hasVBBA && hasReimburser

This matches the inline (isAdmin || isAuditor || ...) idiom already used at lines 995 and 1056 — no new helper, no abstraction, smallest possible diff.

Approver question — out of scope here. The two existing precedents add a third role too (Approver). Top Spenders uses (isAdmin || isAuditor || isUserApprover). Spend-over-time uses (isAdmin || isAuditor || isPolicyApprover). The issue body explicitly scopes the request to Auditors based on their read-only access to every report on the workspace — Approvers do not have that property (they only see reports routed to them). Extending the gate to Approvers would change visibility for users who can't read the underlying data, so it should remain out of scope unless PM clarifies otherwise. Mentioning here to surface the inconsistency for a possible follow-up.

Test changes — tests/unit/Search/SearchUIUtilsTest.ts (this is the part neither prior proposal mentions):

The file already contains a describe('Test getSuggestedSearchesVisibility', ...) block. Every existing test case in that block constructs the policy with role: CONST.POLICY.ROLE.ADMIN, so the Auditor path has zero coverage today and the regression would not be caught. Add focused cases that lock in the new behaviour:

1. Should show Unapproved cash for Auditor when approvals + payments are enabled — policy with role: AUDITOR, isPaidGroupPolicy = true, approvalMode != OPTIONAL, arePaymentsEnabled = true → expect visibility.unapprovedCash === true.
2. Should show Unapproved card for Auditor when approvals + a card feed exist — role: AUDITOR with a cardFeed entry → expect visibility.unapprovedCard === true.
3. Should show Reconciliation for Auditor when Expensify Cards are enabled — role: AUDITOR, areExpensifyCardsEnabled = true → expect visibility.reconciliation === true.
4. Should show Reconciliation for Auditor when VBBA + reimburser are configured — role: AUDITOR with an OPEN achAccount and reimburser set → expect visibility.reconciliation === true.
5. Should still hide Unapproved cash for non-admin/non-auditor (member) — regression guard against widening the gate too far.

These five cases exercise each of the four flipped flags plus the negative case, all in the same testing style the file already uses.

Out of scope / not touched:

• createTypeMenuSections and the Accounting section render path — visibility is the source of truth and no rendering logic change is needed.
• EXPORT (isExporter gate) and STATEMENTS (company-cards gate) — not admin-only, not part of this defect.
• Approver-role widening — see "out of scope" note above; flagged for PM only.
• Backend, Onyx keys, or API contracts — purely client-side visibility change in one shared utility.

What alternative solutions did you explore? (Optional)

• Introduce an isAccountingViewer = isAdmin || isAuditor helper at the top of the function. Cleaner if a third role is later admitted, but adds an abstraction for one call group and diverges from the inline idiom already established at lines 995 and 1056. Rejected as premature.

• Filter at render time inside createTypeMenuSections instead of at the visibility-flag layer. Rejected because every other suggested-search section in this file is gated through getSuggestedSearchesVisibility. Splitting role logic across two layers would diverge from the existing pattern and double the surface area for future role changes.

• Open the Accounting section to all non-restricted workspace members. Rejected because the issue explicitly scopes the change to Auditors based on the data-access symmetry. A regular member doesn't already see every workspace report and shouldn't get these suggestions.

• Also broaden EXPORT to include Auditors. Rejected because EXPORT surfaces only to the configured exporter (not even to all admins), so widening only to Auditors would create asymmetric behaviour with non-exporter admins. Out of scope and would need PM confirmation.

[github-actions]

⚠️ @oqildev Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.