NFT Holdings Reconciliation: Reconciling Things That Aren't Fungible

This spoke takes the reconciliation pillar into a place where its core question changes shape. Reconciling a fungible token asks one thing: does the recorded quantity tie to the chain? NFTs break that model, because each is a distinct item, so reconciliation becomes a per-token inventory existence-and-ownership check rather than a balance. The focus here is the identifier-level discipline NFT holdings need, distinct from token reconciliation. Because the sufficiency and the related valuation are controls and auditor questions, this stays hedged.

In short

• Fungible reconciliation is a quantity-and-value check; NFT reconciliation is a per-item existence-and-ownership inventory check, since each token is distinct.
• The unit of reconciliation is the specific NFT identified by contract plus token ID at the wallet, checked against on-chain state, not an aggregate count (the right 12, not just 12).
• Reconciliation is not valuation: existence and ownership are separate from the often difficult NFT valuation judgement, and both must hold.
• Transfers, sales, and burns must be detected per token, because a missed single-NFT transfer is not absorbed into a balance.
• Defensibility comes from an identifier-level register, a defined cadence, acquisitions, transfers, sales, and burns captured, and the break workflow.
• These are the entity's controls; sufficiency and valuation are the auditor's. Not accounting advice.

Why not like fungible tokens

Fungible-token reconciliation is a quantity-and-value check: does the recorded quantity tie to the chain. NFTs are non-fungible, each token a distinct item with its own identifier, so reconciliation is closer to an inventory check. Does the entity still hold each specific NFT it records, at the specific contract and token ID, and does it not hold NFTs it failed to record? This is per-item existence and ownership, not a single balance (compare auditing existence and ownership).

The unit of reconciliation

Generally it is the specific NFT identified by contract address plus token ID at the holding wallet, reconciled against on-chain state, not an aggregate count. An aggregate "we hold 12 NFTs" that ties by number can still be wrong if it is the wrong 12. Reconciliation operates at the individual-token level, which is why a complete, identifier-level register of NFT holdings is the basis (see NFT cost basis and disposal tracking).

Reconciliation vs valuation

These are separate questions. Reconciliation establishes existence and ownership of each specific NFT; valuation, often hard for thin or illiquid NFT markets, is a distinct accounting judgement. A reconciled NFT inventory does not imply a correct carrying value, and a valuation cannot be relied on if the underlying holdings are not reconciled. Both must hold, and valuation remains an auditor judgement.

Transfers and burns

An NFT can be transferred out, sold, or burned, so reconciliation must detect that the specific token is no longer held and that the disposal or burn is recorded, and conversely that received NFTs are recorded. Because each is unique, a missed transfer of one NFT is not absorbed into a balance the way a fungible amount might be. It is a specific item, present or not, which makes per-item completeness important.

Building a defensible NFT register

A defensible NFT holdings register has these components, which are the foundation for reconciliation:

Identifier fields. For each NFT: contract address (EVM) or mint address (Solana) or inscription number (Bitcoin Ordinals), token ID (EVM), and holding wallet address. These three fields together are the unique key that identifies a specific NFT held at a specific wallet. Without all three, the register cannot be reconciled against on-chain state with certainty.

Acquisition record. Date, transaction hash, acquisition cost (price + gas + fees), acquisition type (purchase / mint / airdrop / reward). Acquisition cost is the cost-basis record for tax and the carrying-value basis for accounting.

Disposal or transfer record. Date, transaction hash, event type (sale / transfer / burn), sale proceeds or transfer-to address. A sale generates a gain/loss computation; a transfer between the entity's own wallets is a movement with no gain/loss; a burn is a derecognition.

Cadence. Reconciliation should run on a defined cadence — monthly at minimum for corporate holders, more frequently for active NFT traders or marketplaces. The cadence defines the maximum period in which an unrecorded event can go undetected.

Break investigation. When the register does not match on-chain state — the entity's records show an NFT it no longer holds, or the chain shows an NFT the entity received but did not record — the break investigation applies the same workflow as fungible-token reconciliation breaks: identify the on-chain event, determine whether it was a missed recording or a genuine unexplained movement, and resolve with a correcting entry and documentation.

