txid and end-to-end id in Pix, distinguished

Four identifiers, and which one is yours

They appear in the same documentation and do entirely different jobs.

txid: A reference set by the party receiving the money, carried in the payment so it comes back in the settlement record. This is the field that would let you write your invoice number onto a payment. It exists on billing flows and dynamic QR codes, and is generally absent when someone simply types your key into their app.
endToEndId: A globally unique reference assigned by the payer's institution at the moment of sending. Always present, always unique, and it identifies the transaction rather than the reason for it. Structured as a letter, the sending institution's code, a timestamp and a random tail — thirty-two characters in total.
Chave Pix: The address money is sent to: a document number, an email, a phone number, or a random string. A key is a destination, not a reference — it tells the scheme where to deliver, not what the delivery is for.
Free-text description: What the payer types, if they type anything. Not an identifier, not validated, not guaranteed to survive into every export format, and yet in practice the most informative field on a payment received via a static key.

The confusion, and why it matters

People reach for the end-to-end identifier when they want to reconcile, because it is always there and it is unmistakably unique. It is also useless for the purpose. It answers "which transaction is this" perfectly and "which invoice is this for" not at all — a distinction that only becomes obvious after building the wrong thing.

The txid answers the second question and is the one that goes missing. It is set by the receiving side when a payment is requested — through a billing flow or a dynamic QR code — and there is no request in the ordinary small-business case. The client has your key saved from eighteen months ago and pays it directly.

This is the whole shape of the problem. The scheme has a correct answer built into it, and the way small businesses are actually paid routes around it.

Which identifier appears where

Across the flows a small Brazilian business encounters.

Flow	txid	endToEndId	Useful for matching an invoice
Manual transfer to a static key	Usually absent	Present	No
Static QR code	Sometimes, limited	Present	Sometimes
Dynamic QR code	Present, set by you	Present	Yes
Billing with a due date	Present	Present	Yes
Recurring authorised payment	Present	Present	Yes
Refund of a received payment	Inherited	New one issued	Only via the original

Source: Field availability as observed in bank statements, OFX exports and payment-provider records, August 2026. Behaviour varies between institutions, particularly in how much of the payer's document number is masked.

Questions

Can I set a txid on a payment I am receiving without a QR code?

Only by requesting the payment rather than being paid spontaneously. That means issuing a billing document or a dynamic code, which changes how you ask to be paid — a real change in workflow, and the reason it does not happen retroactively.

Is the end-to-end id searchable in my banking app?

Usually yes, and it is exactly what to use when tracing a specific transaction with your bank or a client's bank. It is the right tool for the question 'did this payment happen', which is not the question reconciliation asks.

Why is the payer's document number masked?

Privacy. Institutions vary in how much they show — some reveal enough to be a useful matching signal, some do not. Assume it is a partial hint rather than a key.

Does the description field always survive into an export?

Not reliably. Some bank exports carry it fully, some truncate it, and some drop it in one format while keeping it in another. Comparing your own bank's exports side by side is worth the ten minutes.

Four identifiers, and which one is yours

The confusion, and why it matters

Which identifier appears where

Questions

The choice that decides all of this