[$250] Global Reimbursement incorrectly appears disabled in New Expensify for fully set-up US Corpay bank accounts

[melvin-bot]

Action Performed:

1. Have a US business bank account that is fully set up / enabled for Global Reimbursement (i.e. set up outside of the NewDot API onboarding flow).
2. Open Account > Wallet in New Expensify.
3. Tap the bank account row.
4. Review the Global Reimbursement status.

Expected Result:

New Expensify recognizes the account's existing Global Reimbursement configuration and reflects it as enabled, matching Expensify Classic.

Actual Result:

Global Reimbursement appears as not enabled in New Expensify (the "Enable global reimbursements" button is shown), even though the account is enabled for Global Reimbursement in Classic.

Root cause / proposed direction:

The button is gated here:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in fd467ee

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

The condition depends on additionalData.corpay.achAuthorizationForm. That field is only populated when the bank account was added through the NewDot API onboarding flow, so accounts that were fully set up another way don't have it — causing NewDot to treat an already-enabled account as not enabled.

We want to update the check to look at additionalData.verifications.corpay instead of additionalData.corpay.achAuthorizationForm, consistent with how Classic determines Corpay status.

Platforms:

New Expensify Website

Version Number:

v9.4.33-8

Related:

• [Due for payment 2025-10-09] We show option to enable global reimbursements for account that already has it enabled #70811 (related, closed) — inverse case where the enable button showed for non-US accounts.

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @ShridharGoel

[MelvinBot]

Proposal

What is the root cause of that problem?

Confirmed. The "Enable global reimbursements" button is gated on the presence of the signed ACH authorization file, not on whether the account is actually enabled for global reimbursement:

src/pages/settings/Wallet/WalletPage/index.tsx:427-431

const shouldShowEnableGlobalReimbursementsButton =
    additionalData?.currency === CONST.CURRENCY.USD &&
    type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
    !additionalData?.corpay?.achAuthorizationForm &&   // ← unreliable signal
    state === CONST.BANK_ACCOUNT.STATE.OPEN;

additionalData.corpay.achAuthorizationForm is the Docusign/ACH form uploaded during the NewDot Corpay onboarding flow — it's a request parameter of ENABLE_GLOBAL_REIMBURSEMENTS_FOR_USD_BANK_ACCOUNT / FINISH_CORPAY_BANK_ACCOUNT_ONBOARDING. A US business account that was fully enabled for global reimbursement in Classic never produced that file, so the field is empty and NewDot shows the "enable" button as if the account were not set up.

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

⚠️ Important caveat on the proposed fix: the issue suggests switching to additionalData.verifications.corpay, but that field does not exist anywhere in the App codebase. The only verifications field in App is on ReimbursementAccount.achData and holds KYB externalApiResponses, not Corpay status (src/types/onyx/ReimbursementAccount.ts:230-249). Under additionalData.corpay the only field is achAuthorizationForm (src/types/onyx/BankAccount.ts:37-41).

So this cannot be a pure client-side field swap. The App only knows what the backend puts into accountData.additionalData, and no "Corpay already enabled" status is currently surfaced there. The proper fix is:

1. Backend (outside App — internal work required): have the payments-page response populate a reliable "global reimbursement enabled" signal on the bank account's additionalData (mirroring how Classic reads Corpay status). achAuthorizationForm is not that signal.
2. App: once that field is exposed and added to BankAccountAdditionalData, change the gate at index.tsx:429 to key off the real enabled-status field instead of !achAuthorizationForm.

Because step 1 requires a change in a repo other than App, this needs an internal engineer to define/expose the correct status field before the frontend gate can be fixed reliably. Filing the App-side change alone would just move the guess from one field to another that also isn't guaranteed to reflect Classic accounts.

What alternative solutions did you explore? (Optional)

Investigation details & things ruled out

