ERC-20 Tokens for Accountants: Chain, Contract, Balance

A plain ERC-20 token looks simple in a wallet: a ticker, a quantity, and a market value. That presentation is useful for a user, but it is not enough for accounting. ERC-20 tokens for accountants begin one level below the ticker, with the network the token lives on and the contract that keeps the balance.

Four questions decide the record for ERC-20 tokens for accountants: what identifies the asset, what a balance is made of, how that balance can move, and what pays for the movement. Each one is worked through below against contracts read live on chain.

ERC-20 tokens for accountants: the problem starts before the journal entry

For accounting purposes, a token position has to be identified by at least two technical facts:

1. the blockchain network, normally represented by a chain ID
2. the token contract address on that network

The ticker is not an identifier. Two unrelated contracts can both call themselves ABC, USDC, LINK, or anything else. The Ethereum protocol does not reserve names or symbols.

LINK is its own demonstration of the point. Read on 9 September 2026 against each network's own public node, each read pinned to the block carrying the same timestamp on that network, four contracts on four networks all return the name ChainLink Token, the symbol LINK, and 18 decimals, and all four report a different total supply.

Four contracts, one ticker, four different supplies, and one of the four has an owner function that the other three do not. The issuer's own documentation describes the mechanism that creates the position: the LINK token "was originally issued on the Ethereum blockchain and can be securely transferred cross-chain" using a bridging protocol. A portfolio system that groups those four holdings under one symbol has combined four different assets with four different administrative regimes into one line.

That is why chain ID is part of the asset identifier and not a routing detail.

Ethereum natively tracks ETH. It does not natively track LINK, BAT, USDC, or any other ERC-20 token. Instead, each token is implemented by a smart contract, a smart contract being a program stored at its own address on the network, which runs only when a transaction calls it and which keeps its own records in the network's state. That contract maintains the balances.

For a plain fungible token, the basic model is:

Ethereum protocol
    |
    | executes calls
    v
Token contract
    |
    | stores balances for addresses
    v
address A -> 1,250 units
address B ->   400 units
address C ->     0 units

The network validates the execution of the contract. The token's own contract defines what a balance means and how it can change.

This is why the first accounting question is not "what is the ticker?" It is "what contract, on what chain, and what rights or rules does that contract create?"

What ERC-20 actually standardises

ERC-20 is an interface standard. The original standard, EIP-20, specifies a common set of functions and events so wallets, exchanges, and other applications can interact with fungible tokens in a consistent way.

The functions the standard specifies are:

• totalSupply()
• balanceOf(address)
• transfer(address,uint256)
• transferFrom(address,address,uint256)
• approve(address,uint256)
• allowance(address,address)

The standard also defines Transfer and Approval events.

Three further methods carry the token's descriptive metadata, and they are the ones an accountant will reach for first: name(), symbol(), and decimals(). EIP-20 marks all three OPTIONAL, attaching the identical caution to each: "OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present." The scaling factor that turns a raw integer into a reportable quantity is, by the standard's own terms, an optional courtesy. The consequences of that are worked through below.

What the standard does not tell an accountant is equally important. ERC-20 is silent on:

• what the token legally represents
• whether anyone owes the holder anything
• whether the token is redeemable
• whether an administrator can mint, freeze, seize, or destroy balances
• whether the contract can be upgraded
• whether balances can change without ordinary transfers
• whether another asset sits behind the token
• whether the token is an asset, a liability, a security, a claim, a receipt, or merely a governance instrument

Supply is the clearest case. The whole of what EIP-20 says about totalSupply() is that it "Returns the total token supply". There is no mint function in the standard and no prohibition on one, so whether a token's supply can grow is a property of the individual contract and is discoverable only by reading that contract.

The phrase "ERC-20 token" therefore describes a technical interface, not an accounting classification.

The reference case: a plain fungible token

A plain fungible token is useful as a baseline because its economics are intentionally narrow.

For this series, a token belongs in the plain fungible category only when the holder's balance behaves like an ordinary transferable quantity and no additional economic feature changes the accounting analysis. In practical terms, the token should not have a redemption right, embedded yield, rebasing mechanism, claim on another asset, or similar feature that changes what the holder owns.

LINK is a useful reference example because its Ethereum contract behaves like a conventional fungible token rather than a receipt or redemption claim: a fixed supply of exactly 1,000,000,000 units, 18 decimals, no owner function, and no proxy, all read from the contract at block 25,942,271 on 9 September 2026.

