The meaning and timing of confirmations vary by network. A service's internal crediting process can add another step after its network requirement has been met.
Inclusion, confirmations and finality
A transaction can be broadcast before it is included in a block. Some networks then count additional blocks as confirmations; other systems describe finality through a different consensus process. A receiving platform chooses its own credit threshold. A universal statement that every transfer needs a fixed number of confirmations is therefore inaccurate.
In a simplified block-counting convention, a transaction included in block 100 has one confirmation at that stage and six when the chain reaches block 105. The exact explorer convention and network must be checked. Six confirmations on one network are not necessarily equivalent to six on another.
Confirmed on-chain versus credited in an account
After the network threshold is met, the receiving service may still need to reconcile the asset, address, amount or destination tag. A supported deposit threshold and minimum amount are separate conditions. Successful inclusion cannot correct sending an unsupported token or using the wrong route.
Reading a delayed transfer
First identify whether the transfer is unbroadcast, awaiting inclusion, progressing through confirmations or awaiting account reconciliation. Then ask the responsible service about that stage. Keep the transaction hash and network in the report. Do not send a second transfer to force the first to confirm, and do not assume a changing explorer count establishes that every receiving account has already been credited.
In practice
If a hypothetical recipient requires three confirmations, seeing only one does not meet that recipient's threshold. Reaching three still needs to be distinguished from its completed account credit.
What to check
Check the network, required threshold and recipient's crediting status. Do not compare confirmation counts across networks as though they were identical time units.