[Due for payment 2026-05-26] [CFI] [$250] "View payment history" shows billing receipts for all users instead of just the billing owner

[MelvinBot]

Updated 2026-05-01: Corrected based on feedback from johncschuster and discussion with tom and ted.

Slack thread: https://expensify.slack.com/archives/C03U7DCU4/p1777661997504489

Problem

When a billing owner navigates to Account > Subscription > View payment history, they are routed to the Search/Expenses page filtered by merchant "Expensify, Inc.". The billing owner's own billing receipts are missing from the results, and instead only billing receipts from other team members are shown.

Expected behavior

The billing owner should see their own billing receipts — i.e., invoices for billing incurred under their own workspaces.

Actual behavior

The billing owner sees none of their own billing receipts. Instead, they only see billing receipts incurred by other team members (likely appearing due to consolidated billing). The billing owner's own receipts exist but are in Deleted status, which causes them to be excluded from the default search results. Additionally, because no from: filter is applied, receipts from other team members are included.

Root cause

The viewPurchases() function builds a search query with only three filters:

• type:expense
• status: (all statuses, but does not include Deleted)
• merchant:"Expensify, Inc."

Two gaps:

1. Missing from:me filter — without this, the search returns billing receipts from all users, not just the billing owner
2. Missing Deleted status — the billing owner's own receipts are in Deleted status and are excluded from the results because the status filter does not include Deleted

Recommended Fix

In viewPurchases(), update the search query to:

1. Add a from:me filter to scope results to the billing owner's own expenses
2. Update the status filter to include Deleted so that the billing owner's receipts (which are in Deleted status) are returned

Reproduction steps

1. Support log in as the billing owner for a company
2. In New Expensify, navigate to Account > Subscription > View payment history
3. Observe the Expenses page filtered by merchant Expensify, Inc.
4. Notice that the billing owner's own billing receipts are missing, and only receipts from other team members appear

2026-05-01_13-58-48.mp4

Environment

• New Expensify (all platforms)

Issue Owner

Current Issue Owner: @mananjadhav