It is not, however, a bare EIP-20 token, and the difference is a reconciliation trap rather than a curiosity. LINK also implements transferAndCall(address,uint256,bytes), an extension usually called ERC-677 which moves a balance and then calls the recipient contract. Chainlink's own documentation states that "the LINK token is an ERC-677 token that inherits functionality from the ERC-20 token standard and allows token transfers to contain a data payload". ERC-677 was never adopted as a numbered EIP: it exists as GitHub issue 677, opened in July 2017 with the status Draft and closed in 2022 without adoption, so nothing can be asserted about what ERC-677 requires, only about what LINK's own verified code does.

The extension exists because a plain ERC-20 transfer tells the recipient nothing. The receiving contract's code never runs, which is why the Ethereum Foundation's own documentation warns that "when ERC-20 tokens are sent to a smart contract that is not designed to handle ERC-20 tokens, those tokens can be permanently lost".

What transferAndCall does is emit two records for one movement. One call produces two logs both named Transfer, under two different topic hashes, 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef for the three-parameter EIP-20 event and 0xe19260aff97b920c7df27010903aeb9c8d2be5d310a2c67824cf3f15396e4c16 for the four-parameter extension. In transaction 0xd9fbb7b61f9c32309c22fdc51b924b250f7dd8061a83644fe0495bacad0c892c at block 25,942,584, one movement of 2.558481175212356882 LINK produced both. A subledger that matches log entries by event name rather than by topic hash records twice the quantity that moved.

BAT at 0x0d8775f648430679a709e98d2b0cb6250d2887ef is another token whose current holder accounting can be analysed as a plain fungible token, with a fixed supply of exactly 1,500,000,000 units, even though the contract contains historical sale-related code.

The category itself is an analytical construct, and this article's own construct rather than a standard's. Accounting standards do not publish a category called "plain fungible token". The purpose of the category is to isolate the simplest case before analysing more complicated token types. Even the cleanest reference token does something the standard does not describe, which is what the checklist below is for.

Upgradeability can change the rules after acquisition

A token contract can appear simple while delegating its logic to another contract through a proxy. A proxy is a contract that holds the balances and the address a holder deals with, while forwarding the decision about what those balances mean to a second contract whose address an administrator can replace.

In that arrangement, the address holding balances can remain unchanged while an administrator replaces the implementation code. A token that is plain today can therefore acquire new transfer restrictions, minting logic, or other behaviour later if the governance structure allows it.

The test has to be run in one direction only. A non-zero value in a proxy storage slot proves upgradeability. A zero value proves nothing, because the slot is a convention and there are several of them. EIP-1967 fixes the current convention at storage slot 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, and a good deal of deployed code predates it. Read on 9 September 2026, USDC at 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 reads zero in that slot and holds a live implementation address, 0x43506849d7c04f9138d1a2050bbf3a0c054402dd, in an older OpenZeppelin slot. It is an upgradeable proxy that the current test alone would clear. Establishing that a contract is not upgradeable takes reading the deployed code or a verified source.

An onboarding review should record the implementation address and the upgrade authority where either exists. A period-end control should also detect whether the implementation changed during the period, because EIP-1967 says only that a change to the slot "SHOULD be notified by the event", so an indexer watching for that event may not catch it. Upgradeability is a reporting-date question rather than an onboarding one.

The accounting reason is straightforward: the contract address identifies the asset, but the code governing that asset may not be immutable.

A token balance is an integer first, a displayed number second

On chain, token quantities are stored as whole numbers. The decimal point seen in a wallet is a display convention.

Suppose a contract reports:

raw balance = 2404456208915486393

If the contract uses 18 decimals, the displayed quantity is:

2.404456208915486393 tokens

If the same raw integer belonged to a six-decimal token, the displayed quantity would be completely different.

This is why an accounting system should never hard-code 18 decimals for all ERC-20 assets.

The decimal setting is a property of the individual contract rather than of the ticker, and the only way to know it is to read the contract. Read live on Ethereum mainnet at block 25,942,271 on 9 September 2026:

A subledger that assumes 18 decimals reports that USDC balance a trillion times too small and that GUSD balance ten thousand trillion times too small.

It is worse than a range of values to look up. EIP-20 marks name, symbol, and decimals OPTIONAL, each with the same caution that other contracts "MUST NOT expect these values to be present". Where a contract does not expose decimals(), nothing on chain will supply the figure. It has to be established from the verified source code or the project's documentation, recorded in the token-classification memo, and evidenced there rather than assumed. A system that silently defaults to 18 when the call fails produces exactly the error this section exists to prevent.

A robust token master should therefore store, at minimum:

The quantity ledger should retain raw integer units where possible. Display quantities should be derived from the raw units and the decimal figure recorded in the token master, which is not always the same thing as the contract's own answer.

