For SEPA payments, use structured code fields whenever your bank or payment file supports them, and keep the “mokėjimo paskirties laukas” itself short and purely descriptive. For administrative fines and tax obligations, the ROIK (violation ID) and įmokos kodas must go into their own dedicated fields, never buried in free text. Follow SEPA’s character limit for free-text payment purposes, which is shorter than before and the guidance from VMI and VATESI to the letter. Reconciliation gets far easier on both ends.

TL;DR:

Using structured purpose codes properly can streamline payment routing and reconciliation, especially with ISO 20022 standard elements now prioritized by banks.

Payment purpose fields are limited to 140 characters in SEPA, so including invoice or reference numbers upfront improves processing speed and accuracy.

For Lithuanian administrative fines, the violation ID (ROIK) and payment code (įmokos kodas) must go into dedicated fields, not the general purpose description.

Automating reference entry with templates and validating IBANs before payment reduces delays, errors, and the risk of requests for additional information.

Relying solely on vague free text triggers RFIs, causes settlement delays, and complicates regulatory reporting; structured data significantly lessens these issues.

DemivoltMake SEPA Payments Easier to ControlDemivolt helps businesses manage dedicated IBAN accounts, SEPA payments, and payment operations through compliant digital-first infrastructure.Explore Demivolt

SEPA Rules That Shape What Goes in the Payment Purpose Field
Paying Fines and Taxes: Where ROIK and Įmokos Kodas Actually Belong
Copy-Ready Templates for Common Lithuanian Payment Scenarios
The Real Cost of Getting the Payment Purpose Wrong
What a Regulated Fintech Recommends Before You Hit Send
Structured Payments Are Where Lithuanian Banking Is Headed
Reduce Payment Errors With Demivolt’s IBAN Tools
Where These Rules Come From
Sources
FAQ

SEPA Rules That Shape What Goes in the Payment Purpose Field

SEPA cut the free-text purpose field from 300 characters down to 140, and that shorter limit is not arbitrary. It exists because the ISO 20022 messaging standard built dedicated structured elements, purpose codes and Category Purpose, specifically so banks would stop relying on loosely typed sentences to figure out what a payment is for.

A purpose code (like SALA for salary or SUPP for supplier payment) travels with the payment message itself, in a field separate from your free text. Category Purpose works at a broader level, telling processing banks how to treat a batch of payments. Free text, meanwhile, stays what it always was: a note for the human on the other end, not something automated systems reliably parse.

When mapping an invoice or reference into SEPA’s allowed fields, work through this order:

Put the invoice number or internal reference first, since that’s what your accounts payable software will search for.
Add the creditor or debtor short name if space allows.
Skip filler phrases like “for services rendered” or “payment as agreed.”
Use a structured purpose code instead of free text wherever your bank’s platform exposes that option.

Standardized purpose codes exist for a reason: processing banks that receive a recognizable ISO 20022 purpose code can route and reconcile a payment automatically. A vague description forces a human to intervene, and that’s exactly the moment a Request for Information gets triggered, according to SWIFT’s guidance on ISO 20022.

Paying Fines and Taxes: Where ROIK and Įmokos Kodas Actually Belong

Administrative payments in Lithuania run on a different logic than a regular invoice settlement, and treating them the same way is the single most common mistake finance teams make. VATESI states plainly that the payment purpose field should not carry the identifying information for an administrative fine. Instead, the violation identification code, known as ROIK, belongs in its own dedicated field, alongside the correct įmokos kodas.

For a straightforward tax liability, that įmokos kodas is often something like 1001. VMI’s own instructions walk through exactly where that code goes on the online payment form, and the same page explains that the “Unique payment code” field (Unikalus mokėjimo kodas) is where a ROIK gets entered for a fine specifically, not the general purpose box.

Before you send anything to a government recipient, run through this:

Confirm the exact įmokos kodas for the obligation type. Codes differ between tax categories, fines, and fees.
Enter the ROIK in the dedicated code field, not appended to the free-text description.
If you’re paying from a foreign bank, include your payer identifier wherever the form allows one, and follow the specific paying instructions listed on the recipient’s own page.
Double-check the recipient account number against the current official listing, since these occasionally change.

Pro Tip: Keep a short internal reference sheet of the įmokos kodas values your business uses most often to collect dance studio payments online. Finance staff searching for the right code mid-payment is where errors and delays start.

Copy-Ready Templates for Common Lithuanian Payment Scenarios

Most reconciliation headaches come down to one thing: someone typed a description instead of the identifier the receiving system actually needs. These templates solve that.

Domestic supplier invoice. Enter: INV-2026-0417 Baltic Supplies UAB. Keep the invoice number first, since that’s what accounting software scans for, and the short creditor name second.
Invoice payment from abroad. Enter the invoice ID and your own reference in whatever field your foreign bank exposes for a payer reference, separate from the free-text purpose: Invoice 2026-0417, Ref BUYER-88213.
Administrative fine. Structured fields carry the code and ROIK; the free-text field stays minimal or blank, since VATESI’s guidance is explicit that the fine identifier does not belong there.
Fee or permit payment. Enter: Įmokos kodas 1024, permit renewal 2026. Short, identifying, and matched to the exact code the issuing agency requires.

