← All guides

Charge bearer SLEV: what ChrgBr must be for SEPA credit transfers

Why SEPA files must carry ChrgBr = SLEV, what the four charge codes actually mean, and why ERP defaults keep sneaking DEBT and SHAR into euro payment files.

Four short codes decide who pays for a payment, and one of them causes a steady drip of rejected SEPA files. The element is ChrgBr, the charge bearer, and it appears in every payment block of a pain.001 file. The ISO standard allows four values. The SEPA scheme allows exactly one of them: SLEV. When an ERP system exports a euro payment with one of the other three codes — usually because the same template also handles international payments — the file can pass every generic check and still be rejected by the bank’s scheme validation. This guide explains what the codes mean, why SEPA insists on SLEV, where the wrong values creep in, and how to keep them out.

The four codes and what they promise

DEBT means all charges are borne by the debtor: the sender pays every fee along the way, so the beneficiary should receive the full amount untouched. CRED is the mirror image: all charges are borne by the creditor, deducted from the payment as it travels. SHAR means shared: each side pays the charges of its own bank, the classic arrangement for international wires. SLEV is different in kind: it says charges are handled following the rules of the service level — here, the SEPA scheme. Under the scheme, a SEPA credit transfer is executed for the full amount, the debtor pays their own bank’s charges, and the creditor pays their own bank’s charges, with no deductions from the principal in transit. SLEV is the only code that describes how SEPA payments are actually required to behave, which is why the rulebook demands it.

Why does the scheme care so much about a code that sounds like bookkeeping? Because the promise behind SEPA is that a euro payment arrives whole. If charges could be deducted along the way, a supplier expecting 1,000.00 might receive 985.00 with no explanation, and reconciliation across Europe would drown in small unexplained differences. The full-amount rule makes the amount in the file equal the amount credited, always, which is also what makes control totals meaningful: the CtrlSum in your file describes real money movement, not money movement minus mystery fees. The charge code is the switch that declares which world the payment lives in, and SLEV declares the SEPA world. It is a small element carrying a large promise, which is why validators — ours included — treat a wrong value as an error, not a warning.

Where the wrong code comes from

Nobody types ChrgBr by hand. The wrong value is always a default that travelled. The most common story is a shared template: the ERP uses one payment format for euro SEPA payments and for international payments in other currencies, and the international side legitimately wants SHAR or DEBT, so the shared template stamps that code on everything. Second story: an older domestic format was migrated to pain.001 and its charge convention came along unexamined. Third story: the value is derived from master data — a per-supplier or per-bank charge setting captured years ago for a different payment type. In every story, the person exporting the file sees nothing wrong, because the value looks plausible and the file is structurally perfect. This is a textbook case of the valid-but-rejected gap we describe in our guide to bank implementation guidelines: the schema cannot help you, because all four codes are legal XML values.

Notice also where ChrgBr sits: in the payment information block, not in each transaction. A file with several payment blocks — say, one for salaries and one for suppliers — carries the code once per block, and the blocks can disagree. Mixed files are therefore a real pattern: the salary block correctly says SLEV because payroll set it up, the supplier block says DEBT because accounts payable inherited a different template, and only one block gets the file rejected. When you hunt a charge-bearer error, check every block, not the first one. Validators that report the block and the batch context save real time here, and ours names the payment block and the batch booking flag involved so you can find the template that produced it.

How to fix it — and keep it fixed

The immediate fix is one word: set ChrgBr to SLEV in every payment block of every SEPA file. The durable fix is to find where the value is decided and pin it there. In most ERPs the charge bearer comes from the payment method, the payment type configuration, or the house bank settings; locate the setting that governs SEPA credit transfers and set it once, centrally, rather than letting each template or company code choose. Then do the unglamorous verification work: export a test file for each payment type you run — salaries, suppliers, one-off payments, direct-debit refunds if you originate them as credit transfers — and check the code in each block of each file. Templates multiply silently in ERP systems, and a fix applied to the template you use daily does nothing for the quarterly one that nobody remembered.

• One rule to write down: SEPA euro credit transfer means SLEV, always, in every PmtInf block.
• Audit the templates, not the files: fix the setting where the export is configured, then regenerate a sample of every payment type.
• Re-check after upgrades and migrations: charge defaults are classic silent-reset settings.
• Do not mix payment worlds in one file: if a run contains both SEPA and international payments, split the exports so each carries its own conventions.
• Add ChrgBr to your pre-flight checklist: it is a one-second machine check that prevents a whole-file rejection.

