Direct answer

What ongoing trading cost tracking actually involves

Ongoing trading cost tracking is not glancing at each calculation as it happens; it is recording your estimated conditions, your actual execution and charges, any condition changes and the reasons for variance under one rule for units and dates, then recalculating periodically. You keep the all-in cost you estimated before entry and the realized cost you pulled from the execution history and statements as separate entries, then match them at month end and sort the variance by cause. When spread or swap/funding conditions change, you log the before, after, effective date, money impact and source. That accumulation is what trading cost tracking really is.

In other words, alongside a one-off calculator you need a way to accumulate records and compare them. How each cost component is derived — spread, commission, swap, break-even and so on — is covered systematically in the Trading Cost Calculation Guide. This article picks up after that: the stage where you take the costs you have derived and, assuming conditions will move, keep and audit them in an ongoing ledger. Below, a single consistent fictional example — a position whose round-trip cost of about 2,070 JPY moves to 2,560 JPY after a condition change — carries us through the ledger columns, the change log, moving-average auditing, monthly reconciliation and finally the storage design.

Three layers

Separate the one-off calculation, in-session comparison and ongoing ledger

Trading cost work splits into three layers with different purposes. Conflating them either leaves you trying to run ongoing management with a tool that cannot save, or forces heavy record-keeping on a reader for whom a one-off answer is enough. Start by separating the roles.

• One-off calculation (a single check): for the current trade, produce the per-side or round-trip cost, break-even pips/price, per-pip value, an approximate swap and so on. This is the free calculator’s territory.
• In-session comparison (analysis within a session): line the same trade up across several conditions and dig into spread sensitivity, cost by holding days and change scenarios. Nothing is saved. Comparing brokers and account types (how to compare broker and account trading costs) and reading swap movement (swap and overnight financing cost) live in this layer.
• Ongoing ledger (the auditing routine): accumulate estimated and realized figures, keep condition changes as a time series and match them monthly. Saving, history and reports are assumed, and this is Premium’s territory.

The diagram below is a fictional mapping showing that even for the same “trading cost,” the unit of work — single, session or ongoing — differs by layer. It distinguishes the layers with labels and the unit of work, not color alone.

What matters here is the order. First confirm a single case for free; when you want to compare several conditions, move to Pro; and only readers who reach “I want to record and audit this” move on to the ongoing ledger (Premium). If you have no need to save, Pro is enough. The ledger design that follows is practical work aimed at readers who have stepped into that ongoing layer.

Ledger design

Minimum ledger fields, and separating estimated from realized

The foundation of ongoing management is a trading cost ledger with one row per trade. Too few columns and you cannot trace the cause of a variance; too many and you will not keep it up. The minimum you want is below. Include units in the column names so there is no hesitation when recording.

• Timestamp (execution date/time) / broker/account label / symbol / size (lot)
• Spread (pips) / commission (JPY, state per-side or round-trip) / slippage (pips or JPY)
• Swap/funding (JPY/day) / dividend adjustment (JPY) / rollover (JPY) / currency conversion (JPY markup)
• Estimated or realized flag / source (fee schedule, execution-history URL, etc.) / notes

The most important thing is to hold estimated and realized in separate rows (or columns). Estimated is the all-in cost you assumed before the trade; realized is the actual amount pulled from the execution history and statements. Mix them and the variance disappears. How to count per-side versus round-trip and how to turn a fixed fee into a total cost are handled in the trading commission calculator guide, and the definition of the commission column follows it. The table below places one trade from the consistent example side by side as estimated and realized — a fictional ledger row.

Even from this one row, the reason realized exceeded estimated by 690 JPY breaks down into “spread widened +400,” “slippage +200” and “swap increase +90.” Accumulate not one trade but a month of them and this becomes the raw material for the monthly reconciliation later. For how units and holding-cost shape change by asset class (XAUUSD, stock indices, crypto CFDs and so on), use the asset-class cost guide as a reference for the symbol definitions in your ledger.

Log the changes

Cost-condition change ledger: keep before/after with an effective date

Spread, commission and swap conditions move with a broker’s fee revision or an account-type change. Rather than burying that inside the trade ledger, break it out as a cost-condition change ledger. Per change, keep the before, after, effective date, money/pips impact, affected instruments and source URL on one row. The diagram below shows the example’s spread moving from 1.2 pips to 1.6 pips on 06-15, drawn as a step that rises on the effective date — a fictional example.

As ledger rows it looks like the following. Keeping the impact both “per trade” and “monthly” speeds up the later matching. For the source URL, write somewhere you can verify afterward, such as the broker’s official fee page or a notice (the URLs in the table below are fictional record examples).

Changes like these ripple into break-even pips and the cost ratio too. If the spread rises by 0.4 pips, break-even moves by that much. How condition changes feed into break-even and the friction score is covered in the break-even and cost ratio guide. The change ledger exists to keep that “knock-on” traceable afterward, complete with an effective date.

