BSK implementergsguide ISO 20022 PAIN 001.001.03 ustomer redit Transfer Bankenes felles implementasjonsguide BSK ver. 1.5 september 2014
Versjonsoversikt Dato Ver Utført av endrger 15.01.2012 1.0 orten Holter Første versjon. 15.09.2014 1.5 orten Holter Språklig oppdaterg og rettelser i tabell. Se hange ontrol Innhold Innledng Funksjonell beskrivelse Omfang av meldgssettet eldgsflyt Betalgstyper Kvalitet Eksempler Teknisk beskrivelse Struktur Prciples and rules essage Functionality Functional Structure hange ontrol
Innledng Implementasjonsguiden er utarbeidet i regi av BSK. Denne implementasjonsguiden for ustomerredittransfer meldg er basert på ISO 20022 essage Defition Report (DR) og ommon Global Implementation GI Guide for ISO 20022 ustomerredittransfer Initiation (T) of June 2011. Implementasjonsguiden beskriver hvordan XL ISO 20022 skal benyttes for formidlg av betalgsoppdrag n mot norske banker, og deferer hvilke formasjonser som må være med i et betalgsoppdrag, og som bankene kan formidle videre til betalgsmottakers bank. Implementasjonsguiden kan også være til nytte i planleggg og oppbyggg av ERP-systemer. ISO 20022 essage Defition Report (DR) og essage Usage Guidele (UG) kan lastes ned fra: http://www.iso20022.org ommon Global Implementation arket Practice (ISO 20022 GI P) er et "SWIFT community" itiativ hvis hovedoppgave er å defere én felles standard for implementerg av ISO 20022 meldger til bruk mellom banker og bankenes bedriftskunder. GI Implementasjons er tilgjengelig på GI-P hjemmeside. http://www.swift.com/corporates/cgi/dex?lang=en ålgruppe ustomerredittransfer-meldgen er betalgsstruksjoner til betalers bank som neholder formasjon beregnet på de fansielle stitusjonene som er volvert i betalgen, samt formasjon rettet til betalgsmottakeren. Første del av implementasjonsguiden gir en oversikt på generelt grunnlag om bruk av ustomerredittransfer meldger, med fokus på funksjonalitet og omfang. Denne delen er på norsk. eldgen skal nyttes av oppdragsgiver til å struere betalers bank om å foreta en betalgsoverførg fra en angitt konto, samt gi grunnlag for å gi betalgsmottaker nødvendig formasjon om hva betalgen gjelder. Denne implementasjonsguiden gir flere eksempler på hvordan dette kan gjøres (se kapittelet eldgsflyt). Andre del er en veiledng i hvordan meldgstypen skal implementeres, og er rettet mot teknisk personell. Den er bygget opp i tabellform med detaljert beskrivelse av meldgsstruktur og krav til meldgsnhold, samt eventuelle tilleggsforklarger for å tydeliggjøre bruken av feltene. Denne delen er skrevet på engelsk for å gjøre det enklere å sammenholde detaljer mellom ISO20022- DR, GI- og BSK-, og se hvor det er nasjonale avvik/presiserg. Funksjonell beskrivelse ustomerredittransferinitiation meldgen neholder all den formasjonen de fansielle stitusjonene trenger for å utføre en betalg. En ustomerredittransferinitiation meldg gir fansstitusjonen en struks om å overføre et bestemt beløp i en spesifisert valuta fra en bestemt konto til en bestemt mottakskonto. Det er mulig å overføre flere slike bestillger i den samme meldgen. ustomerredittransferinitiation meldgen kan neholde nødvendig formasjon som gir betalgsmottakeren mulighet til enkelt å matche ngående betalger mot, for eksempel utestående kundefordrger i eget system, ved at fakturanummer eller KID kan følge med som strukturert formasjon. En ustomerredittransferinitiation meldg kan referere til en eller flere fakturaer og kreditnotater, eller andre grunner for betalgen. Omfang av meldgssettet
ustomerredittransferinitiation meldger utveksles mellom en oppdragsgiver (InitiatgParty) og betalers bank (DebtorAgent) eventuelt via en formidler (ForwardgAgent). eldgssettet dekker betalers behov for å itiere betalger, overvåke og admistrere betalgene. eldgstypene er: Denne implementasjonsguiden dekker pa.001.001.03 ustomerredittransferinitiationv03: eldgen brukes til å itiere et betalgsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. Forutsetter avtale mellom betaler og bank/formidler. eldgen ngår i et sett med meldger som er nødvendige for å kunne tilby elektronisk itierte betalgsoppdrag. De øvrige meldgstypene er: pa.002.001.03 ustomerpaymentstatusreportv03: brukes til å rapportere status på betalgsoppdraget. Den blir sendt fra betalers bank eller via formidler tilbake til betaler. Bruk av denne meldgstypen avtales mellom betaler og bank/formidler. camt055.001.01 ustomerpaymentancelationrequestv01: brukes til å sende en stoppordre på et tidligere nsendt betalgsoppdrag. Den sendes fra betaler til betalers bank, eventuelt via en formidler. pa.008.001.02 ustomerdirectdebitinitiationv02 : brukes for kreditoritiert betalgsoppdrag, så som Avtalegiro og Autogiro. Kontakt d bank for å få vite hvilke meldgstyper de supporterer. eldgsflyt ustomerredittransferinitiation meldgen sendes fra Oppdragsgiver/betaler (InitiatgParty) til betalers bank (Debtor Agent), eventuelt via en formidler (ForwardgAgent). Scenariene som er beskrevet, viser forskjellige kunderoller på betalersiden av et betalgsoppdrag, og tilsvarende på betalgsmottakersiden. På oppdragssiden, kan ntil tre roller spesifiseres: InitiatgParty, dvs. den som sender meldgen, Debtor, dvs. eier av konto som skal belastes, og UltimateDebtor, dvs. den som skylder penger til kreditor som følge av mottak av varer eller tjenester. Disse tre rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. ustomerredittransferinitiation meldgen gjør det mulig å kludere alle tre roller i en meldg. På mottakerssiden kan ntil to roller spesifiseres: reditor, dvs. eieren av kontoen som skal godskrives, og Ultimatereditor, dvs. den som er fordrgshaver / den som skal motta pengene. Disse to rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. ustomerredittransferinitiation meldgen gjør det mulig å kludere begge roller i en meldg. Betalgstyper ustomerredittransfer meldger skal benyttes til nenlandske og grensekryssende betalger. Betalgsoppdrag dekker formasjonsbehovet ved betalg av en eller flere fakturaer hvor det skal være en spesifikasjon i form av en referanse m.m. til underliggende handelstransaksjon. asseutbetalger omfatter normalt lønns- eller pensjonsutbetalger eller 1-til-mange regngsbetalger. Kvalitet I forbdelse med elektronisk utvekslg av meldger, vil meldgene bli lest maskelt av system hos mottaker av meldgen. an bør derfor legge opp til strenge ruter rundt meldgsutvekslg, herunder bl.a.: -Nummererg av meldger for å sikre at meldger ikke går tapt under overførg -Ruter for å sikre at meldger ikke sendes flere ganger -Sikre at meldgsnhold ikke kan manipuleres under overførg -Sikre at avsender faktisk er den han gir seg ut for å være -Ved bruk av strukturert nhold sikre at meldg fra avsender kan tolkes maskelt hos mottakeren. *Sikre at formasjon i meldgen ikke kan leses av uvedkommende -Statusrapport fra bank bekrefter at bank har overtatt ansvar
Eksempler på bruk av ustomerredittransfer-meldger 1 Enkel betalg itiert av debitor I dette eksemplet er det kontoeier (Debtor) som itierer betalgsoppdraget. Betalers konto er i Bank A (DebtorAgent). Betalgsmottaker (reditor) har s konto i Bank B (reditoragent). (Eksempelvis lønn, pensjon). Betaler genererer i sitt system en ustomerredittransferinitiation meldgen som sendes til betalers bank (Bank B) med struksjon om overførg av beløp til kreditors konto i Bank B. Betalg utføres, og transaksjon med formasjon fra ustomerredittransferinitiation meldgen sendes bank B for godskrift av kreditors konto og utsendg av formasjon om krediterg til betalgsmottaker. 2 Betalg på grunnlag av mottatt faktura (Papir eller elektronisk Faktura)
Kreditor sender faktura til Betaler på papir eller som efaktura (avhengig av om betaler kan motta efaktura). Hvis efaktura er avtalt går den via Access punkt som videreformidler til betaler. Betaler mottar efaktura og leser denne n i sitt ERP system og behandlg "ende-til-ende" er tiltrettelagt for elektronisk fakturahåndterg. Autorisert efaktura vil generere en ustomerredittransferinitiation meldg med formasjon fra efakturaen. Denne sendes til Bank A som betalgsstruksjon. Betalg utføres, og transaksjon med formasjon fra ustomerredittransferinitiation meldgen sendes bank B for godskrift av kreditors konto og utsendg av formasjon om krediterg til betalgsmottaker. 3 Enkeltbetalg kontohaver itierer en betalg på vegne av 3.part. I dette eksemplet har vi tatt utgangspunkt i et konsern, hvor mor er kontoeier, også for alle datterselskap. or itierer betalgsoppdrag på vegne av et datterselskap som er skyldner, og mottaker av faktura. På fakturautsteder siden har vi en tilsvarende konstellasjon, hvor mor er eier av kreditkonto oppgitt i fakturaen, men hvor datterselskap er den egentlige fordrgshaver.
4 På vegne av 3.part ved bruk av servicesenter I dette eksemplet er Kunde A både kontohaver og skyldner (mottaker av faktura), så derfor er det kun nødvendig å angi Betaler (Debtor) rollen i meldgen. Kunde a benytter seg av et Shared Service enter, som f.eks kan være et regnskapskontor, for å foreta betalger. Siden Shared Service enter kun opererer på vegne av Kunde A, vil Shared Service enter kun være en operatør som lager meldgen, og fungere som en Gateway for Kunde A for elektronisk utvekslg mot banken. Shared Service enter trenger derfor ikke å være identifisert i ustomerredittransferinitiation meldgen.
Teknisk beskrivelse eldg Pa.001.001.03 ustomerredittransferinitiation V03 Bruk av meldg ustomer redit Transfer-meldgen kan benyttes både for nlandsbetalger og for grensekryssende betalger. ustomer redit Transfer-meldgen kan benyttes både for nlandsbetalger og for grensekryssende betalger. ustomer redit Transfer-meldgen identifiseres i xml-skjemaet på følgende måte: urn: iso: std: iso: 20022: tech: xsd: pa.001.001.03 En ustomer redit Transfer-meldg kan neholde: - En eller flere betalgsoppdrag - Et betalgsoppdrag kan neholde en eller flere betalgstransaksjoner - En betalgstransaksjon kan resultere i en kontooverførg eller utstedelse av bankanvisng / Sjekk. Når meldgen benyttes til enkeltbetalger, vil Paymentformation -komponenten gjentas pr redit transaction -komponent. eldgen kan også brukes til å gruppere betalger, da vil Payment formation -komponenten (debetsiden) forekomme en gang, med flere etterfølgende redittrasnfertransactioninformation (kreditsiden). Identifikasjon av kunderoller I ustomer redit Transfer-meldgen kan man angi flere kunderoller. På oppdragssiden, kan ntil tre roller spesifiseres: Initiatg Party, dvs. den som sender meldgen, Debtor, dvs. eier av konto som skal belastes, og UltimateDebtor, dvs. den som skylder penger til kreditor som følge av mottak av varer eller tjenester. Disse tre rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører.oppbygggen av ustomer redit Transfer-meldgen gjør det mulig å kludere alle tre roller i en meldg. På mottakersiden, kan ntil to roller spesifiseres: reditor, dvs. eieren av kontoen som skal godskrives, og Ultimatereditor, dvs. den som er fordrgshaver / den som skal motta pengene. Disse to rollene kan dekkes av én og samme aktør, eller de kan dekkes av ulike aktører. Oppbygggen av ustomer redit Transfer-meldgen gjør det mulig å kludere begge roller i en meldg. Betalgsformasjon ustomer redit Transfer-meldgen kan neholde grunnleggende betalgsformasjon. Den kan også neholde strukturert referanseformasjon som henviser til betalgsformasjon som er sendt separat fra betaler. yndighetsrapporterg For betalgstyper som krever spesiell myndighetsrapporterg, gir ustomer redit Transfer-meldger mulighet for å angi nødvendig formasjon i tilknytng til transaksjoner hvor rapporterg er nødvendig. eldgsoppbyggg ustomer redit Transfer-meldg basert på ISO20022 PAIN.001.001.03 er bygd opp av tre nivåer, vist i figur under, og alle må være med i en meldg.
Struktur Forklarg til tabellene GENERELLE PRINSIPPER FOR TABELLEN SO ER BENYTTET FOR Å BESKRIVE FORAT OG STRUKTUR FOR ISO 20022- ELDINGER Alle er som må være med (andatory) i ISO20022.meldger, er med i den norske er med i den norske meldgsguiden. Det samme gjelder dersom de er (Required) i «GI Implementation Guide» for ISO 20022 meldger, og for er som kan være med eller er avhengige av gitte kriterier. Elementer som ikke benyttes i norsk betalgsformidlg er ikke tatt med i denne. Dette gjelder selv om de er tatt med i ISO 20022 essage Defition Report eller i GI Implementation Guide» for ISO 20022 meldger. Dette er gjort for å forenkle bruken av meldgsguiden. Formatspesifikasjon -Standard XL versjon angivelse skal spesifisere at XL V. 1.0 blir benyttet, videre må det angis hvilket karaktersett som benyttes. Krav til karaktersett er ISO UTF8. <Document>Koden bør angi riktige navneområdet. Eksempel:<?xml version="1.0" encodg="utf-8"?></document> Under er en forklarg til kolonnene i tabellene: ISO er referansenummer som henviser til relatert feltbeskrivelse i ISO 20022 essage Defition Report essage Item refererer til det faktiske "tag"navnet i XL som angis i kolonnen XL Tag Name. Det kan være et eldgs (som kan sammenlignes med felt i en tradisjonell meldg), eller en eldgs Komponent (det vil si en bunt med formasjon bestående av flere forskjellige meldgs). Hvert meldgs komplementeres med hva slags type det er (angis i kolonnen Type). Tag Name, er den spesifikke koden knyttet til et XL- som vil ngå i et XL Schema for å identifisere et XL-. Tag Name vil starte strengen med formasjon som skal ngå i et (f.eks. <Dbtr>) og strengen avsluttes med den samme tagen med en forutgående slash (f.eks. </Dbtr>). Structural angir hvor i meldgsstrukturen et er plassert ultiplicity, angir hvor mange ganger et et kan/skal være med. Page 11 of 40
Type, angir den type verdi som skal overføres for det aktuelle et i XL-notasjon. Det er 7 forskjellige Data Type representasjoner som kan benyttes, ode, Text, Rate, Date Time, Amount, Indicator. Attributter er angitt med prefiks @. Use, angir BSK klassifiserg som er fastsatt for norske meldgsguider. ISO 20022 benytter klassifisergene 1..n for mandatory, og 0..n for optional. BSK har en mer gradert klassifiserg. Følgende klassifiserger benyttes i denne kolonnen: Defitions / Special comments, angir defisjon av det aktuelle et, regler for utfyllg, lovlige verdier mm, i henhold til ISO 20022 essage Defition Report. I kursiv vil det stå forklarger på bruken av et i det norske markedet Da norsk implementasjonsguideles skal være kompatibel med GI vil vi ikke ha med er som er angitt som NU i GI se guideles. Videre vil BSK ikke ha noen mer fleksibel klassifiserg enn GI. Det vil si at er som i GI er klassifisert som R, ikke kan klassifiseres som BD i BSK. Derimot kan er som av GI er klassifisert som BD bli klassifisert som i BSK. Page 12 of 40
Prciples and Rules for use of odes Identifyg Parties a message Pa001 In addition to UST and BANK, we troduces VANS, order to recognize a Service Provider/Shared Service enter as Initiatg Party pa001. (sender pa001 / receiver pa002) This requires a change of GI defitions for the above mentioned codes. Initiatg Party a pa001 is identified GRHD, and relates to an agreement with the bank, that regulates the terchange and use of messages UST = Debtor a Agreement BANK = Sub-level Agreement under the ma agreement (bilateral agreement customer/bank) i.e special service or related to subsidiary's or divisions. ID the PmtInf block, identifies either the debtors ma agreement (UST), or the debtors eventual lk to a sub-service agreement (BANK) for the transactions that specific payment block.
essage Functionality The message starts with the Document that identifies what iso standard is used, and what message type it is. In this case it is: urn:iso:std:iso:20022:tech:xsd:pa.001.001.03 This message is built up by three buildg blocks: GroupHeader, PaymentInformation and redittransfertransactioninformation.
Functional Structure ustomer redit Transfer Initiation pa.001.001.03 Bankenes Standardisergskontor Implementasjonsguide av Januar 2012 NO requirements cluded september 2014 ISO Or essage Item Tag Name Structural ult. Type Use <stmrdttrfinitn - R essage root, identifyg message type > 1.0 GroupHeader <GrpHdr> + [1..1] Set of characteristics shared by all dividual transactions cluded the message. 1.1 essageidentification <sgid> ++ [1..1] ax 35 Text Pot to pot reference, as assigned by the structg party, and sent to the next party the cha to unambiguously identify the message. Unique for each customer m. 3 month Will be used status reports (PSR) itiated by this message 1.2 reationdatetime <redttm> ++ [1..1] DateTime Date and time at which the message was created. 1.3 Authorisation <Authstn> ++ [0..2] BD 1.4 {Or ode <d> +++ [1..1] ode BD 1.5 Or} Proprietary <Prtry> +++ [1..1] Text BD 1.6 NumberOfTransactions <NbOfTxs> ++ [1..1] Text 1.7 ontrolsum <trlsum> ++ [0..1] Decimal Number BD Total of all dividual amounts cluded the message, irrespective of currencies. To be agreed with the debtors bank 1.8 InitiatgParty <InitgPty> ++ [1..1] Party Identification32 omponent Party that itiates the payment. This can either be the debtor or the party that itiates the credit transfer on behalf of the debtor 9.1.0 Name <Nm> +++ [0..1] ax 140 Text BD Name by which a party is known and which is usually used to identify that party. Page 15 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.12 Identification <Id> +++ [0..1] hoice R Unique and unambiguous identification of a party. omponenet 9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1] Organisation Unique and unambiguous way to identify an organisation. Identification4 9.1.14 BIOrBEI <BIOrBEI> +++++ [0..1] AnyBI Identifier BD ode allocated to organisations by the ISO 9362 Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes). Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> +++++ [0..n] Organisation Identification1 BD Unique identification of an organisation, as assigned by an stitution, usg an identification scheme. 9.1.16 Identification <Id> ++++++ [1..1] Text ax35 Identification assigned by an stitution. This may be the customer-id the debtor bank, which may be based on Brønnøysundregistrene and their entral oordatg Register of Legal Entities, or another identification agreed with the bank 9.1.17 SchemeName <SchmeNm> ++++++ [0..1] rganisationidentific ationschemename 1hoice BD Name of the identification scheme. Page 16 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.18 ode <d> +++++++ [1..1] ode Name of the identification scheme, a coded form as published an external list. PAIN and AT messages do not cover the banks and their customers need for a unified way of identifyg parties, when routg different messages to and from. Norway wants to troduce what we regard as a logical use of codes identifyg the parties a message exchange, across message types, and a uniform use of GroupHeader. Party/Other/ode UST = Debtor/reditor relates to a-agreement with the fancial Institution BANK = Debtor/reditor relates to a Sub-level Agreement under the ma agreement (bilateral agreement customer/bank) i.e special service or related to subsidiary's or divisions. 2.0 PaymentInformation <PmtInf> + [1..n] Set of characteristics that applies to the debit side of the payment transactions cluded the credit transfer itiation 2.1 PaymentInformationIdentification <PmtInfId> ++ [1..1] ax35text Unique identification, as assigned by a sendg party, to unambiguously identify the payment formation group with the message. Unique for each customer 2.2 Paymentethod <Pmttd> ++ [1..1] ode Specifies the means of payment that will be used to move the amount of money. Page 17 of 40
Or essage Item Tag Name Structural ult. Type Use 2.3 BatchBookg <BtchBookg> ++ [0..1] Batch Bookg Indicator 2.5 ontrolsum <trlsum> ++ [0..1] Decimal Number fraction Digits: 17 total Digits: 18 2.6 PaymentTypeInformation <PmtTpInf> ++ [0..1] Payment Type Information 19 BD BD R Identifies whether a sgle entry per dividual transaction or a batch entry for the sum of the amounts of all transactions with the group of a message is requested. Usage: Batch bookg is used to request and not order a possible batch bookg. For domestic payments If used: True: Identifies that a batch entry for the sum of the amounts of all transactions the message is requested. False: Identifies that a sgle entry for each of the transactions the message is requested. For domestic payments only General defition: Total of all dividual amounts cluded the group, irrespective of currencies. All dividual amounts must be the same currency Set of s used to further specify the type of transaction. Required at either Payment or Transaction Level, but should not be present at both levels. Recommnded usage is at Payment level. 2.7 InstructionPriority <InstrPrty> +++ [0..1] ode BD Based on whether priority processg vs. normal processg is offered by the bank. Valid codes: HH - High priority processg NOR - Normal processg 2.8 ServiceLevel <SvcLvl> +++ [0..1] Service Level8 hoice 2.9 {Or ode <d> ++++ [1..1] ode maxlength: 4 Agreement/rule under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published an external service level code list. Page 18 of 40
Or essage Item Tag Name Structural ult. Type Use 2.11 LocalInstrument <LclInstrm> +++ [0..1] This is used to specify a local strument, local clearg option and/or further qualify the service or service level. 2.13 Or} Proprietary <Prtry> ++++ [1..1] Text Local Instrument a proprietary form. 2.14 ategorypurpose <tgypurp> +++ [0..1] ategorypurpose1 hoice Specifies the high level purpose of the struction based on a set of pre-defed categories. Usage: This is used by the itiatg party to provide formation concerng the processg of the payment. It is likely to trigger special processg by any of the agents volved the payment cha. In absence of this, the payment will be prosessed as a supplier payment 2.15 {Or ode <d> ++++ [1..1] Externalategory Purpose1 ode maxlength: 4 Specifies the high level purpose of the struction based on a set of pre-defed categories. Usage: This is used by the itiatg party to provide formation concerng the processg of the payment. It is likely to trigger special processg by any of the agents volved the payment cha. Ref. External odelist (ISO 20022) and verify with your bank. 2.17 RequestedExecutionDate <ReqdExctnDt> ++ [1..1] DateTime Date at which the itiatg party requests the clearg agent to process the payment. Usage: This is the date on which the debtor's account is to be debited. If payment by cheque, the date when the cheque must be generated by the bank. 2.19 Debtor <Dbtr> ++ [1..1] PartyIdentification32 Party that owes an amount of money to the (ultimate) creditor. This is the owner of the debtor account 9.1.0 Name <Nm> +++ [0..1] Text R 9.1.1 PostalAddress <PstlAdr> +++ [0..1] R 9.1.10 ountry <try> ++++ [0..1] ode R 9.1.12 Identification <Id> +++ [0..1] Party6hoice R Unique and unambiguous identification of a party. Page 19 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1] Organisation Unique and unambiguous way to identify an organisation. Identification4 9.1.14 BIOrBEI <BIOrBEI> +++++ [0..1] AnyBIIdentifier BD ode allocated to organisations by the ISO 9362 Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes). Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> +++++ [0..n] GenericOrganisation Identification1 9.1.16 Identification <Id> ++++++ [1..1] ax35text maxlength: 35 2.20 DebtorAccount <DbtrAcct> ++ [1..1] ashaccount16 BD Unique identification of an organisation, as assigned by an stitution, usg an identification scheme. Identification assigned by an stitution. Organisation number Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. 1.1.0 Identification <Id> +++ [1..1] AccountIdentification 4 hoice Unique and unambiguous identification for the account between the account owner and the account servicer. Page 20 of 40
Or essage Item Tag Name Structural ult. Type Use 1.1.1 {Or IBAN <IBAN> ++++ [1..1] IBAN2007Identifier Format: [A- Z]{2,2}[0-9]{2,2}[azA-Z0-9]{1,30} 1.1.2 Or} Other <Othr> ++++ [1..1] GenericAccount Identification1 1.1.3 Identification <Id> +++++ [1..1] ax34text maxlength: 34 International Bank Account Number (IBAN) - identifier used ternationally by fancial stitutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found the standard ISO 13616 "Bankg and related fancial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions. A valid IBAN consists of all three of the followg components: ountry ode, check digits and BBAN. Unique identification of an account, as assigned by the account servicer, usg an identification scheme. Identification assigned by an stitution. Local accountnumber that will be debited for the transactions 1.1.4 SchemeName <SchmeNm> +++++ [0..1] AccountSchemeNam e1 hoice BD Name of the identification scheme 1.1.5 {{Or ode <d> ++++++ [1..1] ExternalAccount Identification1ode maxlength: 4 2.21 DebtorAgent <DbtrAgt> ++ [1..1] BranchAndFancialI nstitutionidentificatio n4 6.1.0 FancialInstitutionIdentification <FInstnId> +++ [1..1] FancialInstitution Identification7 Name of the identification scheme, a coded form as published an external list. Valid code: BBAN Fancial stitution servicg an account for the debtor. Unique and unambiguous identification of a fancial stitution, as assigned under an ternationally recognised or proprietary identification scheme. Page 21 of 40
Or essage Item Tag Name Structural ult. Type Use 6.1.1 BI <BI> ++++ [0..1] BI Identifier R Bank Identifier ode. ode allocated to fancial stitutions by the Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes) Valid BIs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 6.1.8 PostalAddress <PstlAdr> ++++ [0..1] R 6.1.17 ountry <try> +++++ [0..1] ode R 2.23 UltimateDebtor <UltmtDbtr> ++ [0..1] PartyIdentification32 Ultimate party that owes an amount of money to the (ultimate) creditor. 9.1.0 Name <Nm> +++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> +++ [0..1] PostalAddress6 9.1.5 StreetName <StrtNm> ++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> ++++ [0..1] ax16text maxlength: 16 R Name by which a party is known and which is usually used to identify that party. Field length restrictions may apply, contact your bank Information that locates and identifies a specific address, as defed by postal services. Use of structured address is recommended. Name of a street or thoroughfare. Field length restrictions may apply, contact your bank Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg. Page 22 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.8 TownName <TwnNm> ++++ [0..1] ax16text maxlength: 16 9.1.10 ountry <try> ++++ [0..1] ountryode Format: [A-Z]{2,2} 9.1.11 AddressLe <AdrLe> ++++ [0..7] ax70text maxlength: 70 2.24 hargebearer <hrgbr> ++ [0..1] hargebearertype1 ode R Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg of mail. Nation with its own government. Information that locates and identifies a specific address, as defed by postal services, presented free format text. Field length restrictions may apply, contact your bank Specifies which party/parties will bear the charges associated with the processg of the payment transaction. Domestic payments SHAR; SEPA payments SLEV; ross Border payments DEBT, RED, SHAR, onditional based on wether used on payment- and crdittrasaction level. In absence of this, the bank will handle this as a payment where each party pays their own cost. 2.27 redittransfertransactioninformation <dttrftxinf> ++ [1..n] Set of s used to provide formation on the dividual credit transfer transaction(s) cluded the message. 2.28 PaymentIdentification <PmtId> +++ [1..1] Payment Identification1 2.29 InstructionIdentification <InstrId> ++++ [0..1] ax35text maxlength: 35 BD Set of s used to reference a payment struction. Unique identification as assigned by an structg party for an structed party to unambiguously identify the struction. Use of this may differ from bank to bank. Please contact yor bank agent. Page 23 of 40
Or essage Item Tag Name Structural ult. Type Use 2.30 EndToEndIdentification <EndToEndId> ++++ [1..1] ax35text maxlength: 35 Unique identification assigned by the itiatg party to unumbiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-toend cha. 2.31 PaymentTypeInformation <PmtTpInf> +++ [0..1] PaymentType Information19 R Set of s used to further specify the type of transaction. ay be used either on this level or the Payment Information Level 2.32 InstructionPriority <InstrPrty> ++++ [0..1] Priority2ode BD Based on whether priority processg vs. normal processg is offered by the bank. Valid codes: HH - High priority processg NOR - Normal processg 2.33 ServiceLevel <SvcLvl> ++++ [0..1] ServiceLevel8 hoice 2.34 {Or ode <d> +++++ [1..1] ExternalServiceLevel 1ode maxlength: 4 2.39 ategorypurpose <tgypurp> ++++ [0..1] ategory Purpose1hoice Agreement under which or rules under which the transaction should be processed. Specifies a pre-agreed service or level of service between the parties, as published an external service level code list. ontact the fancial stitution for formation Specifies the high level purpose of the struction based on a set of pre-defed categories. Usage: This is used by the itiatg party to provide formation concerng the processg of the payment. It is likely to trigger special processg by any of the agents volved the payment cha. In absence of this, the payment will be prosessed as a supplier payment Page 24 of 40
Or essage Item Tag Name Structural ult. Type Use 2.40 {Or ode <d> +++++ [1..1] ExternalategoryPur pose1ode maxlength: 4 2.42 Amount <Amt> +++ [1..1] AmountType3 hoice ategory purpose, as published an external category purpose code list. Valid codes excamples: INT, PENS, SALA, SUPP, TREA Verify use of codes with ypur bankagent Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed the currency as ordered by the itiatg party. 2.43 {Or InstructedAmount <InstdAmt cy="aaa"> ++++ [1..1] ActiveOrHistoricurr encyode fractiondigits: 5 minclusive: 0 totaldigits: 18 Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed the currency as ordered by the itiatg party. 2.44 Or} EquivalentAmount <EqvtAmt> ++++ [1..1] Equivalent Amount2 2.45 Amount <Amt cy="aaa"> +++++ [1..1] ActiveOrHistoricurr encyode fractiondigits: 5 minclusive: 0 totaldigits: 18 2.46 urrencyoftransfer <cyoftrf> +++++ [1..1] ActiveOrHistoricurr encyode 2.47 ExchangeRateInformation <XchgRateInf> +++ [0..1] ExchangeRate Information1 BD Amount of money to be moved between the debtor and creditor, expressed the currency of the debtor's account, and the currency which the amount is to be moved. Amount of money to be moved between debtor and creditor, before deduction of charges, expressed the currency of the debtor's account, and to be moved a different currency. Usage: The first agent will convert the equivalent amount to the amount to be moved. Specifies the currency of the to be transferred amount, which is different from the currency of the debtor's account. The urrency ode must be registered, or have already been registered. Valid active or historic currency codes are registered with ISO 4217 Set of s used to provide details on the currency exchange rate and contract. Page 25 of 40
Or essage Item Tag Name Structural ult. Type Use 2.48 ExchangeRate <XchgRate> ++++ [0..1] BaseOneRate fractiondigits: 10 totaldigits: 11 2.49 RateType <RateTp> ++++ [0..1] ExchangeRate Type1ode 2.50 ontractidentification <trctid> ++++ [0..1] ax35text maxlength: 35 2.51 hargebearer <hrgbr> +++ [0..1] hargebearer Type1ode BD The factor used for conversion of an amount from one currency to another. This reflects the price at which one currency was bought with another currency. Specifies the type used to complete the currency exchange AGRD - Exhange rate applied is the rate agreed between the parties SALE - Exchange rate applied is the market rate at time of the sale SPOT - Exchange rate applied is the spot rate Unique and unambiguous reference to the foreign exchange contract agreed between the itiatg party/ creditor and the debtor agent. Specifies which party/parties will bear the charges associated with the processg of the payment transaction. Domestic payments - SHAR SEPA payments - SLEV ross Border payments - DEBT, RED, SHAR, SLEV onditional based on wether used on payment- og crdittrasaction level. In absence of this, the bank will handle this as a payment where each party pays their own cost.. 2.52 hequeinstruction <hqinstr> +++ [0..1] heque6 Set of s needed to issue a cheque. 2.53 hequetype <hqtp> ++++ [0..1] hequetype2 ode R Specifies the type of cheque to be issued. Valid codes: BHQ - heque drawn on the account of the debtor's fancial stitution. The fancial stitution prts and certifies the cheque, guaranteeg the payment. Synonym is 'cashier's cheque'. Page 26 of 40
Or essage Item Tag Name Structural ult. Type Use 2.58 Deliveryethod <Dlvrytd> ++++ [0..1] heque Deliveryethod1 hoice 2.59 {Or ode <d> +++++ [1..1] hequedelivery1od e BD Specifies the delivery method of the cheque by the debtor's agent. Specifies the delivery method of the cheque by the debtor's agent. Valid codes: LD - ailtoreditor LDB - heque is to be sent through mail services to debtor. PUDB - heque will be picked up by the debtor. 2.70 UltimateDebtor <UltmtDbtr> +++ [0..1] Party Identification32 Ultimate party that owes an amount of money to the (ultimate) creditor. 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text maxlength: 35 R Name by which a party is known and which is usually used to identify that party. Field length restrictions may apply, contact your bank Information that locates and identifies a specific address, as defed by postal services. Use of structured address is recommended. Name of a street or thoroughfare. Field length restrictions may apply, contact your bank Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg of mail. Page 27 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.10 ountry <try> +++++ [0..1] ountryode R Nation with its own government. The code is checked agast the list of country names obtaed from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLe <AdrLe> +++++ [0..7] ax70text maxlength: 70 2.71 IntermediaryAgent1 <IntrmyAgt1> +++ [0..1] BranchAnd Fancial Institution Identification4 6.1.0 FancialInstitutionIdentification <FInstnId> ++++ [1..1] Fancial Institution Identification7 BD Information that locates and identifies a specific address, as defed by postal services, presented free format text. Agent between the debtor's agent and the creditor's agent. Only one termediary agent is present, Used only if reditor Agent has structed that the payment should pass their agent. Unique and unambiguous identification of a fancial stitution, as assigned under an ternationally recognised or proprietary identification scheme. 6.1.1 BI <BI> +++++ [0..1] BI Identifier Bank Identifier ode. ode allocated to fancial stitutions by the Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes). Valid BIs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 2.77 reditoragent <dtragt> +++ [0..1] BranchAnd Fancial Institution Identification Fancial stitution servicg an account for the creditor. Required for ross Border Payments and SEPA Payments 6.1.0 FancialInstitutionIdentification <FInstnId> ++++ [1..1] Page 28 of 40
Or essage Item Tag Name Structural ult. Type Use 6.1.1 BI <BI> +++++ [0..1] BI Identifier Bank Identifier ode. ode allocated to fancial stitutions by the Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes). Valid BIs are registered with the ISO 9362 Registration Authority, and consist of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 6.1.2 leargsystememberidentification <lrsysmbid> +++++ [0..1] leargsystem ember Identification 6.1.3 leargsystemidentification <lrsysid> ++++++ [0..1] leargsystem Identification hoice 6.1.4 {Or ode <d> +++++++ [1..1] Externallearg System Identification1 ode maxlength: 5 6.1.6 emberidentification <mbid> ++++++ [1..1] ax35text maxlength: 35 R Information used to identify a member with a clearg system. Specification of a pre-agreed offerg between clearg agents or the channel through which the payment struction is processed. Identification of a clearg system, a coded form as published an external list. This message item is part of choice 6.1.3 leargsystemidentification. Valid codes: NIS Identification of a member of a clearg system. Page 29 of 40
Or essage Item Tag Name Structural ult. Type Use 6.1.7 Name <Nm> +++++ [0..1] ax140text maxlength: 140 6.1.8 PostalAddress <PstlAdr> +++++ [0..1] PostalAddress6 R Name by which an agent is known and which is usually used to identify that agent. Field length restrictions may apply, contact your bank Information that locates and identifies a specific address, as defed by postal services. 6.1.17 ountry <try> ++++++ [0..1] ountryode R Nation with its own government. The code is checked agast the list of country names obtaed from the United Nations (ISO 3166, 6.1.18 AddressLe <AdrLe> ++++++ [0..7] ax70text maxlength: 70 2.79 reditor <dtr> +++ [0..1] PartyIdentification32 R Information that locates and identifies a specific address, as defed by postal services, presented free format text. Feld length restrictions may apply, contact your bank Party to which an amount of money is due. Required ross Border Payments and SEPA Payments For Norwegian domestic payments, except money orders, only credit account is needed. reditoragent is required to forward formation related to the payment, and uses reditor Adress formation connected to the reditaccount their own system. 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 R R Name by which a party is known and which is usually used to identify that party. Feld length restrictions may apply, contact your bank Information that locates and identifies a specific address, as defed by postal services. Use of structured address is recommended. Required for cross border payments Page 30 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text maxlength: 35 Name of a street or thoroughfare. Field length restrictions may apply, contact your bank Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg of mail. Name of a built-up area, with defed boundaries, and a local government. Field length restrictions may apply, contact your bank 9.1.10 ountry <try> +++++ [0..1] ountryode Nation with its own government. The code is checked agast the list of country names obtaed from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLe <AdrLe> +++++ [0..7] ax70text maxlength: 70 9.1.12 Identification <Id> ++++ [0..1] Party6 hoice 9.1.13 {Or OrganisationIdentification <OrgId> +++++ [1..1] Organisation Identification4 Information that locates and identifies a specific address, as defed by postal services, presented free format text. Feld length restrictions may apply, contact your bank Unique and unambiguous identification of a party. Unique and unambiguous way to identify an organisation. This message item is part of choice 9.1.12 Identification. Page 31 of 40
Or essage Item Tag Name Structural ult. Type Use 9.1.14 BIOrBEI <BIOrBEI> ++++++ [0..1] AnyBIIdentifier ode allocated to organisations by the ISO 9362 Registration Authority, under an ternational identification scheme, as described the latest version of the standard ISO 9362 Bankg (Bankg telecommunication messages, Bank Identifier odes). Only a valid BI or BEI is allowed. Valid BEI and BI are registered with the ISO 9362 Registration Authority, and consists of eight (8) or eleven (11) contiguous characters comprisg the first three or all four of the followg components: BANK ODE, OUNTRY ODE, LOATION ODE, BRANH ODE. The bank code, country code and location code are mandatory, while the branch code is optional. 9.1.15 Other <Othr> ++++++ [0..n] 9.1.16 Identification <Id> +++++++ [1..1] Text 9.1.33 ountryofresidence <tryofres> ++++ [0..1] ountryode ountry which a person resides (the place of a person's home). In the case of a company, it is the country from which the affairs of that company are directed. The code is checked agast the list of country names obtaed from the United Nations (ISO 3166, Alpha-2 code). 2.80 reditoraccount <dtracct> +++ [0..1] ashaccount16 1.1.0 Identification <Id> ++++ [1..1] AccountIdentification 4 hoice Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. Required all payments except local ternational cheque and local payment orders. Unique and unambiguous identification for the account between the account owner and the account servicer. Page 32 of 40
Or essage Item Tag Name Structural ult. Type Use 1.1.1 {Or IBAN <IBAN> +++++ [1..1] IBAN2007Identifier Format: [A- Z]{2,2}[0-9]{2,2}[azA-Z0-9]{1,30} 1.1.2 Or} Other <Othr> +++++ [1..1] GenericAccount Identification1 1.1.3 Identification <Id> ++++++ [1..1] ax34text maxlength: 34 1.1.4 SchemeName <SchmeNm> ++++++ [0..1] AccountSchemeNam e1 hoice 1.1.5 {{Or ode <d> +++++++ [1..1] ExternalAccount Identification1ode maxlength: 4 2.81 Ultimatereditor <Ultmtdtr> +++ [0..1] PartyIdentification32 9.1.0 Name <Nm> ++++ [0..1] ax140text maxlength: 140 9.1.1 PostalAddress <PstlAdr> ++++ [0..1] PostalAddress6 Page 33 of 40 R R International Bank Account Number (IBAN) - identifier used ternationally by fancial stitutions to uniquely identify the account of a customer. Further specifications of the format and content of the IBAN can be found the standard ISO 13616 "Bankg and related fancial services - International Bank Account Number (IBAN)" version 1997-10-01, or later revisions. A valid IBAN consists of all three of the followg components: ountry ode, check digits and BBAN. Unique identification of an account, as assigned by the account servicer, usg an identification scheme. Identification assigned by an stitution. Local accountnumber that will be credited for the transactions Name of the identification scheme Name of the identification scheme, a coded form as published an external list. Valid code: BBAN Ultimate party to which an amount of money is due. Name by which a party is known and which is usually used to identify that party. Field length restrictions may apply, contact your bank Information that locates and identifies a specific address, as defed by postal services. Field length restrictions may apply, contact your bank
Or essage Item Tag Name Structural ult. Type Use 9.1.5 StreetName <StrtNm> +++++ [0..1] ax70text maxlength: 70 9.1.7 Postode <Pstd> +++++ [0..1] ax16text maxlength: 16 9.1.8 TownName <TwnNm> +++++ [0..1] ax35text maxlength: 35 Name of a street or thoroughfare. Identifier consistg of a group of letters and/or numbers that is added to a postal address to assist the sortg of mail. Name of a built-up area, with defed boundaries, and a local government. 9.1.10 ountry <try> +++++ [0..1] ountryode R Nation with its own government. The code is checked agast the list of country names obtaed from the United Nations (ISO 3166, Alpha-2 code). 9.1.11 AddressLe <AdrLe> +++++ [0..7] ax70text maxlength: 70 2.82 InstructionForreditorAgent <InstrFordtrAgt> +++ [0..n] InstructionFor reditoragent1 BD Information that locates and identifies a specific address, as defed by postal services, presented free format text. Field length restrictions may apply, contact your bank Further formation related to the processg of the payment struction, provided by the itiatg party, and tended for the creditor agent. Page 34 of 40
Or essage Item Tag Name Structural ult. Type Use 2.83 ode <d> ++++ [0..1] Instruction ode BD oded formation related to the processg of the payment struction, provided by the itiatg party, and tended for the creditor's agent. Excamples: HQB - (Ultimate) creditor must be paid by cheque. HOLD - Amount of money must be held for the (ultimate) creditor, who will call. Pay on identification. PHOB - Please advise/contact (ultimate) creditor/claimant by phone TELB - Please advise/contact (ultimate) creditor/claimant by the most efficient means of telecommunication 2.84 InstructionInformation <InstrInf> ++++ [0..1] ax140text maxlength: 140 2.89 RegulatoryReportg <RgltryRptg> +++ [0..10] Regulatory Reportg3 11.1.4 Details <Dtls> ++++ [0..n] Structured Regulatory Reportg3 11.1.8 ode <d> +++++ [0..1] ax10text maxlength: 10 BD R R Further formation complementg the coded struction or struction to the creditor's agent that is bilaterally agreed or specific to a user community. Information needed due to regulatory and statutory requirements. Required for cross border payments with a value that exceeds 100 000 NOK Set of s used to provide details on the regulatory reportg formation. Specifies the nature, purpose, and reason for the transaction to be reported for regulatory and statutory requirements a coded form. ontact the fancial stitution for formation as to use of the, and updated code-list. 11.1.9 Amount <Amt cy="aaa"> +++++ [0..1] Amount 11.1.10 Information <Inf> +++++ [0..n] ax35text maxlength: 35 R Additional details that cater for specific domestic regulatory requirements. Page 35 of 40
Or essage Item Tag Name Structural ult. Type Use 2.98 RemittanceInformation <RmtInf> +++ [0..1] Remittance Information5 2.99 Unstructured <Ustrd> ++++ [0..n] ax140text maxlength: 140 2.100 Structured <Strd> ++++ [0..n] Structured Remittance Information7 2.101 ReferredDocumentInformation <RfrdDocInf> +++++ [0..n] Referred Document Information3 2.102 Type <Tp> ++++++ [0..1] ReferredDocument Type2 2.103 odeorproprietary <dorprtry> +++++++ [1..1] ReferredDocument Type1hoice R Information supplied to enable the matchg of an entry with the items that the transfer is tended to settle, such as commercial voices an accounts' receivable system. Structured Remittance formation is preferred Information supplied to enable the matchg/reconciliation of an entry with the items that the payment is tended to settle, such as commercial voices an accounts' receivable system, an unstructured form. Domestic, max 1750 International, max 140 Structured remittance formation is preferred Information supplied to enable the matchg/reconciliation of an entry with the items that the payment is tended to settle, such as commercial voices an accounts' receivable system, a structured form. Recommended Set of s used to identify the documents referred to the remittance formation. Reffered document formation is used if voice- or credit note number is presented as structured formation, Specifies the type of referred document. Provides the type details of the referred document. 2.104 {Or ode <d> +++++++ + [1..1] DocumentType5 ode Document type a coded form. INV - Document is an voice..ren - Document is a credit note. Page 36 of 40