• Client never writes the field optimistically: neither enableGlobalReimbursementsForUSDBankAccount nor finishCorpayBankAccountOnboarding writes corpay.achAuthorizationForm into the bank account list (src/libs/actions/BankAccounts.ts) — it's populated server-side, so its presence depends entirely on backend mapping.
• Alternative explanation considered: achAuthorizationForm could be undefined transiently (data not yet loaded) rather than because the account came from Classic. That would produce the same false positive, which further argues the gate shouldn't rely on this field at all.
• Confidence: Medium. The frontend mechanism is verified with code evidence. What's not verifiable from the public App checkout is exactly what the backend returns for a real Classic-enabled US Corpay account, and which field should replace achAuthorizationForm. Confirming that requires internal backend investigation (and ideally a real affected bankAccountID).
• Related: the issue links [Due for payment 2025-10-09] We show option to enable global reimbursements for account that already has it enabled #70811 (closed) — the inverse case where the enable button incorrectly showed for non-US accounts. Same button, opposite mis-gating, worth reviewing for consistency.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96385) to create a draft PR. Note the App-only change is blocked on the backend exposing a real enabled-status field (see above).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 11:36:57 UTC.

Proposal

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

For a US business bank account that is fully set up and enabled for Global Reimbursement outside the NewDot in-app onboarding flow (e.g. enabled in Expensify Classic), New Expensify still shows the "Enable global reimbursements" button on the bank account detail view, presenting an already-enabled account as if it were not enabled.

What is the root cause of that problem?

The visibility of the button is gated on the absence of additionalData.corpay.achAuthorizationForm:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in 220fb40

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

const shouldShowEnableGlobalReimbursementsButton =
    paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
    paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
    !paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
    paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

achAuthorizationForm is the ACH authorization powerform file array, and it is only written onto the bank account when the account completes the NewDot ENABLE_GLOBAL_REIMBURSEMENTS_FOR_USD_BANK_ACCOUNT flow. It is declared solely as a byproduct of that flow:

App/src/types/onyx/BankAccount.ts

Lines 38 to 41 in 220fb40

	corpay?: {
	/** Powerform files */
	achAuthorizationForm?: FileObject[];
	};

So achAuthorizationForm is a signal for "was Global Reimbursement enabled through this specific NewDot flow", not for "is this account enabled for Global Reimbursement". An account enabled through any other surface (Classic, or set up server-side) never receives achAuthorizationForm, so !...achAuthorizationForm stays true and the button is shown even though the account is already enabled.

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

Gate the button on the actual Corpay setup signal that the backend returns and that Classic reads — additionalData.verifications.corpay — instead of the NewDot-flow-only achAuthorizationForm. verifications.corpay is populated regardless of which surface enabled the account, so it correctly reflects the enabled state in every case.

In src/pages/settings/Wallet/WalletPage/index.tsx:

const shouldShowEnableGlobalReimbursementsButton =
    paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
    paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
    !paymentMethod.selectedPaymentMethod?.additionalData?.verifications?.corpay &&
    paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

verifications is not yet declared on the bank-account additionalData type, so I'd add it to BankAccountAdditionalData in src/types/onyx/BankAccount.ts alongside the existing corpay field:

/** Statuses of additional verification checks returned by the backend */
verifications?: {
    /** Present once the account is set up with Corpay for Global Reimbursement */
    corpay?: Record<string, unknown>;
};

This makes NewDot's enabled/not-enabled determination match Classic and removes the dependency on the account having gone through the NewDot flow.

What alternative solutions did you explore? (Optional)

Keep achAuthorizationForm but OR it with verifications.corpay (!(achAuthorizationForm || verifications?.corpay)). This preserves both signals, but since verifications.corpay is the authoritative "is enabled" flag for every path (including the NewDot flow), the achAuthorizationForm check becomes redundant, so I'd prefer the single, Classic-consistent condition above.

[abbasifaizan70]

Proposal

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