Character limits matter here. SEPA gives you 140 characters, but the useful information usually fits in under 40. Abbreviate the description, never the invoice number or code, since that’s the piece the recipient’s system actually reads.

Here’s what not to do:

“Payment for services” is the phrase that shows up more often than any other on flagged transactions. It tells a receiving bank nothing about which invoice, which obligation, or which department the money belongs to, and that ambiguity is precisely what triggers a manual review.

To convert an internal payment instruction into something copy-ready: pull the invoice or code number first, strip any explanatory language, confirm the character count fits the field, then paste the identifier into the structured field if one exists rather than the description box.

The Real Cost of Getting the Payment Purpose Wrong

A missing or vague purpose field doesn’t just look sloppy. It has a direct operational cost. Intermediary banks and payment processors can issue a Request for Information when structured data is absent, and that single step can add days to settlement, according to SWIFT’s own guidance on payment messaging.

Beyond delay, incomplete codes cause misallocated payments, meaning your finance team spends hours tracing where a transaction actually landed instead of closing the books. There’s also a compliance angle: structured purpose data and proper regulatory reporting elements reduce the odds a payment gets held for anti-money-laundering screening. The fix isn’t complicated. Keep a consistent internal reference format for every recipient type, and maintain a short mapping table so anyone on the team enters the same code the same way every time.

What a Regulated Fintech Recommends Before You Hit Send

A short pre-send routine catches most of the errors that cause payment friction later. Validate the IBAN format, confirm the beneficiary name matches what the receiving bank expects, and enter the invoice ID in a standard short format like INV-2026-0417. For government payments, put the ROIK and įmokos kodas in their dedicated fields, never folded into the description.

Standardize internal references (INV-YYYY-####) so reconciliation software matches payments automatically.
Run every IBAN through a validator before submitting a payment file.
Where your payment system supports it, preview the SEPA XML output to confirm the purpose code mapped correctly.
Build compliance fields like purposeCode into automated payment files whenever the corridor requires them, a practice detailed in this SME payment compliance checklist.

Pro Tip: Run a test payment through your IBAN checker before the first transaction to a new recipient. It takes seconds and eliminates one of the most common causes of returned payments.

Structured Payments Are Where Lithuanian Banking Is Headed

Free-text purpose fields are already fading in importance, and that trend will keep accelerating. As more banks and payment platforms expose ISO 20022 purpose codes directly in their interfaces, businesses that standardize their internal references now will avoid the bulk of future RFIs.

Systems capable of populating a proper purposeCode automatically will settle faster and require less manual reconciliation than ones still typing descriptions by hand. The practical move for any finance team is to start with fixed templates today, then automate the mapping once volume justifies it.

— dd

Reduce Payment Errors With Demivolt’s IBAN Tools

Getting the payment purpose field right matters, but it only helps if the IBAN behind it is correct too. Demivolt built a free IBAN validator that checks format and country-specific rules before you submit a payment, catching the input errors that cause returns and delayed settlements long before they reach a bank’s processing queue.

For businesses managing regular SEPA and administrative payments, that single check can save the hours otherwise spent tracing a misrouted transaction. Pair it with Demivolt’s explainer on IBAN structure if your team needs a refresher on why each segment of the number matters for reconciliation. Run your next payment’s IBAN through the validator before you send it, and build that check into your standard pre-send routine going forward.

Where These Rules Come From

Every rule above traces back to a public source you can verify directly: VMI’s payment code guidance, VATESI’s SEPA fine instructions, and SWIFT’s ISO 20022 purpose code documentation. For reconciliation workflow details, Demivolt’s payment reconciliation guide and international payment checklist go deeper on execution.

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

FAQ

What Is the Character Limit for the SEPA Payment Purpose Field?

SEPA limits the free-text payment purpose to 140 characters, down from the earlier 300 character allowance, and structured fields are preferred wherever the payment system supports them.

What Is Įmokos Kodas 1001 Used For?

Įmokos kodas 1001 is one of the standard codes VMI assigns to specific tax liability categories, and it must be entered in the designated code field when paying that obligation.

Why Did My Payment Get an RFI (Request for Information)?

Banks issue an RFI when a payment lacks clear structured purpose data, which most often happens when a sender relies on vague free text instead of an invoice number, code, or ISO 20022 purpose code.

Can I Use Free Text Instead of a Structured Code?

For most invoice payments, brief free text works if it includes the invoice number, but for administrative fines and certain tax payments, VMI guidance since January 2016 specifies that the general payment purpose field should not be relied on at all.

Does Demivolt Help With Payment Accuracy?

IBAN validators check account format and country rules before you send a payment, reducing the input errors that most often trigger returns or reconciliation delays.

140 Character SEPA Rule: Payment Purpose Templates for Lithuania

Table of Contents