Issue with Account Data During EA Strategy Testing – Need Expert Insight

 

Hello everyone, While testing my Expert Advisor (EA) in the Strategy Tester, I encountered a strange and critical issue related to account data readings, and I’m hoping someone with experience can shed light on it.

Problem Description: I’m using built-in account functions like AccountInfoDouble(ACCOUNT_EQUITY) and AccountInfoDouble(ACCOUNT_PROFIT) as part of a sensitive logic in my EA that handles emergency conditions — specifically, to trigger a full closure of all trades when losses exceed a threshold.

However, during testing, I noticed that ACCOUNT_EQUITY suddenly starts returning the exact same value as ACCOUNT_BALANCE , as if there’s no floating profit or loss. At the same time, ACCOUNT_PROFIT returns zero, even though there are open trades and the market is moving.

What I Did to Investigate: I created a manual profit calculation by looping through all open positions and summing their individual profits using PositionGetDouble(POSITION_PROFIT) . This manual method returned correct values — matching the individual profits shown per trade — while ACCOUNT_PROFIT remained zero and ACCOUNT_EQUITY falsely matched the balance.

Additional Behavior During Trade Closure: When the EA begins closing trades sequentially (as part of the emergency logic), the floating profit continues to show as zero, and equity remains equal to balance. However, both values update gradually with each closed trade, reflecting the individual profit of each position only after it’s closed — not while it’s still open.

My Question: Has anyone experienced this kind of discrepancy in the Strategy Tester? Is this a known limitation of the testing environment, or is there a recommended workaround to ensure reliable readings during critical decision-making?

Any insights or shared experiences would be greatly appreciated. Thanks in advance!

Files:
desaeter.PNG  51 kb
 
JAKI.JJ:

It's not an isolated error but a known limitation of the Strategy Tester, especially noticeable in visual mode.

 

Unfortunately, I’ve modified the code several times in an attempt to bypass the issue, so I no longer have an exact copy of the version where the problem first appeared. However, I do have a very long test log, and I’ve kept the portion that clearly shows the beginning of the issue, which occurred at:


2025.09.29 20:09:53.299 → 2025.08.06 14:56:21 

++AccountInfoDouble(ACCOUNT_PROFIT) started giving zero after a series of big losses ( witch was wrong ) which triggered the EA’s protection logic and led to a full shutdown of trades.

🔍 Problem Description: The core logic in the code was based on monitoring the value of AccountInfoDouble(ACCOUNT_PROFIT) , where a decision would be made to close all open positions if the floating profit returned to zero after a series of losing trades.

📁 Log Notes (for clarification only):

  • Alert: CloseWinningPosition profit -0.21 This message is part of a loop designed to close winning positions. In this case, the position reached was actually losing, so it was skipped and the loop moved on to the next one.

  • Alert: CloseLosingPosition profit: -0.21 Indicates that the position is indeed losing and was closed accordingly as part of the loss-handling logic.

During the sequential closing of positions, the floating profit ( ACCOUNT_PROFIT ) remained zero, even though the account balance was changing after each closure. This suggests that the profit value wasn’t updating while the position was still open, but only after it was closed — which disrupts the EA’s protection logic and leads to inaccurate decisions.

Files:
desaeter2.txt  28 kb
 
JAKI.JJ # This suggests that the profit value wasn’t updating while the position was still open, but only after it was closed — which disrupts the EA’s protection logic and leads to inaccurate decisions.
When multiple transactions or closures occur within the same tick, the tester updates the balance and transactions first but freezes ACCOUNT_PROFIT at zero and sets ACCOUNT_EQUITY equal to the balance until the next tick.

In visual mode, if playback speed is high, this effect becomes more noticeable because many operations are grouped into a single simulated tick, so the account readings do not change in real time.

Although in visual mode you may see ACCOUNT_PROFIT and ACCOUNT_EQUITY remain frozen during a tick with many closures, in the background the tester calculates everything correctly.

This is why the final result of a visual and non-visual backtest is the same: the discrepancy only affects how values are displayed in visual mode, not the overall calculation of balance, equity, or the statistics in the report.
 
Miguel Angel Vico Alba #:
When multiple transactions or closures occur within the same tick, the tester updates the balance and transactions first but freezes ACCOUNT_PROFIT at zero and sets ACCOUNT_EQUITY equal to the balance until the next tick.

In visual mode, if playback speed is high, this effect becomes more noticeable because many operations are grouped into a single simulated tick, so the account readings do not change in real time.

Although in visual mode you may see ACCOUNT_PROFIT and ACCOUNT_EQUITY remain frozen during a tick with many closures, in the background the tester calculates everything correctly.

This is why the final result of a visual and non-visual backtest is the same: the discrepancy only affects how values are displayed in visual mode, not the overall calculation of balance, equity, or the statistics in the report.

Thank you for the clarification, but in my case, the issue wasn’t related to grouping operations within a single tick or execution pressure.

🔸 What actually happened: I activated the closing logic in the code based on a clear condition: if AccountInfoDouble(ACCOUNT_PROFIT) returned to zero after a series of losing trades, all open positions would be closed as a protective measure.