In a subledger, that gives an asset object holding the technical identity and the accounting attributes together without confusing them:

asset_id
  chain_id
  contract_address
  decimals
  decimals_source
  symbol
  name
  proxy_status
  implementation_address
  accounting_classification
  valuation_policy_id
  tax_asset_id

A transaction row then references that asset object and adds the event-specific evidence:

tx_hash
block_number
block_timestamp
from_address
to_address
raw_quantity
scaled_quantity
gas_used              (the units of computation the transaction consumed)
effective_gas_price   (the price per unit actually paid, so that
                       gas_used x effective_gas_price is the fee in ETH)
fee_asset
business_event_type
book_lot_reference
tax_lot_reference

This design prevents three common failures at once: ticker collisions, decimal-scaling errors, and the loss of the link between the token movement and the ETH fee.

balanceOf reports a state, not a history

The function balanceOf(address) answers a narrow question: what quantity does this contract currently report for this address?

That is valuable evidence, but it is not a complete accounting record.

It does not establish:

• why the balance changed
• who economically controlled the address
• whether the token was bought, borrowed, received as revenue, or transferred between the entity's own wallets
• whether a previous balance belonged to a custodian rather than the entity
• what cost basis attaches to the units
• whether a transfer created gain, loss, revenue, expense, or no P&L event at all
• whether off-chain legal rights change the substance of the position

A balance is therefore a quantity assertion, not a journal entry.

transfer is only one way a balance can move

A common mistake is to assume that a token balance changes only when the holder signs a transfer. ERC-20 includes transferFrom, which allows another address to move a holder's tokens where the holder previously granted authority through an allowance, and EIP-20 describes it as a withdraw workflow whose purpose is exactly that. The holder may not sign the disposal, may pay no fee, and may see no outgoing transaction from the address at all, so a process that searches only for transactions the entity originated can miss a real token outflow.

Allowances therefore belong in the control environment rather than in a technical security checklist. What the holder of an ERC-20 token actually owns sets out what a standing allowance is as an exposure over the entity's property, and why a token balance is not an accounting record gives the completeness procedure that catches the movement, with a real transaction in which 206 LINK left an ordinary account that neither sent nor paid for the transaction.

Gas belongs to a different asset

Moving an ERC-20 token on Ethereum requires gas, and gas is paid in ETH.

Gas is the unit in which Ethereum meters computation: it "refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network". Every transaction consumes a number of gas units fixed by the work it does, and the sender pays for each unit in ETH. The price per unit has two parts, a base fee the protocol sets and every sender must pay, and a priority fee the sender adds as a tip to the validator. Gas prices are quoted in gwei, and each gwei is one-billionth of an ETH. The fee "is paid regardless of whether a transaction succeeds or fails".

A fee is therefore gas units multiplied by a price per unit. A record that keeps only the dollar amount cannot be reperformed.

That creates a two-asset accounting problem:

• the token moves
• ETH is consumed to pay for the transaction

The fee is not paid in the ERC-20 token unless some separate application converts or reimburses it. At the protocol level, Ethereum transaction fees are paid in ETH.

One real transfer shows both halves at once. In transaction 0x4114bab7125b0fc11e324f6ea9ef23f7b3089aef33e091a59844bfe4af66c8d9, block 25,942,251 on 9 September 2026 at 20:38:11 UTC, the LINK contract's own log records 13,563,144,080,629,700,000 raw units, which is 13.5631440806297 LINK at 18 decimals, moving from 0x278d858f05b94576c1e6f73285886876ff6ef8d2 to 0x5d4f3c6fa16908609bac31ff148bd002aa6b8c83. The quantity changed inside the token contract. Nothing in that log says how many decimals to apply, so the scaling factor has to be read from the contract separately. And the fee for the transaction left the sender's ETH balance, which the LINK contract knows nothing about.

Two real LINK fees read from their receipts the same day make the arithmetic concrete: 34,989 gas units at 2,088,958,188 wei per unit is 0.000073090558039932 ETH, and 52,089 gas units at 2,059,362,123 wei per unit is 0.000107270113624947 ETH. Neither fee is paid in LINK.

The fee does not scale with the market value of the token being moved. Sending $50 of LINK costs the same gas as sending $5 million of LINK. What does change the gas is the recipient. In four ordinary LINK transfers read from receipts on 9 September 2026, the two sent to a recipient whose LINK balance was zero at the previous block each consumed 52,089 gas units, while the two sent to a recipient that already held LINK consumed 35,001 and 34,989. The difference between 52,089 and 34,989 is exactly 17,100.

