A SEPA pain.001 file is an XML payment order based on ISO 20022. Your company sends it to its bank to start one or many SEPA credit transfers at once. In Lithuania, the Lithuanian Banking Association (LBA) rules, version 4, describe the pain.001.001.09 message for this purpose. Most rejections come from the same few problems: a wrong IBAN, mismatched control totals, bad characters, or a bank-specific rule the base schema does not cover. This guide explains the structure, the validation steps and the fixes.

DemivoltManage SEPA Payments with Business BankingDemivolt provides business banking with SEPA payment support, dedicated IBAN accounts and tools for managing business payments.Visit Demivolt

TL;DR

pain.001 is the XML format for sending SEPA credit transfers to a bank. It is a structured, machine-readable payment order, not a document for people to read.
The LBA v.4 rules, effective 5 October 2025, describe pain.001.001.09 for the customer-bank space in Lithuania.
Every file has one Group Header, then Payment Information blocks, then transaction blocks. The header’s transaction count and control sum must match the payments inside.
Validate in three layers: XSD schema, SEPA business rules, then your bank’s own profile.
Your bank answers with a pain.002 status report. It confirms receipt and validation, not execution.

What a pain.001 file is and who uses it
Which version applies in Lithuania
Structure of a pain.001 file
How to build a clean file: six checks
Three layers of validation
Why Lithuanian banks reject files
Reading the pain.002 status report
What pain.001 does not cover
Cost of SEPA transfers at Demivolt
Our perspective
Open a business account for your payment runs
FAQ
Sources

What a pain.001 file is and who uses it

pain.001 is the customer credit transfer initiation message of the ISO 20022 standard. The European Payments Council (EPC) standardized its SEPA use. Companies, public bodies and financial institutions use it to send payment orders to banks across the 36-country SEPA zone. The same source notes it has largely replaced older national formats such as CFONB in France, DTA in Germany and CLIEOP in the Netherlands.

For a finance team, the practical meaning is simple. Your accounting or ERP system exports a batch of supplier payments, salaries or refunds as one XML file. You upload it to the bank, or send it through an integration. The bank reads the file, validates it, and executes the transfers.

A companion format, pain.008, covers the reverse flow: SEPA direct debits, where you collect money from debtors. This article stays with credit transfers, the file most businesses produce every week.

Which version applies in Lithuania

The Lithuanian Banking Association published the rules for using ISO 20022 XML standard messages, version 4, effective from 5 October 2025. The document sets how SEPA credit transfers and account information are exchanged between customers and banks in Lithuania. For credit transfer initiation it describes the pain.001.001.09 message.

If your ERP still produces an older version, such as pain.001.001.03, check with your bank whether it still accepts it and until when. Do not assume the file that worked last year is still valid under the current rules. Bank support pages and the LBA document are the places to confirm this.

Structure of a pain.001 file

The LBA document describes a message with one message root and one Group Header. The header holds five elements:

Message Identification
Creation Date Time
Number of Transactions
Control Sum
Initiating Party

After the header come one or more Payment Information blocks. Each of those holds one or more Credit Transfer Transaction Information blocks.

The Swiss Payment Standards describe the same three levels in plain terms. These are Swiss rules, but the ISO 20022 logic they describe is the same:

Level	Block	Occurrence	What it contains
A	Group Header	Exactly once	Message ID, creation time, transaction count, control sum, initiating party
B	Payment Information	At least once	Debtor (payer) information, execution date
C	Credit Transfer Transaction Information	At least once per B-level	Creditor (beneficiary) information, amount, remittance details

A practical way to think about it: level B is “who pays, from which account, on which date”, and level C is “who gets how much, and why”. One file can hold several B blocks, for example one per debit account or per execution date.

Debtor agent and BIC

The LBA document explains that a BIC identifies a financial institution and can have eight or eleven symbols. The Debtor Agent field needs either the BICFI element, or the Other/Identification element with the value NOTPROVIDED when the BIC is not available. For SEPA payments inside the EEA, the BIC has been optional since 2016, so the IBAN is what routes the payment.

Fields that cause most trouble

