[$250] Add the ability to display tag gl codes when displaying a tag

[flaviadefaria]

Similar to #93155 let's implement the ability for customer to enable tag gl codes (either manually entered or imported via an integration).

Overview

Based on Gong call reviews, some admins requested the ability to see the code when selecting a tag (for example a project code for a project tag) and to be able to search via tag codes. This is a simple improvement that would improve customer satisfaction with the product.

Proposed Solution

• Add a toggle in Tags Settings that enables showing the tag gl code when selecting a tag. The code would be added at the end of the tag name (in parentheses), e.g. Sunshine Project (SP4100)
• Make the code searchable in the tag list
• No changes to the Spend tables (a dedicated tag code column is being added separately)

These were the mockups used for the Category GL codes implementation and can be used here as reference for the corresponding Tag GL code implementation:

Settings

Category Picker

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078085671601088011
• Upwork Job ID: 2078085671601088011
• Last Price Increase: 2026-07-17

Issue Owner

Current Issue Owner: @neerajbachani

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Design team member for new feature review - @dubielzyk-expensify (NewFeature)

[melvin-bot]

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

[samranahm]

Proposal

What is the root cause of that problem?

When a user interacts with a tag selection component (e.g., a tag filter in Search), the application currently does not display General Ledger (GL) codes alongside tag names, nor does it allow searching for tags using their GL codes.

This problem stems from two main gaps:

1. Missing policy setting and tag data structure: There is no policy-level setting to enable the display of tag GL codes, and the tag data fetched from Onyx (via ONYXKEYS.COLLECTION.POLICY_TAGS as seen in useAdvancedSearchFilters:

   App/src/hooks/useAdvancedSearchFilters.ts

   Lines 323 to 396 in acedb02

   	function useAdvancedSearchFilters(type: SearchDataTypes | undefined, policyID: Filter | undefined) {
   	const [shouldDisplayCardFilter] = useOnyx(ONYXKEYS.DERIVED.PERSONAL_AND_WORKSPACE_CARD_LIST, {selector: shouldDisplayCardFilterSelector});
   	const [policies = getEmptyObject<NonNullable<OnyxCollection<Policy>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: advancedSearchPoliciesSelector});
   	const [policyDerived] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: policyDerivedSelector});
   	const [allPolicyCategories = getEmptyObject<NonNullable<OnyxCollection<PolicyCategories>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY_CATEGORIES, {
   	selector: availablePolicyCategoriesSelector,
   	});
   	const selectedPolicyCategories = policyID?.value?.length ? getAllPolicyValues(policyID, ONYXKEYS.COLLECTION.POLICY_CATEGORIES, allPolicyCategories) : [];
   	const [allPolicyTagLists = getEmptyObject<NonNullable<OnyxCollection<PolicyTagLists>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY_TAGS, {selector: passthroughPolicyTagListSelector});
   	const selectedPolicyTagLists = policyID?.value?.length ? getAllPolicyValues(policyID, ONYXKEYS.COLLECTION.POLICY_TAGS, allPolicyTagLists) : [];
   	const [hasTags] = useOnyx(ONYXKEYS.COLLECTION.POLICY_TAGS, {selector: hasTagsSelector});
   	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
   	const {workspaces} = useAdvancedSearchFiltersWorkspaces(policies);
   	// When looking if a user has any categories to display, we want to ignore the policies that are of type PERSONAL
   	const hasNonPersonalPolicyCategories = Object.keys(allPolicyCategories).some((policyCategoryId) => {
   	const categoryPolicyID = policyCategoryId.replace(ONYXKEYS.COLLECTION.POLICY_CATEGORIES, '');
   	const policy = policies[`${ONYXKEYS.COLLECTION.POLICY}${categoryPolicyID}`];
   	return !!policy && policy.type !== CONST.POLICY.TYPE.PERSONAL;
   	});
   	const shouldDisplayCategoryFilter = shouldDisplayFilter(hasNonPersonalPolicyCategories ? 1 : 0, policyDerived?.areCategoriesEnabled ?? false, selectedPolicyCategories?.length > 0);
   	const hasSelectedPolicyTags = selectedPolicyTagLists.some(policyTagListHasTags);
   	const shouldDisplayTagFilter = shouldDisplayFilter(hasTags ? 1 : 0, policyDerived?.areTagsEnabled ?? false, hasSelectedPolicyTags);
   	// Count business accounts that aren't partially set up, mirroring BankAccountSelector so the row never shows above an empty picker.
   	const hasFilterableBankAccount = Object.values(bankAccountList ?? {}).some(isFilterableBankAccount);
   	const shouldDisplayBankAccountFilter = shouldDisplayFilter(hasFilterableBankAccount ? 1 : 0, true);
   	const shouldDisplayTaxFilter = shouldDisplayFilter(policyDerived?.hasAnyTaxRates ? 1 : 0, policyDerived?.areTaxEnabled ?? false);
   	const shouldDisplayWorkspaceFilter = workspaces.some((section) => section.data.length > 1);
   	let currentType = type ?? CONST.SEARCH.DATA_TYPES.EXPENSE;
   	if (!(currentType in typeFiltersKeys)) {
   	currentType = CONST.SEARCH.DATA_TYPES.EXPENSE;
   	}
   	return typeFiltersKeys[currentType]
   	.map((section) =>
   	section
   	.map((key) => {
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.CATEGORY && !shouldDisplayCategoryFilter) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.TAG && !shouldDisplayTagFilter) {
   	return;
   	}
   	if (
   	(key === CONST.SEARCH.SYNTAX_FILTER_KEYS.CARD_ID || key === CONST.SEARCH.SYNTAX_FILTER_KEYS.POSTED || key === CONST.SEARCH.SYNTAX_FILTER_KEYS.FEED) &&
   	!shouldDisplayCardFilter
   	) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.BANK_ACCOUNT && !shouldDisplayBankAccountFilter) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.TAX_RATE && !shouldDisplayTaxFilter) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.POLICY_ID && !shouldDisplayWorkspaceFilter) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.ATTENDEE && !(policyDerived?.isAttendeeTrackingEnabled ?? true)) {
   	return;
   	}
   	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_FIELD && !(policyDerived?.hasReportFields ?? false)) {
   	return;
   	}
   	return key;
   	})
   	.filter((filter): filter is NonNullable<typeof filter> => !!filter),
   	)
   	.filter((section) => !!section.length);
   	}

   ) does not include a glCode property for individual tags.
