SEPA Payment Reference: EndToEndId, Remittance and Purpose Codes

When sending a euro transfer, alongside the IBAN, the amount and the payee name, there are a few more "reference" fields. These let the payment be matched with the correct invoice, the correct customer or the correct accounting record on the other side. The ISO 20022 messaging standard underlying SEPA separates these fields clearly. In this guide we explain the most frequently confused fields — EndToEndId, remittance, Purpose Code and Category Purpose Code — and show why they are different from the UETR in the SWIFT world.

EndToEndId (end-to-end reference)

The EndToEndId is a reference the sender adds to the payment that is intended to be carried unchanged throughout the payment chain. Its purpose is to match the payment with a single key between the sender's system and the recipient's system: for example, if you put an invoice number here, the recipient's accounting software can automatically link the incoming payment to that invoice. In this respect the EndToEndId is a technical field used by the machine rather than a remittance read by a human.

There are format constraints, and these are determined by ISO 20022 and the relevant EPC Implementation Guideline. In general, the field length is limited to at most ~35 characters and only the character set permitted by the guideline (Latin letters, digits and a limited number of punctuation marks) is accepted. Characters specific to Turkish or some special symbols can be rejected. When no value is given, the common default in the implementation guides is the phrase "NOTPROVIDED"; that is, instead of sending the field blank, the system places this constant. Because the exact length and character-set rules can vary by the version of the guideline your bank applies, in a critical integration you must confirm these with your bank — otherwise they should be treated as unverified.

Remittance information

The remittance field (remittance information) tells the recipient what the payment is for. It has two forms, and the difference matters for automatic reconciliation:

• Unstructured: Free text. In the standard SEPA Credit Transfer flow this field is typically limited to ~140 characters. It is suitable for a human-read note such as "March invoice payment", but it offers no formal guarantee for automatic matching.
• Structured: A field carrying a standard reference format. The most widespread format in Europe is the ISO 11649 "RF" Creditor Reference. This reference contains a check digit; the recipient's system can read the reference and close the invoice automatically and without error. That is why it is preferred in corporate and collection flows.

A practical rule: if a human is going to read it, unstructured text is enough; if a piece of software is going to match the payment automatically, the structured (RF) reference is much more reliable. Usually one of these two forms is used in a payment; the possibility of using both at the same time, and the rules for it, vary by guideline version.

Purpose Code and Category Purpose Code (purpose codes)

Purpose codes indicate what the payment is made for with a standard code. There are two separate fields:

• Purpose Code: A code selected from the ISO 20022 external code lists (External Code Sets) that indicates the purpose of a single payment. Common examples: SALA (salary), SUPP (supplier payment), RENT (rent). This code mainly informs the recipient and the reporting side.
• Category Purpose Code: The code that indicates the category of the payment and aims to give the bank a processing/prioritisation hint. Example: SALA (salary payment), PENS (pension). The idea is that the bank can process a bulk salary file differently according to this.

Important warning: whether a bank actually takes the Category Purpose Code into account, and how it processes it if it does, varies by bank. Entering a code does not mean that behaviour is guaranteed. Also, the code lists are updated over time. That is why we gave above only commonly known codes as examples; always verify that the code you will use is current and valid via the ISO 20022 External Code Sets. If it is not verified that a code in the list will produce a specific result at your bank, do not assume it for certain.

Seeing the fields together

The table below summarises the purpose of these fields, who fills them in and their approximate character limits. Because the limits can vary by the version of the EPC Implementation Guideline, they are given as "approximate".

Field	Purpose	Who fills it in	Character limit (approximate)
EndToEndId	End-to-end technical reference; automatic matching	Sender (person/software)	~35, limited character set
Remittance — unstructured	Free note the recipient will read	Sender	~140 (SCT)
Remittance — structured (ISO 11649 RF)	Reconciliation reference with a check digit, for automatic matching	Usually set by the creditor, entered by the sender	RF + at most 21 characters
Purpose Code	The purpose of the payment (e.g. SALA, SUPP, RENT)	Sender (optional)	4-letter code
Category Purpose Code	Category/processing hint (e.g. SALA, PENS)	Sender (optional)	4-letter code

Do not confuse it with the UETR (that is SWIFT)

A frequent mistake is thinking the EndToEndId is the same as the UETR. The UETR (Unique End-to-end Transaction Reference) is a reference specific to SWIFT gpi and is generated in UUID format (a standard 36-character identity). Its purpose is to track an international SWIFT payment end to end across the network. The UETR belongs to a different network (SWIFT) and a different purpose (payment tracking); it should not be confused with SEPA's EndToEndId. In short: the EndToEndId is the matching reference of the SEPA/ISO 20022 world, and the UETR is the tracking identity of the SWIFT world. Because euro transfers between Turkey and Europe are usually made with SWIFT, it is normal for you to see a UETR in that corridor; this can be an indication that the transaction is processed as SWIFT rather than SEPA.

In practice: how you fill in and see these fields

If you are preparing a payment file (ISO 20022 pain.001), each of these fields is written into the relevant sections of the message: the EndToEndId into the reference field of the payment item, the remittance into the structured or unstructured remittance section, and the purpose codes into their own fields. To try out the structure of the fields and see their format, you can use the pain.001 generator tool.

After the payment has taken place, these references also appear in the account statement. When the bank statement comes in the ISO 20022 camt format (for example camt.053), the EndToEndId and remittance fields are in the relevant transaction record; in this way you can match the reference you sent with the incoming record. To make a camt file readable, you can look at the camt converter tool. These tools run entirely in your browser; the data you enter is not sent to a server.

Summary

In a SEPA payment, the EndToEndId is the technical/matching reference and is carried unchanged (default "NOTPROVIDED"); the remittance field can be unstructured free text (~140 characters) or a structured ISO 11649 RF reference. The purpose codes (Purpose and Category Purpose) indicate the nature of the payment but their effects vary by bank and the code lists are updated. None of these is the same thing as the UETR specific to the SWIFT network. Because the exact formats and behaviours depend on the version of the EPC Implementation Guideline, in critical integrations you need to verify the current code lists from the ISO 20022 source.