Keep the order boundary before calculating an average
An order can be executed in several parts at different prices. A screen may display one average while an export contains several execution rows. This worksheet checks whether those rows belong to the same stated order before calculating their quantity-weighted price. It also compares the observed quantity with the request and a separately supplied filled total, so a plausible average cannot hide missing coverage.
This is a review of supplied executions, not a simulation of how an order might consume an order book. It does not average an entire position, match earlier purchases to later sales, calculate FIFO cost, or estimate profit. The useful output is a bounded reconciliation for one exact order, available before the optional link to this site’s separate offer.
Order IDs and fill IDs answer different questions
Kraken’s trades-history documentation distinguishes a transaction ID for each partial execution from the order ID shared by executions belonging to that order. It describes the pair as base and quote, volume in base units and price in quote currency per base unit. These field definitions illustrate why grouping by an order and avoiding duplicate fills are separate steps. They do not authenticate any record entered here.
Use the exact order, product and side, and preserve fill IDs as text. If a duplicate fill ID appears, stop and inspect the two source rows rather than counting both or keeping the latest automatically. A different order ID cannot be brought into the average merely because its instrument and price look similar. Scope discrepancies remain visible and withhold aggregation.
Sources: Kraken — Trades History FAQ.
Weight by executed quantity, not by the number of rows
For each supplied fill, multiply its base quantity by its CAD price. Add those products, then divide by the total base quantity. The result is the average CAD price per supplied base unit. Counting rows equally would give a small fill the same influence as a large one and answer a different question.
For the fictional rows,3×100=300 CAD,2×102=204 CAD and 1×99=99 CAD. The total is 603 CAD for 6 units, so the weighted price is 100.5 CAD per unit. The simple average of 100,102 and 99 is 100.3333…; it does not represent these unequal quantities. No unobserved remainder is priced at the last fill.
| Fill | Base quantity | CAD per base | Quantity × price |
|---|---|---|---|
| DEMO-F 1 | 3 | 100 | 300 CAD |
| DEMO-F 2 | 2 | 102 | 204 CAD |
| DEMO-F 3 | 1 | 99 | 99 CAD |
| Total | 6 | VWAP 100.5 | 603 CAD |
A quantity match is useful, but it is not a complete-order receipt
The requested quantity and the separately reported filled quantity are optional inputs with different meanings. Requested minus observed tells you how much of the stated request is not represented by these rows. Reported minus observed compares your excerpt with another supplied quantity figure. Neither input is fetched from a venue, and a matching figure is not independent verification.
In the example,10 minus 6 leaves 4 units. Those 4 might still be open, might have been cancelled, or might reflect an amended request or missing records. This worksheet cannot decide. It keeps current order state and quantity still available to fill unknown. If observed quantity exceeds the request, the negative difference is shown as an inconsistency rather than clipped to zero.
Reported fee value and actual deduction must stay separate
Kraken’s field guidance says its trade-history fee value can be expressed in quote currency even when the actual account deduction uses the base asset; the ledger is needed to establish the deducted asset. A reported CAD equivalent is therefore not automatically a CAD balance movement. The worksheet groups known fees by both their stated basis and asset. It never adds those different groups together.
The default has 0.3 CAD labelled as an actual ledger deduction,0.2 CAD labelled only as a reported quote equivalent, and an incomplete third fee. The first two are separate subtotals, not a verified 0.5 CAD charge. An explicit zero with an asset and evidence basis is different from a blank. Fees stay outside the displayed gross VWAP, and no all-in price or net base receipt is inferred.
Sources: Kraken — Trades History FAQ.
An order can cross the Toronto diary boundary
The first fictional fill at 03:59 UTC on 20 October 2026 displays as 23:59 on 19 October in Toronto; later fills at 04:01 and 04:02 UTC belong to 20 October locally. The selected diary day is 20 October, so the first row is flagged. It still belongs to the same supplied order and remains in the weighted average. A daily file split must not silently redefine the order boundary.
The NRC summer map identifies Eastern Daylight Time as UTC−4. Its broader Canadian time-zone page is under review and warns that some information will change from 1 November 2026. This guide’s worked offset is a dated October example, not a promise about every Canadian region or future rule. Preserve each original known-offset timestamp and check the local date your journal actually uses.
Sources: National Research Council Canada — Summer Time Zones map, NRC — Time zones and daylight saving time.
Missing evidence should stop the right conclusion
Change one row’s quote from CAD to USD. The tool will preserve the row and flag its scope, but withhold the combined price, quantity and fee subtotals. It will not assume a one-to-one exchange rate, quietly omit the row or create an average from the apparently valid subset. A missing fill reference has the same effect because the output is meant to represent the stated excerpt coherently.
A blank requested quantity is less severe: it removes the requested-minus-observed comparison while leaving the supplied-fill average available. A blank reported filled quantity likewise leaves coverage against that report unknown. These cases are not zero-size orders. Separating scope failure from an optional comparison makes the reason for an unavailable field clear.
Exact decimal sums still have a limited reporting meaning
The tool parses prices and quantities into fixed-scale integers, multiplies and sums them exactly, and rounds only the displayed gross CAD and weighted price to eight decimal places. The weighted average therefore does not reuse a previously rounded gross value. Its extra digits are a presentation choice, not evidence that a venue reported prices to that accuracy.
Price times quantity can differ from a venue’s separately booked cost because of the source’s rounding, fee treatment or other definitions. This worksheet does not claim to reconcile a cash ledger or settlement amount. Keep the venue’s original fields available and compare them in a separate properly scoped review. Never change your source export to make its total fit this model.
Keep evidence and exclusions with the result
Review unique IDs, row scope, quantity coverage, fees and diary-date flags before the average itself. The CSV preserves the source identifiers, times, units, row issues and each fee basis. It also states which account outcomes remain unknown. A later report can then explain why an amount changed without rewriting the earlier capture.
All arithmetic and downloads are local; no account credentials, exchange connection or file upload are required. Editing a field invalidates stale results and exports. Manual copying remains available if clipboard access fails. Without JavaScript, the complete method and worked fill table remain readable. No order is placed, changed or cancelled.
Worked examples
Example 1
The fictional fills are 3 units at 100 CAD, 2 at 102 CAD and 1 at 99 CAD. Their gross sum is 603 CAD for 6 units, giving 100.50000000 CAD per unit. A requested 10 leaves an arithmetic difference of 4; it does not prove 4 remain open. The separate reported 6 matches the supplied quantity. Fees show 0.3 CAD as an actual-deduction subtotal and 0.2 CAD as a reported-equivalent subtotal, plus one unknown fee. One fill falls on the preceding Toronto date.
Inspect example inputs
{
"order_id": "DEMO-ORDER-001",
"product": "DEMO-ASSET/CAD",
"base": "DEMO-ASSET",
"side": "buy",
"requested_quantity": "10",
"reported_filled_quantity": "6",
"as_of": "2026-10-20T04:05:00Z",
"journal_date": "2026-10-20",
"rows": "fill_id|order_id|product|base|quote|side|quantity|price|filled_at|reference|fee_asset|fee_amount|fee_basis\nDEMO-F1|DEMO-ORDER-001|DEMO-ASSET/CAD|DEMO-ASSET|CAD|buy|3|100|2026-10-20T03:59:00Z|DEMO fill evidence1|CAD|0.3|ledger_actual\nDEMO-F2|DEMO-ORDER-001|DEMO-ASSET/CAD|DEMO-ASSET|CAD|buy|2|102|2026-10-20T04:01:00Z|DEMO fill evidence2|CAD|0.2|reported_quote_equivalent\nDEMO-F3|DEMO-ORDER-001|DEMO-ASSET/CAD|DEMO-ASSET|CAD|buy|1|99|2026-10-20T04:02:00Z|DEMO fill evidence3|||unknown"
}Questions about the method
Is the four-unit difference an instruction to trade?
No. It is requested quantity minus the supplied fills, not a confirmed open remainder.
Why not add the fee subtotal to VWAP?
Its asset and evidence basis may differ, and some fees can be missing. This report keeps gross execution arithmetic separate.
Does matching the reported filled quantity prove completeness?
No. It only shows agreement between supplied figures; the account and the report were not independently checked.
Primary sources and scope
- Kraken — Trades History FAQChecked 2026-10-20. Partial execution ID versus shared order ID, base/quote units and fee-value versus actual-deduction distinction. No country eligibility or live account assertion.
- National Research Council Canada — Summer Time Zones mapChecked 2026-10-20. Historical summer-map EDT offset UTC−4; used with the dated October Toronto example only.
- NRC — Time zones and daylight saving timeChecked 2026-10-20. Observed notice says the page is under review and some information changes from 1 November 2026. No blanket future Canadian DST rule is asserted.
Examples explain a method. They do not predict prices or establish where a trading service is available. Check the named source before relying on future schedules.