However, the problem was that ACCOUNT_PROFIT returned zero before any closing operations occurred, even though there were clearly losing positions. This value was incorrect and triggered the closing logic based on a false reading.

🔸 Important note: There was no execution pressure or grouping of operations in the same tick. The EA was opening or closing one position every few seconds, in a normal and consistent manner—not within a single tick or under high-speed playback.

I will also share part of the trade log that preceded the issue for further clarification: During a full minute before the closing logic was triggered, no more than five or six trades were executed. This confirms that the issue wasn’t caused by operation density or playback speed, but rather by unexpected behavior in how ACCOUNT_PROFIT was updated inside the Strategy Tester before any closures.

Therefore, it seems the issue is not just about how values are displayed in visual mode, but rather a real behavior within the Strategy Tester that affects the timing of ACCOUNT_PROFIT updates prior to closing.


2025.09.29 20:09:53.288 2025.08.06 14:56:04   sell stop 0.01 BTCUSDm at 114809.57 tp: 114760.57 (114822.16 / 114843.76)

2025.09.29 20:09:53.290 2025.08.06 14:56:04   CTrade::OrderSend: sell stop 0.01 BTCUSDm at 114809.57 tp: 114760.57 [done]

2025.09.29 20:09:53.290 2025.08.06 14:56:04   📉 SellStop : 114809.57

2025.09.29 20:09:53.291 2025.08.06 14:56:07   sell stop 0.01 BTCUSDm at 114868.98 tp: 114819.98 (114878.98 / 114900.58)

2025.09.29 20:09:53.293 2025.08.06 14:56:07   CTrade::OrderSend: sell stop 0.01 BTCUSDm at 114868.98 tp: 114819.98 [done]

2025.09.29 20:09:53.293 2025.08.06 14:56:07   📉 SellStop : 114868.98