Control sum and transaction count: these header values must equal the totals of the payments in the file.
Unstructured remittance information: the EPC business rules limit it to 140 characters.
Charge bearer: the same source lists ChrgBr set to SLEV as mandatory for SEPA.
Names and addresses: the LBA rejection codes show that missing debtor or creditor names and addresses stop a payment.
Characters: only the ISO 20022 Latin character set is accepted, so names with some local letters may need transliteration according to your bank’s guidance.

How to build a clean file: six checks

Whether your ERP generates the file or your engineers wrote the export, run the same sequence before every upload. We cover the same workflow in our guide to stopping SEPA rejections with pain.001.

Confirm the version. Match the pain.001 version to the one your bank’s current rules require.
Validate every IBAN. Run the mod-97 checksum and check the length for the country before the IBAN enters the file.
Count in cents. Calculate amounts and the control sum with integer or decimal arithmetic, never floating point.
Clean the text. Strip or transliterate characters outside the permitted set and trim remittance text to the limit.
Validate against the XSD. Software providers should test each message against the pain.001 schema in advance, because financial institutions reject messages that violate it.
Check the cut-off. Submit before your bank’s deadline for the execution date you want.

Three layers of validation

A file can pass one check and fail the next. Ifriqa’s validator guide describes three independent layers:

Layer	What it checks	Example
1. XSD schema	Document structure, element order, namespace	A missing mandatory element
2. EPC business rules	Field limits, character set, amount precision	Remittance text above 140 characters
3. Bank overlay	BIC routing rules, risk scoring, AML and sanctions checks	A field combination your bank does not accept

The schema only checks structure. As the same vendor explains in a guide on why valid files still get rejected, XSD validation cannot confirm that the control sum matches the transactions or that an IBAN is real. Floating-point arithmetic, the guide says, causes control sum mismatches more often than any other single error.

Banks also define overlays on top of the base schema. A file valid under the ISO XSD may still fail a specific bank’s profile, and the bank may return only a short error code. That is why a test upload or sample-file exchange with your bank is part of any new integration.

Why Lithuanian banks reject files

The LBA v.4 document lists reason codes you can expect to see. Here is what each one means for your file and how to fix it.

Code	Meaning	Typical fix
AC01	Incorrect IBAN	Re-validate the IBAN checksum and length
AG02	Incorrect file format	Check version and message type against the bank’s rules
AM05	Duplicated payment	Check for the same payment submitted twice; vary the identification only for genuinely separate payments
CNOR	Creditor bank not registered with the provided BIC	Correct the BIC or remove it and rely on the IBAN
DNOR	Debtor bank not registered with the provided BIC	Correct the debtor BIC or use NOTPROVIDED
FF01	Invalid file format	Validate against the schema
RC01	Incorrect BIC	Fix the BIC format (8 or 11 symbols)
RR01	Missing debtor account or identification	Fill in the debtor account
RR02	Missing debtor name or address	Complete the debtor details
RR03	Missing creditor name or address	Complete the beneficiary details
TM01	File submitted after the cut-off time	Submit earlier or accept the next execution day

These codes come from the LBA rules. Outside the official document, two further patterns recur in vendor guides. Account identifier errors are the most common cause of SEPA rejections, including bad IBAN checksums, wrong IBAN length and deprecated BICs. Broken totals and characters outside the Latin set are the other regular culprits.

Timing: the TM01 problem

A file that is technically perfect still fails if it arrives too late. Cut-off times decide whether a payment goes out today or the next business day. Our article on SEPA cut-off times in Lithuania explains how to plan batch submission around them. Build the cut-off into your payment run schedule rather than into a last-minute checklist.

Reading the pain.002 status report

Every submitted pain.001 is answered with at least one pain.002. Per the Swiss Payment Standards status report guide, it is an immediate response about the whole message or about individual B-levels. It is not an execution confirmation. The statuses include ACCP, ACWC, PART, RJCT and ACTC.

In practice:

ACTC and ACCP mean the file passed technical validation or was accepted for processing. Money has not necessarily moved yet.
ACWC means accepted, but with a change the bank made.
PART means only some payments were accepted. Find the rejected B-levels and resubmit those.
RJCT means rejection. Read the reason code and use the table above.