For a US business bank account that is already fully set up and enabled for Global Reimbursement in Expensify Classic (set up outside of the NewDot API onboarding flow), New Expensify still shows the "Enable global reimbursements" button on Account > Wallet > bank account details, instead of recognizing that Global Reimbursement is already enabled.

What is the root cause of that problem?

The button's visibility is controlled by shouldShowEnableGlobalReimbursementsButton, which treats the account as "not enabled for Global Reimbursement" whenever additionalData.corpay.achAuthorizationForm is missing:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in c0a4080

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

achAuthorizationForm is only populated when the account went through the NewDot API onboarding flow (it stores the uploaded ACH powerform files for that flow). Accounts that were fully set up and enabled for Global Reimbursement through another path (e.g. directly in Classic) never populate this field, even though they're already Corpay-verified. So the condition incorrectly evaluates to "show the enable button" for accounts that are already enabled, because it's checking the wrong signal (onboarding-form-submission) instead of the actual enablement/verification status. Classic instead keys off the account's Corpay verification status, which isn't reflected anywhere in this check.

The BankAccountAdditionalData type also has no field for Corpay verification status today, only the onboarding form data:

App/src/types/onyx/BankAccount.ts

Lines 37 to 41 in c0a4080

	/** Corpay fields */
	corpay?: {
	/** Powerform files */
	achAuthorizationForm?: FileObject[];
	};

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

Add the Corpay verification flag to BankAccountAdditionalData so it can be read from the bank account's additionalData:

App/src/types/onyx/BankAccount.ts

Lines 37 to 41 in c0a4080

	/** Corpay fields */
	corpay?: {
	/** Powerform files */
	achAuthorizationForm?: FileObject[];
	};

    /** Corpay fields */
    corpay?: {
        /** Powerform files */
        achAuthorizationForm?: FileObject[];
    };

    /** Whether the bank account is verified/enabled for Corpay Global Reimbursement */
    verifications?: {
        /** Corpay Global Reimbursement enablement status */
        corpay?: boolean;
    };

Then update the gating condition to check the actual enablement status instead of the presence of the onboarding form:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in c0a4080

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

    const shouldShowEnableGlobalReimbursementsButton =
        paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
        paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
        !paymentMethod.selectedPaymentMethod?.additionalData?.verifications?.corpay &&
        paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

This way, any US business bank account that is already Corpay-verified/enabled for Global Reimbursement — regardless of which flow enabled it — will correctly hide the "Enable global reimbursements" button, matching Expensify Classic's behavior.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The "Enable global reimbursements" button is gated on the absence of additionalData.corpay.achAuthorizationForm:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in fd467ee

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

So the flow uses "this account has no ACH authorization form" as a proxy for "Global Reimbursement is not enabled yet". That proxy is wrong.

achAuthorizationForm is written to the bank account only at the end of the NewDot enable flow — EnableGlobalReimbursementsSignPage uploads the powerform and submits it through enableGlobalReimbursementsForUSDBankAccount:

App/src/pages/settings/Wallet/EnableGlobalReimbursements/EnableGlobalReimbursementsSignPage.tsx

