Manage cost basis calculation in TRES Finance: check status, view/change strategy (FIFO, LIFO, AVG, MAX_GAINS, MAX_LOSSES, FIFO_IMPAIRMENT), trigger recalculation, review financial issues, manage reevaluations/impairments, set bulk fiat prices, configure spec-ID lot disposal rules, view per-asset cost basis results, and export cost basis reports. Trigger this skill whenever the user asks about cost basis, gains/losses, realized gains, unrealized gains, COGS, inventory lots, tax lots, cost basis strategy, reevaluation, impairment, fiat value override, spec-ID rules, financial issues (negative balance, missing fiat), or anything related to how their crypto assets are costed. Also trigger when the user says "calculate cost basis", "what is my cost basis strategy", "show me financial issues", "create a reevaluation", "run cost basis", "change strategy to LIFO", or similar.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Manage cost basis calculation in TRES Finance: check status, view/change strategy (FIFO, LIFO, AVG, MAX_GAINS, MAX_LOSSES, FIFO_IMPAIRMENT), trigger recalculation, review financial issues, manage reevaluations/impairments, set bulk fiat prices, configure spec-ID lot disposal rules, view per-asset cost basis results, and export cost basis reports. Trigger this skill whenever the user asks about cost basis, gains/losses, realized gains, unrealized gains, COGS, inventory lots, tax lots, cost basis strategy, reevaluation, impairment, fiat value override, spec-ID rules, financial issues (negative balance, missing fiat), or anything related to how their crypto assets are costed. Also trigger when the user says "calculate cost basis", "what is my cost basis strategy", "show me financial issues", "create a reevaluation", "run cost basis", "change strategy to LIFO", or similar.
compatibility
Requires TRES Finance MCP connector
TRES Finance — Cost Basis Management
End-to-end skill for managing cost basis calculation, strategy configuration,
reevaluations, financial issue review, and related operations in TRES Finance.
MCP Server
All calls use the user-tres-finance MCP server (the TRES Finance MCP connector).
All variable keys and nested input fields MUST use camelCase (e.g. assetClassId, not asset_class_id).
Step 1 — Authenticate and confirm org
Call get_viewer with no arguments. Confirm the org name with the user if there
is any ambiguity.
Step 2 — Ensure a cost basis strategy is defined (gate before calculation)
Before any cost basis calculation can run, the organization must have a strategy
defined. This step is a — run it automatically whenever the
user wants to calculate cost basis (Section D), or when they first ask for help
with cost basis.
prerequisite gate
Fetch the current strategy using the query in Section B.
If defaultStrategy is returned (any valid value like FIFO, LIFO, etc.),
the strategy is already set — skip ahead and inform the user:
"Your cost basis strategy is set to [STRATEGY]. Proceeding."
If no strategy is configured (the query returns null or an error), present
the user with all available methods and ask them to choose:
"Before calculating cost basis, you need to choose a costing method.
Here are the available strategies:
FIFO — First-in, first-out. Earliest acquired lots are disposed first. The most common method.
LIFO — Last-in, first-out. Most recently acquired lots are disposed first.
FIFO_IMPAIRMENT — FIFO with impairment accounting support (for orgs using impairment write-downs).
Which method would you like to use?"
Once the user picks a strategy, set it using the mutation in Section C
(with an empty strategyPeriods array if they just want a single default).
Then proceed to the requested operation (typically Section D — trigger calculation).
This gate ensures no calculation runs without an explicit strategy choice.
Step 3 — Run cost basis calculation
After confirming strategy, check the current calculation status (Section A) and
offer to run or re-run the calculation:
Fetch status using the query in Section A.
If status is IN_PROGRESS, inform the user it's already running and offer
to wait:
"Cost basis calculation is currently in progress (started at [time]). Would you like me to wait for it to finish?"
If status is DONE, show when it last ran and ask:
"Cost basis was last calculated on [lastFinishedAt]. Would you like to
recalculate now, or view the existing results?"
If status is ITEM_NOT_FOUND, this org has never calculated — proceed
directly to trigger.
When the user confirms (or on first-time run), trigger the calculation
using the mutation in Section D.
Poll status every ~10 seconds until status = "DONE".
Once done, automatically proceed to show results per asset (Section E)
and financial issues (Section F).
This step ensures the user always has fresh results and understands the
calculation state before viewing data.
Available operations
Based on the user's request, follow the appropriate section below.
Many users will come in with a general question like "help me with cost basis" —
in that case, run Steps 1–3 (authenticate, check strategy, run calculation),
then show results.
A. Check cost basis calculation status
Use this when the user asks whether cost basis is running, done, or when it last ran.
query CostBasisGetStatus {
costBasisGetStatus {
status
firstStartedAt
lastFinishedAt
updatedAt
}}
status values: DONE, IN_PROGRESS, ITEM_NOT_FOUND (never calculated).
Report the status clearly. If IN_PROGRESS, let the user know it's still running
and they should wait. If DONE, report when it last finished.
B. View current cost basis strategy
Fetches the default strategy and any date-specific strategy overrides.
If updating to a period-based config, first fetch the existing periods (Section B)
so you don't accidentally overwrite them — the mutation replaces ALL periods.
After a successful strategy change, ask the user if they want to trigger a
cost basis recalculation (Section D).
D. Trigger cost basis calculation
Prerequisite: Before triggering, run Step 2 (strategy gate) to ensure a
strategy is defined. If none is set, the user must choose one first.
Starts (or restarts) the cost basis calculation. Can target specific assets or
recalculate everything.
To recalculate everything: pass assetClassIds: null (or omit it).
To recalculate specific assets: pass an array of asset class IDs, e.g. [42, 88].
To find asset class IDs, query assetBalance or assetClass first:
query AssetClasses($limit: Int){
assetClass(limit:$limit) {
results { id symbol name }}}
After triggering — poll until completion
After a successful trigger (success: true), poll the status using the
query from Section A. The calculation typically takes 10–60 seconds for small
orgs but can take minutes for large ones.
1. Trigger → success: true
2. Poll costBasisGetStatus every ~10 seconds
3. When status = "DONE" → proceed to show results (Section E)
Do NOT present results or offer report downloads until status is DONE.
While IN_PROGRESS, show a brief wait message to the user.
E. View cost basis results per asset
Shows the cost basis breakdown per asset-wallet pair — total cost, realized
gains, COGS, running inventory, and more.
Important: Use the assetBalance query (NOT organizationBalance). The
assetBalance query returns per-wallet asset rows, each with a nested
costBasis field from FifoCostBasisQuery.
Paginate if totalCount > 50 — increment offset by 50 and fetch again until
all results are retrieved.
Key fields explained
assetFifoCostBasis — The total cost basis for this asset-wallet pair (top-level shortcut).
totalProfitLoss — Total realized P&L (top-level shortcut).
costBasis — Nested object with full detail (null if not calculated):
costBasis / totalCost — Total cost of current inventory.
totalRealizedGains — Net realized gains/losses.
totalShortTermRealizedGains / totalLongTermRealizedGains — Split by holding period.
cogs — Cost of goods sold for disposals.
proceeds — Total proceeds from disposals.
totalRunningInventoryQuantity — Current inventory quantity.
runningBalance — Running token balance.
Presenting results — the full picture
After fetching all pages, split the results into two groups:
Group 1 — Assets with cost basis data (costBasis is not null):
Present as a table sorted by absolute realized P&L descending, with columns:
Asset, Wallet, Holdings, Cost Basis ($), Realized P&L ($).
Use color coding: green/+ for gains, red/- for losses.
Group 2 — Assets without cost basis (costBasis is null AND calculatedBalance != 0):
These are assets where cost basis was NOT calculated — usually because of missing
fiat values, no transactions, or unverified/spam assets. Present them separately
under a clear heading like:
Assets without cost basis data:
The following assets have balances but no cost basis calculated. This typically
means they have missing fiat prices that need to be resolved before cost basis
can be computed.
Show: Asset, Wallet, Holdings, and a note about likely cause (spam token, NFT,
missing fiat, etc.).
Always show both groups so the user sees the complete picture. If Group 2
contains any non-trivial assets (not spam/virtual), also run the financial
issues query (Section F) filtered to HIGH severity to check for missing_fiat
issues, and report them alongside.
When missing fiat issues are found, automatically look up historical prices
using the pricing query (Section G.1) for each affected asset at the transaction
timestamp. Present the looked-up prices to the user and offer to apply them
using bulk fiat edit (Section G.2).
Recommended: Generate an HTML dashboard file with styled tables for both
groups plus a financial issues summary. Save it to the outputs folder and
share the link with the user.
Use standard number formatting:
Fiat values >= $1M: "$X.XXXM", >= $1K: "$X.XXK", else "$X.XX"
Positive gains: "+" prefix, negative: "-" prefix
F. View financial issues
Financial issues are problems detected during cost basis calculation — negative
balances, missing fiat values, circular transfers, etc.
query FinancialIssues($limit: Int, $offset: Int, $severity: String){
financialIssue(limit:$limit, offset:$offset, severity:$severity) {
totalCount
results {
id
type
severity
message
balanceImpact
assetClass {
id
symbol
name
}
assetClassId
internalAccount {
name
}
internalAccountId
tx {
identifier
timestamp
}
subTx {
id
amount
}}}}
Filter options
Important: Filter values must be lowercase — the API uses DB-stored values.
severity: "high", "medium", "low"
Do NOT filter by type directly in the query — instead, fetch all issues
and filter/group in the presentation. The type filter uses internal DB values
that may not match the display names.
Actual issue types returned
The type field returns lowercase strings like:
missing_fiat — Sub-transaction has no fiat price. Affects cost basis accuracy.
Can be resolved with bulk fiat edit (Section G).
negative_balance — Inventory went below zero (more sold than acquired). Usually
means missing inflow transactions.
result_was_rounded — Minor rounding occurred during calculation. Low severity.
ignored — Sub-transaction was skipped (e.g. internal transfer to same account).
no_opposite_tx — Internal transfer has no matching counterpart.
circular_internal_sbxs — Circular dependency in internal transfer matching.
Group results by severity and present HIGH issues first. The most common pattern
is a handful of HIGH severity missing_fiat issues plus many LOW severity
result_was_rounded issues — summarize the LOW ones as a count rather than
listing each individually.
G. Fix missing fiat values
This is a two-part flow: first look up historical prices, then apply them.
G.1 — Look up historical token prices
Use the TRES MCP pricing queries to fetch historical prices for tokens with
missing fiat values. This uses the platform's pricing engine which aggregates
from CoinGecko, CoinMarketCap, exchanges, and other sources.
The prices field returns a JSON object like {"usd": 0.015}.
How to use this in the missing fiat flow:
From the financial issues (Section F), collect each missing_fiat issue's
assetClass.id and tx.timestamp.
Call getBatchStatelessPricingByAssetClass with one request per issue.
Present the results to the user:
"I found historical prices for the missing fiat transactions:
CHSB on 2018-06-18: $0.015 per token
CHSB on 2020-11-24: $0.085 per token
vBUSD on 2020-11-27: $0.021 per token
Would you like me to apply these prices?"
If the user confirms, apply them using Section G.2 (bulk fiat edit).
Pricing sources to try: If the default source returns empty, try these
apiSource values in order: COINMARKETCAP, CRYPTO_COMPARE, REGULAR_FLOW,
COINBASE, BINANCE, KRAKEN. Pass the apiSource field in the request:
Important: The pricing query returns prices: {} (empty object) when no
price data is available — this is common for obscure, delisted, or DeFi-wrapped
tokens. Try multiple sources before giving up.
If ALL pricing sources return empty for a token, inform the user and ask them
to provide a manual price. Suggest approximate values if you know the token
(e.g. BUSD-pegged tokens ≈ $1.00).
G.2 — Bulk fiat value edit
Override fiat unit prices for an asset across a date range. Useful for fixing
MISSING_FIAT issues or correcting OTC prices.
Always confirm parameters with the user before executing — this writes
fiat values to potentially many sub-transactions.
updateExistingFiat: false (default) — only fills in missing fiat values.
updateExistingFiat: true — overwrites all fiat values in the range.
To find the assetClassId, query assetClass by symbol first.
When applying prices from G.1, use the looked-up unit price and set the date
range tightly around the transaction date (same day for startDate and endDate)
to avoid overwriting prices on other transactions.
After bulk fiat edits, suggest the user trigger a cost basis recalculation (Section D).
H. Reevaluations and impairments
Reevaluations adjust the fair market value (FMV) of inventory lots at a specific
point in time. Impairments are a special case where the FMV drops below cost.
H.1 — List reevaluations
query GetReevaluations($limit: Int, $offset: Int, $assetClassId_In: [ID]){
reevaluation(limit:$limit,
offset:$offset,
assetClassId_In:$assetClassId_In,
ordering:"-timestamp"){
totalCount
results {
id
timestamp
unitPrice
currency
isImpairment
assetClass {
id
symbol
}
appliedCostBasis {
id
totalCost
revaluedCostAdjustment
internalAccount {
id
name
}}}}}
mutation DeleteReevaluation($reevaluationId: Int!){
deleteReevaluation(reevaluationId:$reevaluationId) {
status
}}
Deleting also removes the associated manual transaction from the ledger.
I. Spec-ID rules (specific lot disposal)
Spec-ID rules let the user specify exactly which acquisition lot to use when
disposing of an asset — overriding the default strategy (e.g. FIFO) for
specific transactions.
I.1 — View spec-ID rules
query CostBasisSpecIdRules($limit: Int,
$offset: Int,
$outflowSubTransaction_In: [String]){
costBasisSpecIdRule(limit:$limit,
offset:$offset,
outflowSubTransaction_In:$outflowSubTransaction_In){
totalCount
results {
id
outflowSubTransaction {
id
amount
timestamp
asset { symbol }
belongsTo { name }}
disposedLotSubTransaction {
id
amount
timestamp
}
amountToDispose
priority
}}}
I.2 — Set spec-ID rules
Always confirm with the user before executing. This replaces all existing
rules for the given outflow sub-transaction.
By default, TRES trims old inventory lots to reduce storage. For specific
transactions where the user needs the complete inventory queue visible, toggle
full inventory saving.
{"exportName":"Cost Basis Stack Per Asset - April 2024","exportFormat":"COST_BASIS_STACK_PER_ASSET","currency":"usd","outputFormat":"XLSX"}
Then poll the report query until status = "DONE" and provide the download link:
query Reports($limit: Int, $offset: Int){
report(limit:$limit, offset:$offset, ordering:"-created_at"){
totalCount
results {
id
name
status
downloadUrl
createdAt
}}}
Critical: Do NOT present the download link while status is IN_PROGRESS —
the file has not been written to S3 yet and the link will return a NoSuchKey
error. Poll every ~10 seconds until status = "DONE", then present the
downloadUrl to the user.
Guardrails
Confirm before writes: Always confirm with the user before executing any
mutation (strategy change, reevaluation, spec-ID rules, bulk fiat edit, trigger calc).
Recalculation reminder: After any configuration change (strategy, reevaluation,
spec-ID, fiat edit), remind the user that cost basis needs to be recalculated for
changes to take effect.
Locked periods: If a mutation fails with a "locked period" error, inform the
user that the timestamp falls within a locked accounting period and they may need
to unlock it first.
Status check before trigger: Before triggering a recalculation, check the
current status — if already IN_PROGRESS, let the user know it's still running.
Limitations — not available via MCP
The following cost basis features exist in the backend but are NOT exposed through
the MCP GraphQL API, so this skill cannot perform them:
Per-wallet reallocation flow — The two-phase reallocation process
(unified inventory -> per-wallet split) is an internal backend operation
triggered by org settings, not directly callable via API.
Viewing raw inventory queue details — The assetRunningQueueFifo field
is available on FifoCostBasisQuery but returns large JSON blobs. The queue
data is best viewed through the TRES dashboard or via exported reports
(COST_BASIS_STACK_PER_ACCOUNT / COST_BASIS_STACK_PER_ASSET).
Short position / loan queue management — Short position tracking (loan
queue) is configured at the org-settings level and computed automatically.
There is no direct API to view or manipulate the loan queue.
Cost basis calculation internals — The actual calculation engine
(CostBasisCalculator, CostBasisManager) runs server-side. We can trigger it
and read results, but cannot control the internal calculation flow, caching,
or S3 queue persistence.
Internal transfer cost basis mapping — How cost basis is carried over
between wallets in internal transfers is automatic and not configurable
per-transaction via the API.
For any of these, direct the user to the TRES Finance dashboard or suggest
exporting the relevant cost basis report for offline analysis.
