← All guides

Creditor reference (RF) and structured remittance information in pain.001

How structured remittance information works: the RF creditor reference with its own mod-97 check digits, SCOR, and why structured references reconcile themselves.

Every payment carries a note that says what it is for. In pain.001 that note is the remittance information, and it comes in two flavours: unstructured, a free-text line up to 140 characters, and structured, a small set of coded fields that machines can read without guessing. The star of the structured flavour is the creditor reference — the RF reference — a code printed on invoices across Europe that identifies exactly which bill a payment settles. When it travels correctly, the receiving system books the payment against the invoice automatically, no human reads anything, and the age-old question of what was this money for never gets asked. This guide explains how structured remittance information is built, how the RF reference protects itself with check digits, and how to choose between structured and unstructured text.

Unstructured versus structured: the basic choice

Unstructured remittance information is one or more free-text lines, the element Ustrd, with a total of up to 140 characters per payment in the SEPA scheme. It is the right tool for human messages: salary November, rent for the Berlin office, thank you for the catering. Its weakness is that it is prose. The receiver’s software cannot reliably extract an invoice number from a sentence, especially when senders improvise formats. Structured remittance information, the Strd block, instead carries typed pieces: a creditor reference with the code SCOR that declares what kind of reference it is, fields for referred documents, dates, and amounts. The receiver does not parse; it reads. If your payments exist to settle invoices — most business payments do — structured information is what turns reconciliation from a monthly chore into a non-event.

SEPA payments generally carry either unstructured or structured remittance information for a payment, and bank guidelines are firm about not mixing expectations: if the invoice shows an RF reference, that reference belongs in the structured block as the creditor reference, not typed into the free-text line. Putting the right data in the wrong container is a quiet failure: the payment succeeds, the money arrives, and the automatic matching fails anyway, because the receiving system looks for the reference in the structured field and finds a sentence instead. Nobody gets an error. The accounts team just inherits a manual matching job and a vague feeling that automation does not work. Data placement is a feature, and this is one of the places it shows.

Anatomy of an RF reference

An RF reference starts with the letters RF, followed by two check digits, followed by the reference itself — up to 21 more characters of letters and digits, for a maximum of 25. An example looks like RF18 5390 0754 7034. The reference part is chosen by the creditor whose invoice it is: often a customer number plus an invoice number, padded or arranged to the creditor’s liking. The check digits are not decoration; they are computed with exactly the same mod-97 machinery that protects IBANs, which is no coincidence — the RF standard (ISO 11649) borrowed the strongest typo detector in payments. If you understand IBAN check digits, you already understand these. If not, our mod-97 explainer works the arithmetic in plain steps, and everything there transfers directly.

To validate an RF reference by the book: take the whole reference, move the first four characters (RF and the check digits) to the end, convert letters to numbers with A as 10 through Z as 35 — R becomes 27, F becomes 15 — and divide by 97. A correct reference leaves remainder 1. A single mistyped digit anywhere in the reference breaks the remainder. This has a practical consequence for accounts payable: when your system imports an invoice, validating the printed RF reference on entry catches OCR errors and manual typos at the moment they enter your data, weeks before the payment run. A reference that fails its check digits should never be paid as-is, because the money will arrive unmatchable — the creditor’s system will reject the reference, and a human at their end inherits the same detective work you were trying to avoid.

Where the reference sits in the file

In the XML, the structured block lives inside each transaction’s RmtInf element. The creditor reference itself sits in the path for structured remittance, under the creditor reference information: a type block that says this is a SCOR reference (the code for a structured creditor reference, with the issuer typically the creditor), and the Ref element holding the RF value itself, without spaces. The spaces in printed references are for human eyes only; in the file the reference is one continuous string, and including the spaces can break both the format and the check. While you are in that part of the file, note the neighbouring fields the structured block offers: referred document information for invoice numbers and dates, remitted amounts for part-payments, and tax remittance details. Most teams use only the creditor reference, which is fine — it is the field the matching engines actually key on.

Rules and limits worth memorising