[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/~022050281211372798656

[MelvinBot]

Proposal

What is the root cause of that problem?

The viewPurchases() function builds a search query with type, status, and merchant filters but does not include a from: filter. Without scoping by the current user's accountID, the search returns all Expensify, Inc. merchant expenses visible to the account — including those belonging to other users.

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

Add a from: filter using the current session's accountID (already available via useOnyx(ONYXKEYS.SESSION) at line 56) to the filter object passed to buildQueryStringFromFilterFormValues(). This is the same pattern used in ForYouSection where from: [${accountID}] is passed to the same builder function.

What alternative solutions did you explore? (Optional)

None needed — the from: filter is the standard, established pattern for scoping search results to a specific user in this codebase.

Supporting evidence

• buildQueryStringFromFilterFormValues handles from: as an array filter at SearchQueryUtils.ts:925-954, serializing it as from:<accountID>
• FILTER_KEYS.FROM is defined in SearchAdvancedFiltersForm.ts:127

Possibly related issue

• Expensify/App#82519 — $0 billing receipts not visible in New Expensify payment history

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[aswin-s]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-01 20:08:31 UTC.

Proposal (Updated)

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

When a billing owner taps "View payment history" under Account > Subscription, the Search/Expenses view shows Expensify billing receipts from every visible user instead of only the billing owner's receipts. Additionally, the billing owner's own receipts are missing because they are in Deleted status, which is excluded by the default status filter.

What is the root cause of that problem?

The viewPurchases function in src/pages/settings/Subscription/CardSection/CardSection.tsx builds a search query with only type, status, and merchant:

App/src/pages/settings/Subscription/CardSection/CardSection.tsx

Lines 100 to 108 in 9fe568d

	const viewPurchases = () => {
	const query = buildQueryStringFromFilterFormValues({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	status: CONST.SEARCH.STATUS.EXPENSE.ALL,
	merchant: CONST.EXPENSIFY_MERCHANT,
	});
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
	};

There are two gaps:

1. No from filter — without scoping by the current user, the search returns all visible Expensify, Inc. merchant expenses, including those from other users.

2. Deleted status excluded — CONST.SEARCH.STATUS.EXPENSE.ALL is an empty string (''). In buildQueryStringFromFilterFormValues, the status is only emitted when status && typeof status === 'string' (line 815) or status && Array.isArray(status) (line 820) of SearchQueryUtils.ts. Passing ALL ('') is falsy, so the status filter is skipped entirely, defaulting to backend behavior which excludes Deleted expenses. Since the billing owner's own receipts are in Deleted status, they never appear.

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

In src/pages/settings/Subscription/CardSection/CardSection.tsx, update viewPurchases to:

1. Add a from filter using CONST.SEARCH.ME ('me') wrapped in an array. The from filter is handled as an array type in buildQueryStringFromFilterFormValues (line 933-946 of SearchQueryUtils.ts), so it must be [CONST.SEARCH.ME]. This generates from:me in the query, which the backend resolves to the current user. This is cleaner than using session?.accountID since it requires no conditional guard and uses an existing constant.

2. Pass status as an explicit array of all expense statuses including Deleted. The query builder natively supports status arrays (line 820-823 of SearchQueryUtils.ts), handling deduplication and sanitization internally.

const viewPurchases = () => {
    const query = buildQueryStringFromFilterFormValues({
        type: CONST.SEARCH.DATA_TYPES.EXPENSE,
        status: [
            CONST.SEARCH.STATUS.EXPENSE.UNREPORTED,
            CONST.SEARCH.STATUS.EXPENSE.DRAFTS,
            CONST.SEARCH.STATUS.EXPENSE.OUTSTANDING,
            CONST.SEARCH.STATUS.EXPENSE.APPROVED,
            CONST.SEARCH.STATUS.EXPENSE.DONE,
            CONST.SEARCH.STATUS.EXPENSE.PAID,
            CONST.SEARCH.STATUS.EXPENSE.DELETED,
        ],
        merchant: CONST.EXPENSIFY_MERCHANT,
        from: [CONST.SEARCH.ME],
    });

    Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
};

This generates a query like: type:expense status:unreported,drafts,outstanding,approved,done,paid,deleted merchant:"Expensify, Inc." from:me

What alternative solutions did you explore? (Optional)

• session?.accountID for from: The established pattern in SearchUIUtils.ts (line 720) passes from: [`${accountID}`]. However, CONST.SEARCH.ME is a purpose-built constant that avoids the need for a conditional guard (session?.accountID ? ... : undefined) and is semantically clearer.
• status as .join(',') string: While the query builder accepts status as a string (line 815), passing it as an array is preferred because the builder handles deduplication (new Set) and sanitization (sanitizeSearchValue) internally (line 820-823).
• Keeping CONST.SEARCH.STATUS.EXPENSE.ALL: ALL is '' (empty string), which is falsy and gets skipped by the query builder. There is no way to include Deleted without explicitly listing statuses.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

View payment history builds a Search query in CardSection.viewPurchases() with only type:expense, status: and merchant:"Expensify, Inc.":

App/src/pages/settings/Subscription/CardSection/CardSection.tsx

Lines 100 to 108 in a8dad1c

	const viewPurchases = () => {
	const query = buildQueryStringFromFilterFormValues({
	type: CONST.SEARCH.DATA_TYPES.EXPENSE,
	status: CONST.SEARCH.STATUS.EXPENSE.ALL,
	merchant: CONST.EXPENSIFY_MERCHANT,
	});
	Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query, rawQuery: query}));
	};

That merchant-only filter is too broad. CONST.EXPENSIFY_MERCHANT is the shared merchant value for Expensify billing receipts:

App/src/CONST/index.ts