The reason is the storage write. Creating a recipient's balance entry from zero is priced far above updating one that already holds a value, and EIP-3529 prices the two cases at 22,100 gas and 5,000 gas respectively in its own worked ERC-20 example. A gas accrual, a recharge, or a cost allocation built on a single observed figure will be wrong by almost half for the other case, and a gas variance between two apparently identical transfers is normal rather than evidence of an error.

For accounting systems, this means every on-chain token transaction may require a linked ETH entry or tax-lot event in addition to the token entry itself, which is the subject of Ethereum gas fee accounting.

The token contract can matter more than the ticker

Before treating a token as plain, a preparer should inspect whether the contract contains additional powers or mechanics, and should not infer plainness from branding. The contract is what has to be tested.

A reasonable technical sequence is:

1. Read totalSupply and balanceOf from the exact contract, and read name, symbol, and decimals where the contract implements them. EIP-20 marks all three metadata methods OPTIONAL, so where decimals() does not answer, the scaling factor has to be established from the verified source or the issuer's documentation and recorded in the token master with its evidence.
2. Check whether the address is a proxy or delegates execution elsewhere, on more than one slot convention, and remember that a zero result establishes nothing.
3. Inspect verified source code where available, but remember that verification only proves that the published source compiles to the deployed bytecode. It does not prove the code is safe, economically fair, or correctly classified.
4. Search for owner, admin, minter, pauser, blacklist, freeze, seize, wipe, upgrade, rebase, index, exchange-rate, redemption, or vault functions.
5. Determine every path by which a holder's balance or total supply can change.
6. Determine whether another party owes the holder cash, goods, services, or another asset.
7. Determine what the contract does beyond the standard, such as the transferAndCall entry point described above.
8. Record the result in a token-classification memo.

Any "yes" to an administrative power or an economic claim may move the token out of this article's scope. Read at block 25,942,635 on 9 September 2026, the boundary cases are concrete:

• a stablecoin may create a contractual claim on an issuer or reserve arrangement, and may carry live administrative powers. USDT at 0xdAC17F958D2ee523a2206206994597C13D831ec7 carries an owner and a blocklist that has been used, returning true from isBlackListed() for 0x7F367cC41522cE07553e823bf3be79A889DEbe1B
• WETH at 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 is redeemable for ETH against the contract itself at a fixed rate, so the holder has a redemption claim rather than a plain balance
• stETH at 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84 changes the number balanceOf returns with no transfer and no Transfer log, because the figure is a share count multiplied by a rate the protocol updates. The issuer states it plainly: the stETH balance "is not constant, it changes daily as oracle report comes in". Every process built on "the balance moves only on transfer" is wrong for it
• a lending receipt token such as aEthUSDC at 0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c is a claim on a lending protocol rather than a holding. The issuer's documentation states that yield "is distributed to aToken holders directly by continuously increasing their wallet balance", its scaledBalanceOf returns a different number from its balanceOf, and its code is replaceable
• an ERC-4626 vault share such as sDAI at 0x83F20F44975D03b1b09e64809B757c47f942BEeA declares the relationship itself: asset() returns the DAI contract address and convertToAssets returned 1.180332646351678564 DAI per share
• a tokenised real-world asset such as PAXG at 0x45804880De22913dAFE09f4980848ECE6EcbAf78 carries a redemption right against a named issuer and an issuer role system including freeze, wipeFrozenAddress, and pause

Calling all of these "ERC-20" is technically possible and accounting-wise inadequate. The final question is not "does it support ERC-20?" The final question is "what else does it do?"

The next article in this series separates the four economically different positions that can carry the same ticker, and the one after it shows why reconciliation must key on chain and contract rather than on symbol.

What the chain can prove, and what it cannot

The chain can provide strong evidence for technical facts, especially when queries are pinned to a specific block. A block is one batch of transactions added to the chain, numbered in sequence, and it is the chain's equivalent of a dated ledger page: a query pinned to a block asks what was true when that page closed. Pinning is available because the node interface's state-reading methods each take a block parameter, so a balance read can be repeated at the same block by a reviewer and an unpinned read cannot.

It can help prove:

• the code deployed at an address
• the state of a balance at a block
• transaction inclusion
• transaction sender and recipient
• logs, the records a contract emits during execution
• ETH spent on gas
• contract storage values
• whether a particular function call succeeds or reverts

The chain usually cannot prove:

