Execution report (order status message)
An execution report is the message a broker or exchange sends back for every change in an order's life: accepted, partially filled, filled, modified, cancelled or rejected. It carries the order's identifiers, its status, the quantity filled so far and the quantity left. A trading screen's working orders and positions are only as accurate as the stream of these reports it has received.
Senzoukria · Glossary · Updated September 2026
What a report tells you
- Which order: the client's own reference and the broker's or exchange's order id.
- What happened: new, partial fill, fill, replaced, cancelled, rejected, expired.
- How much: the quantity of this fill, the cumulative quantity filled and the quantity still open.
- At what price: the price of this fill and, often, the average so far.
- Why, for a rejection: a reason text or code.
Worked example
A limit order to buy 5 contracts produces a sequence of reports. Accepted: filled 0, open 5. Partial fill of 2: filled 2, open 3, and 2 + 3 = 5. Fill of the last 3: filled 5, open 0, status filled. If the trader cancels after the first fill instead, the last report reads cancelled with filled 2 and open 0; the position is 2 contracts, not 5 and not 0.
In FIX terms
In the FIX vocabulary the message is the Execution Report (35=8). Its order status field (39) distinguishes new (0), partially filled (1), filled (2), cancelled (4) and rejected (8), and quantity fields carry the cumulative and remaining amounts. Other protocols use their own message names for the same content.
In Senzoukria
On Rithmic, order events arrive as order notifications whose status is free text with many variants, such as 'Order received by exch gateway', 'Modified' or 'Order sent to exchange'. The application therefore treats an order as working unless its status says it is finished (complete, cancelled, canceled, rejected, expired, filled or done), checks for in-flight wording such as 'pending' or 'partial' first so that 'cancel pending' is not read as cancelled, and logs once each status it keeps alive without recognising. The reasoning is written in its source: for a read-only mirror, showing a stale stop can be corrected, while hiding a live one cannot. When the account feed starts, it also asks for the orders already working, so that orders placed earlier or from another platform are included, and a flatten can only confirm success after that replay has actually been received.
Common mistakes
- Reading an acknowledgement as a fill.
- Taking the order quantity as the position after a partial fill and a cancel.
- Trusting a screen that stopped receiving reports during a disconnect.
Related
In the same section
- Exhaustion
- Execution algorithms
- Expectancy
- Exchange time zone
- Expected move
- Holiday schedule
- Expected shortfall
- EFRP
This page in other languages
Frequently asked questions
- Is an execution report the same as a fill confirmation?
- A fill confirmation is one kind of execution report. The same message type also reports acceptance, modification, cancellation and rejection, so reading the status field is what tells them apart.
- Why can a platform show an order the broker already cancelled?
- Because its display is built from the reports it received. If a cancellation report was missed or used wording the platform did not recognise, the order can linger on screen; the broker's own order list remains the reference.