An accepted status confirms the bank took the instruction. For confirmation of what actually posted, your finance team needs the account statement. Our guide to camt.053 statement rules covers that side of the ISO 20022 cycle. Banks that report validation results under PSD2 rules follow the same logic; a plain overview of the PSD2 payment services directive helps teams see where these reports sit in the wider framework. For the business obligations that follow from it, see PSD2 requirements for businesses in Lithuania.

A reconciliation habit that works: store the message ID from the Group Header with every batch, then match each pain.002 to it. When a rejection comes back, you can find the original batch in seconds.

What pain.001 does not cover

SEPA credit transfers are euro payments inside the SEPA area. A payment in another currency, or to a bank outside SEPA, goes by a different route, usually SWIFT. If your company pays suppliers in several currencies, plan how you will handle currency exchange for small businesses in Lithuania alongside your euro batches.

For SWIFT transfers, timing and references work differently. Our guides on how long a SWIFT transfer takes and on requesting pacs.008, UETR and Field 20 cover what finance teams should ask for.

Cost of SEPA transfers at Demivolt

Batch payments multiply per-transfer fees, so it helps to know them in advance. These are the fees we publish for payments:

Payment type	Fee
SEPA In	€0
SEPA Out	€0.40 per transfer
SWIFT In	€25.00
SWIFT Out	€30.00
Internal transfers between Demivolt accounts	€0
Account opening, verification and monthly maintenance	€0

A batch of 200 outgoing SEPA transfers therefore carries SEPA Out fees of €80.00 (200 × €0.40). You can model your own volumes with our SEPA fee calculator.

Our perspective

Finance teams usually meet pain.001 when something fails: a batch is rejected on payroll day, or a supplier payment is returned. The format itself is not difficult. What makes it painful is that the checks are spread across three places: the schema, the SEPA rules and the bank’s own profile.

We build our business banking and payment infrastructure for companies that treat compliance and predictability as operating requirements. In our view, a regulated account with a dedicated IBAN, clear role-based access and transparent fees removes much of the friction around payment files. The person who prepares a batch, the person who approves it and the person who reconciles it can each have a defined role.

Our advice to treasury and engineering teams is to validate before sending, store the message ID of every batch, and treat the pain.002 as a receipt, not a settlement confirmation. Where a company runs several entities or currencies, a multi-account structure keeps payment runs separate and easier to reconcile. Our fees are published, so the cost of a batch is known before you submit it.

dd

Open a business account for your payment runs

If your company sends SEPA batches, pays suppliers abroad, or issues cards to staff, Demivolt provides regulated business banking with dedicated IBAN accounts, SEPA and SWIFT payments, Visa business cards, multi-account structures and role-based user management. Client funds are held in segregated accounts. Account opening, verification and monthly maintenance are listed at €0, and every client has access to a Dedicated Client Manager at no one-off fee.

See our payments and business accounts pages, or get started with Demivolt and contact us with your monthly payment volumes.

Industry teams can also review how we support e-commerce businesses, SaaS companies and import, export and wholesale payments. If your ERP drives payments, read our guide to BaaS integration with ERP.

FAQ

What does “pain” stand for in pain.001?

It is the ISO 20022 prefix for the payments initiation message family. The message pain.001 is the customer credit transfer initiation, while pain.002 is the status report and pain.008 is used for direct debits.

Which pain.001 version do I use in Lithuania?

The LBA rules, version 4, effective 5 October 2025, describe pain.001.001.09 for credit transfer initiation. Confirm with your bank which versions it currently accepts, because banks publish their own profiles on top of the standard.

Why was my file rejected when the XML is valid?

Schema validation checks structure only. It cannot confirm that your control sum matches the transactions, that an IBAN checksum is correct, or that your bank accepts a certain field combination. Check the reason code against the LBA list and compare the file with your bank’s profile.

Is the BIC required in a SEPA credit transfer file?

For SEPA payments within the EEA the BIC has been optional since 2016. For the Debtor Agent, the LBA rules accept either a BICFI or the value NOTPROVIDED under Other/Identification.

Does a pain.002 with ACCP mean the money was sent?

No. A pain.002 is an immediate status response about receipt and validation, not an execution confirmation. Confirm execution on your account statement.

SEPA pain.001 File: Structure, Validation and Fixes