MT5 Journal Doesn’t Match Account History? A Reconciliation Checklist for Commission, Swap, Partials, and Time

A total in your trading journal does not match the total you see in MetaTrader 5 account history. That can be frustrating—especially when the difference is small enough to look like an error, but large enough to affect your review.

Start with one important point:

A mismatch does not automatically mean either system is wrong

MT5 account history can be viewed and exported through different lenses. A journal, spreadsheet, broker statement, or imported report may use a different date range, trade unit, timestamp display, fee field, or grouping rule.

For example, one comparison may total individual executed deals, while another presents a completed position or groups multiple fills together. Neither view is necessarily incorrect. They may simply answer different accounting questions.

The practical goal is not to guess which number is “right.” It is to make both sides comparable: same scope, same unit, same included fields, and the same interpretation of time.

This checklist is designed for that process.

Synthetic example: A trader sees a $14.20 difference between an MT5 history export and a journal total. The difference is not necessarily a missing trade. It could be commission shown separately from deal profit, a difference in how swap is included in the compared totals, two exit deals from a partial close, or a day boundary shown in another time basis.

First: compare like with like

Before inspecting any individual trade, write down exactly what each side is reporting.

Do not begin with the largest losing or winning trade. Start with the comparison definition. A total is only meaningful when its components use the same rules.

1. Match the history scope and date range

MT5 history selection is date-range based in MQL5: the HistorySelect function selects orders and deals between a requested start and end time. That means a comparison can diverge at the boundary even if every record inside the range is correctly represented.

Check:

• The start date and time on both sides

• The end date and time on both sides

• Whether the range is inclusive or effectively stops at the beginning of the final day

• Whether the selected history is account-wide or limited by another filter

• Whether closed activity near midnight appears on the same calendar date in both views

Use a short, controlled range first—such as one completed day or a small set of known closed activity—rather than a full account-history total. Once that range reconciles, expand it.

Synthetic example: One report covers 1–30 September but ends at 00:00 on 30 September. Another includes the full day through 23:59:59. Trades closed later on 30 September will appear in one total but not the other.

2. Confirm whether you are comparing deals, orders, or positions

In MT5 terminology, these are related but distinct records:

• An order is a trading instruction or request.

• A deal records an execution of a trade operation.

• A position represents the trader’s market exposure and can be affected by one or more deals.

MetaQuotes’ MQL5 documentation describes a deal as the reflection of an executed trade operation based on an order. One order can produce more than one deal when execution occurs in parts. A position can also be opened, changed, reduced, or closed through multiple deals.

This is one structural reason totals or trade counts can appear different.

Ask:

• Is one source counting executions and the other counting completed positions?

• Does one row correspond to an entry, an exit, or a fully grouped round trip?

• Are multi-fill executions represented as multiple rows?

• Are separate entries or exits linked under a single position identifier?

For technical investigation, MT5 exposes both a deal ticket and a position identifier in its deal properties. The DEAL_POSITION_ID property can help establish whether multiple deal records belong to the same position lifecycle.

Do not expect a one-row-to-one-trade comparison until you have confirmed what “trade” means in each view.

3. Reconcile commission, swap, and other fee fields separately

A headline profit figure may not include costs in the same way everywhere.

MQL5 deal properties include distinct fields for:

• DEAL_PROFIT

• DEAL_COMMISSION

• DEAL_SWAP

• DEAL_FEE

These fields are a useful reconciliation starting point because they are separate properties at the deal level. Whether another report or journal includes, excludes, displays, or groups those items is a separate question that must be checked in that system’s documentation or exported data.

For each comparable item, record:

1. Deal profit

2. Commission

3. Swap

4. Fee, if present

5. The final formula used by each side

Avoid assuming a universal formula. A practical comparison is to calculate both:

• Profit-only total: sum of the profit field

• Cost-inclusive total: sum of profit, commission, swap, and any applicable fee field

Then compare the resulting difference with the mismatch you are investigating.

Synthetic example: A closed sequence has DEAL_PROFIT of $100, DEAL_COMMISSION of -$6, and DEAL_SWAP of -$1.50. A profit-only view is $100. A cost-inclusive view is $92.50. A $7.50 difference may be a presentation or inclusion difference, not a missing record.

Important: do not assume a journal applies any particular commission, swap, fee, or net-P&L treatment unless that behavior has been verified for the specific import or workflow being used.

4. Check for partial closes and multiple execution deals

A partial close can turn what feels like one trade into several historical records.

For example, a trader might:

1. Open a position,

2. Close part of its volume,

3. Close the remainder later.

The history can contain separate exit deals. Depending on the account mode and execution path, an order may also generate multiple deals because of partial execution.

When reconciling partials:

• Group related deals by the MT5 position identifier where appropriate.

