---
title: "FIX Execution Reports: Separate Order State from Executed Quantity"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/fix-execution-report-purpose-order-state-fill-quantity"
last-updated: "2026-10-20"
---

# FIX Execution Reports: Separate Order State from Executed Quantity

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

A FIX Execution Report can acknowledge an order, report a trade or communicate another lifecycle event. It is not automatically a distinct fill. Evaluate the report's purpose, the order's current state and the quantity meanings separately. In the fictional sequence below, five complete reports describe two trades totaling 50 units; cancellation closes the other 50 without reversing those executions.

## Read report purpose, current state and quantity separately

A financial data supplier may describe a feed as execution reports and then quote its row count as the number of fills. Before using those rows as AI labels or quantity features, establish what one row represents. A lifecycle report, a trade event and an order's accumulated execution are different units of information.

The reference here is FIX Trading Community's Order State Changes, FIX Latest as of EP284, November 2023. This is a named historical snapshot. Its introduction separates ExecType(150), why a report was sent, from OrdStatus(39), the order's state after the event.

The same introduction names OrderQty(38) as total executable quantity, CumQty(14) as executed quantity, LastQty(32) as last-execution quantity and LeavesQty(151) as quantity still available for execution. CumQty describes accumulation; LastQty describes an execution amount. These definitions do not prescribe the presence, omission or zero value of every field on every actual message.