Read it with averages

Swap/funding change ledger: detect it descriptively with 7- and 30-day averages

Swap/funding moves day to day. Following the single value alone means you miss the flow as it slowly shrinks, zeroes out and eventually reverses sign (from a credit to a charge). So log the daily swap as a time series and show a 7-day average and a 30-day average alongside it. The aim is to descriptively detect consecutive declines, zeroing and sign reversal — not to forecast future swap or turn it into a trading signal. The fictional chart below shows a +50 JPY per night credit fading over roughly a month, with the 7-day average crossing below zero first.

In the ledger, keep the daily value, the two averages and a note. The 7-day average reacts quickly to change; the 30-day average lags behind. From their relationship you read descriptively whether this is a temporary wobble or a sustained decline. The table below extracts the representative points from the chart above — a fictional record.

A sign reversal is the turning point where a holding cost that was a credit becomes a charge, and it is worth keeping the effective date and source in the ledger. That said, this is a summary of past records; it does not guarantee the next day’s value. The swap calculation itself and the treatment of triple-days are left to the swap and overnight financing cost guide; here we concentrate on keeping the change as a time series and auditing it. If you want to tidy up the record format itself, the financial templates hub is also a useful reference.

Use separate ledgers

Why dividend adjustments, rollover and conversion belong in separate ledgers

Some costs look close to swap/funding but arise from different mechanisms on different dates. Adding them into the daily swap column makes it impossible to sort variance by cause at month end. Keep these three in their own ledgers.

• Index-CFD dividend adjustment: arises around the ex-dividend dates of the constituents, with long positions typically receiving and short positions typically paying. Because it ties to the ex-date rather than the calendar day, record it in a dividend-adjustment ledger holding the ex-date, index, direction, adjustment amount and source.
• Rollover (contract-month roll): on a futures-based CFD, the price-difference adjustment when rolling contract months lands in a lump on a specific date along the rollover calendar. Separate from daily funding, manage it in a rollover ledger (rollover planner) holding the contract month, roll date, adjustment amount and source.
• Currency conversion (conversion markup): when the P&L currency differs from the account currency, the gap between the applied rate and a reference rate (the markup) is a burden. Because conversion is a stage separate from the cost calculation, split it into a currency-conversion ledger holding the applied rate, reference rate, direction and amount, so you do not double-count it into break-even or the cost ratio.

The reason to separate them is simple: to work out, at month end, “what was this month’s variance driven by.” Had you mixed the dividend adjustment into the swap column, you could not tell afterward whether it was a swap sign reversal or a one-time adjustment on a dividend ex-date. For currency conversion, always record the rate direction and units in words. For instance, “reference 150.00 against applied 149.70, a 0.30 JPY gap, an illustrative markup burden of about 20,000 JPY on 100,000 units” — adding the direction in words, not just numbers, is the trick to a clean audit. Differences in holding cost by asset class are organized in the asset-class cost guide.

Match it monthly

Monthly reconciliation: the estimate to realized to variance to update loop

The purpose of accumulating a ledger is the month-end match — the reconciliation. On a single sheet you gather the estimated all-in cost, realized all-in cost, variance, cause category and the templates that need updating, then feed it into next month’s estimate. This cycle — estimate to realized to variance to condition update to (next month’s) estimate — is the heart of ongoing management. The diagram below shows that audit loop.

Building the month with the consistent example gives the following. Against an estimated 41,400 JPY over 20 trades, realized is 52,600 JPY. The variance of +11,200 JPY is sorted into change-driven (spread, swap) and execution-driven (slippage).

The point is not to aim for zero variance. Markets and fills move, so variance will always appear. The goal is to keep the variance explainable as change-driven, execution-driven or record-gap, and to update next month’s estimate template. Running this whole routine with saving, history and reports is what Premium’s territory covers.

Mini learning aid

Cost-change impact mini-audit

The mini-audit below takes the before and after of a condition change and shows the per-trade, monthly, annualized and break-even differences, plus a one-row ledger preview. It makes no pass/fail or “favorable/adverse” judgment. The calculation runs entirely in your browser, and inputs are neither sent nor saved anywhere. Saving, encryption and export are not performed here; move to Premium when you need them. First, so it reads even with JavaScript disabled, here is a static calculation table at the default values.

This audit is a simplified teaching version of the actual trade cost calculator and its ledgers. The per-trade cost is approximated as “spread x value per pip + commission + holding cost x holding days,” and tax, execution slippage, dividend adjustment, rollover and currency conversion are excluded. If the P&L currency differs from the account currency, a separate conversion is required. It performs no saving, encryption or CSV/PDF export to a ledger. For the full set of inputs including contract specifications and the saving features, confirm on SG Group’s free Trade Cost Calculator and the plans page.

