[Due for payment 2026-04-16] [$250] Custom export format formula not working {expense:tax:code}

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

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

Action Performed:

1. Log in to New Expensify
2. Go to Reports > Reports
3. Select any report
4. Export To > Custom Export configured in OD with tax code
5. Open CSV report and see the tax code is missing for some expenses

Expected Result:

The tax code should populate since there tax is selected for each expense

Actual Result:

Only some of the tax codes export
The tax code does export when exporting from Classic but not New Expensify

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039370786192457663
• Upwork Job ID: 2039370786192457663
• Last Price Increase: 2026-04-01
• Automatic offers:
• wildan-m | Contributor | 110985432

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

Proposal

What is the root cause of that problem?

The {expense:tax:code} custom export formula resolves server-side by reading the taxCode field stored on each transaction. When expenses are created through New Expensify via the multi-scan receipt flow (and other skip-confirmation paths), the taxCode is not included in the API call parameters — it defaults to an empty string ''.

Specifically, in src/libs/actions/IOU/MoneyRequest.ts:251-270, the createTransaction() function calls requestMoney() with a transactionParams object that omits taxCode and taxAmount:

transactionParams: {
    amount: 0,
    currency: transaction?.currency ?? 'USD',
    created: transaction?.created ?? '',
    merchant: '',
    receipt,
    billable,
    reimbursable,
}

In contrast, the confirmation page flow (IOURequestStepConfirmation.tsx:309-312) correctly computes a default tax code using getDefaultTaxCode(policy, transaction) and passes it to the API. So expenses that go through the confirmation step have valid tax codes, while expenses that skip it do not — explaining why "only some of the tax codes export."

The split-bill flow in handleMoneyRequestStepScanParticipants at line 400 does pass initialTransaction.taxCode, making this an asymmetry specific to non-split expense creation via multi-scan/skip-confirmation.

Additionally, the formula resolution for {expense:tax:code} happens entirely in the backend (Web-Expensify). The App only sends templateName and transactionIDList via the QueueExportSearchWithTemplate API command — no tax data is sent during export. If the backend transaction record has an empty taxCode, the formula outputs nothing. Classic Expensify likely populates tax codes through a different code path (server-side defaults or different API flows), which is why the same report exports correctly from Classic.

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

In src/libs/actions/IOU/MoneyRequest.ts, the createTransaction() function (around line 261) should include taxCode and taxAmount in the transactionParams passed to requestMoney(), computed using the same default resolution logic as the confirmation page:

1. Use getDefaultTaxCode(policy, transaction) to compute the default tax code
2. Use getTaxValue(policy, transaction, taxCode) and calculateTaxAmount() to compute the tax amount
3. Pass both taxCode and taxAmount in the transactionParams object

This mirrors what IOURequestStepConfirmation.tsx:309-312 already does and ensures all expense creation paths consistently populate tax data.

What alternative solutions did you explore? (Optional)

• Backend fix: The backend could default the tax code when receiving an empty taxCode from NE, using the policy's defaultExternalID or foreignTaxDefault. However, this would only be a workaround — the frontend should send the correct data in the first place.
• Post-creation update: A separate API call to update the tax code after expense creation. This adds unnecessary complexity and latency.

---

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

Cat fact: Cats can rotate their ears 180 degrees independently of each other, using 32 muscles in each ear — compared to just 6 muscles in a human ear.

[melvin-bot]

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

[melvin-bot]

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

[trasnake87]

Proposal

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

When exporting expenses from New Expensify using a custom export formula containing {expense:tax:code}, the tax code is missing for some expenses — specifically those created through flows that skip the confirmation step (e.g., multi-scan receipts).

What is the root cause of that problem?

The root cause is in buildOptimisticTransaction at https://github.com/Expensify/App/blob/main/src/libs/TransactionUtils/index.ts#L423-L424. When no taxCode is passed in transactionParams, it defaults to an empty string '' and taxAmount defaults to 0. This function already receives a policy parameter (line 409) that contains the workspace's default tax configuration (policy.taxRates.defaultExternalID), but it never uses it as a fallback. Every code path that skips the confirmation step (scan, track, per diem) omits taxCode from transactionParams, so the transaction is created with an empty tax code that the backend then exports as blank.

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

We should update buildOptimisticTransaction in src/libs/TransactionUtils/index.ts to derive the default tax code from the policy when none is explicitly provided. This is the single chokepoint through which all optimistic transactions are built, so fixing it here covers every skip-confirmation flow at once (scan, track, per diem, etc.) rather than patching each caller individually.

// In buildOptimisticTransaction, after destructuring transactionParams (around line 448):
const resolvedTaxCode = taxCode || (policy?.taxRates?.defaultExternalID 
    ? getDefaultTaxCode(policy, null, currency) 
    : '');
const resolvedTaxAmount = taxAmount || (resolvedTaxCode && !taxAmount ? 0 : taxAmount);

Then use resolvedTaxCode instead of taxCode in the returned transaction object at line 537:

return {
    // ... existing fields ...
    taxCode: resolvedTaxCode,
    taxAmount,
    // ...
};

This ensures that any transaction built without an explicit tax code will inherit the policy's default, matching the behavior of the confirmation-step flow that already calls getDefaultTaxCode(policy, transaction).

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!