Cross-chain NFT reconciliation complexity

For entities holding NFTs across EVM, Solana, and Bitcoin Ordinals, the reconciliation procedure must be run separately per chain because the identity model differs (see cross-chain NFT portfolio). Aggregating into a single register for presentation is appropriate, but the on-chain check must use the right method per chain — you cannot verify a Solana cNFT by querying an EVM contract, and you cannot verify a Bitcoin Ordinal by querying Solana.

A multi-chain NFT register typically uses a chain identifier as an additional field alongside the native identifier (contract+tokenId for EVM, mint for Solana, inscription number for Ordinals) to ensure the on-chain verification query is directed to the right chain and the right API.

Common errors in NFT reconciliation practice

Counting NFTs rather than identifying them. An entity that records "we received 5 NFTs from collection X" without recording the individual token IDs cannot reconcile at the item level. If one of those 5 is subsequently transferred out, the count drops to 4, but the entity cannot verify which specific token was transferred or whether the accounting matches.

Treating ERC-1155 tokens as ERC-721 without quantity fields. An ERC-1155 holding of token ID 42 at quantity 100 is not the same as 100 distinct ERC-721 tokens. The ERC-1155 register needs a quantity field, and reconciliation checks both the token ID and the quantity against the chain's balance.

Not detecting stealth transfers. Some wallets receive NFTs from unknown addresses (often NSFW content or scam airdrops). These appear in the on-chain NFT balance but are not in the entity's records. The reconciliation will flag them as "on-chain but not in records" breaks, which should be investigated and — if they are unwanted/zero-value airdrops — documented as received and immediately derecognised.

Practical guidance

1. Reconcile per token (contract plus token ID plus wallet), not an aggregate count.
2. Maintain an identifier-level register of all NFT holdings.
3. Keep reconciliation separate from valuation; both must hold.
4. Detect transfers, sales, and burns per token, because no balance absorbs a miss.
5. Run the standard break workflow at a defined cadence.
6. Sufficiency and valuation are the auditor's, being entity- and framework-specific. Not accounting advice.

Configuring a tool for NFT reconciliation

Tools such as Cryptio and Bitwave can hold an identifier-level NFT register and reconcile each token against on-chain state, including transfers and burns. The tool reconciles per token; the sufficiency and the valuation or classification remain auditor judgements. Worth confirming:

• it keys the register on contract address (or mint address, or inscription number) plus token ID plus wallet, so each holding is identified, not just counted;
• it reconciles per token against the correct chain's method, since a Solana cNFT cannot be verified by querying an EVM contract;
• it surfaces on-chain NFTs that are not in your records (including stealth or scam airdrops) as breaks rather than ignoring them.

A count that ties by number is not a reconciliation; the per-token identity is what makes it one.

Where Wag3s fits

Wag3s Ledger maintains an identifier-level NFT register (contract plus token ID plus wallet), and reconciles each against on-chain state with acquisitions, transfers, sales, and burns captured under a break workflow on an audit trail. The sufficiency and the NFT valuation or classification stay auditor-confirmed; Ledger establishes existence and ownership to support those judgements rather than make them. See the Ledger product page.

Further reading

• NFT Accounting (Corporate)
• NFT Cost Basis and Disposal Tracking
• NFT Portfolio Valuation
• Auditing Crypto Existence & Ownership
• Reconciliation Break Investigation (Crypto)
• Wallet-to-Ledger Reconciliation Process

Notes on sources

NFT reconciliation is an operational inventory exercise rather than something governed by an external standard, so it has no canonical authority to cite. The discipline follows from the nature of non-fungible tokens: each is a distinct contract-and-token-ID item, so reconciliation is a per-item existence-and-ownership check against on-chain state rather than a single balance, and a missed single-NFT transfer is not absorbed into a quantity. Reconciliation establishes existence and ownership; NFT valuation, often difficult in thin or illiquid markets, is a separate accounting judgement. Both must hold, and the sufficiency and the valuation or classification remain judgements for the entity's accountant and auditor. This is not accounting advice.