TRC20 USDT activity belongs to TRON. BEP20 USDT activity belongs to BNB Smart Chain. A reliable reconciliation process must keep the network, token contract, address ownership, and transaction identifier attached to every movement.

Why merging by symbol fails

A row labeled only USDT cannot answer:

• Which network confirmed the transfer?
• Which token contract emitted it?
• Which block explorer can verify it?
• Was the sender or recipient one of the company's wallets?
• Is the apparent payment actually an internal treasury movement?

The symbol is useful for display, but it is not a primary key.

A safer transfer identity is:

network + token contract + transaction hash + event index

For TRON, the transaction identifier and contract event identify the token transfer. For BSC, one transaction can emit more than one token-transfer event, so an event or log index prevents accidental collapse.

Keep wallet ownership network-qualified

Store controlled addresses as explicit records:

An EVM-style address should never be treated as proof that a record belongs to BSC. The network must come from the selected data source and validated token contract.

Detect internal movements before calculating income and expense

If both sides of a transfer belong to the controlled-wallet list, classify the principal as an internal transfer.

Keep the transfer visible, but exclude the principal from ordinary receipt and payment totals. Otherwise the same movement can appear as an expense in one wallet and income in another.

Network fees remain separate. They may still be an operating cost even when the principal movement is internal.

Use two layers

A clean reconciliation model separates:

Public transaction facts

• network
• token contract
• timestamp
• sender
• recipient
• amount
• transaction hash
• confirmation state

Business reconciliation data

• counterparty name
• invoice or reference
• expected amount
• internal-transfer flag
• business note
• status: reconciled, still due, overpaid, or review

The first layer should remain stable. The second layer can be corrected without changing the underlying blockchain record.

Start small

A practical sequence is:

1. add one public wallet address
2. select TRON or BSC explicitly
3. read a recent bounded period
4. validate the USDT contract
5. label known counterparties
6. add the other controlled wallets
7. reclassify controlled-to-controlled movements
8. compare expected payments with confirmed transfers

This makes troubleshooting much easier than importing years of activity from every wallet at once.

Reconciliation does not require wallet access

Reading and organizing public blockchain transactions does not require a seed phrase, private key, wallet connection, or signing permission.

I built a no-sign-up sample that demonstrates the multi-wallet and internal-transfer workflow with example data:

Review the multi-wallet reconciliation example

Disclosure: I built U Ledger. The linked example is a product guide, not a trading, exchange, custody, or investment service.