2025.09.29 20:09:53.293 2025.08.06 14:56:08   order [#720 sell stop 0.01 BTCUSDm at 114868.98] triggered

2025.09.29 20:09:53.293 2025.08.06 14:56:08   deal #715 sell 0.01 BTCUSDm at 114860.62 done (based on order #720)

2025.09.29 20:09:53.293 2025.08.06 14:56:08   deal performed [#715 sell 0.01 BTCUSDm at 114860.62]

2025.09.29 20:09:53.293 2025.08.06 14:56:08   order performed sell 0.01 at 114860.62 [#720 sell stop 0.01 BTCUSDm at 114868.98]

2025.09.29 20:09:53.294 2025.08.06 14:56:15   buy stop 0.01 BTCUSDm at 114856.30 tp: 114905.30 (114824.70 / 114846.30)

2025.09.29 20:09:53.296 2025.08.06 14:56:15   CTrade::OrderSend: buy stop 0.01 BTCUSDm at 114856.30 tp: 114905.30 [done]

2025.09.29 20:09:53.296 2025.08.06 14:56:15   📈 BuyStop : 114856.30

2025.09.29 20:09:53.296 2025.08.06 14:56:15   order [#721 buy stop 0.01 BTCUSDm at 114856.30] triggered

2025.09.29 20:09:53.296 2025.08.06 14:56:15   deal #716 buy 0.01 BTCUSDm at 114862.49 done (based on order #721)

2025.09.29 20:09:53.296 2025.08.06 14:56:15   deal performed [#716 buy 0.01 BTCUSDm at 114862.49]

2025.09.29 20:09:53.296 2025.08.06 14:56:15   order performed buy 0.01 at 114862.49 [#721 buy stop 0.01 BTCUSDm at 114856.30]

2025.09.29 20:09:53.296 2025.08.06 14:56:18   take profit triggered #721 buy 0.01 BTCUSDm 114862.49 tp: 114905.30 [#722 sell 0.01 BTCUSDm at 114905.30]

2025.09.29 20:09:53.296 2025.08.06 14:56:18   deal #717 sell 0.01 BTCUSDm at 114908.69 done (based on order #722)

2025.09.29 20:09:53.296 2025.08.06 14:56:18   deal performed [#717 sell 0.01 BTCUSDm at 114908.69]

2025.09.29 20:09:53.296 2025.08.06 14:56:18   order performed sell 0.01 at 114908.69 [#722 sell 0.01 BTCUSDm at 114905.30]

2025.09.29 20:09:53.297 2025.08.06 14:56:20   sell stop 0.01 BTCUSDm at 114921.58 tp: 114872.58 (114931.58 / 114953.18)

2025.09.29 20:09:53.299 2025.08.06 14:56:20   CTrade::OrderSend: sell stop 0.01 BTCUSDm at 114921.58 tp: 114872.58 [done]

2025.09.29 20:09:53.299 2025.08.06 14:56:20   📉 SellStop : 114921.58

2025.09.29 20:09:53.299 2025.08.06 14:56:21   order [#723 sell stop 0.01 BTCUSDm at 114921.58] triggered

2025.09.29 20:09:53.299 2025.08.06 14:56:21   deal #718 sell 0.01 BTCUSDm at 114918.58 done (based on order #723)

2025.09.29 20:09:53.299 2025.08.06 14:56:21   deal performed [#718 sell 0.01 BTCUSDm at 114918.58]

2025.09.29 20:09:53.299 2025.08.06 14:56:21   order performed sell 0.01 at 114918.58 [#723 sell stop 0.01 BTCUSDm at 114921.58]

 
JAKI.JJ #:
My final recommendation:

If ACCOUNT_PROFIT returned zero even without bursts of operations or tick grouping, then this is a limitation of the tester in how it updates account data, not an error in your logic. That explains why the readings don't always match the actual state of open positions.

That's why in backtests it's always more reliable to loop through all positions and sum up POSITION_PROFIT. This calculation consistently reflects the real floating profit, while ACCOUNT_PROFIT can return delayed or zero values depending on the modeling mode. For critical protection logic, the safe practice is to rely on the manual calculation (POSITION_PROFIT), rather than on the direct account value (ACCOUNT_PROFIT).
 
Miguel Angel Vico Alba #:
My final recommendation:

If ACCOUNT_PROFIT returned zero even without bursts of operations or tick grouping, then this is a limitation of the tester in how it updates account data, not an error in your logic. That explains why the readings don't always match the actual state of open positions.

That's why in backtests it's always more reliable to loop through all positions and sum up POSITION_PROFIT. This calculation consistently reflects the real floating profit, while ACCOUNT_PROFIT can return delayed or zero values depending on the modeling mode. For critical protection logic, the safe practice is to rely on the manual calculation (POSITION_PROFIT), rather than on the direct account value (ACCOUNT_PROFIT).

Your recommendation doesn't make sense.

From where the passage I highlighted is coming from ?

 
JAKI.JJ:

Hello everyone, While testing my Expert Advisor (EA) in the Strategy Tester, I encountered a strange and critical issue related to account data readings, and I’m hoping someone with experience can shed light on it.

Problem Description: I’m using built-in account functions like AccountInfoDouble(ACCOUNT_EQUITY) and AccountInfoDouble(ACCOUNT_PROFIT) as part of a sensitive logic in my EA that handles emergency conditions — specifically, to trigger a full closure of all trades when losses exceed a threshold.

However, during testing, I noticed that ACCOUNT_EQUITY suddenly starts returning the exact same value as ACCOUNT_BALANCE , as if there’s no floating profit or loss. At the same time, ACCOUNT_PROFIT returns zero, even though there are open trades and the market is moving.

What I Did to Investigate: I created a manual profit calculation by looping through all open positions and summing their individual profits using PositionGetDouble(POSITION_PROFIT) . This manual method returned correct values — matching the individual profits shown per trade — while ACCOUNT_PROFIT remained zero and ACCOUNT_EQUITY falsely matched the balance.

Additional Behavior During Trade Closure: When the EA begins closing trades sequentially (as part of the emergency logic), the floating profit continues to show as zero, and equity remains equal to balance. However, both values update gradually with each closed trade, reflecting the individual profit of each position only after it’s closed — not while it’s still open.

My Question: Has anyone experienced this kind of discrepancy in the Strategy Tester? Is this a known limitation of the testing environment, or is there a recommended workaround to ensure reliable readings during critical decision-making?

Any insights or shared experiences would be greatly appreciated. Thanks in advance!

Is it doing the same with EURUSD for example ?

What are the strategy tester settings you are using ?

Could also be a bug in the build you are using which seems to be a beta.

 
Alain Verleyen #:

Your recommendation doesn't make sense.

From where the passage I highlighted is coming from ?

The part you questioned is not coming from me. It comes directly from the OP, who already showed that summing POSITION_PROFIT returned correct values while ACCOUNT_PROFIT was stuck at zero.

This behavior is documented in the forum and is reproducible in the tester. That is why the recommendation to rely on POSITION_PROFIT for protection logic is consistent and not contradictory.

Forum on trading, automated trading systems and testing trading strategies

Issue with Account Data During EA Strategy Testing – Need Expert Insight

JAKI.JJ, 2025.09.30 11:16

What I Did to Investigate: I created a manual profit calculation by looping through all open positions and summing their individual profits using PositionGetDouble(POSITION_PROFIT) . This manual method returned correct values — matching the individual profits shown per trade — while ACCOUNT_PROFIT remained zero and ACCOUNT_EQUITY falsely matched the balance.

 
Miguel Angel Vico Alba #:
The part you questioned is not coming from me. It comes directly from the OP, who already showed that summing POSITION_PROFIT returned correct values while ACCOUNT_PROFIT was stuck at zero.

This behavior is documented in the forum and is reproducible in the tester. That is why the recommendation to rely on POSITION_PROFIT for protection logic is consistent and not contradictory.

It's what we called a bug in programming, which is not related to the Visual mode. 
 

Unfortunately, the code is no longer available for re-testing, but I am certain that AccountInfoDouble(ACCOUNT_PROFIT) was returning an incorrect zero value. The attached image shows that this issue occurred repeatedly, which led me to build a recovery model.

I usually perform testing using the settings shown in the attached image, on Bitcoin and Euro pairs, to ensure the EA is comprehensive and adaptable.

Files:
desaeter3.PNG  20 kb
desaeter4.PNG  16 kb