• beneficial ownership
• legal title under a custody agreement
• the entity's accounting purpose
• whether a transfer was a sale, loan, gift, theft, settlement, or internal movement
• whether a director or employee was authorised under the entity's internal controls
• whether an off-chain side agreement creates enforceable rights
• the accounting classification required under IFRS or US GAAP, which for a plain fungible token turns on the June 2019 IFRIC agenda decision and on the six criteria of ASC 350-60-15-1, introduced by ASU 2023-08

Blockchain evidence is therefore part of the audit trail, not a substitute for the accounting analysis.

A practical onboarding checklist

The groundwork for ERC-20 tokens for accountants is an onboarding procedure, not a judgement made later. Before a token enters the ledger, an accountant or digital-asset operations team should establish the following:

1. Identity: chain ID and contract address.
2. Decimals: read from the contract where the contract implements the method, preserve raw units, and where it does not, record the figure's source and evidence.
3. Code status: verified source if available, proxy status tested on more than one slot convention, implementation address if applicable.
4. Administrative powers: mint, freeze, pause, seize, upgrade, blacklist, role-based privileges.
5. Economic rights: redemption, claim on underlying assets, yield, staking, debt, governance, or other rights.
6. Holder relationship: self-custody, custodian, exchange account, fund interest, or derivative exposure.
7. Transfer mechanics: ordinary transfer, allowance-based movement, permit-style authorisation under EIP-2612 (a signed off-chain message that lets another party create the allowance on chain later, covered in the next article in this series), transfer restrictions, and any non-standard entry point such as transferAndCall.
8. Gas asset: which account pays ETH, and how the gas units and the effective gas price will be recorded alongside the fee.
9. Valuation source: principal market, observable price, fallback methodology, and evidence retained.
10. Financial-reporting classification: IFRS, US GAAP, or another framework, supported by a written memo.
11. Tax treatment: jurisdiction, taxpayer type, lot method, basis rules, and treatment of fees.
12. Period-end evidence: block-pinned balances, transaction completeness, custody confirmations, allowance review, and reconciliation.

The accounting takeaway

A plain ERC-20 token is not "a coin inside a wallet". It is a quantity maintained by a specific smart contract on a specific network, controlled through keys and contract rules, and moved using transactions that consume a different asset for gas.

For ERC-20 tokens for accountants, four rules prevent most foundational errors:

• identify the asset by chain and contract address, not ticker
• preserve raw units and contract-specific decimals, and record where the decimal figure came from
• separate the token movement from the ETH gas movement, keeping gas units and price as well as the fee
• prove that the token is actually plain before applying plain-token accounting

Everything else in the cluster builds on those four rules, and the wider bookkeeping context sits in the crypto accounting guide.

How Tokenbooks helps with ERC-20 token accounting

Tokenbooks syncs Ethereum mainnet at the level this article describes. Every transfer is ingested, ERC-20 movements included, and token mechanics are typed rather than assumed, so a rebasing balance, a value-accruing share and an interest-bearing receipt are each a distinct kind rather than one undifferentiated position.

What the transaction was is then a recorded field drawn from a fixed set of operation types, so a purchase, a disposal, an internal move, a fee and a protocol interaction are distinguished in the books rather than inferred by a reviewer from the direction a transfer happened to travel. The interpretation also sits beside its evidence, because the decoded contract calls and the event logs behind a transaction stay visible next to the accounting reading of it.

Wallets on more than 50 blockchains and accounts on more than 80 exchange venues can be connected and synced, so an entity's token positions reach the same set of books.

See how that sync works on the Ethereum integration page.

More in this series

Accounting Token Anatomy: ERC-20 Tokens. This article stands alone, but the series builds in order.

Next (02.1.2): What Does the Holder of an ERC-20 Token Actually Own?

Sources and further reading

• EIP-20, Token Standard. eips.ethereum.org
• EIP-2612, Permit extension for EIP-20 signed approvals. eips.ethereum.org
• EIP-1967, Standard Proxy Storage Slots. eips.ethereum.org
• EIP-3529, Reduction in refunds. eips.ethereum.org
• ERC-677, GitHub issue 677, never adopted as a numbered EIP. github.com
• Ethereum.org, ERC-20 Token Standard. ethereum.org
• Ethereum.org, Gas and fees. ethereum.org
• Ethereum execution APIs, state methods. github.com
• Chainlink, LINK token contracts. docs.chain.link
• Lido, token integration guide. docs.lido.fi
• Aave, tokenization. aave.com
• IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019. ifrs.org
• FASB ASU 2023-08. storage.fasb.org This article is educational material, not legal, tax, investment, or accounting advice for a specific entity. Classification can change with the token's contractual terms, code, facts, jurisdiction, and reporting framework.