fix(expense-claim): revalidate reimbursement amount against grand total and advance

[Dharanidharan2813]

Issue: Expense Claim reimbursement and outstanding amount were miscalculated when advance amounts were involved, and the status was not updated correctly when the payment was fully paid.

Fix: Updated the reimbursement logic to properly consider advance amounts and corrected the outstanding amount calculation, and ensured the status updates correctly when the claim is fully paid.

Closes: 4117

Before:

Screencast.from.2026-02-19.12-36-21.webm

After:

Screencast.from.2026-02-19.12-37-20.webm

Summary by CodeRabbit

Bug Fixes

• Modified how expense claims are marked as paid when advances are linked to reimbursements
• Adjusted outstanding amount calculations related to advance deductions

[coderabbitai]

Walkthrough

The expense claim module has been updated to adjust how reimbursement status and outstanding amounts are calculated. The status-setting logic now incorporates total advance amounts into the condition for marking claims as "Paid" when sanctioned amounts exist. Additionally, the outstanding amount calculation has been modified to no longer deduct advances from the final computation. These changes affect how the system determines claim completion status and remaining balance calculations.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: fixing reimbursement amount validation to account for both grand total and advance amounts in expense claim calculations.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@hrms/hr/doctype/expense_claim/expense_claim.py`:
- Around line 83-86: The "Paid" status check is wrong when payments use journal
entries because advances aren't linked via update_against_claim_in_pe; change
the logic in the status determination (the expression using
flt(self.grand_total, precision) + flt(self.total_advance_amount) ==
flt(self.total_amount_reimbursed, precision)) to branch on the
make_payment_via_journal_entry setting: if make_payment_via_journal_entry is
True, treat total_amount_reimbursed as already net of advances (compare
flt(self.grand_total, precision) == flt(self.total_amount_reimbursed,
precision)), otherwise keep the existing comparison that includes advances; also
update get_outstanding_amount_for_claim to subtract advances for the JV flow or
normalize total_amount_reimbursed calculation so both paths include advances
consistently; finally, fix the minor precision bug by calling
flt(self.total_advance_amount, precision) so all flt calls use the same
precision.

---

Duplicate comments:
In `@hrms/hr/doctype/expense_claim/expense_claim.py`:
- Around line 618-624: get_outstanding_amount_for_claim currently calculates
outstanding_amt without deducting advances, which inflates JV amounts when
make_payment_via_journal_entry is enabled; update this function to conditionally
subtract flt(claim.total_advance_amount) when the system is using the JV path
(i.e., when make_payment_via_journal_entry is true) so that outstanding_amt =
flt(total_sanctioned_amount) + flt(total_taxes_and_charges) -
flt(total_amount_reimbursed) - flt(total_advance_amount) for that path,
otherwise keep the existing logic for the PE path; ensure you reference the
claim properties (total_sanctioned_amount, total_taxes_and_charges,
total_amount_reimbursed, total_advance_amount) and the flag
make_payment_via_journal_entry in the function to normalize behavior for
downstream callers like make_bank_entry.

[Dharanidharan2813]

In Version 15, the Payment Entry is not linked with the Expense Claim, so the issue is not reproducible there.

However, in Version 16, the Payment Entry is linked with the Expense Claim. Because of this change in behavior, the issue occurs only in Version 16.

The test cases are failing when "Make Payment via Journal Entry" is enabled in Accounts Settings. When this setting is enabled, payments are created through a Journal Entry instead of a Payment Entry. In Version 16, the Journal Entry is not properly linked with the Expense Claim, which causes the test cases to fail.

To fix this issue, I am working on linking the Journal Entry with the Expense Claim.

[iamkhanraheel]

In Version 15, the Payment Entry is not linked with the Expense Claim, so the issue is not reproducible there.

However, in Version 16, the Payment Entry is linked with the Expense Claim. Because of this change in behavior, the issue occurs only in Version 16.

The test cases are failing when "Make Payment via Journal Entry" is enabled in Accounts Settings. When this setting is enabled, payments are created through a Journal Entry instead of a Payment Entry. In Version 16, the Journal Entry is not properly linked with the Expense Claim, which causes the test cases to fail.

To fix this issue, I am working on linking the Journal Entry with the Expense Claim.

Journal entry is not supported for payment of records, that's why it is hidden. Use Payment Entry doctype only for payment of the advance.
Most probably, this checkbox will be removed in v17 release.

[Dharanidharan2813]

In Version 15, the Payment Entry is not linked with the Expense Claim, so the issue is not reproducible there.
However, in Version 16, the Payment Entry is linked with the Expense Claim. Because of this change in behavior, the issue occurs only in Version 16.
The test cases are failing when "Make Payment via Journal Entry" is enabled in Accounts Settings. When this setting is enabled, payments are created through a Journal Entry instead of a Payment Entry. In Version 16, the Journal Entry is not properly linked with the Expense Claim, which causes the test cases to fail.
To fix this issue, I am working on linking the Journal Entry with the Expense Claim.

Journal entry is not supported for payment of records, that's why it is hidden. Use Payment Entry doctype only for payment of the advance. Most probably, this checkbox will be removed in v17 release.

Understood. Since Journal Entry for advance payments is no longer supported and is planned for removal in the upcoming release, the related test cases are validating deprecated functionality.

Shall I proceed with removing those test cases?

[newtratip]

Hello,

Just a gentle ping on this PR. Any updates on this?

Thanks!

[Dharanidharan2813]

In Version 15, the Payment Entry is not linked with the Expense Claim, so the issue is not reproducible there.
However, in Version 16, the Payment Entry is linked with the Expense Claim. Because of this change in behavior, the issue occurs only in Version 16.
The test cases are failing when "Make Payment via Journal Entry" is enabled in Accounts Settings. When this setting is enabled, payments are created through a Journal Entry instead of a Payment Entry. In Version 16, the Journal Entry is not properly linked with the Expense Claim, which causes the test cases to fail.
To fix this issue, I am working on linking the Journal Entry with the Expense Claim.

Journal entry is not supported for payment of records, that's why it is hidden. Use Payment Entry doctype only for payment of the advance. Most probably, this checkbox will be removed in v17 release.

Understood. Since Journal Entry for advance payments is no longer supported and is planned for removal in the upcoming release, the related test cases are validating deprecated functionality.

Shall I proceed with removing those test cases?

@iamkhanraheel Shall I proceed with removing those test cases?

[iamkhanraheel]

Hi @Dharanidharan2813
I was testing the changes and found out that the problem was the Total Reimbursed Amount was updated with the already paid advance amount which caused problem in creating payment entry for reimbursed amount. I have fixed this here #4240
Your changes were not fixing the core problem instead it was a just ignoring the already linked payment entry.