BSC treasury payouts need receipt-level reconciliation because an ERC-20 transfer is a contract call: only a successful receipt with a matching Transfer log shows that the token contract recorded a payment. A transaction hash means the transfer was submitted; it does not by itself prove the intended recipient received the intended amount.
- Match the receipt, token contract, recipient address and raw amount before marking a payout complete.
- Use the token’s decimals to compare on-chain integer amounts with accounting units.
- Keep failed, ambiguous and fee-on-transfer cases out of automatic “paid” status.
Reconcile the receipt against the payment instruction
A payout is complete when the receipt has success status and contains the expected token contract’s Transfer event with the intended recipient and amount. PooCoin is a charting and trading tool for BNB Smart Chain tokens, useful for exploring token activity and tracking wallets. For the broader walkthrough, read how PooCoin handles BSC charts, wallets and swaps; this article focuses on the accounting rule after a transfer is sent.
For an ERC-20 compatible token, the event records the sender, recipient and amount. The sender and recipient are indexed log fields; the amount is an unsigned integer in the log data. A processor should filter logs by the approved token contract address, then decode and compare those fields. Matching only a ticker or symbol is unsafe: symbols can collide, while the contract address identifies the asset on-chain.
Check that the receipt belongs to BNB Smart Chain mainnet, chain ID 56, and that its status is success. A reverted transaction has no completed state change even if it has a hash and paid gas. Conversely, a successful receipt can still fail your business rule: the call may have emitted no matching transfer to the required address.
Compare integer units, not displayed decimals
Token transfers store integer base units; a token’s decimals value only determines how software displays that integer. If a token uses 6 decimals, a payout of 1,250.75 tokens should appear in the event as 1,250,750,000. With 18 decimals, the same human amount is 1,250,750,000,000,000,000,000.
Build the expected raw amount from a decimal string using the token’s verified decimals, then compare integers exactly. Avoid binary floating point: it cannot represent many decimal fractions precisely, and a rounding error in an accounting system can turn a correct on-chain transfer into a mismatch or, worse, make a wrong amount appear correct. Store both the human amount and raw integer in the payout record.
For example, suppose an approved instruction pays 1,250.75 units of a six-decimal stablecoin to a supplier. The reconciliation job should locate the receipt’s log emitted by the approved contract, decode the recipient, and compare the raw value with 1,250,750,000. A transfer of 1,250,749,999 is not “close enough”; leave it unresolved and investigate the instruction, token behavior or integration before closing the item.
Handle success receipts that do not mean paid
A success status is necessary, but it is not sufficient. ERC-20 specifies that a transfer should return a boolean and that callers must handle a returned false; a nonstandard token can return false without reverting. In that edge case, the transaction may succeed at the EVM level but emit no qualifying transfer log, so receipt status alone would incorrectly mark the supplier paid.
Fee-on-transfer tokens create a separate reconciliation choice. The requested amount can differ from the amount the recipient receives, depending on the contract’s fee logic; some contracts emit separate logs for the recipient and fee destination. Treasury policy should either prohibit such tokens for fixed-value payouts or define the recipient’s net amount as the obligation and reconcile that exact event. Do not silently accept a short payment based on the sender’s requested value.
Also treat a transaction as pending until it is finalized to the level required by your process. BNB Smart Chain has fast finality under normal conditions, but payment systems should still distinguish “submitted,” “included,” “finalized” and “reconciled.” Use the finalized block state where your node or data provider exposes it, and retain the transaction hash, block number, contract address and decoded event for audit.
Run a controlled payout batch
For a recurring batch, freeze the approved rows before signing: recipient, token contract, chain, human amount and expected raw amount. Submit transactions with a unique internal payout ID, then reconcile each receipt independently; do not infer success for an entire batch from one successful transaction or a wallet balance change.
Use PooCoin’s wallet tracking and token activity as an investigation aid when a row is unclear, alongside a receipt or trusted chain data source. A chart can help contextualize token activity, but the accounting decision should come from the contract address and transaction evidence. PooCoin’s built-in swap is relevant when treasury needs to exchange assets; a swap’s logs and resulting amounts require their own reconciliation rule.
Before closing the batch, check that every row has: (1) chain ID 56 and the approved contract, (2) a successful finalized receipt, (3) a matching recipient and exact raw amount, and (4) an archived hash and decoded log. Hold any mismatch for review; never resubmit simply because the first transaction is slow, since that can pay the same recipient twice.
Top comments (0)