Lines 2598 to 2599 in a8dad1c

	EXPENSIFY_PARTNER_NAME: 'expensify.com',
	EXPENSIFY_MERCHANT: 'Expensify, Inc.',

The Search query builder already supports a from participant filter. SearchAdvancedFiltersForm defines from as a string array:

App/src/types/form/SearchAdvancedFiltersForm.ts

Lines 685 to 689 in a8dad1c

	[FILTER_KEYS.TAG]: string[];
	[FILTER_KEYS.TAG_NOT]: string[];
	[FILTER_KEYS.FROM]: string[];
	[FILTER_KEYS.FROM_NOT]: string[];

buildQueryStringFromFilterFormValues() serializes array filters including from into query syntax:

App/src/libs/SearchQueryUtils.ts

Lines 925 to 953 in a8dad1c

	if (
	(filterKey === FILTER_KEYS.CATEGORY ||
	filterKey === FILTER_KEYS.CARD_ID ||
	filterKey === FILTER_KEYS.TAX_RATE ||
	filterKey === FILTER_KEYS.EXPENSE_TYPE ||
	filterKey === FILTER_KEYS.TAG ||
	filterKey === FILTER_KEYS.CURRENCY ||
	filterKey === FILTER_KEYS.PURCHASE_CURRENCY ||
	filterKey === FILTER_KEYS.FROM ||
	filterKey === FILTER_KEYS.TO ||
	filterKey === FILTER_KEYS.FEED ||
	filterKey === FILTER_KEYS.IN ||
	filterKey === FILTER_KEYS.ASSIGNEE ||
	filterKey === FILTER_KEYS.POLICY_ID ||
	filterKey === FILTER_KEYS.HAS ||
	filterKey === FILTER_KEYS.IS ||
	filterKey === FILTER_KEYS.EXPORTER ||
	filterKey === FILTER_KEYS.EXPORTED_TO ||
	filterKey === FILTER_KEYS.ATTENDEE ||
	filterKey === FILTER_KEYS.COLUMNS) &&
	Array.isArray(filterValue) &&
	filterValue.length > 0
	) {
	const filterValueArray = [...new Set<string>(filterValue)];
	const keyInCorrectForm = (Object.keys(CONST.SEARCH.SYNTAX_FILTER_KEYS) as FilterKeys[]).find((key) => CONST.SEARCH.SYNTAX_FILTER_KEYS[key] === filterKey);
	if (keyInCorrectForm) {
	return `${prefix}${CONST.SEARCH.SYNTAX_FILTER_KEYS[keyInCorrectForm]}:${filterValueArray.map(sanitizeSearchValue).join(',')}`;
	}

Because viewPurchases() does not pass the current billing owner’s accountID into that supported from filter, Search returns every visible expense with merchant Expensify, Inc. instead of only the billing owner’s receipts.

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

Add the current user accountID to the payment-history Search query using the existing from filter.

Required change:

• In src/pages/settings/Subscription/CardSection/CardSection.tsx, update viewPurchases() to pass from: [\${session?.accountID ?? CONST.DEFAULT_NUMBER_ID}`]intobuildQueryStringFromFilterFormValues()`.
• Keep the existing type, status, and merchant filters unchanged.
• Do not add a custom payment-history search path or backend-specific client handling, because the existing Search filter system already supports this root-cause fix.

Tests:

• Verify manually that Account > Subscription > View payment history navigates to Search with from:<currentAccountID> and merchant:"Expensify, Inc.".
• Verify the results exclude Expensify, Inc. expenses submitted by other users visible to the billing owner.
• Verify the Search page still loads all statuses for the billing owner’s Expensify billing receipts.

What alternative solutions did you explore? (Optional)

[github-actions]

⚠️ @nabi-ebrahimi 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.

[johncschuster]

Hold on this, I don't think Melvin has quite captured the actual behavior here. I'm going to update it.

[johncschuster]

Ok, I've updated the OP and raised the behavior in Slack.