Storage design

Local storage, encrypted workspaces and backup health

For an ongoing ledger, where you store it shapes the quality of the routine. SG Group’s plans are described as local-first, with the explanation that calculation inputs, templates, history and asset data are not sent to or stored on SG Group servers. You avoid entrusting account details or trade history to a third-party server, but you need to understand that the responsibility for storage shifts to your own device.

• Local vs server storage: server storage allows “ask support to reissue,” but local storage can be lost when the device fails or is lost. That is exactly why export/import and a backup-health check are prerequisites.
• Encrypted workspaces and passphrases: with an encrypted workspace, losing the passphrase may mean the contents cannot be restored. That is the flip side of its strength, and safekeeping the passphrase becomes central to the routine.
• Export/import and backup health: export regularly to take a backup and confirm it is in a restorable state (backup health). A backup serves a different purpose from a CSV/PDF report.
• Sharing reports: with CSV/PDF/print/amount-hidden reports, it is safer to keep personal and account information out when sharing. An amount-hidden report suits cases where you want to share only the structure with the figures redacted.

Because these storage locations, encryption methods and scope can change, confirm the current service page and privacy documents before use. Once you reach the “accumulate and audit” stage of a ledger, a design that does not lose or leak data matters as much as the correctness of the calculation.

Check it free

Checking with the free calculator, and where Pro and Premium fit

Before you start ongoing management, first turn your current conditions into numbers. The free Trade Cost Calculator lets you confirm, from your input conditions, the per-side and round-trip trading cost, a break-even estimate including spread, commission and swap/funding, break-even pips/price, per-pip value, the cost ratio, the friction score and daily-to-annual swap checks. Results also support amount-hidden sharing and add-to-home-screen. Because price and specifications can change, they are not fixed in this copy; confirm the current scope on the plans page.

If you only need to check current conditions once, the free version is enough. When you reach the stage of lining the same trade up across several conditions, or digging into spread sensitivity and cost by holding days, Pro’s in-session analysis comes into view; and only when you reach “I want to accumulate estimated and realized and match them monthly” or “I want to audit condition changes, dividend adjustments, rollover and conversion in a ledger” do Premium’s saving, ledgers and reports become necessary. Holding to the rule that “if a one-off comparison is enough, stop at Pro” is the trick to avoiding over-engineering. Other English articles can be browsed by purpose from the article library. Because feature names, scope and pricing can change, confirm the latest on the current service and plans pages before use.

Avoid

Common mistakes and how to avoid them

Failures in ongoing management cluster at the record-design stage. If any of these ring true, that is where to start your review.

• Mixing estimated and realized: overwriting the assumed value and the actual amount in the same column, so the variance disappears and its cause cannot be traced.
• Burying condition changes in trade rows: keeping no effective date or source, so you cannot reproduce “when did what change” afterward.
• Watching only the single swap value: taking no moving average and missing the flow of consecutive decline, zeroing and sign reversal.
• Summing dividend, rollover and conversion into swap: mixing items with different dates and mechanisms, which breaks the monthly cause categories.
• Double-counting currency conversion: adding the conversion markup into the cost ratio and break-even as well, counting the burden twice.
• Aiming for zero variance: treating the variance that market moves inevitably produce as an anomaly, and losing sight of the real goal of updating templates.
• Not taking backups: never exporting a locally stored ledger, and losing every record to a device failure or a forgotten passphrase.

Summary

Summary: the answer to the main question and your next step

Ongoing trading cost tracking is the routine of recording estimated conditions, actual execution, condition changes and variance reasons in the same units and dates, then recalculating monthly. Hold estimated and realized separately in the minimum ledger fields, keep cost-condition changes with before/after, effective date, money impact and source, and detect consecutive decline, zeroing and sign reversal in swap/funding descriptively with 7- and 30-day averages. Because dividend adjustments, rollover and currency conversion differ in date and mechanism, keep them in separate ledgers, and sort variance by cause in the monthly reconciliation. In the fictional example, a condition change moved the per-trade cost from 2,070 JPY to 2,560 JPY, letting us break out a monthly difference of +9,800 JPY and a monthly variance against realized of +11,200 JPY. The goal is explainable causes, not zero variance.

In practice: (1) fix the ledger columns and units, (2) accumulate estimated and realized separately, (3) keep condition changes with an effective date, (4) audit swap with moving averages, (5) match monthly and update templates, and (6) protect local storage with export and backup health — run it in that order and you will not lose sight of cost even as conditions move. Start by turning your current conditions into numbers for free, and consider Premium once you actually need to save. If you do not need persistence, Pro is enough.

Related

Related reading

If you want to settle the all-in cost comparison across several accounts first, see how to compare broker and account trading costs; if you want to tidy up your record format, see the financial templates hub.