Preventing Double-Counted USDT Transfers in a Multi-Wallet Ledger

U Ledger — Mon, 20 Jul 2026 07:07:20 +0000

A multi-wallet USDT ledger has a classification problem that is easy to miss: the same internal movement appears as an outgoing transfer in one owned wallet and an incoming transfer in another.

If those wallet histories are aggregated without an ownership model, the principal may be counted as both an expense and income.

This post describes a small, deterministic data model for handling that case across TRON and BSC.

1. Keep network identity in every key

An address string is not a complete identity.

TRON addresses and EVM addresses use different formats, while the same 0x... address can exist on BSC, Ethereum, Polygon, Base, or another EVM network.

Use a network-qualified key:

function addressKey(network, address) {
  return `${network.toLowerCase()}:${address.toLowerCase()}`;
}

The same rule should apply to transaction identifiers:

function transferKey(network, txHash, logIndex = 0) {
  return `${network.toLowerCase()}:${txHash.toLowerCase()}:${logIndex}`;
}

Including a log index is useful on EVM networks when one transaction emits multiple token-transfer events.

2. Maintain an explicit ownership registry

Do not infer ownership from recent activity or transfer direction.

const owned = new Map([
  ["tron:T_SAMPLE_OPERATIONS", { name: "TRON operations" }],
  ["tron:T_SAMPLE_PAYMENTS", { name: "TRON payments" }],
  ["bsc:0xsampleoperations", { name: "BSC operations" }],
  ["bsc:0xsampletreasury", { name: "BSC treasury" }],
]);

In production, normalize addresses according to the network before adding them to the registry.

The ownership list should be user-controlled because public blockchain data cannot reliably explain the business relationship behind an address.

3. Classify principal movement before calculating totals

A minimal transfer record might look like this:

{
  network,
  txHash,
  logIndex,
  timestamp,
  tokenContract,
  from,
  to,
  amount,
  fee,
  confirmations
}

Then classification becomes deterministic:

function classifyTransfer(tx, owned) {
  const fromOwned = owned.has(addressKey(tx.network, tx.from));
  const toOwned = owned.has(addressKey(tx.network, tx.to));

  if (fromOwned && toOwned) return "internal";
  if (fromOwned) return "outgoing";
  if (toOwned) return "incoming";
  return "external";
}

Only incoming and outgoing principal movements should contribute to ordinary receipt and payment totals.

An internal movement should remain visible in the ledger for traceability, but its principal should not be added to revenue or expense.

4. Treat network fees separately

The principal transfer and the network fee are different accounting events.

For an internal transfer:

principal movement: internal, excluded from ordinary income/expense
network fee: possible operating cost, retained separately

Combining both into one signed amount makes later reconciliation harder.

5. Separate blockchain facts from business meaning

The blockchain can confirm:

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

It cannot confirm whether the transfer represents a customer payment, supplier payment, refund, treasury movement, or test.

Keep business metadata in a separate layer:

{
  expectedAmount,
  counterpartyId,
  invoiceId,
  note,
  status: "reconciled" | "still_due" | "overpaid" | "review"
}

This prevents a label correction from rewriting the underlying public transaction record.

6. Start with a bounded range

A safer onboarding sequence is:

add one owned public address
read a recent bounded period
validate the network and token contract
label known counterparties
add the remaining owned wallets
reclassify owned-to-owned transfers
compare expected and actual payments
import older history only when needed

This makes failures easier to isolate. A zero result might otherwise mean the wrong network, the wrong token contract, an incomplete provider response, or simply no activity.

7. Do not request wallet authority for reconciliation

This workflow uses public transaction data. It does not require a wallet connection, seed phrase, private key, or signing permission.

I built an interactive sample of the multi-wallet deduplication flow using example wallets and transfers. It can be reviewed without registration or a real address:

Open the no-sign-up multi-wallet example

Disclosure: I built U Ledger. The link is a product guide and sample workflow, not a trading, custody, exchange, or investment service.

How to Reconcile USDT Across Multiple Wallets Without Double-Counting Internal Transfers

U Ledger — Wed, 15 Jul 2026 06:32:09 +0000

Managing USDT across several wallets looks simple until the first internal transfer appears.

If one business controls wallet A and wallet B, moving 5,000 USDT from A to B is not revenue and it is not an expense. It is a change in custody. Yet a basic transaction export often shows one outgoing movement and one incoming movement, which can inflate both sides of an operating report.

Why summing wallet activity fails

A reliable multi-wallet ledger needs more context than amount and timestamp. For every transaction, preserve at least:

network and transaction hash;
sending and receiving addresses;
which addresses belong to the same business;
token amount and network fee;
transaction direction from the business perspective;
a link between both sides of an internal transfer.

TRON and BNB Smart Chain should also remain separate. They have different fee mechanics and transaction identifiers, even when the transferred asset is USDT.

A practical reconciliation workflow

1. Build an ownership map

Give every controlled address an operational name such as Treasury TRON, Sales BSC, or Vendor Wallet. Do not rely on shortened address fragments during review.

2. Import public transaction histories

Import each wallet separately and retain its source network. Normalize timestamps and token units, but keep the original transaction hash so every record can be traced back to the chain.

3. Classify by ownership

For each transfer, ask whether the sender and receiver are controlled by the same business.

External sender to controlled receiver: candidate inflow.
Controlled sender to external receiver: candidate outflow.
Controlled sender to controlled receiver: internal transfer.
Neither side controlled: outside the ledger scope.

This classification is more reliable than rules based only on direction or amount.

4. Separate fees from principal

An internal transfer may still create a real cost. The USDT principal remains internal, while TRX or BNB paid as network fees is an expense. Combining them into one number hides useful accounting detail.

5. Match both sides

Use the transaction hash when possible. If data came from sources that represent the two sides differently, match on network, token, amount, addresses, and a narrow time window. Store an explicit relationship between the paired records instead of deleting one side.

6. Review exceptions

Flag unmatched internal-looking transfers, duplicate imports, unsupported tokens, missing fees, and sudden balance differences. Exceptions deserve human review; normal transfers should not require repeated manual work.

A privacy boundary that is easy to explain

Reconciliation only needs public blockchain data. A bookkeeping tool should not require a wallet connection, seed phrase, private key, or signing permission.

That boundary reduces risk and makes the workflow easier to audit: the tool reads public history and organizes it, but it cannot move funds.

Explore a sample workflow

I built U Ledger to demonstrate this approach for operational USDT records across TRON and BSC. The English demo uses sample data, so you can explore the workflow without creating an account or entering a real wallet address.

Explore the multi-wallet reconciliation guide

The most important principle is simple: ownership relationships determine whether a transfer changes the business's economic position. Once that rule is explicit, multi-wallet reporting becomes much easier to trust.

DEV Community: U Ledger