[Due for payment 2026-06-26] [Due for payment 2026-06-25] [$250] Both Export to accounting options don't show in the bulk select menu until opening the report first.

[trjExpensify]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: v9.4.0-2
Reproducible in staging?:
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @Kel-Expensify
Slack conversation (hyperlinked to channel name): #expensify-bugs

Action Performed:

1. Connect to an accounting solution
2. Create a bunch of reports > get them into the approved state
3. Clear cache and restart
4. Go to Spend > Reports > Select an approved report
5. Observe neither Export to accounting options in the bulk select menu (i.e "Export to NetSuite" & "Mark as manually exported")
6. Open the report
7. Go back to Spend > Reports > Select an approved report
8. Observe both buttons now appear in the bulk select menu.

Expected Result:

The report shouldn't need to be opened first for the buttons to show.

Actual Result:

You have to open the report first.

Workaround:

Open the report first, but that defeats the purpose of the feature.

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

In thread here.

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064112439939852919
• Upwork Job ID: 2064112439939852919
• Last Price Increase: 2026-06-08

[MelvinBot]

Proposal

What is the root cause of that problem?

The two export-to-accounting options in the Search bulk-select menu are computed in useSearchBulkActions, and their visibility reads from the live Onyx collections (policy_* and report_*) instead of the Search snapshot (currentSearchResults.data).

Two gates fail on a fresh load:

1. The integration gate — useSearchBulkActions.ts:1149-1154 reads policy from policies (the live useOnyx(POLICY) collection at line 324) and calls getConnectedIntegration(policy), which needs policy.connections. The whole menu block at line 1194 is wrapped in if (connectedIntegration).
2. The per-report gate — canReportBeExported at line 1166 reads completeReport from allReports (live useOnyx(REPORT)) and returns false immediately if it's missing.

On a fresh load after clearing cache, the Search > Reports list hydrates the snapshot (currentSearchResults.data["report_<id>"] / ["policy_<id>"]) but does not write those reports/policies into the live report_* / policy_* collections. So both gates evaluate against empty data and the options are hidden.

Opening the report fires openReport() (SearchMoneyRequestReportPage.tsx:208); the OpenReport response populates the live report_<id> and policy_<id>.connections. On return to Search both gates now pass — which is exactly the "open it first" workaround in the report.

The tell that this is the bug: the sibling transaction logic in the same hook already reads from the snapshot first and only falls back to live Onyx — useSearchBulkActions.ts:273 — but the export logic was never given that fallback.

Evidence & data flow

• getSecondaryExportReportActions → isExportAction / isMarkAsExportedAction (ReportSecondaryActionUtils.ts:469-558) both short-circuit on getValidConnectedIntegration(policy), which inspects policy.connections.
• getConnectedIntegration / getValidConnectedIntegration read policy?.connections?.[integration] (PolicyUtils.ts:1986-2031). connections is an optional field on Policy and is only hydrated by an API response.
• The snapshot already carries policy_* / report_* entries and is read elsewhere in this hook (e.g. useSearchBulkActions.ts:432-438) — but getExportOptions/canReportBeExported ignore it and read live Onyx only.

Flow: load Search → snapshot filled, live report_*/policy_* empty → select approved report → both gates fail → options hidden. Open report → OpenReport populates live report_<id> + policy_<id>.connections → back to Search → gates pass → options appear.

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

Make the export-visibility logic read from the Search snapshot first, falling back to live Onyx — mirroring the pattern already used at useSearchBulkActions.ts:273:

• In canReportBeExported (lines 1165-1166), resolve completeReport and reportPolicy from currentSearchResults.data first, then allReports / policies.
• In the integration gate (line 1149), resolve policy from the snapshot first as well so getConnectedIntegration(policy) sees connections.

⚠️ One thing to verify before implementing: this client-only fix works only if the Search API snapshot includes policy.connections (and the config.autoSync it reads). If the backend Search response strips connections from the policy snapshot, the fix must instead live in the backend (extend the Search response to include policy.connections) — which is outside the App repo and would need an internal engineer. Worth confirming the snapshot shape for an approved report on a connected policy first.

What alternative solutions did you explore? (Optional)

• Backend: extend the Search API response to write the full policy (with connections) into the live policy_* collection, so the existing live-Onyx checks pass. Outside the App repo.
• Side-fetch: when a report is selected in Search bulk mode, proactively fetch the policy connections for its policyID. More requests; not preferred over the snapshot fallback.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92976) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

Proposal

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

On Spend > Reports, after connecting an accounting integration and selecting approved reports in the bulk-select menu, the report-level accounting export options such as "Export to NetSuite" and "Mark as manually exported" are missing until the user opens one of those reports first.

