Find the order ID before counting rows. Order history describes an instruction and its state; trade history describes execution. One instruction can match more than once, and an interface may combine those matches into one displayed record. A different row count does not, by itself, mean a missing order.
Three records, three questions
Open orders help answer what may still execute. Order history helps answer what happened to the instruction. Trade records help answer how much actually changed hands. A cancelled instruction can have no fills, or it can have fills followed by cancellation of its remainder. Those are different outcomes even when the final status looks similar.
Binance’s spot activity explanation separates these views and notes that matching activity may be aggregated in the interface. The individual events below are a teaching ledger, not a promise about the number of rows your app will display.
Keep the comparison inside one instruction
Record the full pair, side, order ID and submission time, including the time zone. ABC/USDT and ABC/BTC use different quote assets. A buy and a sell should not be added merely because both mention ABC. Check the product too: spot records cannot be used as a substitute for another product’s order history.
Imagine order A requests three units. A first match executes 0.8 and a second executes 0.7; the rest is then cancelled. There is one original instruction, 1.5 units executed and 1.5 units that did not execute. A screen might show individual fills or a combined amount. Never add the original three units to the fills: the requested quantity is not an extra purchase.
Reconcile quantity before value
Write requested quantity, cumulative execution and the difference on separate lines. The difference tells you what has not traded, but status tells you whether it can still trade. An open remainder and a terminated remainder require different decisions.
For an original example, let those fills occur at 100 and 102 quote units. Their pre-fee values are 80 and 71.4. Total value is 151.4, and the weighted price is 151.4 divided by 1.5, about 100.9333. Averaging the two prices directly would ignore their different quantities. This calculation helps identify columns; it is not a complete profit or balance reconciliation.
Fees and movements unrelated to this instruction can affect wallet balances. Add the fills for this order first, then check fees and transfers separately. Where displayed numbers are rounded, retain the more precise source values before adding them rather than changing a quantity to force a match.
An empty list needs a filter check
Check the date range, time zone, pair, direction and status filters. A current-pair-only option can hide the relevant instruction. Older activity may require another supported date window or export method. Use the limits stated by the current interface rather than assuming a fixed historical range.
If recent activity is still unclear, query it again through the official interface and preserve the submission details. Placing a replacement is not a way to test whether the first order existed. Without a stable order identifier, nearby times and similar amounts are clues, not proof that two records belong together.
Give each order its own row
Before writing that note, make a small reconciliation sheet with one row per original instruction. Include the identifier, pair, side, original quantity, executed quantity, final or current status, and the time you checked it. Keep fill-level detail separately when your source provides it. This prevents a combined display row from being mistaken for a missing individual event.
Consider two nearby instructions: A requests three ABC and B requests two ABC. A executes 1.5 before cancellation; B executes two. The account has 3.5 units of gross purchases from these instructions, but neither order should be marked as executed for 3.5. The account-level total answers a different question. First reconcile A to its own execution and B to its own execution; only then combine them for a broader purpose.
Check both dates when an order crosses midnight
A similar problem occurs when records cross midnight. An instruction may be submitted just before midnight and fill just afterwards. Filtering only the submission date in one view and only the execution date in another can hide half the story. Widen the date range around the event and retain the time-zone labels. Do not shift dates merely to make a spreadsheet look consistent: document the conversion if you deliberately normalize timestamps.
Exports deserve a quick boundary check before they become evidence. Read the first and last recorded times, the product name and any stated filters. A successful download does not establish that the file contains every requested event. An export covering buys only cannot disprove a sale, and a file from another account cannot settle a spot-order question. Treat filenames as labels supplied by a tool, not as guarantees about the contents.
If an identifier is absent, preserve the uncertainty. You might label a row “possible match by pair, side and time; order ID not confirmed.” That is a useful intermediate result. It lets support or a later export settle the relationship without requiring you to undo an earlier confident assertion. Never invent an ID or attach the closest-looking trade simply because its amount makes the totals match.
An earlier screenshot and a later query can both be correct
Separate the state at inspection from the state at submission. An order open in an earlier screenshot can legitimately be filled in a later query. Keep both timestamps instead of declaring the records contradictory. The contradiction worth investigating is between records that purport to describe the same instruction at a compatible stage and still cannot explain its quantity. This distinction helps you ask a precise support question while retaining an honest account of what remains unknown.
“Order A: buy three, executed 1.5, remainder cancelled, checked at this time” is more useful than “it failed.” Keep supporting files privately. Passwords and verification secrets have no role in matching an order with its fills. For an active remainder, continue with partial execution; for a cancellation still awaiting confirmation, read cancelling before replacing.