References: [FIX1](https://www.fixtrading.org/wp-content/uploads/download-manager-files/FIX-Latest-as-of-EP284-Order-State-Changes.pdf)

## IND-FIX-01: five reports for one 100-unit order

IND-FIX-01 is an original fictional case. One order concerns 100 constant abstract executable units. Exactly five complete reports are supplied, in the order shown, and exactly two ordinary trades occur. There are no missing or duplicate reports, corrections or trade busts, replacements, multiday carry, cash-quantity complications or other executions.

OrderQty is 100 throughout. All quantities in the table use the same abstract unit; none denotes money, a real instrument, price or elapsed time. The rows annotate report meanings. They are neither valid FIX messages nor instructions for entering or canceling orders.

On nontrade rows, no last execution quantity is supplied in this illustration. “Not supplied” below does not mean a mandatory zero field or a claim about an actual message's field requirements.

IND-FIX-01: conceptual report sequence; OrderQty(38) remains 100 abstract units
| Report and purpose | Current OrdStatus(39) | CumQty(14) | LeavesQty(151) | LastQty(32) supplied | Source |
| --- | --- | --- | --- | --- | --- |
| 1 — New-order acknowledgement | New | 0 | 100 | Not supplied | Planning analysis |
| 2 — Trade | Partially Filled | 20 | 80 | 20 | Planning analysis |
| 3 — Pending-cancel report | Pending Cancel | 20 | 80 | Not supplied | Planning analysis |
| 4 — Trade while cancel pending | Pending Cancel | 50 | 50 | 30 | Planning analysis |
| 5 — Confirmed cancellation of remainder | Canceled | 50 | 0 | Not supplied | Planning analysis |
Original fictional quantities and a simplified sequence, not a reproduction of the official B.1.b matrix. The official scenario supports the purpose/state distinction; these five supplied reports stipulate the complete activity for this example.

## Report 4 adds a trade while the status stays Pending Cancel

The reference's precedence section gives Pending Cancel priority over Partially Filled when both apply. Pending Cancel acknowledges a pending request; it does not confirm cancellation. Scenario B.1.b explicitly includes a Trade report whose OrdStatus remains Pending Cancel, followed by a canceled order retaining executed quantity.

Apply that distinction to IND-FIX-01. Report 3 leaves the accumulated execution at 20. Report 4 adds 30, bringing it to 50, while the current status stays Pending Cancel. An unchanged status has accompanied a new execution.

If a supplier recognizes trades only when OrdStatus says Partially Filled, it would recognize report 2 but miss report 4 in this case. Conversely, treating every Pending Cancel row as a trade would wrongly include report 3. The two reports share a current state while describing different events. Their report purposes and quantities preserve that difference.

References: [FIX1](https://www.fixtrading.org/wp-content/uploads/download-manager-files/FIX-Latest-as-of-EP284-Order-State-Changes.pdf)

## The final cancellation closes 50 unexecuted units

At report 5, the fictional order still has 50 executed units, and no quantity remains open for further execution. The cancellation closes the unexecuted 50. It neither supplies another trade nor undoes either earlier trade.

Calling the final order canceled is accurate. Using that label to say nothing executed would discard the supplied history. Inferring that all 100 executed because LeavesQty became zero would produce the opposite error.

The first four rows satisfy 100 = CumQty + LeavesQty. The final row has 100 as its OrderQty but 50 + 0 across those other fields. The unexecuted remainder has been closed by cancellation. OrderQty = CumQty + LeavesQty therefore cannot be imposed as an unconditional invariant across terminal states. In particular, subtracting final LeavesQty from the original 100 would mislabel the canceled remainder as executed quantity.

## Five reports, two trades and 50 executed units

The report count is five. The ordinary trade count is two: reports 2 and 4. Their supplied execution amounts are 20 and 30, so executed quantity is 20 + 30 = 50 abstract units. The final CumQty of 50 agrees with that stipulated activity.

Adding CumQty down the five rows gives 0 + 20 + 20 + 50 + 50 = 140. That sum repeatedly counts previously accumulated state. Report 3 repeats the 20 already executed, report 4's 50 includes the earlier 20 alongside its new 30, and report 5 repeats the 50 already executed. Those repetitions communicate order history without creating more volume.

A supplier claiming five fills or 100 filled cannot support either claim from this sequence. A supplier claiming 140 executed units has added snapshots as though they were independent increments. These errors arise even though every report is supplied once and no activity is missing.

The 20 + 30 calculation is valid under this case's explicit assumptions. It is not a universal instruction to sum LastQty across a real feed. Delivery identity, corrections, trade cancellations, session boundaries and applicable business rules need separate evidence before any broader reconstruction method can be justified.

## Compare what reaches the intended AI input

Suppose Offer A supplies five rows labeled fills and marks the order fully executed when its open quantity reaches zero. Offer B retains the distinction between report purpose, current status and quantity type. It explains the two trade events, the final 50 executed units and the 50 unexecuted units closed by cancellation. These are fictional offers for the same stipulated case.

B supports this interpretation. A's labels do not. The difference establishes whether the supplied meanings answer this task; it establishes no return, latency or model-quality result.

Define the input boundary before comparing a real offer. Is the consumer receiving original reports, a supplier's normalized event rows, or one final row per order? Have the supplier show how the offered representation retains the event purpose, current state and relevant quantities, and where it combines or omits them. A column named quantity leaves its cumulative-versus-event meaning unanswered.

For an event-level label, reports 3 and 4 must remain distinguishable even though both carry Pending Cancel. For an order-level executed-quantity feature, the final canceled status must remain distinguishable from its executed amount of 50. A model trained on a mislabeled “canceled means zero execution” target would be learning the supplier's imposed label in this case, rather than the stipulated execution outcome.

Ask the supplier to explain those exact rows and the final 50/50 split using the fields it actually supplies. If it provides only status, leave executed quantity unresolved. If it provides only a cumulative amount, it has not thereby identified which individual rows represent trades. More rows do not replace the missing meaning.

For an actual instrument, establish the declared quantity unit, instrument identity and applicable FIX version, venue and business conventions. Do not substitute abstract units for that evidence or assume a venue implements this historical scenario unchanged.

The related counter guide addresses cumulative-counter resets, the retry-key guide addresses repeated request effects, and the OPC UA guide addresses which observations survive delivery stages. This example stipulates complete delivery; its remaining problem is the meaning of the delivered reports.

## Connect a separate equipment project to physical deployment

If the wider project also requires equipment receiving, rack integration, agreed hardware QA, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service can discuss those physical stages as a defined package. Use the service and project inquiry below with a nonconfidential equipment, site and physical handoff outline.

This feed analysis is educational. Financial data supply, FIX integration, trading software and AI feature engineering belong with the separately appointed providers; the physical equipment inquiry concerns installation scope, requirements and availability.

References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment)

## Primary sources

- [FIX1 — FIX Trading Community — Order State Changes, FIX Latest as of EP284, November 2023](https://www.fixtrading.org/wp-content/uploads/download-manager-files/FIX-Latest-as-of-EP284-Order-State-Changes.pdf). Checked 2026-10-20. Introduction and quantity definitions on PDF page 4; status precedence on page 5; B.1.b on page 13. Supports purpose, state and quantity distinctions in this named historical snapshot. The fictional five-report case uses its own quantities and simplified activity.
- [L1 — Leviathan Systems — Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Defines receiving, rack integration, agreed hardware QA, installation and cabling scope for a separately scoped physical equipment project.

## Related Leviathan resources

- [Cumulative request counters: resets before aggregation](/articles/inference-cumulative-counter-resets-before-aggregation)
- [Retry keys: request identities and resulting effects](/articles/api-idempotency-key-scope-request-effects)
- [Industrial data feeds: sampling and retained changes](/articles/industrial-ai-opcua-sampling-queue-publishing)
- [Complete Physical Deployment service](/services/turnkey-gpu-deployment)
- [Discuss a separate physical equipment project](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Ffix-execution-report-purpose-order-state-fill-quantity)

## Have a separate physical equipment project?

Share a nonconfidential equipment, site and physical handoff outline to discuss installation scope, requirements and availability.

[Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/fix-execution-report-purpose-order-state-fill-quantity)