Orders, Deals and Positions: Reconcile Requests with Exposure

Keep the three record types separate

An order expresses an instruction to transact under specified conditions. A deal records an executed transaction or fill. A position describes remaining exposure under the platform and account model. MetaTrader explains these basic trading concepts, including how account modes affect position accounting.

Some platforms use different vocabulary, so map meanings before comparing logs. The order identifier, execution identifier and position identifier can link related records without being identical. Counting all messages as trades can overstate both activity and exposure.

Reconstruct a partial-fill example

Assume hypothetical order 42 requests a buy of 1.00 lot. Deal 71 fills 0.40 lot at 1.1001 and deal 72 fills 0.60 lot at 1.1003. Executed quantity totals 1.00 lot. The quantity-weighted price is (0.40 × 1.1001 + 0.60 × 1.1003) ÷ 1.00 = 1.10022.

There are two deals, but they do not establish two independent 1.00-lot positions. If the second deal had not occurred, only 0.40 lot would be executed; the status of the remaining 0.60 would need checking. It could remain pending, be canceled or have another state under the order's rules.

Account mode changes the position interpretation

Under a simple netting example, an existing 1.00-lot long followed by a 0.30-lot sell reduces net long exposure to 0.70 lot. A hedging account may instead retain separate long and short positions, depending on the request and platform behavior. The executed sell quantity alone does not establish which accounting outcome occurred.

Read the position record and account mode rather than guessing from an order label. A close request, reversal or partial exit should be reconciled through actual deals and resulting inventory. The gross sum of historical deal quantities is not the same as current open quantity.

Handle uncertain request outcomes

MetaQuotes warns that a successful OrderSend return is not itself proof of execution. Response codes and subsequent trade records supply additional state. Similarly, a network timeout can leave the caller uncertain without proving that the broker rejected the request.

Before retrying an uncertain action, reconcile its identifier, broker response and current exposure through the appropriate supported workflow. Blind repetition can create a duplicate order if the first instruction actually succeeded. This reference explains the accounting issue rather than providing executable order-submission code.

Create a useful comparison record

Preserve source and follower account identifiers, instrument mapping, request and execution times, requested and filled quantities, prices, status codes and linked record IDs. Redact credentials and unnecessary personal data before sharing logs. When assessing copy behavior, compare the intended exposure change with the follower's resulting inventory. A mismatch in raw event counts may be normal partial-fill bookkeeping, while equal counts can still conceal different quantities or prices.