SEPA purpose code: what it is and how to use it correctly
2026-07-19
The bulk transfer has to go out today. The IBAN columns are checked, the amounts are correct, the remittance information is entered. Then, in the export or in the import mask, a field appears that slows many teams down: the Purpose Code, sometimes also called the business transaction code or payment purpose code.
At this point, unnecessary uncertainty often begins. Does the field always have to be filled in? Isn’t the remittance information enough? And if a code is needed after all, which one fits salary, pension, rent or a trade payment?
This is exactly where expensive mistakes happen. Not because the SEPA standard is incomprehensible, but because theory, banking practice and software masks often get muddled. For accounting, treasury and developers, one thing is therefore especially important: knowing when a SEPA Purpose Code is actually relevant, where it sits in the XML, and when to deliberately leave the field empty.
Introduction: the SEPA Purpose Code in practice
A typical situation in the finance department looks like this: you are preparing a payment file for several recipients. Some are salary payments, some are ordinary supplier invoices. On export from ERP, banking tool or Excel, an additional field appears. It is not called the same everywhere, but the effect is the same. Someone on the team asks: “Should we enter something everywhere, just so the bank doesn’t reject anything?”
That is understandable. Out of caution, many teams treat the field like a mandatory field. But that is exactly what often leads to the wrong decisions. An unnecessary code creates additional maintenance effort. An unsuitable code can trigger checks or follow-up questions. And if no one internally documents cleanly why a certain code was used, the file is corrected manually again on the next run.
Practical rule: Just because a field technically exists in payments does not automatically mean it is required in practice.
With the SEPA Purpose Code, it is therefore not just about formalities. It is about clean payment processes. Anyone who understands the purpose of the field can distinguish between: - a genuine must, when rules or process logic require it, - a sensible use, when the classification brings advantages, - a deliberate omission, when a standard payment does not need an additional code.
For accounting teams, this is the most important relief. They do not have to reflexively fill every new XML field. They only need to know which fields are relevant for the specific payment type.
What is a SEPA Purpose Code
The SEPA Purpose Code is a standardized code that classifies the purpose of a payment. In practice, you can think of it like a technical label. Instead of the bank or recipient system having to interpret the free text in the remittance information, the payment type is provided in structured form.
The practical core
An analogy is especially helpful here. In the SEPA XML, the Purpose Code functions as the technical equivalent of the former DTA text key. According to Windata on the function of SEPA Purpose Codes, it enables the automatic classification of transfers and direct debits by payment service providers. This can have concrete consequences in processing, for example in the automatic calculation of account maintenance fees or in granting overdraft facilities for salary payments.
This is the point many misunderstand. The Purpose Code does not replace the remittance information. It fulfills a different task. The remittance information explains to a human what it is about. The Purpose Code classifies the payment for systems.
Where it differs from the remittance information
The remittance information is free text. It contains, for example, an invoice number, a service month or an internal reference. That is important for reconciliation and posting.
The Purpose Code, by contrast, is structured. It answers not the question “which invoice?”, but rather “what kind of payment is this?”.
A simple picture:
| Element | Task |
|---|---|
| Remittance information | Human-readable information for recipient and accounting |
| Purpose Code | Structured classification for technical processing |
A clean remittance information helps your accounting. A fitting Purpose Code helps systems classify the payment.
Where the code technically ends up
In the ISO 20022 format, the code is passed in the XML as an element within <Purp><Cd>. So if a payment run contains a Purpose Code, standardized information becomes part of the message, not just a freely worded note.
For accounting and ERP teams, this is decisive, because two levels should thereby remain separate:
- the substantive description in the remittance information,
- the technical categorization in the Purpose Code.
Anyone who understands this separation saves themselves many discussions during file checking, mapping and bank reconciliation.
Mandatory or optional: the legal context
The most common question can be answered surprisingly clearly. In most cases, the SEPA Purpose Code is not a mandatory field.
Since 1 February 2017, providing the BIC has been dropped for domestic and cross-border transfers in the SEPA context. The IBAN is enough. At the same time, over 99% of all German SEPA transfers have been processed without a Purpose Code since 2017, because the central bank does not prescribe mandatory coding for mass payments. This classification is described by the consumer advice center in its overview of the SEPA rules.
Why the confusion is still so great
The misconception arises because many users mix up three things:
-
The standard knows the field. Anyone who sees an XML schema recognizes the place for the code and concludes that it must always be necessary.
-
Banking software often displays the field visibly. But visible is not the same as mandatory.
-
Some special cases actually need structured information. From this, the wrong rule for all payments is quickly derived.
What this means in practice for companies
For the usual payments of a company, law firm, agency or trading business, in daily life something very down-to-earth usually applies: if the IBAN is correct and the other mandatory details are right, the payment can be processed without a Purpose Code.
This lowers complexity in several areas: - when exporting from ERP or payroll systems, - with Excel or CSV-based payment lists, - during the manual check before the bank upload, - with API-based file generation.
Small and medium-sized enterprises in particular benefit from this, because they do not have to maintain additional classification data per transaction when the process does not require it at all.
When you should take a closer look
Optional does not mean meaningless. There are constellations in which a Purpose Code can be sensible or relevant due to bank-side, procedural or country-specific requirements. This affects above all cases in which a structured classification of the payment is desired.
A helpful decision aid is this:
| Question | Consequence |
|---|---|
| Is it a normal domestic transfer in a retail context? | Often leave the field empty |
| Should the payment be recognized system-side as a specific payment type? | Check a code |
| Are there bank- or process-specific requirements? | Clarify requirements in advance |
Anyone who reflexively treats the Purpose Code as a mandatory field often builds themselves more process load than the standard actually requires.
For compliance and accounting teams, the most important conclusion is therefore not “always fill it in”, but “decide deliberately”.
The most important Purpose Codes and their use
Once the legal pressure is out of the way, the more practical question remains: When is a Purpose Code worthwhile from a business standpoint? The answer is usually: when the payment should be recognizable as a specific category.
Typical codes in everyday work
Some codes appear again and again in practice. Not every one is relevant for every company, but the logic behind them is easy to understand.
| Code | Typical use | Practical example |
|---|---|---|
| SALA | Salary payment | Monthly wage to employees |
| PENS | Pension payment | Payment from a pension case |
| TRAD | Trade-related payment | Payment in connection with a goods or trade transaction |
| CBFF | Capital-forming benefit | Payment into a corresponding savings or investment context |
| RENT | Rent-related payment | Rent payment, when a structured label is desired |
Think in terms of use cases
When choosing, no abstract code list helps, but the question: What should the receiving system recognize?
Take three typical cases:
-
Payroll run from HR accounting When employees should recognize a transfer as a salary receipt, or bank-side processes build on it, SALA is the obvious code.
-
Normal supplier invoice Here, no Purpose Code is often needed. The actual information value usually lies in the remittance information with invoice number, period or creditor reference.
-
Regular rent payment Here too, the field is often not mandatory. If a clean classification is desired internally or system-side, RENT can be a good fit.
What often goes wrong
Many teams make a thinking error. They first look for a code and only then for the actual benefit. This leads to unnecessary over-coding.
This order is better:
-
Determine the payment type substantively Is it salary, pension, trade, rent or simply a normal invoice?
-
Check whether a structured label brings added value Does a bank, a recipient system or an internal workflow really need this information?
-
Only then use the fitting code Otherwise, the field stays empty.
For many payments, no code is the cleanest decision. Not because the field is unimportant, but because unnecessary classification does not produce a better file.
Especially important for salaries
The most common genuine use case in corporate life is SALA. This is because salary payments can be clearly delimited from a business standpoint, and the code can be useful in processing chains.
Even so, the following applies: the code does not replace the rest of the care. For payroll runs, recipient data, due date, amount and remittance information must still be maintained cleanly. The Purpose Code is only additional structured information.
Do not confuse with return codes
Another classic in practice: Purpose Codes are confused with return codes. These are two completely different things.
Purpose Codes describe the type of intended payment. Return codes describe the reason why a bank rejects or reports back a transaction.
Anyone who separates these levels already avoids a large part of the typical errors in day-to-day business.
How the Purpose Code is embedded in the SEPA XML
For developers, ERP managers and anyone who checks or debugs payment files, in the end the technical position in the XML is what counts. The Purpose Code is not somewhere in the free-text area, but at a clear place within the transaction data.
The right place in the message structure
Within a transfer, the code typically sits in the block CdtTrfTxInf. That is where the details of a single transaction are, that is, amount, recipient and references.
The Purpose Code appears as a nested element:
<Purp>- below it
<Cd> - inside it the actual code, for example
SALA
Shown briefly:
| XML element | Meaning |
|---|---|
<Purp> |
Area for the payment purpose as a structured category |
<Cd> |
The specific standardized code |
In practice, this looks something like: <Purp><Cd>SALA</Cd></Purp>.
Why the exact position matters
Banks validate SEPA files not only substantively, but also structurally. A correct code is useless if it ends up in the wrong place in the XML or is written into a free text field.
Typical technical errors are: - the code is placed in the remittance information instead of the Purpose element, - the element is inserted at the wrong level, - the value is formally not a valid code, - a mapping writes the value into an adjacent but substantively different field.
If you check or generate XML files manually, a look at a clean structure helps. Anyone who wants to dive deeper into the structure will find good technical orientation in the article creating a SEPA XML file.
With XML payment files, “almost right” is not enough. A field must not only be present, but also stand in the intended place.
A simple check process
If a payment run stands out because of a Purpose Code, proceed in this order:
- Does the element exist only when it is meant to be used?
- Is the code in the right transaction block?
- Is it a real Purpose Code and not a freely invented short text?
- For bulk files, was the mapping applied correctly for every transaction?
This lets you narrow down many XML errors very quickly, before the file goes to the bank.
Using Purpose Codes easily with GenerateSEPA
In practice, there are two user groups. One works with Excel or CSV and wants to generate a clean SEPA file without XML knowledge. The other automates payment processes from ERP, accounting or a custom application. For both groups, handling the Purpose Code is easiest when it is treated as a normal data field.
For finance teams in the interface
If you prepare payment lists from Excel or CSV, the cleanest way is a separate column for the code. The column can be called, for example, Purpose Code, Purpose or similar. What matters is not the column name itself, but that it is correctly assigned to the field in the mapping.
The workflow is simple: - upload the file - assign the columns to the SEPA fields - pass a code only where it is substantively wanted - generate and check the XML file
This is especially helpful in mixed payment runs. Salary payments can carry a code, normal supplier payments do not. What is decisive is that the mapping does not dilute the logic.
For developers via the API
In the API context, the same idea becomes even clearer. The Purpose Code is then simply an additional attribute in the payload of a transaction. A typical schema works with a field like purpose_code, to which you assign, for example, SALA.
Technically interesting here is less the parameter name than the process idea: - Your application decides substantively whether a code is set. - The interface handles the technical embedding into the XML structure. - The check happens before sending to the bank, not only after a response.
Anyone who wants to build the JSON-based integration for automated processes will find the entry point on the GenerateSEPA API utility page.
The real benefit in operation
The benefit lies not in teams now being able to “fill in more fields”. The benefit lies in business decisions being cleanly translated into technical structures.
This is important in daily life when: - different departments prepare the same payment file, - an ERP natively supports only part of the SEPA fields, - recurring exports from legacy formats are transferred into XML, - developers need to quickly trace follow-up questions from accounting.
This turns a confusing field into a controlled part of the payment process.
Common errors and how to avoid them
The biggest error is rarely a broken XML tag. The biggest error is uncertainty. Teams do not know exactly whether the SEPA Purpose Code is needed, and then react either with over-caution or with improvised entries.
Error pattern one and the mandatory-field trap
A common sequence looks like this: the field is visible, so it is filled in. Not out of substantive necessity, but for reassurance. Then someone writes internal abbreviations into it that sound logical within the company but are not valid codes in the SEPA context.
The problem with this is twofold: - The payment file becomes unnecessarily complex. - Wrong values can trigger checks or rejections.
A simple principle is cleaner: If there is no concrete substantive reason for a Purpose Code, the field stays empty.
Error pattern two and the mix-up with return codes
Standardized codes are known above all as reasons for returns. In its overview of SEPA business transaction codes and return codes, HypoVereinsbank names examples such as LEGL, AC06, AM04 or MD07 for bank-side returned reasons.
These codes do not describe the purpose of a new payment. They describe the reason for a return or rejection. This is exactly where teams often get muddled, especially when they work simultaneously from return lists, bank protocols and XML fields.
When a code comes back from the bank after failed processing, it is usually not a Purpose Code, but a return reason.
Error pattern three and poor mapping
In Excel, CSV or ERP processes, another error usually arises in the mapping: - The column is not clearly named. - A field is accidentally connected to the remittance information. - The code is copied blanketly onto all payments, even though only individual transactions should carry it.
Long policies do not help against this, but clear working rules do:
-
Document the field logic Define internally when a code is maintained and who decides that.
-
Handle mixed files deliberately Salary payments and supplier invoices should not automatically receive the same classification value.
-
Validate before the bank upload Check that only valid codes were used and that the field is really mapped to the correct XML place.
Error pattern four and blind trust in free text
Some teams try to compensate for a missing structured code with wording in the remittance information. This only works to a limited extent. Free text is meant for humans, not for clean technical classification.
So if a certain payment type should really be recognized as such, the information belongs in the structured field provided for it. If that is not necessary, a clear remittance information is entirely sufficient.
In the end, the best error prevention is surprisingly unspectacular: use Purpose Codes only deliberately, do not confuse return codes, and check the mapping consistently.
If you generate SEPA files from Excel, CSV, JSON or legacy formats and want to transfer Purpose Codes cleanly into valid XML, GenerateSEPA is a practical route for finance teams and developers. The platform helps with mapping, reduces typical format errors, and turns raw data into bank-ready SEPA XML files without manual XML editing.
Frequently Asked Questions
- Is the SEPA purpose code mandatory in Germany?
- For most standard domestic SEPA credit transfers in bulk retail payment processing, no. The field exists in the standard but is optional for the vast majority of payments.
- Does the purpose code replace remittance information?
- No. Remittance text is free-form for people and accounting. The purpose code classifies the payment type for systems, such as salary or trade.
- Where does the code appear in SEPA XML?
- In ISO 20022 it typically sits under Purp with child element Cd. Excel or ERP mapping must target that field, not the free-text remittance line.
- What is the most common purpose code mistake?
- Teams confuse them with bank return reason codes or fill every line out of caution. Both add noise — use purpose codes only when they add real classification value.