What is the root cause of that problem?

The bulk action menu is calculating report-level export eligibility from the full report entry in the ONYXKEYS.COLLECTION.REPORT collection, but the Spend > Reports search/list view can have the selected report available only as search result data after a cache clear.

In SearchContext, when a report-group row is selected, selectedReports is built from the search list item. That list item is already a TransactionReportGroupListItemType, which extends Report, but the selection state strips it down to a smaller object.

Then useSearchBulkActions decides whether to show the two integration export options with canReportBeExported(). That helper does this:

const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`];

if (!completeReport) {
    return false;
}

So on a cold cache, the report row can be visible and selected from the search snapshot, but if allReports[reportID] has not been hydrated yet, both canExportAllReportsToIntegration and canMarkAllReportsAsExported become false. Opening the report hydrates the full report Onyx entry, so the exact same bulk-selection path starts passing and the two options appear.

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

Make the report-level bulk export eligibility use the report data that is already available from the search/list result before falling back to the full Onyx report collection.

Concretely:

1. Preserve the selected report row's report data when building selectedReports in SearchContext, or otherwise keep enough of the Report fields on the selected report object for secondary action checks.

2. In useSearchBulkActions's canReportBeExported(), resolve the report in this order:

   • allReports[REPORT + reportID], when it exists;
   • the report entry in currentSearchResults.data[REPORT + reportID], when present;
   • the selected report/list item data preserved from SearchContext.

3. Pass that resolved report into getSecondaryExportReportActions() instead of returning false just because the standalone report collection entry is missing.

4. Keep the existing policy/accounting checks unchanged. The fix should only remove the artificial dependency on opening the report first; it should not make export actions appear for reports that getSecondaryExportReportActions() would reject.

5. Add regression coverage around the Spend > Reports bulk menu with an approved report whose search result exists but whose ONYXKEYS.COLLECTION.REPORT + reportID entry is not loaded. The test should verify that the integration export item and "Mark as manually exported" item are still included when getSecondaryExportReportActions() would allow them, and that the normal non-eligible report cases remain hidden.

What alternative solutions did you explore? (Optional)

Forcing the app to fetch or hydrate every selected report before opening the bulk menu would also make allReports[reportID] exist, but it adds extra loading and keeps the UI coupled to a cache side effect. Using the already-loaded search result report is more direct and matches how the Reports list can render and select the report before the detail page has ever been opened.

[abbasifaizan70]

Proposal

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

In Spend > Reports, when an approved report is selected, the bulk‑select menu does not show the two accounting export options ("Export to NetSuite" and "Mark as manually exported") on a fresh load (after clearing cache and restarting). The options only appear after the user opens the report once and navigates back. They should be available immediately, without the user having to open the report first.

What is the root cause of that problem?

The bulk‑select export options are gated on whether the report exists in the full report_ Onyx collection (allReports), which is only populated for a report once that report has been opened (an OpenReport call writes the full report into report_<reportID>). On a fresh load the report only lives in the Search snapshot, so the gate fails and both options are hidden.

canReportBeExported reads the report from allReports and returns false when it is missing, instead of falling back to the Search snapshot the menu already has. This early return is the bug:

App/src/hooks/useSearchBulkActions.ts

Lines 1160 to 1181 in bf9ef82

	const canReportBeExported = (report: (typeof selectedReports)[0], exportOption: ValueOf<typeof CONST.REPORT.EXPORT_OPTIONS>) => {
	if (!report.reportID) {
	return false;
	}
	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`];
	if (!completeReport) {
	return false;
	}
	const reportExportOptions = getSecondaryExportReportActions(
	currentUserPersonalDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserPersonalDetails?.login ?? '',
	completeReport,
	bankAccountList,
	reportPolicy,
	);
	return reportExportOptions.includes(exportOption);
	};

Both export options are computed by calling canReportBeExported for every selected report, so when it returns false for an unopened report, neither "Export to integration" nor "Mark as manually exported" is added to the menu:

App/src/hooks/useSearchBulkActions.ts

Lines 1183 to 1192 in bf9ef82

	const canExportAllReportsToIntegration =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION));
	const canMarkAllReportsAsExported =
	isReportsTab &&
	selectedReportIDs.length > 0 &&
	includeReportLevelExport &&
	selectedReports.every((report) => canReportBeExported(report, CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED));

The eligibility check itself (getSecondaryExportReportActions) only needs report fields that are already present in the Search snapshot — type, statusNum/stateNum, policyID, ownerAccountID, etc. It does not require any data that is exclusive to the opened‑report payload, so requiring the full report_ entry is unnecessary:

App/src/libs/ReportSecondaryActionUtils.ts

Lines 1088 to 1113 in bf9ef82

	function getSecondaryExportReportActions(
	currentUserAccountID: number,
	currentUserLogin: string,
	report: Report,
	bankAccountList: OnyxEntry<BankAccountList>,
	policy?: Policy,
	exportTemplates: ExportTemplate[] = [],
	): Array<ValueOf<string>> {
	const options: Array<ValueOf<string>> = [];
	if (isExportAction(currentUserAccountID, currentUserLogin, report, bankAccountList, policy)) {
	options.push(CONST.REPORT.EXPORT_OPTIONS.EXPORT_TO_INTEGRATION);
	}
	if (isMarkAsExportedAction(currentUserAccountID, currentUserLogin, report, bankAccountList, policy)) {
	options.push(CONST.REPORT.EXPORT_OPTIONS.MARK_AS_EXPORTED);
	}
	options.push(CONST.REPORT.EXPORT_OPTIONS.DOWNLOAD_CSV);
	// Add any custom IS templates that have been added to the user's account as export options
	for (const template of exportTemplates) {
	options.push(template.name);
	}
	return options;
	}

The same hook already establishes the correct pattern elsewhere — it reads the report from the Search snapshot first and falls back to allReports — which is exactly the resilience missing in canReportBeExported:

App/src/hooks/useSearchBulkActions.ts

Line 273 in bf9ef82

const report = reportID ? ((searchData?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] as Report | undefined) ?? allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]) : undefined;

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

All suggested code is TypeScript and only shows the lines that actually change.

Make canReportBeExported fall back to the Search snapshot (currentSearchResults?.data) when the full report is not yet in allReports, mirroring the existing pattern at line 273. The original block is shown by the permalink in the root cause above; the changed lines become:

const completeReport =
    allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`] ??
    (currentSearchResults?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`] as Report | undefined);

if (!completeReport) {
    return false;
}

currentSearchResults is already destructured in this hook (const {currentSearchResults} = useSearchResultsContext();) and is used throughout getExportOptions, so it is in scope and no new dependency is introduced. With the snapshot fallback, getSecondaryExportReportActions receives the report data on first render and both options appear without the report needing to be opened.

A verification step should confirm: (1) on a fresh load both options appear for an approved report; (2) the options remain correct after the report is opened (where allReports now takes precedence, preserving the freshest data); and (3) non‑exportable reports (e.g. open/processing, no connection) still correctly hide the options.

What alternative solutions did you explore? (Optional)

1. Use the report argument (the selected snapshot report) directly instead of re‑deriving completeReport. canReportBeExported already receives the selected report object, so it could pass report straight into getSecondaryExportReportActions. Rejected as the primary fix because keeping the allReports lookup as the preferred source ensures the freshest data once a report has been opened/updated; the snapshot is used only as a fallback. (Functionally close to the proposed fix, but the snapshot‑fallback form is more consistent with line 273.)

2. Prefetch the full reports via OpenReport when the Reports search results load. This would populate allReports so the existing gate passes. Rejected because it fires N network requests just to render a menu, defeats the purpose of the Search snapshot, and adds latency and load for what is purely a client‑side eligibility check.

3. Relax the gate by removing the if (!completeReport) return false; guard and computing options from whatever data is available. Rejected because it risks getSecondaryExportReportActions receiving an undefined report and could surface options for ineligible reports; the snapshot fallback keeps a valid Report object flowing into the check.

[melvin-bot]

Current assignee @ahmedGaber93 is eligible for the External assigner, not assigning anyone new.

[aswin-s]

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

On Web (Spend > Reports), after a fresh cache + restart, selecting an approved report does not show the "Export to NetSuite" or "Mark as manually exported" options in the bulk select menu. The options only appear after the user opens the report once and goes back. Expected: both options should be available without having to open the report first.

What is the root cause of that problem?

getExportOptions in useSearchBulkActions.ts derives the workspace policy from the Onyx collection at two distinct points, and both fail on a cold load:

Point 1 — connectedIntegration gate (line ~1149–1154). policy is resolved as:

const policy = selectedPolicyIDs.length === 1
    ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`]
    : undefined;
const connectedIntegration = getConnectedIntegration(policy);

The entire export submenu is wrapped in if (connectedIntegration). On a fresh load ONYXKEYS.COLLECTION.POLICY has not yet hydrated, so policy is undefined, connectedIntegration is undefined, and the if branch is never entered — neither option is rendered at all.

Point 2 — canReportBeExported predicate (lines ~1160–1181). Inside the predicate, completeReport and reportPolicy are resolved exclusively from the Onyx collections:

const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`];