A word on exceptions, because someone always asks. Are there euro payments where another code is right? Outside the SEPA scheme — for example certain TARGET or high-value payments, or euro payments routed as international wires — other codes can be legitimate, and the pain.001 standard supports them for exactly those cases. The rule in this guide applies to SEPA credit transfers under the EPC scheme, which is what the overwhelming majority of euro business payments are. If a payment genuinely travels outside the scheme, it does not belong in the same file as your SEPA run anyway. When in doubt, the test is the scheme: if the file claims SEPA processing, the charge bearer says SLEV.

What actually happens to the charges under SLEV

SLEV is sometimes misread as “no charges”, which it does not promise. Your bank may still charge you for the payment service — a per-item fee, a monthly bundle — and the creditor’s bank may charge them for receiving. What SLEV fixes is where those charges are collected: from each customer’s own account, under their own agreement with their own bank, and never by skimming the payment in transit. The amount that leaves your account as principal equals the amount credited as principal, and any fees appear as separate, explainable bookings. That separation is what makes SEPA payments reconcile cleanly: the invoice amount, the file amount and the credited amount are one number, and fees live in the fee line where accountants expect them. Under CRED, by contrast, the credited amount depends on every intermediary’s tariff, so the same 1,000.00 payment can arrive as three different amounts at three banks — a reconciliation riddle that no reference number can solve. When a supplier complains they were short-paid on a SEPA payment, a wrong charge code in the originating file is one of the first things to check, because the shortfall pattern matches deduction en route exactly.

It also helps to know that the other three codes are not villains in their own worlds. DEBT is the honest choice when a sender genuinely contracts to deliver a full amount internationally and pay all transfer costs — common in treasury and trade contexts, priced accordingly by banks. SHAR remains the default grammar of classic correspondent banking, where each side paying its own institution is the fair split and both sides know deductions are not the model. CRED serves arrangements where the beneficiary has agreed to absorb costs, for example inside a group that nets fees centrally. The codes fail only when they emigrate: carried by a shared template into a scheme whose rulebook has already made the decision for everyone. SEPA’s designers removed the choice deliberately, because a scheme in which every payment negotiates its own charge logic cannot promise the one thing SEPA exists to promise — that a euro sent is a euro received, identically, in 41 countries. SLEV is simply that promise, encoded in four letters in your file.

A thirty-second audit you can run today

Here is the whole topic compressed into a test. Take the last SEPA file your bank accepted and the next one your system is about to produce. In each file, find every payment information block and read its ChrgBr value aloud. Every value should say SLEV, in both files, with no exceptions and no variety. If any block says anything else, you do not have a mystery; you have a template or a setting to fix, and this guide has told you where those live. If both files are uniformly SLEV, your remaining charge-bearer risk is change itself: the next ERP upgrade, the next template someone clones for a new company code, the next payment type added in a hurry. Guard against that day by writing the rule where the next implementer will trip over it — in the payment-type configuration’s documentation, in the export checklist, and in the validation step that runs before upload. Rules that live only in one person’s memory retire when that person does; rules that live in checklists and validators keep working. Four letters, one value, zero variety: that is the entire audit, and it takes less time than reading this paragraph did.

If you inherit a payment setup from someone else — a new job, an acquisition, a system you did not implement — put ChrgBr on your first-week checklist, alongside the debtor account and the pain.001 version. Inherited setups fail in inherited ways, and charge settings are among the most inherited things in finance IT: chosen once for reasons nobody recorded, copied into every template since, and invisible until a bank enforces the rule on a day when the payment cannot be late. Thirty seconds of reading values in a sample file tells you exactly which inheritance you received, and whether it will survive first contact with the bank.

Charge bearer mistakes are among the cheapest rejections to prevent and the most embarrassing to explain, because the fix is a single word and the cause is always an inherited default. Fold the check into your routine: validate the file before upload and a wrong ChrgBr is flagged with its block and the value found, before the bank ever sees it. If your team runs many files, the paid plans check every block of every file in a batch — see pricing — and the report becomes the evidence that the setting stayed fixed. And if this guide found you after a rejection, take heart: of all the reasons in our rejection roundup, this is the one you can retire permanently in a single afternoon.