This might sound like a dumb question, but bear with me — it’s a real one
With traditional bank transfers in a business context, it’s standard practice to attach a reference to the transaction (invoice number, customer ID, etc.) so that both parties can reconcile it against their accounting ledgers.
I know the recommended practice with Bitcoin is to generate a fresh address per transaction/invoice, which gives you both better privacy (and arguably quantum resistance) and unambiguous reconciliation.
Still, that only works when you control the receiving side.
The Bitcoin network supports embedding additional data in transactions (OP_RETURN), and EVM chains have the calldata/input data field.
So why is it so uncommon for applications — not just browser wallets — to let the sender attach a reference when sending funds?
If blockchain payments are ever going to reach mainstream business adoption, this seems as obviously useful as a bank payment reference.
I’m asking because I’m personally affected: I’m developing a blockchain transaction integration for an ERP system, and reconciliation with accounting is a real pain without it.
A few substantive notes before you post, since forum regulars will likely raise these:
OP_RETURN exists but is discouraged for this use — it costs extra fees, some wallets/nodes filter it, and the Bitcoin community historically resists using the chain as a data store. You might preempt that by acknowledging it.
BIP21 payment URIs and BIP70/BIP71 (deprecated) / BIP270 tried to solve exactly this at the protocol-adjacent layer — the reference lives in the payment request, not on-chain. Someone will point this out, so you could sharpen your question to: “why did payment-request protocols with reference fields never gain wallet adoption?” That’s actually the deeper question.
On EVM, plain ETH transfers to EOAs can carry input data, but ERC-20 transfers can’t easily (the data field is consumed by the transfer() call itself) — worth mentioning if your ERP deals with stablecoins like USDC, since that’s probably your actual case.