if (!completeReport) {
    return false;
}

On a fresh load the report exists in the search snapshot (currentSearchResults.data) — which is why it renders in the list — but its full record has not yet been hydrated into ONYXKEYS.COLLECTION.REPORT. With completeReport undefined, the predicate returns false early, so canExportAllReportsToIntegration and canMarkAllReportsAsExported are both false even if the connectedIntegration gate were somehow passed. Opening the report hydrates both Onyx collections, after which both guards pass — matching the reproduction exactly.

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

Three targeted edits to src/hooks/useSearchBulkActions.ts, all within getExportOptions:

1. Add a snapshot fallback when deriving policy (fixes the connectedIntegration gate, line ~1149).

// Before
const policy = selectedPolicyIDs.length === 1
    ? policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`]
    : undefined;

// After
const policy =
    selectedPolicyIDs.length === 1
        ? (policies?.[`${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`] ??
          (currentSearchResults?.data?.[
              `${ONYXKEYS.COLLECTION.POLICY}${selectedPolicyIDs.at(0)}`
          ] as OnyxEntry<Policy>))
        : undefined;

This ensures getConnectedIntegration(policy) returns the integration name even before ONYXKEYS.COLLECTION.POLICY has hydrated, so the if (connectedIntegration) branch is entered and the options are rendered.

2. Add snapshot fallbacks inside canReportBeExported for both completeReport and reportPolicy (fixes the predicate, lines ~1165–1166).

// Before
const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`];

// After
const reportPolicy =
    policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`] ??
    (currentSearchResults?.data?.[
        `${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`
    ] as OnyxEntry<Policy>);
const completeReport =
    allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`] ??
    (currentSearchResults?.data?.[
        `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`
    ] as OnyxEntry<Report>);

This mirrors the pattern already used elsewhere in this same file — for example, shouldShowBulkDuplicateOption's getReportOrDraftReport(reportID, searchReports) usage and the duplicate-option block at line 273 — where the search snapshot is consulted as a fallback for the Onyx collection. With a real completeReport, getSecondaryExportReportActions can determine eligibility, and with a real reportPolicy it receives the connection info needed to do so.

3. No dependency array change needed. currentSearchResults?.data is already present in the headerButtonsOptions useMemo dependency array, so no additional wiring is required.

4. No platform twin needed — the hook is shared and the issue is reported on Web/MacOS Chrome only; the same code path runs on all platforms.

What alternative solutions did you explore? (Optional)

Eagerly hydrating selected reports into ONYXKEYS.COLLECTION.REPORT on selection would fix it globally, but it widens blast radius beyond bulk-actions and races with other consumers; the snapshot fallback is the minimal, locally-consistent fix.

[melvin-bot]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

In the bulk-select export logic, both "Export to [integration]" and "Mark as manually exported" are gated by canExportAllReportsToIntegration / canMarkAllReportsAsExported, which require selectedReports.every((report) => canReportBeExported(...)) (useSearchBulkActions.ts#L1183-L1192).

canReportBeExported looks up the report only in the live Onyx report collection:

const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`];
if (!completeReport) {
    return false;
}

(useSearchBulkActions.ts#L1166-L1170)

Causal chain: after a cache clear/restart, the Search results snapshot (currentSearchResults.data) holds the report, but the live COLLECTION.REPORT key is empty until the report is fetched → opening the report triggers OpenReport, which populates allReports → only then is completeReport non-null and both options appear. Before that, canReportBeExported returns false for every selected report, so neither option is built (useSearchBulkActions.ts#L1241-L1263). This is the same "snapshot vs. live Onyx" gap already noted elsewhere in this file (e.g. the flattenedReportActions merge at #L502-L523).

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

In canReportBeExported, fall back to the Search snapshot when the live report is missing, instead of bailing out:

const completeReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`]
    ?? (currentSearchResults?.data?.[`${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`] as Report | undefined);

The snapshot report carries the fields getSecondaryExportReportActions needs (state/status, isExportedToIntegration, etc.), so the options compute correctly without first opening the report. The same fallback should be applied to the allReports lookup inside handleExportAction (#L1203) so the "export again" confirmation is consistent.

What alternative solutions did you explore? (Optional)

Eagerly fetch full report data for selected reports (e.g. call OpenReport/metadata fetch when a report is selected in Search). This fixes the symptom but adds network round-trips and a visible delay, whereas the snapshot already contains what's needed — so the snapshot fallback is preferred.