Lines 34 to 50 in fd467ee

	enableGlobalReimbursementsForUSDBankAccount({
	inputs: JSON.stringify({
	provideTruthfulInformation: enableGlobalReimbursementsDraft?.[INPUT_IDS.PROVIDE_TRUTHFUL_INFORMATION],
	agreeToTermsAndConditions: enableGlobalReimbursementsDraft?.[INPUT_IDS.AGREE_TO_TERMS_AND_CONDITIONS],
	consentToPrivacyNotice: enableGlobalReimbursementsDraft?.[INPUT_IDS.CONSENT_TO_PRIVACY_NOTICE],
	authorizedToBindClientToAgreement: enableGlobalReimbursementsDraft?.[INPUT_IDS.AUTHORIZED_TO_BIND_CLIENT_TO_AGREEMENT],
	natureOfBusiness: enableGlobalReimbursementsDraft?.[INPUT_IDS.BUSINESS_CATEGORY],
	applicantTypeId: enableGlobalReimbursementsDraft?.[INPUT_IDS.APPLICANT_TYPE_ID],
	tradeVolume: enableGlobalReimbursementsDraft?.[INPUT_IDS.TRADE_VOLUME],
	annualVolume: enableGlobalReimbursementsDraft?.[INPUT_IDS.ANNUAL_VOLUME],
	businessRegistrationIncorporationNumber: enableGlobalReimbursementsDraft?.[INPUT_IDS.BUSINESS_REGISTRATION_INCORPORATION_NUMBER],
	fundSourceCountries: country,
	fundDestinationCountries: country,
	currencyNeeded: currency,
	purposeOfTransactionId: CONST.NON_USD_BANK_ACCOUNT.PURPOSE_OF_TRANSACTION_ID,
	}),
	achAuthorizationForm: enableGlobalReimbursementsDraft?.[INPUT_IDS.ACH_AUTHORIZATION_FORM].at(0),

The field itself lives under corpay on the bank account's additionalData, and its only source is this NewDot powerform:

App/src/types/onyx/BankAccount.ts

Lines 37 to 41 in fd467ee

	/** Corpay fields */
	corpay?: {
	/** Powerform files */
	achAuthorizationForm?: FileObject[];
	};

An account that was fully set up for Global Reimbursement outside the NewDot API onboarding flow (e.g. in Expensify Classic) therefore never has achAuthorizationForm populated. !additionalData?.corpay?.achAuthorizationForm evaluates to true, all the other guards (currency === USD, type === BUSINESS, state === OPEN) pass, and NewDot shows the enable button for an account that is already enabled.

This gate was introduced in #67326 ("do not show GR option on partially setup accounts"). The intent there was to hide the button for accounts that had not finished the NewDot onboarding — but it conflates "has not finished the NewDot powerform step" with "Global Reimbursement is not enabled". The powerform's presence only proves the NewDot path completed; it says nothing about accounts enabled through any other path, which is exactly the case that regresses here.

Classic determines Corpay status from the verification state (additionalData.verifications.corpay), which reflects the actual enablement regardless of how the account was set up. That value is currently not even part of the BankAccountAdditionalData type, so the front end has no way to read the real status today.

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

1. BankAccountAdditionalData — add the verifications.corpay status that the backend already returns, so we can read the real Corpay state. In src/types/onyx/BankAccount.ts:

/** Corpay fields */
corpay?: {
    /** Powerform files */
    achAuthorizationForm?: FileObject[];
};

/** Corpay verification statuses, mirroring how Classic determines Corpay status */
verifications?: {
    /** Corpay enablement/verification status */
    corpay?: unknown;
};

2. shouldShowEnableGlobalReimbursementsButton — gate on the verification status instead of the powerform file. In src/pages/settings/Wallet/WalletPage/index.tsx:

const shouldShowEnableGlobalReimbursementsButton =
    paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
    paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
    !paymentMethod.selectedPaymentMethod?.additionalData?.verifications?.corpay &&
    paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

Why this is safe:

• The currency === USD, type === BUSINESS, and state === OPEN guards are untouched, so the button's scope is unchanged for every other account.
• verifications.corpay reflects the true Corpay status for any setup path (NewDot onboarding or Classic), so it fixes the false negative for Classic-enabled accounts while still hiding the button for genuinely not-enabled accounts — which is what Partially setup account #67326 was trying to achieve.
• It also keeps the partially-setup case hidden correctly: a partially-setup account has no completed Corpay verification, so verifications.corpay is falsy and the button shows, exactly as intended before.

We should confirm the exact shape/truthiness contract of verifications.corpay against what the API returns for these accounts and type it precisely (rather than unknown) once confirmed, but the gating change is the same regardless of the concrete shape.

Result: Global Reimbursement status in NewDot is driven by the same signal Classic uses, so a fully set-up US Corpay account correctly shows as enabled and the redundant enable button no longer appears.

What alternative solutions did you explore? (Optional)

• Keep the achAuthorizationForm check and additionally OR-in the verification status: unnecessary complexity — the powerform presence is a strict subset of "enabled" and adds no signal that verifications.corpay doesn't already carry, while keeping the misleading proxy in the condition.
• Have the backend backfill achAuthorizationForm for Classic-enabled accounts: the file genuinely does not exist for those accounts, so this would fabricate data purely to satisfy a front-end proxy; the correct fix is to read the status field that already exists.

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The Wallet bank-account menu decides whether to show “Enable Global Reimbursements” from shouldShowEnableGlobalReimbursementsButton, and that condition treats a USD business account as not enabled whenever additionalData.corpay.achAuthorizationForm is missing (https://github.com/Expensify/App/blob/main/src/pages/settings/Wallet/WalletPage/index.tsx#L427-L431). That field is only the Docusign file submitted by the NewDot enable-global-reimbursements flow (https://github.com/Expensify/App/blob/main/src/pages/settings/Wallet/EnableGlobalReimbursements/EnableGlobalReimbursementsSignPage.tsx#L33-L51), so a bank account that was already enabled through Classic can have the real Corpay verification status but no NewDot achAuthorizationForm. Since the selected payment method reads from accountData.additionalData (https://github.com/Expensify/App/blob/main/src/types/onyx/AccountData.ts#L45-L46), the Wallet UI is checking the wrong source of truth for enabled Corpay status.

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

Update shouldShowEnableGlobalReimbursementsButton in WalletPage to hide the button when the selected USD business bank account already has additionalData.verifications.corpay, instead of using the presence of additionalData.corpay.achAuthorizationForm as the enabled-state check (https://github.com/Expensify/App/blob/main/src/pages/settings/Wallet/WalletPage/index.tsx#L427-L431). The rest of the existing gate should stay the same: only USD, business, open bank accounts that are not Corpay-verified should see the enable action.

Because BankAccountAdditionalData currently only types the corpay.achAuthorizationForm powerform data (https://github.com/Expensify/App/blob/main/src/types/onyx/BankAccount.ts#L37-L41), add the backend-provided verifications.corpay shape to that type and use it in the Wallet condition. This keeps the frontend aligned with the actual account status returned in additionalData, and it still allows accounts enabled through the NewDot flow to stop showing the button once their Corpay verification is reflected in the bank account data.

What alternative solutions did you explore? (Optional)

I considered keeping achAuthorizationForm as a fallback, but that preserves the current bug for fully set-up accounts that were enabled outside the NewDot flow. The button visibility should be based on the account’s Corpay verification status, not on which onboarding path produced the account.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 11:36:08 UTC.

Proposal

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

A US business bank account that is already fully enabled for Global Reimbursement (set up outside the NewDot API onboarding flow, e.g. via Classic) still shows the "Enable Global Reimbursements" option in Account > Wallet. New Expensify treats the account as not enabled, even though Classic correctly shows it as enabled.

What is the root cause of that problem?

1. The button is gated in WalletPage, and the "not yet enabled" term is !additionalData?.corpay?.achAuthorizationForm:

   App/src/pages/settings/Wallet/WalletPage/index.tsx

   Lines 427 to 431 in 220fb40

   	const shouldShowEnableGlobalReimbursementsButton =
   	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
   	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
   	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
   	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

2. additionalData.corpay.achAuthorizationForm is a NewDot flow artifact, not a status flag. It only exists when the ACH authorization powerform was uploaded through one of NewDot's own flows: the wallet enable flow (

   App/src/pages/settings/Wallet/EnableGlobalReimbursements/EnableGlobalReimbursementsSignPage.tsx

   Line 50 in 220fb40

   achAuthorizationForm: enableGlobalReimbursementsDraft?.[INPUT_IDS.ACH_AUTHORIZATION_FORM].at(0),

   → enableGlobalReimbursementsForUSDBankAccount,

   App/src/libs/actions/BankAccounts.ts

   Line 1179 in 220fb40

   function enableGlobalReimbursementsForUSDBankAccount(parameters: EnableGlobalReimbursementsForUSDBankAccountParams) {

   ) or the non-USD Docusign onboarding step (

   App/src/pages/ReimbursementAccount/NonUSD/Docusign/index.tsx

   Line 39 in 220fb40

   achAuthorizationForm: finalStepValues.achAuthorizationForm.at(0),

   ). No code path ever backfills it for an account enabled elsewhere.

3. So the structural cause is: the gate overloads "a powerform file is on record from a NewDot flow" as "the account is enabled for Global Reimbursement". Classic instead reads the actual status marker the backend stores on the account, additionalData.verifications.corpay. For the repro account, substituting into each term of the gate: currency === USD ✓, type === BUSINESS ✓, achAuthorizationForm is undefined so !undefined → true ✓, state === OPEN ✓ — every term passes and the button renders.

4. Affected paths: shouldShowEnableGlobalReimbursementsButton is computed in exactly one place and feeds the same threeDotsMenuItems array used by both the wide-layout three-dot menu and the narrow-layout bottom-mounted menu (

   App/src/pages/settings/Wallet/WalletPage/index.tsx

   Lines 540 to 560 in 220fb40

   	...(shouldShowEnableGlobalReimbursementsButton
   	? [
   	{
   	text: translate('common.enableGlobalReimbursements'),
   	icon: icons.Globe,
   	onSelected: () => {
   	if (isAccountLocked) {
   	closeModal(() => showLockedAccountModal());
   	return;
   	}
   	closeModal(() =>
   	Navigation.navigate(
   	ROUTES.SETTINGS_WALLET_ENABLE_GLOBAL_REIMBURSEMENTS_BUSINESS.getRoute(
   	paymentMethod.selectedPaymentMethod.bankAccountID,
   	CONST.ENABLE_GLOBAL_REIMBURSEMENTS.PAGE_NAME.BUSINESS_INFO.REGISTRATION_NUMBER,
   	),
   	),
   	);
   	},
   	},
   	]

   ), and WalletPage/index.tsx has no platform split — so one gate fix covers all layouts and platforms.

5. One more thing the one-line direction misses: verifications is not declared on BankAccountAdditionalData (

   App/src/types/onyx/BankAccount.ts

   Lines 37 to 41 in 220fb40

   	/** Corpay fields */
   	corpay?: {
   	/** Powerform files */
   	achAuthorizationForm?: FileObject[];
   	};

   , reached via AccountData.additionalData,

   App/src/types/onyx/AccountData.ts

   Line 46 in 220fb40

   additionalData?: BankAccountAdditionalData;

   ). The type must be extended or the fix does not compile. The naming precedent already exists on ACHData.verifications (

   App/src/types/onyx/ReimbursementAccount.ts

   Line 230 in 220fb40

   verifications?: {

   ).

6. History: PR #67172 introduced the feature with this proxy check; PR #70973 (issue #70811) later fixed the inverse bug (button shown for non-US accounts) by adding the USD term, but left the enabled-status term on the flow artifact. This issue is the remaining half of that same gate.

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

Read the real status marker, matching Classic.

1. Declare the field in BankAccountAdditionalData (src/types/onyx/BankAccount.ts):

/** Statuses of verification checks run against this bank account */
verifications?: {
    /** Corpay verification data — present when the account is enabled for global reimbursements */
    corpay?: Record<string, unknown>;
};

2. Swap the gate term in WalletPage/index.tsx (L430):

!paymentMethod.selectedPaymentMethod?.additionalData?.verifications?.corpay &&

Regression safety: the change is read-only and additive — the other achAuthorizationForm references (Docusign upload, sign page, API params) are write-side form plumbing that stays untouched, and the type addition is optional so no existing data shape breaks.

Why the obvious spot fix fails: pasting only the new condition into WalletPage without step 1 fails TypeScript compilation, because verifications does not exist on BankAccountAdditionalData. And any fix that keeps reading corpay.achAuthorizationForm (e.g. OR-ing extra heuristics onto it) can never classify Classic-enabled accounts correctly, because the only two writers of that field are the NewDot upload flows in step 2 above — the data is structurally absent for these accounts, so the gate must move to the field the backend actually stamps. The true source of the status is backend-populated additionalData, but the mergeable App-side fix is simply reading the field Classic already reads.

What alternative solutions did you explore? (Optional)

• Belt-and-braces gate: treat the account as enabled if EITHER marker exists (!verifications?.corpay && !corpay?.achAuthorizationForm). Covers a transient window right after completing the NewDot enable flow if the backend stamps verifications.corpay asynchronously. I'd keep this as optional hardening only — the stated Classic-parity check is the minimal correct fix.
• Backend-only fix (backfill corpay.achAuthorizationForm for all enabled accounts): rejected — it rewrites stored account data to satisfy a UI proxy, and ships no App change.
• WalletPage-only one-liner without the type change: rejected — does not compile (see above).

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[mukhrr]

Proposal

What is the root cause of that problem?

I found that shouldShowEnableGlobalReimbursementsButton treats the presence of additionalData.corpay.achAuthorizationForm as proof that Global Reimbursements are enabled:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 427 to 431 in 82c4804

	const shouldShowEnableGlobalReimbursementsButton =
	paymentMethod.selectedPaymentMethod?.additionalData?.currency === CONST.CURRENCY.USD &&
	paymentMethod.selectedPaymentMethod.type === CONST.BANK_ACCOUNT.TYPE.BUSINESS &&
	!paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;

However, achAuthorizationForm is only the uploaded Powerform file associated with NewDot’s onboarding flow, not the account’s authoritative Corpay verification status:

App/src/types/onyx/BankAccount.ts

Lines 37 to 41 in 82c4804

	/** Corpay fields */
	corpay?: {
	/** Powerform files */
	achAuthorizationForm?: FileObject[];
	};

Therefore, an account enabled outside that flow can have additionalData.verifications.corpay set while lacking achAuthorizationForm. The negated form check then evaluates to true, incorrectly showing “Enable Global Reimbursements.”

History also shows that this form-based condition was retained when the menu was restricted to open accounts; that change solved partially configured accounts but did not make the Corpay-status check authoritative:

App/src/pages/settings/Wallet/WalletPage/index.tsx

Lines 258 to 262 in eab7991

	) &&
	paymentMethod.selectedPaymentMethod?.state === CONST.BANK_ACCOUNT.STATE.OPEN;
	const shouldShowEnableGlobalReimbursementsButton =
	isBetaEnabled(CONST.BETAS.GLOBAL_REIMBURSEMENTS_ON_ND) &&

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

I think we should update shouldShowEnableGlobalReimbursementsButton in WalletPage to use additionalData.verifications.corpay, matching the backend/Classic indicator of whether Corpay is configured:

- !paymentMethod.selectedPaymentMethod?.additionalData?.corpay?.achAuthorizationForm &&
+ !paymentMethod.selectedPaymentMethod?.additionalData?.verifications?.corpay &&

I would also add the verifications.corpay field to BankAccountAdditionalData so the existing API response is represented correctly by the Onyx type.

This preserves the existing USD, business-account, and open-state checks. Consequently, non-US accounts remain excluded, partially configured accounts remain excluded, and eligible accounts without Corpay verification still see the enable action. Both Classic-created and NewDot-created accounts with the authoritative Corpay verification will no longer see it.

[lorretheboy]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.