• The RF reference is at most 25 characters in total: RF, two check digits, and up to 21 characters of reference.
• In the file it carries no spaces, even when the invoice prints it in groups of four.
• The check digits follow ISO 11649 and the mod-97 test: rearrange, convert, divide, remainder 1.
• If an invoice shows an RF reference, put it in the structured creditor reference field — not in the free-text line.
• Characters are letters and digits only; the reference lives happily inside the SEPA character set by construction.
• Do not invent an RF reference when the invoice does not have one: a fabricated reference matches nothing and can mislead the creditor’s matching. Use unstructured text instead.

One more limit catches people: the EndToEndId is not a remittance reference. Teams sometimes copy the RF reference into EndToEndId thinking it will help matching, or leave EndToEndId as a constant because the real reference lives in RmtInf. The two fields do different jobs — EndToEndId is your identifier for the payment itself, as our identifiers guide explains — and the creditor’s matching engine reads the creditor reference from its own field. Keep each datum in its own home and both systems work; merge them and both jobs get done badly. Structured data rewards tidiness with interest.

What good looks like, and how to check it

In a healthy accounts-payable flow, the reference is captured once, from the invoice, validated on entry (format and check digits), stored with the payable, and placed into the structured field at export without human retyping. The payment run then validates the file as a whole, reference included, so a reference that broke somewhere in the chain is caught before the bank sees the file. Our validator checks RF references with the mod-97 test and flags references placed in free text when they clearly follow the RF pattern — a small nudge that has saved many reconciliation afternoons. You can validate a file free on the home page to see both checks on your own data; teams that pay hundreds of invoices per run usually move to batch validation, covered on the pricing page.

National references and other structured variants

The RF reference is the international member of a family. Several countries ran structured reference schemes long before ISO 11649 — Finland, the Netherlands, Belgium, Norway and others have domestic reference traditions with their own lengths and check digits, and creditors in those markets still print them. The structured block accommodates them through the same SCOR type: the code declares the reference is a structured creditor reference, and the format follows the applicable scheme’s rules, national or international. Two practical consequences follow. First, do not force every reference into RF shape: if the invoice carries a national reference, send it as issued, in the structured field, without inventing an RF wrapper. Second, expect your validation to be scheme-aware: a reference that is perfect under Finnish rules is not judged by RF’s 25-character limit, and software — ours included — treats the RF test as applying to references that claim to be RF, while format and placement checks apply to all. When you onboard suppliers from a new country, ask one question early — what reference do your invoices carry, exactly as printed? — and record the answer in the supplier’s master data next to the IBAN, because reference format is master data too.

There is also a humble middle option worth knowing: the structured block can carry the referred document information — the invoice number and date as typed fields — even when no formal reference scheme is in play. It is more work to populate than a free-text line, and matching engines weight a true creditor reference more heavily, but typed invoice fields still beat prose for receivers whose systems extract them. Teams migrating gradually often start by moving the invoice number from the sentence they used to type (“Payment for invoice 1042 thank you”) into the structured document field, and add real RF references as suppliers provide them. The direction matters more than the speed: every payment that carries its meaning in fields instead of sentences is a payment that reconciles itself, and the stock of sentence-payments shrinks with every new supplier onboarded the tidy way.

What should you do when a payment must settle several invoices at once — the monthly statement run, the consolidated supplier payment? The structured block was designed with this in mind: it can carry the creditor reference for the statement the creditor issued, or the referred-document details for the individual invoices being settled, and the remitted amount fields let you state how the lump sum divides. The discipline that makes it work is the creditor’s: if they issued one statement reference, use it and let their system do the allocating it was built to do; if they did not, list the documents you are settling rather than squeezing five invoice numbers into a free-text sentence with commas, where the fifth one silently falls off the 140-character cliff. And never pay a round sum against a pile of invoices with no references at all and a note saying “as agreed”: the creditor’s team will apply it to the oldest invoices, which may not be the ones you meant, and the disagreement will surface a quarter later as a dunning letter for an invoice you paid in a lump you cannot prove. References are how money explains itself after it arrives. Give every lump sum an explanation in fields, and it will never need a meeting.

The payoff for this tidiness is easy to understate because it looks like nothing happening: payments match themselves, the suspense account stays empty, and the month-end close stops depending on one person’s memory of which supplier writes references in which format. Structured remittance information is the part of ISO 20022 where the standard’s promise — rich data, travelling intact — becomes visible in daily work. An RF reference is 25 characters at most. Getting them right is one of the highest-return habits in the whole payment process, and it starts with treating the reference as data with a checksum, not as a comment.