Orders, Deals and Positions: Reconcile Requests with Exposure

Keep orders, deals and positions separate

An order is an instruction to transact under stated conditions. A deal or execution record documents quantity that actually traded. A position describes resulting exposure under the platform and account model. MetaTrader’s basic trading principles use these distinctions and explain why one order can produce several deals.

Platforms use different labels, identifiers and lifecycle states. Map the meaning of each record before comparing two exports. An order ID, deal ID and position ID can be related without being identical. Counting all messages as separate trades can overstate activity; counting only orders can hide partial fills and rejections.

Reconstruct a complete 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. Add only rows linked to the same instruction and expressed in the same quantity unit.

Hypothetical order 42 reconciled from two deals

Record	ID	Requested	Executed	Remaining	Price	Position after
Order	42	1.00 lot	—	1.00 lot	—	—
Deal	71	—	0.40 lot	0.60 lot	1.1001	0.40 lot long
Deal	72	—	0.60 lot	0.00 lot	1.1003	1.00 lot long
Reconciled result	—	1.00 lot	1.00 lot	0.00 lot	1.10022 weighted	1.00 lot long

Executed quantity is the sum of deal quantities: 0.40 + 0.60 = 1.00 lot. The weighted fill is ((0.40 × 1.1001) + (0.60 × 1.1003)) ÷ 1.00 = 1.10022. Two deals do not establish two independent 1.00-lot positions.

Leave an incomplete outcome unresolved

If only deal 71 is present, executed quantity is 0.40 lot and the unresolved remainder is 0.60 lot. The ledger must not invent whether that remainder is working, canceled, expired, rejected or waiting for another record.

The same example before the second deal is known

Evidence present	Executed	Unresolved remainder	Safe conclusion
Order 42 and deal 71	0.40 lot	0.60 lot	At least 0.40 lot executed; inspect later order, deal and position records before assigning a terminal state.

A duplicate export row must not be counted twice. Mixed lots, units, contracts or shares must not be added until a documented conversion exists. Amendments and replacement orders also need their parent identifiers and native states before a remaining quantity can be reconstructed.

Account mode changes the position result

In a simplified netting example, an existing 1.00-lot long followed by an executed 0.30-lot sell leaves a signed net position of +0.70 lot. A hedging account may retain separate long and short positions, depending on the request and platform behavior. The executed sell quantity alone does not establish which accounting result occurred.

Read the account mode and actual position records rather than guessing from an order label. A close request, reversal or partial exit should be reconciled through its deals and resulting inventory. Historical deal quantity is not current open quantity.

Do not turn acceptance or timeout into a fill decision

MetaQuotes explains that a successful OrderSend return does not itself prove execution. Response codes and later trade records supply more evidence. OnTradeTransaction documentation also shows that one request can generate several events whose arrival priority is not guaranteed.

A network timeout means the caller lacks a response; it does not prove rejection. Reconcile the request ID, broker order and deal history, current positions and any supported copier logs before deciding what happened. Blind repetition can create duplicate exposure if the original instruction actually succeeded.

Match source and follower evidence in a fixed sequence

1. Name the intended change. Record the source action, exact symbol, side, quantity unit, requested quantity and applicable order constraints.
2. Link stable identifiers. Keep source event, router correlation, destination request, order, deal and position identifiers in separate columns.
3. Preserve native states. Store the platform’s original status and code before assigning a conceptual normalized state.
4. Sum confirmed executions. Reconcile partial fills by linked identifier and quantity unit; flag duplicates before arithmetic.
5. Read resulting exposure. Compare actual positions under the account’s netting or hedging model.
6. Classify the exception. Use a factual category such as symbol mismatch, quantity difference, rejection, timeout/unknown, partial fill, unmatched close or remaining exposure.
7. Resolve through the supported workflow. Preserve evidence and contact support for an account-specific unresolved incident; the worksheet does not issue or repeat orders.

TradeCopier activity logs provide the product context for operational events. The generic ledger below does not claim to reproduce every native log or broker export field.

Use the generic CSV ledger safely

Download the blank reconciliation ledger or download the sanitized worked example. Version generic-copy-reconciliation-v1 stores one observed event or record per row. It is a generic manual worksheet, not a TradeCopier import format, automated recovery tool or broker instruction.

Core ledger fields and rules

Field group	What to record	Rule
Group and sequence	Version, copy-group ID and observed event sequence	Use pseudonymous IDs; sequence records without assuming that different clocks are synchronized.
Time	Event time and clock source	Use RFC 3339 with Z or an explicit offset. Leave unknown precision blank.
Owner and account	Source, router or follower; alias; platform; account mode	Never place a login, credential, token or personal identifier in the file.
Record and event	Order, deal, position snapshot or system event; open, modify, close or cancel	Keep record type separate from the business action.
Identifiers	Native record, parent and correlation IDs	Do not assume IDs from different systems are interchangeable.
Instrument and quantity	Exact symbol, units, side, requested, executed and remaining quantity	Do not aggregate mixed units or contract specifications.
State	Native wording/code and optional normalized state	Native evidence controls; normalized labels are a comparison aid.
Position evidence	Quantity before and after	Use actual snapshots; do not manufacture a net position for a hedging account.
Review	Evidence source/reference, reconciled flag and factual notes	Use yes, no or unknown and state what remains missing.

The file follows the field-order contract shown on this page. RFC 4180 describes common CSV conventions, including double quotes for fields containing commas, quotes or line breaks. RFC 3339 supplies the timestamp format. Treat cells that begin with spreadsheet formula characters as unsafe user input; do not paste credentials or untrusted exports into a spreadsheet without reviewing them.

Keep reconciliation separate from performance review

This ledger explains whether related records support the intended exposure change. Use the slippage cost calculator for a defined reference-price comparison, volume-step rounding for quantity grids and the trading journal workflow for strategy notes, P&L and review. The execution-quality study methodology defines the additional clock, sampling and outcome rules required for a publishable benchmark.