[$250] Add a reimbursable toggle on the expense form in New Expensify

[flaviadefaria]

I HAVE UPDATED THIS OP TO ACCOUNT FOR ALL THE PLANNING DISCUSSIONS THAT TOOK PLACE ON THE ISSUE, THIS IS ALL YOU NEED TO READ FOR YOUR PROPOSAL:

---

• Add reimbursable toggle on the expense form, similar to how the Billable toggle displays when enabled.

• The placement for this toggle should be after all expense fields but before the billable toggle, so:
  - Expense fields
  - Reimbursable toggle
  - Billable toggle

• The Reimbursable toggle should be enabled by default if no credit cards are connected (more details below)
  - An imported card transaction is non-reimbursable and cannot be changed, so the toggle should not be displayed at all on card transactions (like OldDot).
  - The toggle should only be displayed on expenses you create to submit to a workspace, as it's a workspace feature. (e.g don't show it on expenses you submit to a friend in a DM).
  - The toggle should abide by the same permission logic as the date and amount fields when it comes to editing, which I believe is as follows:
  - Submitter: can't edit the toggle on processing reports after first level approval.
  - Non-admin manager: can't edit the toggle after they've approved (i.e no longer the report's managerID)
  - Admins: can't edit the toggle if it's on a report in the approved, reimbursed or closed state.

Then for cross-platform consistency we'll want to include the following instructions:

1. If Default reimbursable is set via OldDot, show the toggle enabled by default on expense creation.
2. If Default non-reimbursable is set via OldDot, show the toggle disabled by default on expense creation.
3. If Always non-reimbursable is set via OldDot, don't show the toggle at all and create the cash expense as non-reimbursable.
4. If Always reimbursable is set via OldDot, don't show the toggle at all and create the cash expense as reimbursable.

cc @Expensify/design in case you have any additional input you want to share.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021902042013735835234
• Upwork Job ID: 1902042013735835234
• Last Price Increase: 2025-03-25
• Automatic offers:
• daledah | Contributor | 106681987

Issue Owner

Current Issue Owner: @getusha

Adding here the list of issues that need to be fixed with a new PR:

Issue	Frontend/Backend	Status
No toggle for reimbursement when sharing expense with accountant	Frontend	🔴 Not started
Reimbursable toggle is enabled in invoice thread when it is disabled on confirm page	Frontend	🔴 Not started
Reimbursable toggle is shown for p2p expense when creating expense from iou report	Frontend	🔴 Not started
Reimbursable is enabled in transaction thread when it is disabled on confirmation page	Frontend - Perhaps bug is unique due to offline mode	🔴 Not started
Reimbursable toggle is disabled for new members by default	Potentially Backend - To investigate	🔴 Not started
Pay button does not disappear after disabling Reimbursable in offline mode	Frontend	🔴 Not started
Reimbursable toggle is disabled when it is enabled on confirm page when categorizing expense	Potentially Frontend issue with optimistic updates - To investigate	🔴 Not started
"Waiting for you to pay expense" still seen after disabling "Reimbursable" option	Frontend - Similar to issue 4 above	🔴 Not started

Keys:
🔴 Not started
🟡 In Progress
🟢 Completed

[melvin-bot]

Current assignee @flaviadefaria is eligible for the NewFeature assigner, not assigning anyone new.

[melvin-bot]

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

[melvin-bot]

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

[dannymcclain]

Seems pretty straight-forward to me. Where does a user enable the option to display this toggle? (asking mostly out of curiosity)

[shawnborton]

Agree, seems pretty straight forward. Similar question as Danny, though I am wondering if we are just going to show it for all expenses on a workspace for feature parity with OldDot?

[daledah]

🚨 Edited by proposal-police: This proposal was edited at 2025-03-18 18:33:08 UTC.

Proposal

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

Add a non-reimbursable toggle on the expense form in New Expensify

What is the root cause of that problem?

New feature

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

Note

The following reimbursable values are set to reflect default reimbursable value sent by BE when request money. Proposed changes use manual expense, the same can be applied to other expenses

1. In MoneyRequestConfirmationListFooter, add non-reimbursable field to before billable toggle

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 600 in af28497

{

{
            item: (
                <View
                    key={Str.UCFirst(translate('iou.reimbursable'))}
                    style={[styles.flexRow, styles.justifyContentBetween, styles.alignItemsCenter, styles.ml5, styles.mr8, styles.optionRow]}
                >
                    <ToggleSettingOptionRow
                        switchAccessibilityLabel={Str.UCFirst(translate('iou.reimbursable'))}
                        title={Str.UCFirst(translate('iou.reimbursable'))}
                        onToggle={(isOn) => onToggleReimbursable?.(isOn)}
                        isActive={iouIsReimbursable}
                        disabled={isReadOnly}
                        wrapperStyle={styles.flex1}
                    />
                </View>
            ),
            shouldShow: shouldShowReimbursable,
            isSupplementary: true,
        },

With new props introduced are:onToggleReimbursable, iouIsReimbursable passed from IOURequestStepConfirmation, implemented similar to onToggleBillable and iouIsBillable:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 914 in af28497

<MoneyRequestConfirmationList

setReimbursable={setReimbursable}
iouIsReimbursable={transaction?.reimbursable ?? policy?.defaultReimbursable}

Before that we need to add defaultReimbursable prop to Policy type, which is not available anywhere yet but existed in Onyx data.

shouldShowReimbursable is similar to shouldShowBillable, with additional check for card transaction

App/src/components/MoneyRequestConfirmationListFooter.tsx

Line 276 in af28497

const shouldShowBillable = policy?.disabledFields?.defaultBillable === false;

const shouldShowReimbursable = policy?.disabledFields?.reimbursable === false && !isCardTransaction(transaction);

2. To send the input to RequestMoney:

First we need to update the misspelled reimbursible prop in RequestMoneyParams and RequestMoneyInformation to the correct value reimbursable:

App/src/libs/actions/IOU.ts

Line 380 in af28497

reimbursible?: boolean;

App/src/libs/API/parameters/RequestMoneyParams.ts

Line 30 in af28497

reimbursible?: boolean;

Then add reimbursable here

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 359 in af28497

requestMoneyIOUActions({

reimbursable: transaction.reimbursable

OR we can add reimbursable to BaseTransactionParams

App/src/libs/actions/IOU.ts

Line 203 in af28497

type BaseTransactionParams = {

and add reimbursable here

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Line 373 in af28497

transactionParams: {

Then in requestMoney, add reimbursable to parameters:

App/src/libs/actions/IOU.ts

Line 4725 in af28497

const parameters: RequestMoneyParams = {

with reimbursable get from requestMoneyInformation or transactionParams added above

3. On Money Request View, if we want to show Reimbursable toggle, add the toggle to before billable toggle:

Note

To make the toggle work, we need to make a new API endpoint similar to UpdateMoneyRequestBillable, which isn't available right now, so this part is open for discussions

App/src/components/ReportActionItem/MoneyRequestView.tsx

Line 761 in af28497

{shouldShowBillable && (

{shouldShowReimbursable && (
                    <View style={[styles.flexRow, styles.optionRow, styles.justifyContentBetween, styles.alignItemsCenter, styles.ml5, styles.mr8]}>
                        <View>
                            <Text>Reimbursable</Text>
                        </View>
                        <Switch
                            accessibilityLabel="Reimbursable"
                            isOn={updatedTransaction?.reimbursable ?? !!transactionReimbursable}
                            onToggle={saveReimbursable}
                            disabled={!canEdit}
                        />
                    </View>
                )}

Again, with logics similar to Billable toggle.

For all the translations, we can use iou.nonReimbursable or iou.reimbursable here:

App/src/languages/en.ts

Lines 1106 to 1107 in af28497

	reimbursable: 'reimbursable',
	nonReimbursable: 'non-reimbursable',

And optional to capitalize first letter

Here's the result:

Screen.Recording.2025-03-19.at.01.11.27.mp4

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

None, New feature

What alternative solutions did you explore? (Optional)

NA

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.

[github-actions]

⚠️ @daledah Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[flaviadefaria]

@shawnborton @dannymcclain

Seems pretty straight-forward to me. Where does a user enable the option to display this toggle? (asking mostly out of curiosity)

This will be enabled by default on all expenses

Agree, seems pretty straight forward. Similar question as Danny, though I am wondering if we are just going to show it for all expenses on a workspace for feature parity with OldDot?

Exactly this is dor parity with OldDot so that we can migrated coming cohorts.

[dannymcclain]

Right on—thanks!

[trjExpensify]

It should display right after tags (if any)

I think we'd want it placed after all the fields on the expense, so the toggles are at the bottom. Tax comes after Tags, so I don't think we want a toggle inbetween those fields. I would suggest the instruction for placement is:

• Expense fields
• Reimbursable toggle
• Billable toggle

Add a non-reimbursable toggle on the expense form, similar to how the Billable toggle displays when enabled.

For the avoidance of doubt, we want the toggle to be named Reimbursable not Non-reimbursable right? When it's enabled the expense is marked as reimbursable, when it's disabled the expense is marked as non-reimbursable.

Further, for the proposals and implementation...

• An imported card transaction is non-reimbursable and cannot be changed, so the toggle should not be displayed at all on card transactions (like OldDot).
• The toggle should only be displayed on expenses you create to submit to a workspace, as it's a workspace feature. (e.g don't show it on expenses you submit to a friend in a DM).
• The toggle should abide by the same permission logic as the date and amount fields when it comes to editing, which I believe is as follows:
  • Submitter: can't edit the toggle on processing reports after first level approval.
  • Non-admin manager: can't edit the toggle after they've approved (i.e no longer the report's managerID)
  • Admins: can't edit the toggle if it's on a report in the approved, reimbursed or closed state.

The Reimbursable toggle should be enabled by default

@flaviadefaria regarding this one, for existing collect workspaces that have this feature set to non-reimbursable by default or "Always xx" via OldDot workspace settings, are we going to abide by that while the feature exists to configure on OldDot? 🤔 I'm a bit on the fence for cross-platform consistency. CC: @JmillsExpensify too. If we do, then we'll want to include the following instructions:

1. If Default reimbursable is set via OldDot, show the toggle enabled by default on expense creation.
2. If Default non-reimbursable is set via OldDot, show the toggle disabled by default on expense creation.
3. If Always non-reimbursable is set via OldDot, don't show the toggle at all and create the cash expense as non-reimbursable.
4. If Always reimbursable is set via OldDot, don't show the toggle at all and create the cash expense as reimbursable.

I think that's all I had to add, excited for this one! 🚀

[daledah]

PROPOSAL UPDATED

Update proposal to apply suggested changes in #58588 (comment)

[flaviadefaria]

@trjExpensify:

I think we'd want it placed after all the fields on the expense, so the toggles are at the bottom. Tax comes after Tags, so I don't think we want a toggle inbetween those fields. I would suggest the instruction for placement is:

Expense fields
Reimbursable toggle
Billable toggle

Yes, this was my intention. I wanted it to come before the Billable toggle but after everything else.

For the avoidance of doubt, we want the toggle to be named Reimbursable not Non-reimbursable right? When it's enabled the expense is marked as reimbursable, when it's disabled the expense is marked as non-reimbursable.

Correct, I realize now I wrote different things in different places. Thanks for catching it.

Further, for the proposals and implementation...

Yes, to all of that! Thanks for flagging these other use cases.

@flaviadefaria regarding this one, for existing collect workspaces that have this feature set to non-reimbursable by default or "Always xx" via OldDot workspace settings, are we going to abide by that while the feature exists to configure on OldDot? 🤔 I'm a bit on the fence for cross-platform consistency. CC: @JmillsExpensify too.

I don’t think so - this would overcomplicate the implementation. If the plan is not to support this feature in New Collect, then I think we should just default to reimbursable unless cards are connected.

Since this isn’t a toggle that Collect customers can disable, not showing it on the expense form shouldn’t be an option.

[trjExpensify]

Since this isn’t a toggle that Collect customers can disable, not showing it on the expense form shouldn’t be an option.

Cool, I'm happy to not abide by what exists in the interim while this feature setting can be changed via OldDot.

If the plan is not to support this feature in New Collect, then I think we should just default to reimbursable unless cards are connected.

Do you just mean not show it on card transactions here? or dynamically behind the scenes switch the default on expense creation depending on if the user has a managed card assigned to them or not?

[JmillsExpensify]

I don't see why we'd ignore a setting we suppport on OldDot. Basically, I think the choices are: upgrade anyone that won't be supported moving forward to Control; alternatively, support full backward compatibility for now and address the upgrade to Control later. For what it's worth, the "always" cases are quite rare, a super small percentage on Control (I don't think we have a sense on Collect).

[flaviadefaria]

Ok, let's align on this here. We agreed no rules would be possible in NewDot so all expenses will be defaulted to reimbursable (as the mainline case when no credit cards are connected), everyone else will be upgrade to Control:

Default to reimbursable - this will be possible in Collect New Dot
Default to non-reimbursable - this won't be possible unless cards are connected >> upgrade to control
Always reimbursable - this won't be possible in Collect NewDot >> upgrade to control
Always non-reimbursable - this won't be possible in Collect NewDot >> upgrade to control

I do not have any data for the latter two options so I'll need to ask @nkuoch to add it to the query.

[trjExpensify]

I do not have any data for the latter two options so I'll need to ask @nkuoch to add it to the query.

It's ~4% use one of the Always options when we last looked here, I believe.

I think we're in agreement about upgrading people to Control that use those settings. I think it's just a question of timing. If we build this feature tomorrow ("set the reimbursability of a newly created "cash" expense based on the workspace setting for it"), it's still configurable on Collect via OldDot in the meantime. Do we abide by that in the interim?

[daledah]

@getusha PR is ready.

[trjExpensify]

@inimaga our wires were crossed in the issue with the reference to "expense report". We for sure need to add this toggle to the "expense" level form, so we're going to need help with the BE it sounds like.

Would you be able to help with that? It should be fairly similar to the billable toggle that exists. CC: @Gonals

[melvin-bot]

This issue has not been updated in over 15 days. @inimaga, @getusha, @flaviadefaria, @daledah eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[flaviadefaria]

The PR is being reviewed.

[melvin-bot]

@getusha Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@getusha Still overdue 6 days?! Let's take care of this!

[melvin-bot]

@getusha Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

@getusha 10 days overdue. Is anyone even seeing these? Hello?

[melvin-bot]

This issue has not been updated in over 14 days. @inimaga, @getusha, @flaviadefaria, @daledah eroding to Weekly issue.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[mallenexpensify]

@flaviadefaria The PR from this issue might have caused a regression. Checking on the potential regression here

[flaviadefaria]

@daledah @getusha @inimaga I've added all the issues that need to be accounted for in a new PR to the OP of this GH so that you can easily find them.

We need to test all those cases in the new PR to avoid the deploy blockers again.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[inimaga]

@flaviadefaria Just saw your comment. Updating the PR description of the original post to include the tracking table.

[flaviadefaria]

Amazing, thank you for doing that @inimaga!