Tracking investment Cost Basis (ACB)
Overview
Portfolio Slicer calculates investment cost basis using an average-cost style approach.
For each sale-related transaction, the workbook uses previous transactions for the same symbol and account to estimate the cost basis that should be associated with the shares being sold.
If cost basis tracking matters for your workflow, this is one of the most important areas of the model to understand.
How Cost Basis Changes
Different transaction types affect cost basis differently.
Transactions That Usually Increase Cost Basis
Examples include:
BuyBuyTADRIPNotionalDistribSymbolTransferIn
Transactions That Usually Decrease Cost Basis
Examples include:
ReturnOfCapitalSellSellTASymbolTransferOutSymbolTransferOutAsSale
Transactions That Usually Do Not Change Total Cost Basis
A Split changes units held but does not directly change total cost basis.
Other transaction types, such as regular dividends, normally do not affect cost basis directly.
How Sales Are Handled
When Portfolio Slicer calculates cost basis impact for sales, it effectively needs to know:
- how many units were held before the sale
- what the accumulated cost basis was at that point
- how much of that accumulated value should be assigned to the units being sold
The exact model logic is internal to the workbook, but the practical point is that prior transactions and transaction order matter.
Where to Inspect Cost Basis Behavior
The best report for understanding cost basis behavior is the TransInfo report, because it shows how transactions affect the model over time.
If cost basis values look surprising, this is one of the first places to review.
Cost Basis Override
Portfolio Slicer includes a CostBasisOverride field in the Transactions table.
This is useful when:
- you transfer positions between accounts and need to preserve historical cost basis
- you want to use your own externally calculated cost basis values
- you encounter one of the known built-in calculation limitations
Using overrides gives you a practical fallback when the default calculation is not sufficient for a specific case.
When Overrides Are Especially Useful
Overrides are most often useful in more complex cases, for example:
- partial transfers between accounts
- repeated partial sales of the same position
- historical data imported from another system where broker cost basis is already known
- corrections after return-of-capital or other special adjustments
Exchange Rate Overrides
If you track cost basis across currencies, exchange rates can matter a great deal.
Portfolio Slicer also supports reporting exchange-rate override fields. These can be useful when:
- your financial institution provides an exact transaction exchange rate
- you need to use a tax-relevant average exchange rate instead of a day-end rate
- your workbook setup does not fully reflect the exchange-rate behavior you want
Known Limitation
Portfolio Slicer has a known limitation in complex partial-sale scenarios.
In some cases, when the same symbol is partially sold multiple times between complete disposals, the built-in calculation can hit a model limitation and return an obviously invalid large value instead.
That is the reason the documentation recommends using CostBasisOverride when necessary.
See also:
Practical Advice
If cost basis is especially important for taxes or formal reporting:
- review the transaction history carefully
- pay close attention to return of capital and notional distributions
- use overrides where necessary
- validate unusual cases rather than assuming every scenario is handled automatically
- compare important cases with broker statements or your own tax records