Compare a stated entry with one actual fill record

A suggested price and a fill have different origins

A message can state an entry price without showing that any particular person executed there. An execution record can show your fill without proving what was published earlier. Keep those two observations separate before comparing their numbers. The useful result is a pair you can trace back to evidence, not a verdict about a channel.

This worksheet handles one stated price and one supplied fill. It does not combine a position, reconstruct every partial fill, or score a history of messages. The examples are invented for recordkeeping practice. You can use the method with saved notes and existing receipts without opening another order.

Preserve the wording and version of the statement

Record a reference to the original message, the wording relevant to the price, its displayed publication time and when you saved it. If the message was edited, keep the version information you actually observed. Do not turn a later edited price into evidence of what was visible at the earlier time.

Label the stated number by its role: a proposed entry, a limit, a target or a descriptive market quote are not interchangeable. This calculator accepts a single stated entry for comparison. If the source gives a range, keep that range in your notes rather than selecting whichever endpoint makes the later difference look smaller.

Where publication time or edit history cannot be established, leave it unknown. A file’s download time and a screenshot’s capture time are useful observations, but neither automatically establishes when the underlying claim was first published.

Use execution fields for the fill side

Bybit’s trade-history documentation distinguishes orderPrice from execPrice and gives executions their own identifier, quantity and timestamp. That distinction matters: an order’s requested price is not automatically its execution price. Read the exact field definition for the product represented by your record.

Kraken’s trade-history documentation likewise describes trades or fills and shows price, quantity, time and an associated order identifier. A documentation example is only an example; use your own existing record when completing the worksheet. No connection to an exchange account is required here.

Preserve a local receipt reference and the execution ID outside any public copy if they identify private account activity. If the only available evidence is a chart screenshot, label it as a market observation and leave the actual-fill field empty. Similar numbers are not enough to establish ownership of an execution.

Sources: Bybit API Documentation — Get Trade History, Kraken Developers — Get Trades History.

Check that the two prices describe the same thing

Write the full instrument and quote unit before calculating. A spot pair, a perpetual contract and a dated future may share an asset name while representing different products. A USD value and a USDT value also need a documented comparison basis; the worksheet performs no currency conversion.

Use a single actual fill for this pair. If an order has several executions, preserve them individually or calculate a separately documented quantity-weighted price before using another tool. Do not quietly substitute the last execution for the entire order and call it the average.

Keep fees and quantity in the surrounding evidence record when needed, but do not mix them into the price difference below. This calculation has no exit price, complete position quantity or fee model. It cannot establish the outcome of a trade.

Calculate a signed difference without a performance label

The first result is fill price minus stated price. The relative result is that difference divided by stated price, multiplied by 10,000, giving basis points. One basis point is 0.01%. A positive result means the supplied fill number is higher; a negative result means it is lower.

For stated 100.00 and fill 100.25, the price difference is +0.25 in the quote unit and the relative difference is +25 bps. For stated 250.00 and fill 249.50, the results are -0.50 and -20 bps. These examples describe the supplied pair only.

A higher fill is not automatically better or worse without direction, order intent and other context. More fundamentally, a comparison against a published claim is not necessarily a measure of execution slippage. The benchmark’s timing and meaning must be established before assigning that label.

Keep British diary dates clear when records cross midnight

Use readable dates such as 21 October 2026 in a written note, and an explicit timestamp such as 2026-10-21T00:00:02+01:00 in a data column. GOV.UK’s data-format guidance supports machine-readable ISO-style timestamps with explicit offsets; it does not require people to write ordinary prose in that format.

For the hypothetical pair, the statement at 2026-10-20T22:59:58Z appears in London at 23:59:58 on 20 October. The fill at 23:00:02Z appears at 00:00:02 on 21 October. They are four seconds apart, despite their different British diary dates. Retain UTC alongside the local display.

British clocks return on 25 October 2026 according to GOV.UK. The offset in this example must therefore not be copied to every later record. Use the full timestamp and the Europe/London zone for each event. If a source gives only a local hour without its offset, preserve that ambiguity instead of inventing UTC.

Sources: GOV.UK — Formatting dates and times in data, GOV.UK — When do the clocks change?.

An elapsed time is not a delivery measurement

The worksheet subtracts the stated timestamp from the fill timestamp only when both are supplied and valid. Four seconds between those inputs does not prove four seconds of transmission, reading or order-routing delay. Each timestamp must be labelled by what its source measures.

If the fill precedes the statement, keep the negative interval and investigate. Possible explanations include a later note about an existing trade, an edited message or mismatched clocks. None is proved by arithmetic. Keep a chronology flag and a precise question for the missing evidence.

When either source reference is absent, the provenance is incomplete even if both prices calculate successfully. When no actual fill is supplied, the comparison remains unavailable. Neither condition should become a zero difference or a successful execution.

Write a conclusion limited to this pair

A complete note might say: “The supplied message version states 100.00; receipt B records 100.25. Difference +25 bps; the recorded timestamps differ by four seconds. Identity and meaning of the two references were checked separately.” Only include that last sentence if you actually performed that check.

One pair cannot establish a win rate, average result, reliability score or history of a Telegram channel. Keep exclusions and missing records visible if a later project reviews a larger set. The optional publisher link below describes a separate offer; completing this worksheet does not require joining it.

Worked examples

Questions before you use the result

Primary sources and scope

1. Bybit API Documentation — Get Trade HistoryChecked 2026-10-20. Separates orderPrice, execPrice, execution ID, quantity and execution timestamp; used for field meanings only.
2. Kraken Developers — Get Trades HistoryChecked 2026-10-20. Describes trades/fills with price, quantity, time and order identifiers. Documentation examples are not user evidence.
3. GOV.UK — Formatting dates and times in dataChecked 2026-10-20. Machine-readable date-time formats and explicit UTC offsets; guidance scope is government data exchange, not trading compliance.
4. GOV.UK — When do the clocks change?Checked 2026-10-20. UK clocks return on 25 October 2026; BST is one hour ahead before the change.

Prepared from the sources listed above. Examples and calculations explain a method; they do not predict prices or certify an investment. Geographic time references do not establish where a trading service is available. Dated schedules can change: consult the named publisher before relying on a future event.