• Compare total closed volume, not only the number of rows.

• Check whether each exit has its own profit, commission, swap, or fee values.

• Confirm whether a summary treats the activity as one position, multiple closed trades, or multiple execution records.

• Do not assume entry and exit timestamps will be identical across grouped records.

MT5 position properties include POSITION_IDENTIFIER. MetaQuotes states that this identifier is generally used to link a position with the orders and deals that opened, modified, or closed it. In a history-based investigation, its deal-side counterpart, DEAL_POSITION_ID, can be useful for building that relationship.

Synthetic example: A 1.00-lot position is closed as 0.40 lots and 0.60 lots at different times. A deal-level history may show two exits. A grouped position view may show one completed position. The trade count differs even when the underlying economic activity is the same.

5. Treat timestamps as data—not just display labels

A calendar-date mismatch can be a time-display mismatch.

MQL5 deal properties include:

• DEAL_TIME

• DEAL_TIME_MSC

DEAL_TIME records deal time in seconds, while DEAL_TIME_MSC provides millisecond-resolution time. When comparing exports or systems, determine what each timestamp represents and how each interface displays it.

Check:

• The exact time attached to the deal or closed position

• The date boundary used in each report

• Whether times are shown with seconds or milliseconds

• Whether the comparison uses a display conversion or another time basis

• Whether the discrepancy is concentrated around midnight, weekends, or daylight-saving transitions

Avoid “correcting” a timestamp by adding or subtracting an assumed offset unless the data source explicitly documents the required interpretation. First preserve the raw exported timestamps and compare them with the displayed values.

Synthetic example: Two exits occur at 23:58 and 00:03 in the displayed account history. If another report places the second record under a different calendar date, a daily total can differ while the full multi-day total still reconciles.

6. Separate trading results from balance operations

Not every account-history line represents a market trade.

Depending on account activity and the history view, you may encounter balance-related operations such as deposits, withdrawals, credits, charges, corrections, or other non-trading entries. In MQL5, deal type and entry-related properties help distinguish categories of historical activity.

For a trade-performance comparison, decide explicitly whether balance operations should be included.

Check for:

• Deposits and withdrawals

• Credits or bonuses

• Charges or adjustments

• Corrections

• Other non-trading account entries

Do not add or remove these lines merely to force a total to match. Label them, then compare trading activity to trading activity and balance activity to balance activity.

7. Verify symbols before declaring a trade missing

A symbol is not always presented identically across sources.

The relevant issue is not whether a label “looks close enough,” but whether both sides refer to the same historical activity. Check for:

• Suffixes or prefixes in the broker’s symbol naming

• Similar instruments with different contract specifications

• Different display labels for the same imported activity

• Filters that include one symbol spelling but exclude another

Use the historical record details—such as ticket, timestamp, volume, price, and position identifier where available—to confirm the match. Do not rely solely on a symbol label.

8. Build a small reconciliation table before escalating

A short evidence table is usually more useful than screenshots of an entire account history.

For each record or grouped position in a controlled date range, capture:

Start with five to ten records around the first discrepancy. If those reconcile, widen the range. If they do not, identify the first row where the two representations diverge.

9. What to include in a support escalation

If the mismatch remains after using the same range, unit, and cost fields, prepare evidence that lets support reproduce the comparison.

Include:

1. The exact account-history range used

2. The timezone or timestamp display information shown by each system, if known

3. Whether you are comparing deals, orders, positions, or a grouped summary

4. The calculation formula on each side

5. A small sample of affected records with tickets and position identifiers where available

6. Screenshots or exports with sensitive personal or account information removed where possible

7. A statement of the expected total, observed total, and exact difference

8. Confirmation of whether balance operations were included or excluded

Avoid sharing login credentials, account passwords, API keys, or other sensitive access information in a support request.

A practical order of operations

If you need a quick sequence, use this one:

1. Set the same narrow date range on both sides.

2. Confirm whether each side reports deals, orders, positions, or grouped trades.

3. Separate profit from commission, swap, and fees.

4. Identify partial closes or multiple deals connected to one position.

5. Inspect timestamps around the first mismatch.

6. Exclude or separately reconcile balance operations.

7. Verify symbol naming and filters.

8. Build a five-to-ten-record evidence table.

9. Escalate only after documenting the exact comparison method.

This process will not make every view identical. It will, however, turn a vague “the totals do not match” problem into a specific, testable question.

Use your imported history as a review starting point

Once your history is reconciled, the useful next step is not just keeping a total. It is reviewing the completed activity consistently: what happened, how records relate, and what you want to examine in your process.

TradingJournal offers a free file import and structured review tools for traders who want to begin organizing and reviewing their history. Start with a free import when you are ready to work from a clearer record of your closed activity.