2. Incomplete display and search logic: UI components that present lists of tags, such as those used in search filters, construct their selectable items using only the tag's primary name. For instance, the tokenizedSearch function (demonstrated in WorkspaceSelector at

   App/src/components/Search/FilterComponents/WorkspaceSelector.tsx

   Line 96 in acedb02

   return (

   ) filters items based solely on their text property, which currently does not incorporate any GL code. This prevents the GL code from being displayed (e.g., Sunshine Project (SP4100)) and from being included in the searchable text.

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

1. Introduce a policy setting for tag GL code display:

   • Modify the Policy Onyx structure to include a new boolean field, policy.tagSettings.showGLCode.
   • In WorkspaceTagsSettingsPage.tsx (the inferred component for managing policy tag settings), add a new ToggleSettingOption component. This toggle will allow policy admins to enable or disable the display of tag GL codes, updating the policy.tagSettings.showGLCode value via Policy.setPolicyTagSettings.

2. Update tag data structure and create a formatting utility:

   • Ensure that individual tag objects stored under ONYXKEYS.COLLECTION.POLICY_TAGS (accessed by useAdvancedSearchFilters:

     App/src/hooks/useAdvancedSearchFilters.ts

     Lines 323 to 396 in acedb02

     	function useAdvancedSearchFilters(type: SearchDataTypes | undefined, policyID: Filter | undefined) {
     	const [shouldDisplayCardFilter] = useOnyx(ONYXKEYS.DERIVED.PERSONAL_AND_WORKSPACE_CARD_LIST, {selector: shouldDisplayCardFilterSelector});
     	const [policies = getEmptyObject<NonNullable<OnyxCollection<Policy>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: advancedSearchPoliciesSelector});
     	const [policyDerived] = useOnyx(ONYXKEYS.COLLECTION.POLICY, {selector: policyDerivedSelector});
     	const [allPolicyCategories = getEmptyObject<NonNullable<OnyxCollection<PolicyCategories>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY_CATEGORIES, {
     	selector: availablePolicyCategoriesSelector,
     	});
     	const selectedPolicyCategories = policyID?.value?.length ? getAllPolicyValues(policyID, ONYXKEYS.COLLECTION.POLICY_CATEGORIES, allPolicyCategories) : [];
     	const [allPolicyTagLists = getEmptyObject<NonNullable<OnyxCollection<PolicyTagLists>>>()] = useOnyx(ONYXKEYS.COLLECTION.POLICY_TAGS, {selector: passthroughPolicyTagListSelector});
     	const selectedPolicyTagLists = policyID?.value?.length ? getAllPolicyValues(policyID, ONYXKEYS.COLLECTION.POLICY_TAGS, allPolicyTagLists) : [];
     	const [hasTags] = useOnyx(ONYXKEYS.COLLECTION.POLICY_TAGS, {selector: hasTagsSelector});
     	const [bankAccountList] = useOnyx(ONYXKEYS.BANK_ACCOUNT_LIST);
     	const {workspaces} = useAdvancedSearchFiltersWorkspaces(policies);
     	// When looking if a user has any categories to display, we want to ignore the policies that are of type PERSONAL
     	const hasNonPersonalPolicyCategories = Object.keys(allPolicyCategories).some((policyCategoryId) => {
     	const categoryPolicyID = policyCategoryId.replace(ONYXKEYS.COLLECTION.POLICY_CATEGORIES, '');
     	const policy = policies[`${ONYXKEYS.COLLECTION.POLICY}${categoryPolicyID}`];
     	return !!policy && policy.type !== CONST.POLICY.TYPE.PERSONAL;
     	});
     	const shouldDisplayCategoryFilter = shouldDisplayFilter(hasNonPersonalPolicyCategories ? 1 : 0, policyDerived?.areCategoriesEnabled ?? false, selectedPolicyCategories?.length > 0);
     	const hasSelectedPolicyTags = selectedPolicyTagLists.some(policyTagListHasTags);
     	const shouldDisplayTagFilter = shouldDisplayFilter(hasTags ? 1 : 0, policyDerived?.areTagsEnabled ?? false, hasSelectedPolicyTags);
     	// Count business accounts that aren't partially set up, mirroring BankAccountSelector so the row never shows above an empty picker.
     	const hasFilterableBankAccount = Object.values(bankAccountList ?? {}).some(isFilterableBankAccount);
     	const shouldDisplayBankAccountFilter = shouldDisplayFilter(hasFilterableBankAccount ? 1 : 0, true);
     	const shouldDisplayTaxFilter = shouldDisplayFilter(policyDerived?.hasAnyTaxRates ? 1 : 0, policyDerived?.areTaxEnabled ?? false);
     	const shouldDisplayWorkspaceFilter = workspaces.some((section) => section.data.length > 1);
     	let currentType = type ?? CONST.SEARCH.DATA_TYPES.EXPENSE;
     	if (!(currentType in typeFiltersKeys)) {
     	currentType = CONST.SEARCH.DATA_TYPES.EXPENSE;
     	}
     	return typeFiltersKeys[currentType]
     	.map((section) =>
     	section
     	.map((key) => {
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.CATEGORY && !shouldDisplayCategoryFilter) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.TAG && !shouldDisplayTagFilter) {
     	return;
     	}
     	if (
     	(key === CONST.SEARCH.SYNTAX_FILTER_KEYS.CARD_ID || key === CONST.SEARCH.SYNTAX_FILTER_KEYS.POSTED || key === CONST.SEARCH.SYNTAX_FILTER_KEYS.FEED) &&
     	!shouldDisplayCardFilter
     	) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.BANK_ACCOUNT && !shouldDisplayBankAccountFilter) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.TAX_RATE && !shouldDisplayTaxFilter) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.POLICY_ID && !shouldDisplayWorkspaceFilter) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.ATTENDEE && !(policyDerived?.isAttendeeTrackingEnabled ?? true)) {
     	return;
     	}
     	if (key === CONST.SEARCH.SYNTAX_FILTER_KEYS.REPORT_FIELD && !(policyDerived?.hasReportFields ?? false)) {
     	return;
     	}
     	return key;
     	})
     	.filter((filter): filter is NonNullable<typeof filter> => !!filter),
     	)
     	.filter((section) => !!section.length);
     	}

     ) can include a glCode property. This will require backend and Onyx schema updates.
   • Create a new utility function, getFormattedTagName, in src/libs/PolicyUtils.ts. This function will take a tag object and the showGLCode boolean from the policy settings. It will return the tag name formatted as Tag Name (GL Code) if showGLCode is true and glCode is present, otherwise it will return just Tag Name.
   • Example getFormattedTagName utility:

     function getFormattedTagName(tag: PolicyTag, showGLCode: boolean): string {
         if (showGLCode && tag.glCode) {
             return `${tag.name} (${tag.glCode})`;
         }
         return tag.name;
     }

