OASIS Committee Note
UBL Payment Means Information Version 1.0
Committee Note 01
04 December 2019
This stage:
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cn01/UBL-Payment-v1.0-cn01.docx (Authoritative)
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cn01/UBL-Payment-v1.0-cn01.html
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cn01/UBL-Payment-v1.0-cn01.pdf
Previous stage:
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cnprd01/UBL-Payment-v1.0-cnprd01.docx (Authoritative)
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cnprd01/UBL-Payment-v1.0-cnprd01.html
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cnprd01/UBL-Payment-v1.0-cnprd01.pdf
Latest stage:
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/UBL-Payment-v1.0.docx (Authoritative)
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/UBL-Payment-v1.0.html
https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/UBL-Payment-v1.0.pdf
Technical Committee:
OASIS Universal Business Language (UBL) TC
Chairs:
G. Ken Holman (gkholman@CraneSoftwrights.com), Crane Softwrights Ltd.
Kenneth Bengtsson (kbengtsson@efact.pe), Individual Member
Editor:
Levine Naidoo (levine.naidoo@au1.ibm.com), IBM
Related work:
Abstract:
This Committee Notes and its associated examples provide support for solution implementers to support different payment means.
Status:
This is a Non-Standards Track Work Product. The patent provisions of the OASIS IPR Policy do not apply.
This document was last revised or approved by the OASIS Universal Business Language (UBL) TC on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl#technical.
TC members should send comments on this document to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/ubl/.
Citation format:
When referencing this document the following citation format should be used:
[UBL-Payment-v1.0]
UBL Payment Means Information Version 1.0. Edited by Levine Naidoo. 04 December 2019. OASIS Committee Note 01. https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/cn01/UBL-Payment-v1.0-cn01.html. Latest stage: https://docs.oasis-open.org/ubl/UBL-Payment/v1.0/UBL-Payment-v1.0.html.
Notices
Copyright © OASIS Open 2019. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1.3 References (non-normative)
2 Guidance on the use of Payment Means
2.2 Communication of payee information
2.2.1 Automated clearing house credit
2.2.4 Electronic Wallet e.g. PayPal, AfterPay or other vendors.
2.2.5 Payment via transfer of Cryptocurrency asset/token
2.2.6 Payment via other methods
2.3 Confirmation of prior payment arrangements
2.3.2 Payment Via Pre-Arranged Direct Debit
2.3.3 Payment via Credit or Debit Card
2.3.4 Prepaid-Payments – Partial or Complete
The payment means complex UBL type is referenced in several UBL documents, viz, CreditNote, DebitNote, FreightInvoice, Invoice, Order, Orderchange, OrderResponse, Quotation, Reminder, RemittanceAdvice, SelfBilledCreditNote, SelfBilledInvoice and Statement.
This Committee Note has been provided to support solution implementers with meaningful examples of how to implement a variety of payment means currently available around the world.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[UBL-2.2] Universal Business Language Version 2.2. Edited by G. Ken Holman. 09 July 2018. OASIS Standard. http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html. Latest version: http://docs.oasis-open.org/ubl/UBL-2.2.html.
[UN/ECE 4461] United Nations Economic Commission for Europe, Payment Means Code,
https://www.unece.org/trade/untdid/d10a/tred/tred4461.htm
There are two broad uses of payment means information
a) Communication of payee information as part of a request for payment
b) Confirmation of prior payment arrangements where payer relevant information is communicated
In all the examples outlined in this document the UN/ECE 4461 code list has been used as the Payment Means Code. Jurisdictions MAY define their own code lists as relevant.
An automated clearing house is an electronic network for generally low value domestic financial transactions. There are several examples.
BPAY is a popular payment means supported by all major Australian Banks. The below example demonstrates how UBL information elements can be used to convey the required BPAY attributes, specifically the Biller Code and the Reference Number.
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE
4461">2</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>BPAY</cbc:PaymentChannelCode>
<cbc:InstructionID schemeName="BPAY Ref">1000000001</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID schemeName="BPAY Biller
Code">0001</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
To make an instant, irrevocable payment without a real-time payment system, the current options are a debit or credit card. These cards serve as a proxy for a user’s account. Real-time payment systems are emerging at a rapid pace. Alias or proxy services are emerging in a number of countries to provide simplicity for consumers and to protect the recipient’s bank account details. Examples include the Paym in the UK, SWISH in Sweden for mobile transactions and NPP in Australia. Generally, these systems are not designed to handle bulk transactions such as payroll, rather simply to process single, instantaneous payments. An example of an alias is the PayID used by the New Payments Platform (NPP) in Australia, which includes:
<cac:PaymentMeans>
<cbc:ID>OSKO</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">2</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>NPP</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>12345678910</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>OSKO</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">2</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>NPP</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>payee@company1.com.au</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>OSKO</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">2</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>NPP</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>0411111111</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
The following examples demonstrate how UBL information elements can be used to convey the required information to support a direct credit into a bank account across international boundaries.
The following example demonstrates how UBL information elements can be used to convey the required information to support a direct credit into a domestic bank in the UK. If in a country where the financial institution branch is identified using a different methodology, for example bank state branch (BSB), the “SORTCODE” scheme name would be replaced with “BSB”:
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE
4461">2</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>SORTCODE</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>83918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cbc:ID schemeName="SORTCODE">403534</cbc:ID>
<cbc:Name>HSBC BANK PLC</cbc:Name>
<cac:Address>
<cbc:ID>1</cbc:ID>
<cbc:AddressTypeCode>Street</cbc:AddressTypeCode>
<cbc:CityName>Oxford</cbc:CityName>
<cbc:PostalZone>OX13HY</cbc:PostalZone>
<cbc:CountrySubentity>Oxfordshire</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>65 Conmarket St</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode listName="Country
Identification Code"
listAgencyID="5">UK</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
It should be noted that most banks have or are moving away the use of sort codes in favour of the IBAN method reflected in 2.2.2.3. Some banks use virtual sort codes for domestic transfers and hence the bank name and address may not be relevant. They would be relevant for international transfers.
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">30</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>IBAN</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>GB86HBUK40353483918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cac:FinancialInstitution>
<cbc:ID>HBUKGB4108P</cbc:ID>
</cac:FinancialInstitution>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE
4461">30</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>SWIFT</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>GB86HBUK40353483918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cbc:ID>08P</cbc:ID>
<cac:FinancialInstitution>
<cbc:ID
schemeName="SWIFTBIC">HBUKGB4108P</cbc:ID>
<cbc:Name>HSBC BANK PLC</cbc:Name>
<cac:Address>
<cbc:ID>1</cbc:ID>
<cbc:AddressTypeCode>Street</cbc:AddressTypeCode>
<cbc:CityName>Oxford</cbc:CityName>
<cbc:PostalZone>OX13HY</cbc:PostalZone>
<cbc:CountrySubentity>Oxfordshire</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>65 Conmarket St</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode listName="Country Identification
Code" listAgencyID="5">UK</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:FinancialInstitution>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
General Interbank Recurring Order (GIRO) is an automated electronic payment service is a payment transfer from one bank account to another bank account and initiated by the payer, not the payee. It is a much earlier form of bank transfer which has been mostly replaced by automated clearing houses and real-time payment systems. At one time it was a system operated by post offices. It is still used in some countries but SWIFT Bank Identification code (BIC) is used to identify the payee bank. The subset of SWIFT BICs can be found here
https://abs.org.sg/docs/library/swift_bic_codes.pdf
<cac:PaymentMeans>
<cbc:ID>GIRO001</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">95</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>SWIFT</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>40353483918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cbc:ID>9548</cbc:ID>
<cac:FinancialInstitution>
<cbc:ID schemeName="SWIFTBIC">HSBCSGS2XXX</cbc:ID>
<cbc:Name>HSBC BANK Singapore Limited</cbc:Name>
<cac:Address>
<cbc:ID>1</cbc:ID>
<cbc:AddressTypeCode>Street</cbc:AddressTypeCode>
<cbc:CityName>Singapore</cbc:CityName>
<cbc:PostalZone>048623</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>50 Raffles Place</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode listName="Country Identification
Code" listAgencyID="5">SG</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:FinancialInstitution>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
Many vendors now provide online payment gateways that enable a user to view a web UI and enter card or online payment account information. The following example highlight how this information MAY be conveyed to the end user:
<cac:PaymentMeans>
<cbc:ID>Online Payment Gateway</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
<cbc:InstructionNote>https://mypaymentgateway.example.com/resource</cbc:InstructionNote>
</cac:PaymentMeans>
Some payment gateways MAY require additional information beyond a URI. In this circumstance, the FinancialAccount ABIE can be used to provide this information.
Cryptocurrencies are growing in popularity and are an accepted means of payment for many businesses. As such the below example has been provided to demonstrate how UBL can be used to provide the information required to facilitate a payment to a specified cryptocurrency address.
It is RECOMMENDED that the schemeName attribute uses the generally accepted abbreviation for the target crypto-currency.
<cac:PaymentMeans>
<cbc:ID>BTC</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
<cac:PayeeFinancialAccount>
<cbc:ID schemeName="Bitcoin”>1BoatSLRHtKNngkdXEeobR76b53LETtpyT</cbc:ID>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>
Although electronic payment means are the preferred method of payment in some regions, many organisations continue to support legacy payment means. As such, the following examples have been provided for completeness.
<cac:PaymentMeans>
<cbc:ID>Phone</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
<cbc:InstructionNote>Call 1300 111 111 to pay by Visa or Mastercard.</cbc:InstructionNote>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>In-Person</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
<cbc:InstructionNote>Pay in person at any of our locations.</cbc:InstructionNote>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>Cheque</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">20</cbc:PaymentMeansCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cbc:InstructionNote>Cheque payable to Company1. Post to Locked Bag 12345 GPO Canberra ACT 2601</cbc:InstructionNote>
</cac:PaymentMeans>
<cac:PaymentMeans>
<cbc:ID>Bank-Cheque</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">23</cbc:PaymentMeansCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cbc:InstructionNote>Cheque payable to Company1. Post to Locked Bag 12345 GPO Canberra ACT 2601</cbc:InstructionNote>
</cac:PaymentMeans>
Direct debit payments are a preferred method of payment for many companies. As such, suppliers who wish to market the availability of Direct Debit capabilities to new or existing customers can use the PaymentMeans ASBIE in the following way:
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">49</cbc:PaymentMeansCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cbc:InstructionNote>Call 1300 111 111 or visit www.company1.com.au to arrange regular automatic payments.</cbc:InstructionNote>
</cac:PaymentMeans>
Note: the presentation of this information to the end customer is the responsibility, and at the discretion of the receiving software solution.
Many suppliers will have Direct Debit arrangements in place with their customers. Suppliers who undertake cyclical invoicing will often send an invoice to a customer several days in advance of the date on which the PayableAmount is deducted from the Payer’s Financial Account.
The following example demonstrates how UBL information elements can be used to convey the required information to support a direct DEBIT into a domestic bank in the UK. If in a country where the financial institution branch is identified using a different methodology, for example bank state branch (BSB), the “SORTCODE” scheme name would be replaced with “BSB”:
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">49</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>SORTCODE</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>83918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cbc:ID
schemeName="SORTCODE">403534</cbc:ID>
<cbc:Name>HSBC BANK PLC</cbc:Name>
<cac:Address>
<cbc:ID>1</cbc:ID>
<cbc:AddressTypeCode>Street</cbc:AddressTypeCode>
<cbc:CityName>Oxford</cbc:CityName>
<cbc:PostalZone>OX13HY</cbc:PostalZone>
<cbc:CountrySubentity>Oxfordshire</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>65 Conmarket St</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode listName="Country
Identification Code" listAgencyID="5">UK</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
<cac:PaymentMandate>
<cbc:ID>EFTDDI1007</cbc:ID>
<cac:PayerFinancialAccount>
<cbc:ID>XXXX920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cbc:ID
schemeName="SORTCODE">403534</cbc:ID>
<cbc:Name>HSBC BANK PLC</cbc:Name>
<cac:Address>
<cbc:ID>1</cbc:ID>
<cbc:AddressTypeCode>Street</cbc:AddressTypeCode>
<cbc:CityName>Oxford</cbc:CityName>
<cbc:PostalZone>OX13HY</cbc:PostalZone>
<cbc:CountrySubentity>Oxfordshire</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>65 Conmarket St</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode listName="Country
Identification Code"
listAgencyID="5">UK</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:FinancialInstitutionBranch>
</cac:PayerFinancialAccount>
<cac:ValidityPeriod>
<cbc:StartDate>2018-07-01</cbc:StartDate>
<cbc:EndDate>2019-06-01</cbc:EndDate>
</cac:ValidityPeriod>
</cac:PaymentMandate>
</cac:PaymentMeans>
Note: the payer’s account number SHOULD be obscured to minimise security risks.
<cac:PaymentMeans>
<cbc:ID>EFT</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE
4461">49</cbc:PaymentMeansCode>
<cbc:PaymentChannelCode>IBAN</cbc:PaymentChannelCode>
<cbc:InstructionID>888276612262653</cbc:InstructionID>
<cac:PayeeFinancialAccount>
<cbc:ID>GB86HBUK40353483918920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cac:FinancialInstitution>
<cbc:ID>HBUKGB4108P</cbc:ID>
</cac:FinancialInstitution>
</cac:FinancialInstitutionBranch>
</cac:PayeeFinancialAccount>
<cac:PaymentMandate>
<cbc:ID>IBANDDI1007</cbc:ID>
<cac:PayerFinancialAccount>
<cbc:ID>xxxxx920</cbc:ID>
<cac:FinancialInstitutionBranch>
<cac:FinancialInstitution>
<cbc:ID>HBUKGB4108P</cbc:ID>
</cac:FinancialInstitution>
</cac:FinancialInstitutionBranch>
</cac:PayerFinancialAccount>
<cac:ValidityPeriod>
<cbc:StartDate>2018-07-01</cbc:StartDate>
<cbc:EndDate>2019-06-01</cbc:EndDate>
</cac:ValidityPeriod>
</cac:PaymentMandate>
</cac:PaymentMeans>
Note: the payer’s account number SHOULD be obscured to minimise security risks.
The PaymentMeans ASBIE can be used in the following way to fulfil the scenario for Credit and Debit Card:
<cac:PaymentMeans>
<cbc:ID>DirectDebit</cbc:ID>
<cbc:PaymentMeansCode listID="UN/ECE 4461">48</cbc:PaymentMeansCode>
<cac:CardAccount>
<cbc:PrimaryAccountNumberID>4558 XXXX XXXX XX01</cbc:PrimaryAccountNumberID>
<cbc:NetworkID>VISA</cbc:NetworkID>
</cac:CardAccount>
</cac:PaymentMeans>
Note: the payer’s account number SHOULD be obscured to minimise security risks.
The NetworkID could contain values from an enumerated list, for example Visa, Mastercard, American Express, Discover, Diners, JCB, UnionPay
It is common for invoices to include information on prepaid amounts including deposits. Solution implementers SHOULD use the UBL PrepaidPayment ASBIE to reflect these amounts.
The following example describes a pre-payment of $200.00 Dollars received by the supplier on the 3rd of December 2018. The InstructionID BBIE has been used to provide additional details including the payment reference received by the supplier.
<cac:PrepaidPayment>
<cbc:ID>EFT</cbc:ID>
<cbc:PaidAmount currencyID="USD">200.00</cbc:PaidAmount>
<cbc:ReceivedDate>2018-12-03</cbc:ReceivedDate>
<cbc:PaidDate>2018-12-01</cbc:PaidDate>
<cbc:PaidTime>2</cbc:PaidTime>
<cbc:InstructionID>REF:888276612262653</cbc:InstructionID>
</cac:PrepaidPayment>
In addition, the PrepaidAmount BBIE SHOULD be populated within the LegalMonetaryTotal ASBIE.
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="AUD”>100.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="AUD">100.00</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="AUD">110.00</cbc:TaxInclusiveAmount>
<cbd:PrepaidAmount currencyID="AUD">55.00</cbc:PrepaidAmount>
<cbc:PayableAmount currencyID="AUD">55.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Todd, Albers (todd.albers@mpls.frb.org) Federal Reserve Bank of Minneapolis
Kenneth Bengtsson (kbengtsson@efact.pe) Individual Member
Martijn van den Boogaard (martijn.vandenboogaard@gmail.com), Individual Member
Ken Holman (gkholman@CraneSoftwrights.com) Crane Softwrights Ltd
Erlend Klakegg Bergheim (erlend.klakegg.bergheim@difi.no) Difi-Agency for Public Management and eGovernment
Matt Lewis (matt@capabilitywise.com.au) Individual Member
Ole Madsen (olemad@erst.dk) Danish Business Authority
Andrew Mitchell (reilly@bigpond.net.au) Individual Member
Oriol Bausa Peris (oriol@b2brouter.net) Individual Member
Revision |
Date |
Editor |
Changes Made |
01 |
11 May 2019 |
Matt & Levine |
Initial version in OASIS format and first instance of incorporating payment types feedback collected from members |
02 |
22 May 2019 |
Levine |
Fixed various structural issues with the examples, eg address Revised to include usage of payment mandate in section |
03 |
06 June 2019 |
Levine |
Revised to include CardAccount under PaymentMandate and removed editorials/working sections |
04 |
20 June 2019 |
Levine |
Incorporated feedback from Pacific Calls. |
05 |
27 November |
Levine |
Incorporated feedback from first public review. |