PAYMENT FILE REPAIR · INDEPENDENT RULE

SEPA IBAN errors: check length and MOD97

Open this fictional error →Loads locally; choose Check locally to execute. No XML upload.

Find pain.001 IBAN format, country-length and MOD97 failures locally. Review precise field locations without confusing checksum validity with account existence.

Three questions before sending the batch

An IBAN can look familiar and still contain a mistyped character. The local SEPA-IBAN check asks whether the electronic value uses uppercase letters and digits, whether its length matches the supported country, and whether its remainder is correct. Each question catches a different export defect. A value copied from a printed invoice may contain spaces intended for human reading; the electronic field must be reviewed at the source.

For MOD97, move the first four characters to the end, convert letters to their numeric equivalents, and calculate the remainder incrementally. The expected remainder is one. This implementation does not convert a complete account identifier into a floating-point number, which would lose precision for long accounts. Its supported length table is an independently maintained set of country facts, not a redistributed bank directory.

Follow the reported account location

The fictional French creditor example ends in 606. Changing the last digit to 7 produces the extra-rule failure shown here. XSD can restrict the lexical shape without calculating MOD97. A schema pass therefore does not answer the checksum question. Conversely, a correct checksum does not prove that the schema structure, account owner or payment instruction is correct.

A creditor error appears at /p:Document[1]/p:CstmrCdtTrfInitn[1]/p:PmtInf[1]/p:CdtTrfTxInf[1]/p:CdtrAcct[1]/p:Id[1]/p:IBAN[1]. A debtor error belongs to the account on PmtInf. Use Show XML location to select the reported line. Repeated names elsewhere in the document are not substituted for this field, and foreign namespaces do not count as the selected payment fields.

Resolve the discrepancy without guessing

Ask the payment owner to confirm the intended account through the organisation’s normal process. Do not calculate a new check digit and assume that it identifies the right beneficiary. A technically consistent replacement could still direct money to an unintended account. Correct the ERP master data only after confirmation, then export and validate again.

This check does not contact a bank, discover whether an account exists, perform Verification of Payee, or compare an account holder’s name with an IBAN. Countries outside the local length table are explicitly outside coverage. Poland and Romania are supported here for EUR-SEPA and export flows; a domestic PLN or RON file is a different scope. Complete bank-specific restrictions remain a separate, unverified layer.

Before and after

Before: business check fails

<IBAN>FR1420041010050500013M02607</IBAN>

After: this field passes

<IBAN>FR1420041010050500013M02606</IBAN>

These fragments belong to the complete fictional .09 file. The field correction alone is not proof of complete file validity. Download the broken example · Download the corrected example.

Account-check boundaries and sources

The EPC SCT customer-to-PSP guidelines describe the payment implementation context. For the message structure itself, obtain the selected artifact from the official ISO archive. Account checksum arithmetic is an additional independent factual check; it cannot replace a bank account verification service.

Bank-specific formats and their supported periods must be confirmed separately; the DK format lifecycle is one relevant primary reference. The local checker notices explain the supported artefact and processing boundaries. No bank directory or protected rulebook is shipped with this guide.

Run the payment check

SEPA pain.001 validator · Related SEPA repair guide · Pro / Team for recurring batches