3. Apply formatted tag names in tag selection components for display and search:

   • Locate the component responsible for rendering tag selection lists (e.g., a TagPicker or a tag filter component within Search, which would consume allPolicyTagLists from useAdvancedSearchFilters).
   • In this component, retrieve the policy.tagSettings.showGLCode value.
   • When mapping PolicyTag objects to MultiSelectItem or ListItem objects for display, use the getFormattedTagName utility (from step 2) to set the text property of each item. This ensures that the displayed tag names include GL codes when enabled.
   • Since tokenizedSearch (as demonstrated in WorkspaceSelector at

     App/src/components/Search/FilterComponents/WorkspaceSelector.tsx

     Line 96 in acedb02

     return (

     ) operates on the text property, this change will automatically make GL codes searchable within tag lists.
   • Example of how text property would be set in a mapping function (assuming tags is an array of PolicyTag objects and showGLCode is available):

     // In a component that maps tags to selectable items
     const tagOptions: Array<MultiSelectItem<string>> = tags.map((tag) => ({
         text: PolicyUtils.getFormattedTagName(tag, showGLCode),
         value: tag.name, // Or tag.tagID, depending on the actual value needed
         // ... other properties like icons
     }));

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[aswin-s]

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

Admins want the ability to display tag GL codes alongside tag names in tag selectors (e.g. Sunshine Project (SP4100)) and to search tags by GL code. Today src/libs/TagsOptionsListUtils.ts builds tag picker sections using only the tag name — the 'GL Code' field on each PolicyTag is stored/edited (see src/pages/workspace/tags/DynamicTagGLCodePage.tsx and UpdatePolicyTagGLCodeParams.ts) and rendered in the workspace tags table (src/components/Tables/WorkspaceTagsTable/WorkspaceTagsTableRow.tsx:67), but it is never surfaced or matched in the tag picker, and there is no policy-level opt-in to control the display. This should mirror the shipped Category GL code data plumbing and add the display/search behavior for both categories and tags.

What is the root cause of that problem?

Three gaps in the existing tag data pipeline:

1. Display: getTagsOptions in src/libs/TagsOptionsListUtils.ts (lines 52–66) builds each picker option from only tag.name — text, keyForList, searchText, and tooltipText are all set from cleanedName/tag.name. There is no code path that appends (GL Code) to any of those fields, and getTagsOptions receives Array<Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction'>> — the 'GL Code' field is not even in the pick, so it is structurally invisible to the formatter.

2. Search: getTagListSections (lines 71–180) runs tokenizedSearch before calling getTagsOptions, and those tokenizedSearch calls extract only getCleanedTagName(tag.name) as the searchable field (lines 121–124). Adding GL Code to the option's searchText after the fact would not fix search — the filter has already discarded non-matching tags by the time getTagsOptions runs. The GL code must be added to the tokenizedSearch extractor callbacks directly.

3. Settings toggle: src/pages/workspace/tags/WorkspaceTagsPage.tsx exposes tag-list settings (import, required, approver, etc.) but has no "Show GL code in picker" switch; there is no corresponding boolean on PolicyTagList/Policy (src/types/onyx/Policy.ts) or a Tag action to persist it.

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

1. Data model — Add a new boolean showTagGLCodeInPicker to PolicyTagList in src/types/onyx/Policy.ts; add a CONST.POLICY.TAG_LIST_FIELDS entry if applicable in src/CONST/index.ts.

2. Backend action — Add setPolicyTagGLCodeDisplayEnabled in src/libs/actions/Policy/Tag.ts (mirroring existing setPolicyTagsRequired / setPolicyTagApprover patterns) with an UpdatePolicyTagGLCodeDisplayEnabled API command and parameters file under src/libs/API/parameters/ and a src/libs/API/types.ts WRITE_COMMANDS entry.

3. Settings UI — In src/pages/workspace/tags/TagsSettingsPage.tsx (or DynamicTagSettingsPage.tsx for multi-level lists), add a ToggleSettingOptionRow labelled with the new workspace.tags.showGLCodeInPicker key, wired to the action above. Add the string in src/languages/en.ts and each other src/languages/*.ts file.

4. Picker display and search — Two coordinated changes are required in src/libs/TagsOptionsListUtils.ts:

   a. Widen the type accepted by getTagsOptions (lines 52–66): change the Pick to include 'GL Code' alongside 'name' | 'enabled' | 'pendingAction', and accept a new showGLCode boolean parameter. When showGLCode is true and tag['GL Code'] is non-empty, format text and tooltipText as `${cleanedName} (${tag['GL Code']})` per the issue mockup. Keep keyForList and the submitted value equal to the raw tag.name so form submission is unchanged. searchText is intentionally left as the plain name here because search filtering happens upstream (see point b).

   // getTagsOptions — add showGLCode param and GL Code to Pick
   function getTagsOptions(
       tags: Array<Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction' | 'GL Code'>>,
       selectedOptions?: SelectedTagOption[],
       showGLCode?: boolean,
   ): TagOption[] {
       return tags.map((tag) => {
           const cleanedName = getCleanedTagName(tag.name);
           const glCode = tag['GL Code'];
           const displayName = showGLCode && glCode ? `${cleanedName} (${glCode})` : cleanedName;
           return {
               text: displayName,
               keyForList: tag.name,
               searchText: tag.name,
               tooltipText: displayName,
               isDisabled: !tag.enabled || tag.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
               isSelected: selectedOptions?.some((selectedTag) => selectedTag.name === tag.name),
               pendingAction: tag.pendingAction,
           };
       });
   }

   b. Fix the tokenizedSearch extractors in getTagListSections (lines 117–128): the search branch narrows the tag list before getTagsOptions is called, so GL code searchability must be added to the extractor callback, not to searchText. When showTagGLCodeInPicker is true, include the GL code as a second candidate in each extractor:

   // Inside getTagListSections, search branch (lines ~117-128)
   if (searchValue) {
       const extractor = (tag: SelectedTagOption | PolicyTag) =>
           showGLCode && (tag as PolicyTag)['GL Code']
               ? [getCleanedTagName(tag.name), (tag as PolicyTag)['GL Code'] ?? '']
               : [getCleanedTagName(tag.name)];
   
       const tagsForSearch = [
           ...tokenizedSearch(selectedTagsWithDisabledState, searchValue, extractor),
           ...tokenizedSearch(enabledTagsWithoutSelectedOptions, searchValue, extractor),
       ];
   
       tagSections.push({
           title: '',
           sectionIndex: 1,
           data: getTagsOptions(tagsForSearch, selectedOptions, showGLCode),
       });
   
       return tagSections;
   }

   c. Selected and recently-used sections: selectedTagsWithDisabledState is built by spreading selectedOptions entries (lines 99–104 in getTagListSections), and filteredRecentlyUsedTags is built as {name, enabled} objects (lines 138–143). Both shapes lack 'GL Code'. To display GL codes in these sections, look up the full PolicyTag from sortedTags by name before constructing selectedTagsWithDisabledState, so the GL code travels through:

   // Replace the selectedTagsWithDisabledState loop
   for (const tag of selectedOptions) {
       const fullTag = sortedTags.find((t) => t.name === tag.name);
       const glCode = fullTag?.['GL Code'];
       if (enabledTagsNames.has(tag.name)) {
           selectedTagsWithDisabledState.push({...tag, enabled: true, ...(glCode ? {'GL Code': glCode} : {})});
           continue;
       }
       selectedTagsWithDisabledState.push({...tag, enabled: false, ...(glCode ? {'GL Code': glCode} : {})});
   }

   For recently-used tags, enrich the .map similarly:

   .map((tag) => {
       const fullTag = sortedTags.find((t) => t.name === tag);
       return {name: tag, enabled: true, ...(fullTag?.['GL Code'] ? {'GL Code': fullTag['GL Code']} : {})};
   });

   Then pass showGLCode to every getTagsOptions call site within getTagListSections.

   getTagListSections must accept showTagGLCodeInPicker (defaulting to false) from its caller, which reads it from the resolved PolicyTagList in src/components/TagPicker/index.tsx.

5. Mirror the same for Categories — The issue is explicitly a copy of [Due for payment 2026-07-30] [$250] Show GL code when selecting a category #93155; apply the analogous flag + CategoryOptionListUtils.ts change + TagsSettingsPage-equivalent toggle in src/pages/workspace/categories/CategorySettingsPage.tsx / workspace categories settings, so both features stay in lockstep.

6. Consumers to leave untouched — WorkspaceTagsTable* and WorkspaceViewTagsTable already render GL code in a dedicated column; do not re-format their text. TransactionItemRow/TagCell and Search results also stay unchanged (the issue explicitly excludes Spend tables).

What alternative solutions did you explore? (Optional)

[lorretheboy]

Note: This isn't a duplicate — The flagged proposal's root cause is that tags have no GL code data at all ("does not include a glCode property … will require backend and Onyx schema updates"); ours is that the code already exists on PolicyTag as 'GL Code' (src/types/onyx/PolicyTag.ts:14-16) and is merely discarded by the Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction'> narrowing in getTagsOptions — so no schema or backend work is needed. The fixes also differ materially: the flagged one adds policy.tagSettings.showGLCode plus a getFormattedTagName helper applied in Search filter components built off useAdvancedSearchFilters/WorkspaceSelector's tokenizedSearch, and relies on text being searched automatically. Ours changes TagsOptionsListUtils (getTagsOptions + both tokenizedSearch matchers in getTagListSections) feeding TagPicker, adds a top-level Policy boolean with an optimistic action modeled on setPolicyRequiresTag, and specifically keeps searchText/keyForList as the raw tag name because TagPicker matches selection via policyTag.searchText === selectedTag — the opposite of the flagged proposal's decorate-text-to-get-search approach.

Proposal

What is the root cause of that problem?

This is a new feature — nothing today can render a tag's GL code beside its name in the tag picker. Two separate gaps cause that:

1. The GL code is dropped before the option is ever built. Each tag already stores its code in Onyx:

App/src/types/onyx/PolicyTag.ts

Lines 14 to 16 in acedb02

	/** "General Ledger code" that corresponds to this tag in an accounting system. Similar to an ID. */
	// eslint-disable-next-line @typescript-eslint/naming-convention
	'GL Code'?: string;

but getTagsOptions narrows its parameter to Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction'>, so the 'GL Code' field is discarded at the type boundary and can never reach text or tooltipText:

App/src/libs/TagsOptionsListUtils.ts

Lines 52 to 66 in acedb02

	function getTagsOptions(tags: Array<Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction'>>, selectedOptions?: SelectedTagOption[]): TagOption[] {
	return tags.map((tag) => {
	// This is to remove unnecessary escaping backslash in tag name sent from backend.
	const cleanedName = getCleanedTagName(tag.name);
	return {
	text: cleanedName,
	keyForList: tag.name,
	searchText: tag.name,
	tooltipText: cleanedName,
	isDisabled: !tag.enabled || tag.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	isSelected: selectedOptions?.some((selectedTag) => selectedTag.name === tag.name),
	pendingAction: tag.pendingAction,
	};
	});
	}

The same omission makes the code unsearchable — both tokenizedSearch calls in getTagListSections match only against the cleaned tag name:

App/src/libs/TagsOptionsListUtils.ts

Lines 118 to 122 in acedb02

	if (searchValue) {
	const tagsForSearch = [
	...tokenizedSearch(selectedTagsWithDisabledState, searchValue, (tag) => [getCleanedTagName(tag.name)]),
	...tokenizedSearch(enabledTagsWithoutSelectedOptions, searchValue, (tag) => [getCleanedTagName(tag.name)]),
	];

2. There is no display setting to toggle. The only GL-code flag on Policy is glCodes, which is the paid-feature entitlement set during workspace upgrade, not a display preference:

App/src/types/onyx/Policy.ts

Lines 2755 to 2759 in acedb02

	/** Max amount for an expense with no itemized receipt violation */
	maxExpenseAmountNoItemizedReceipt?: number;
	/** Whether GL codes are enabled */
	glCodes?: boolean;

and the Tags settings page renders only the requiresTag and trackBillable switches:

App/src/pages/workspace/tags/WorkspaceTagsSettingsPage.tsx

Lines 93 to 134 in acedb02

	{!isRulesRevampEnabled && (
	<>
	<OfflineWithFeedback
	errors={policy?.errorFields?.requiresTag}
	pendingAction={policy?.pendingFields?.requiresTag}
	errorRowStyles={styles.mh5}
	>
	<View style={[styles.flexRow, styles.mh5, styles.mv4, styles.alignItemsCenter, styles.justifyContentBetween]}>
	<Text
	style={[styles.textNormal, styles.flex1, styles.mr2]}
	accessible={false}
	aria-hidden
	>
	{translate('workspace.tags.requiresTag')}
	</Text>
	<Switch
	isOn={policy?.requiresTag ?? false}
	accessibilityLabel={translate('workspace.tags.requiresTag')}
	onToggle={updateWorkspaceRequiresTag}
	disabled={!policy?.areTagsEnabled || !hasEnabledOptions}
	/>
	</View>
	</OfflineWithFeedback>
	<OfflineWithFeedback pendingAction={getBillableExpensesPendingAction(policy)}>
	<View style={[styles.flexRow, styles.mh5, styles.mv4, styles.alignItemsCenter, styles.justifyContentBetween]}>
	<Text
	style={[styles.textNormal, styles.flex1, styles.mr2]}
	accessible={false}
	aria-hidden
	>
	{translate('workspace.tags.trackBillable')}
	</Text>
	<Switch
	isOn={!(policy?.disabledFields?.defaultBillable ?? false)}
	accessibilityLabel={translate('workspace.tags.trackBillable')}
	onToggle={() => toggleBillableExpenses(policy)}
	disabled={!policy?.areTagsEnabled}
	/>
	</View>
	</OfflineWithFeedback>
	</>
	)}

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

Fix it in TagsOptionsListUtils, which is the single convergence point — getTagListSections has exactly one consumer, TagPicker, so every tag-selection surface benefits:

App/src/components/TagPicker/index.tsx

Lines 142 to 149 in acedb02

	const tagSections = getTagListSections({
	searchValue,
	selectedOptions,
	tags: enabledTags,
	recentlyUsedTags: policyRecentlyUsedTagsList,
	localeCompare,
	translate,
	});

1. Add the policy display setting. A new optional boolean on Policy (e.g. shouldShowTagGLCode), toggled by a new action in src/libs/actions/Policy/Tag.ts modeled directly on the existing setPolicyRequiresTag (optimistic value + pendingFields + errors), and surfaced as a third Switch on the Tags settings page alongside requiresTag/trackBillable, disabled when !policy?.areTagsEnabled. It should match whatever field name the category GL code work settles on so the two stay symmetrical.

2. Widen getTagsOptions to carry the code. Include 'GL Code' in the Pick, accept the flag, and append the code to the display text and tooltip only:

const glCode = tag['GL Code'];
const displayName = shouldShowGLCode && glCode ? `${cleanedName} (${glCode})` : cleanedName;
// text: displayName, tooltipText: displayName — keyForList/searchText stay tag.name

searchText must keep holding the raw tag name: TagPicker resolves the currently-selected row with policyTag.searchText === selectedTag, so decorating it would silently break selection highlighting.

3. Make the code searchable. Thread the flag into getTagListSections and add the code as an extra match token in both tokenizedSearch matchers, e.g. (tag) => [getCleanedTagName(tag.name), tag['GL Code']].filter(Boolean). This keeps name matching untouched and makes SP4100 find Sunshine Project.

A small shared helper next to the existing getTagGLCode in PolicyUtils would be a good home for the Name (Code) formatting so other surfaces can reuse it later. Note getTagGLCode resolves codes for a whole transaction tag string, so it isn't a drop-in here — the picker needs the per-tag code.

App/src/libs/PolicyUtils.ts

Lines 1204 to 1209 in acedb02

	/**
	* Resolves a transaction's tag to the GL codes configured on the matching policy tags.
	* Multi-level tags resolve each level against the tag list with the same order weight,
	* and the non-empty GL codes are joined into a single comma-separated string.
	*/
	function getTagGLCode(policyTagLists: OnyxEntry<PolicyTagLists>, transactionTag: string | undefined): string {

Per the issue, the Spend tables are intentionally left alone.

What alternative solutions did you explore? (Optional)

Formatting the name inside TagPicker instead of in the options builder. Rejected: the search filtering lives in getTagListSections, so the code would still be unsearchable, and any future consumer of the builder would miss the codes.

[wildan-m]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 12:06:55 UTC.

Proposal

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

Admins can assign a GL code to a tag, but that code is never surfaced when a member actually picks a tag on an expense, and it cannot be searched. We want an opt-in workspace setting that appends the tag's GL code in parentheses at the end of the tag name in the tag selector (e.g. Sunshine Project (SP4100)), and makes the code searchable in that list — mirroring what was done for category GL codes in #93155.

What is the root cause of that problem?

This is a new feature, so the root cause is the absence of the capability rather than a defect. Concretely, three things are missing today.

First, the tag GL code is deliberately dropped when the selector options are built. getTagsOptions() accepts only name, enabled and pendingAction off each PolicyTag, and it builds the visible text from the tag name alone — the 'GL Code' property that exists on the tag never reaches the option object:

App/src/libs/TagsOptionsListUtils.ts

Lines 52 to 66 in 220fb40

	function getTagsOptions(tags: Array<Pick<PolicyTag, 'name' | 'enabled' | 'pendingAction'>>, selectedOptions?: SelectedTagOption[]): TagOption[] {
	return tags.map((tag) => {
	// This is to remove unnecessary escaping backslash in tag name sent from backend.
	const cleanedName = getCleanedTagName(tag.name);
	return {
	text: cleanedName,
	keyForList: tag.name,
	searchText: tag.name,
	tooltipText: cleanedName,
	isDisabled: !tag.enabled || tag.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
	isSelected: selectedOptions?.some((selectedTag) => selectedTag.name === tag.name),
	pendingAction: tag.pendingAction,
	};
	});
	}

Second, the search path in getTagListSections() tokenizes strictly on getCleanedTagName(tag.name), so typing a GL code matches nothing:

App/src/libs/TagsOptionsListUtils.ts

Lines 118 to 132 in 220fb40

	if (searchValue) {
	const tagsForSearch = [
	...tokenizedSearch(selectedTagsWithDisabledState, searchValue, (tag) => [getCleanedTagName(tag.name)]),
	...tokenizedSearch(enabledTagsWithoutSelectedOptions, searchValue, (tag) => [getCleanedTagName(tag.name)]),
	];
	tagSections.push({
	// "Search" section
	title: '',
	sectionIndex: 1,
	data: getTagsOptions(tagsForSearch, selectedOptions),
	});
	return tagSections;
	}

The GL code itself is present on the tag record, so no new data is needed — it is simply not read here:

App/src/types/onyx/PolicyTag.ts

Line 16 in 220fb40

'GL Code'?: string;

Third, there is no policy-level switch to turn the behavior on. The workspace tag settings page renders toggles only for requiresTag and billable tracking; nothing controls GL code display:

App/src/pages/workspace/tags/WorkspaceTagsSettingsPage.tsx

Lines 96 to 115 in 220fb40

	errors={policy?.errorFields?.requiresTag}
	pendingAction={policy?.pendingFields?.requiresTag}
	errorRowStyles={styles.mh5}
	>
	<View style={[styles.flexRow, styles.mh5, styles.mv4, styles.alignItemsCenter, styles.justifyContentBetween]}>
	<Text
	style={[styles.textNormal, styles.flex1, styles.mr2]}
	accessible={false}
	aria-hidden
	>
	{translate('workspace.tags.requiresTag')}
	</Text>
	<Switch
	isOn={policy?.requiresTag ?? false}
	accessibilityLabel={translate('workspace.tags.requiresTag')}
	onToggle={updateWorkspaceRequiresTag}
	disabled={!policy?.areTagsEnabled || !hasEnabledOptions}
	/>
	</View>
	</OfflineWithFeedback>

The only place a tag GL code is shown today is the admin-facing workspace tags table, gated on a locally-derived boolean rather than a persisted setting, and it does not affect the selector at all:

App/src/pages/workspace/tags/WorkspaceTagsPage.tsx

Line 259 in 220fb40

const shouldShowGLCodeColumn = isControlPolicyWithWideLayout && !isMultiLevelTags && Object.values(policyTagLists?.at(0)?.tags ?? {}).some((tag) => !!tag['GL Code']);

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

Add a persisted policy setting, then have the tag selector honor it.

1. Policy setting. Add an optional boolean to the policy type — placed next to the existing tag-related flags such as requiresTag — that records whether tag GL codes should be shown when selecting a tag. It should default to off so existing workspaces are unaffected.

App/src/types/onyx/Policy.ts

Lines 2587 to 2588 in 220fb40

	/** Whether new transactions need to be tagged */
	requiresTag?: boolean;

2. Toggle in Tags Settings. Add a Switch row to the workspace tags settings page, following the exact shape of the existing requiresTag row: wrapped in OfflineWithFeedback bound to the new field's errorFields/pendingFields, with a new translated label and description added to every language file via the standard translation script. It should be available for the same policy tier the mockups target (Control), and disabled when tags are not enabled — same condition the neighboring toggle uses.

3. Write action. Add a setter in the tag policy actions file alongside setPolicyRequiresTag, applying the same optimistic/failure/success onyxData pattern and pending-field handling, and calling the corresponding API command so the choice persists.

App/src/libs/actions/Policy/Tag.ts

Line 1023 in 220fb40

function setPolicyRequiresTag(policyData: PolicyData, requiresTag: boolean) {

4. Display the code in the selector. Widen the tag parameter type in getTagsOptions() to also pick 'GL Code', and thread a flag (derived from the new policy setting by the caller) into it. When the flag is on and the tag has a non-empty GL code, the displayed text and tooltipText become the cleaned tag name followed by the code in parentheses; when it is off or the code is empty, the output is byte-for-byte what it is today. keyForList must keep using the raw tag.name — it is the selection identity used to write the tag back onto the transaction, so decorating it would break selection and the saved value.

5. Make the code searchable. Add the GL code to the key extractor passed to tokenizedSearch() in the search branch of getTagListSections(), so a query matches either the name or the code. Since tokenizedSearch already accepts an array of searchable strings per item, this is an extra entry rather than new search machinery.

Note that searchText must keep carrying the raw tag.name and must not be decorated with the code. Despite its name it is not what the tag search reads — the search runs on the raw tags before the options are built — and the picker uses it as a selection identity, matching it against the transaction's saved tag to decide which row is initially focused. Appending the code there would silently stop the currently selected tag from being focused when the picker opens.

App/src/components/TagPicker/index.tsx

Line 157 in 220fb40

const selectedOptionKey = sections.at(0)?.data?.find((policyTag) => policyTag.searchText === selectedTag)?.keyForList;

6. Thread the flag from the callers. getTagListSections() is consumed by the tag picker, which already has the policy in scope; it passes the setting down so the picker and the search share one source of truth.

App/src/components/TagPicker/index.tsx

Line 142 in 220fb40

const tagSections = getTagListSections({

7. Keep the "Recent" section consistent. The recently used tags branch rebuilds its entries from the recently used names as {name, enabled}, which drops the GL code, so those rows would render undecorated while every other section shows the code. The tag's GL code should be carried over from the matching policy tag when that list is built.

Per the issue, the Spend tables are intentionally out of scope — a dedicated tag code column is being handled separately — so no changes there.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/96390-tag-gl-code-in-tag-selector?expand=1

What alternative solutions did you explore? (Optional)

I considered always appending the GL code whenever a tag has one, with no setting at all. That is far less code, but it contradicts the issue's explicit ask for an admin toggle and would silently change the tag name every workspace member sees on every expense, so I rejected it.

I also considered reusing the existing derived shouldShowGLCodeColumn boolean from the workspace tags page instead of adding a policy field. It is computed per-render from whether any tag happens to have a GL code, so it is presence-driven rather than a stored admin choice, is scoped to the admin table, and cannot be turned off — it does not satisfy the requirement.