BankServicesBillingStatementV03

camt.086.001.03

Scope The BankServicesBillingStatement message is used to send from a Financial Institution (FI) to its wholesale customers (corporations, governments, institutions, etc.), information describing the FI’s billing of services rendered in the form of an electronic statement in a standardised format. The BankServicesBillingStatement is a periodic (usually end of month) recounting of all service chargeable events that occurred during a reporting cycle, typically a calendar month, along with detailed tax and currency translation information. Account balance information, although strongly recommended, is not required. Usage The BankServicesBillingStatement message is designed to provide details related to invoices (or an advice of debit) which a financial institution may supply to its customers. The BankServicesBillingStatement is not expressly designed to be an invoice, nor to replace invoices currently in use. The message may be used as an invoice by agreement between the sender and the receiver. No regulatory or legislative requirements were considered when creating this message standard. Users of the BankServicesBillingStatement message are cautioned to be aware of any regulatory or legal requirement for invoices before replacing existing invoices. The BankServicesBillingStatement message can supply the detail supporting separate invoices or debits but it is not the invoice or advice of debit of record. The BankServicesBillingStatement message must accurately reflect all the charge and tax related events that occurred during the calendar month and how the FI and taxing authorities were compensated for these events. The BankServicesBillingStatement does not ask the financial institution to revise its established pricing and billing procedures. How, when and what the customer is actually charged for remains in place. The BankServicesBillingStatement message asks the financial institution to aggregate and report what actually happened during the calendar month. The BankServicesBillingStatement message is intended for use with the ISO 20022 Business Application Header.

Message Construction

Every ISO20022 message has at the highest level what we call ‘building blocks’. Because the message is constructed as immutable records, the association is by composition. Below you can see the relationship between the message and its constituent building blocks: For comparison, see the ISO20022 official specification

classDiagram
     direction LR
%% BankServicesBillingStatementV03 recursion level 0 with max 0
BankServicesBillingStatementV03 *-- "1..1" ReportHeader6 : ReportHeader
BankServicesBillingStatementV03 *-- "1..1" StatementGroup3 : BillingStatementGroup
  

Now, we will zero-in one-by-one on each of these building blocks.

ReportHeader building block

Provides header details on the billing statement report. Provides header details on the report. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% ReportHeader6 recursion level 0 with max 1
class ReportHeader6{
    ReportIdentification IsoMax35Text
}
ReportHeader6 *-- "0..1" Pagination1 : MessagePagination
%% Pagination1 recursion level 1 with max 1
class Pagination1{
    PageNumber IsoMax5NumericText
    LastPageIndicator IsoYesNoIndicator
}
  

ReportHeader6 members

BillingStatementGroup building block

Group of bank services billing statements with the same sender and receiver characteristics. Group of the statement header reporting the bank services billing and the billing statement. For comparison, see the ISO20022 official specification

classDiagram
   direction tb
%% StatementGroup3 recursion level 0 with max 1
class StatementGroup3{
    GroupIdentification IsoMax35Text
}
StatementGroup3 *-- "1..1" PartyIdentification138 : Sender
StatementGroup3 *-- "0..2" Contact4 : SenderIndividualContact
StatementGroup3 *-- "1..1" PartyIdentification138 : Receiver
StatementGroup3 *-- "0..2" Contact4 : ReceiverIndividualContact
StatementGroup3 *-- "1..0" BillingStatement3 : BillingStatement
%% PartyIdentification138 recursion level 1 with max 1
class PartyIdentification138{
    Name IsoMax140Text
    LegalName IsoMax140Text
    CountryOfResidence CountryCode
}
PartyIdentification138 *-- "0..1" PostalAddress24 : PostalAddress
PartyIdentification138 *-- "1..1" IParty43Choice : Identification
PartyIdentification138 *-- "0..1" Contact4 : ContactDetails
%% Contact4 recursion level 1 with max 1
class Contact4{
    NamePrefix NamePrefix2Code
    Name IsoMax140Text
    PhoneNumber IsoPhoneNumber
    MobileNumber IsoPhoneNumber
    FaxNumber IsoPhoneNumber
    EmailAddress IsoMax2048Text
    EmailPurpose IsoMax35Text
    JobTitle IsoMax35Text
    Responsibility IsoMax35Text
    Department IsoMax70Text
    PreferredMethod PreferredContactMethod1Code
}
Contact4 *-- "0..0" OtherContact1 : Other
%% PartyIdentification138 recursion level 1 with max 1
class PartyIdentification138{
    Name IsoMax140Text
    LegalName IsoMax140Text
    CountryOfResidence CountryCode
}
PartyIdentification138 *-- "0..1" PostalAddress24 : PostalAddress
PartyIdentification138 *-- "1..1" IParty43Choice : Identification
PartyIdentification138 *-- "0..1" Contact4 : ContactDetails
%% Contact4 recursion level 1 with max 1
class Contact4{
    NamePrefix NamePrefix2Code
    Name IsoMax140Text
    PhoneNumber IsoPhoneNumber
    MobileNumber IsoPhoneNumber
    FaxNumber IsoPhoneNumber
    EmailAddress IsoMax2048Text
    EmailPurpose IsoMax35Text
    JobTitle IsoMax35Text
    Responsibility IsoMax35Text
    Department IsoMax70Text
    PreferredMethod PreferredContactMethod1Code
}
Contact4 *-- "0..0" OtherContact1 : Other
%% BillingStatement3 recursion level 1 with max 1
class BillingStatement3{
    StatementIdentification IsoMax35Text
    CreationDateTime IsoISODateTime
    Status BillingStatementStatus1Code
}
BillingStatement3 *-- "1..1" DatePeriod1 : FromToDate
BillingStatement3 *-- "1..1" CashAccountCharacteristics3 : AccountCharacteristics
BillingStatement3 *-- "0..0" BillingRate1 : RateData
BillingStatement3 *-- "0..0" CurrencyExchange6 : CurrencyExchange
BillingStatement3 *-- "0..0" BillingBalance1 : Balance
BillingStatement3 *-- "0..0" BillingCompensation1 : Compensation
BillingStatement3 *-- "0..0" BillingService2 : Service
BillingStatement3 *-- "0..0" BillingTaxRegion2 : TaxRegion
BillingStatement3 *-- "0..0" BalanceAdjustment1 : BalanceAdjustment
BillingStatement3 *-- "0..0" BillingServiceAdjustment1 : ServiceAdjustment
  

StatementGroup3 members

Extensibility and generalization considerations

To facilitate generalized design patterns in the system, the BankServicesBillingStatementV03 implementation follows a specific implementaiton pattern. First of all, BankServicesBillingStatementV03 impleemnts IOuterRecord indicating it is the outermost logical part of the message definition. Like all message wrappers, BankServicesBillingStatementV03Document implements IOuterDocument. Because BankServicesBillingStatementV03 implements IOuterDocument, it is a suitable template parameter for IOuterDocument, and causes the internal ‘Message’ to be of type BankServicesBillingStatementV03.

classDiagram
    class IOuterRecord
    BankServicesBillingStatementV03 --|> IOuterRecord : Implements
    BankServicesBillingStatementV03Document --|> IOuterDocument~BankServicesBillingStatementV03~ : Implements
    class IOuterDocument~BankServicesBillingStatementV03~ {
        BankServicesBillingStatementV03 Message
     }
  

Document wrapper for serialization

The only real purpose BankServicesBillingStatementV03Document serves is to cause the document to be serialized into the ‘urn:iso:std:iso:20022:tech:xsd:camt.086.001.03’ namespace. Therefore, it will probably be the usual practice to build the message and construct this wrapper at the last minute using BankServicesBillingStatementV03.ToDocument() method. The returned BankServicesBillingStatementV03Document value will serialize correctly according to ISO 20022 standards.

classDiagram
    BankServicesBillingStatementV03Document *-- BankServicesBillingStatementV03 : Document
  

Sample of message format

This is an abbreviated version of what the message should look like.

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:camt.086.001.03">
    <BkSvcsBllgStmt>
        <RptHdr>
            <!-- ReportHeader inner content -->
        </RptHdr>
        <BllgStmtGrp>
            <!-- BillingStatementGroup inner content -->
        </BllgStmtGrp>
    </BkSvcsBllgStmt>
</Document>

Data from ISO specification

This is the technical data from the specification document.

<messageDefinition
  xmi:id="_bf9SDW2PEei3KuUgpx7Xcw"
  nextVersions="_u4dOAdcAEeq_l4BJLVUF2Q"
  previousVersion="_sHrTETqxEeWZFYSPlduMhw"
  name="BankServicesBillingStatementV03"
  definition="Scope&#xD;&#xA;The BankServicesBillingStatement message is used to send from a Financial Institution (FI) to its wholesale customers (corporations, governments, institutions, etc.), information describing the FI’s billing of services rendered in the form of an electronic statement in a standardised format. The BankServicesBillingStatement is a periodic (usually end of month) recounting of all service chargeable events that occurred during a reporting cycle, typically a calendar month, along with detailed tax and currency translation information. Account balance information, although strongly recommended, is not required.&#xD;&#xA;Usage&#xD;&#xA;The BankServicesBillingStatement message is designed to provide details related to invoices (or an advice of debit) which a financial institution may supply to its customers. The BankServicesBillingStatement is not expressly designed to be an invoice, nor to replace invoices currently in use. The message may be used as an invoice by agreement between the sender and the receiver. No regulatory or legislative requirements were considered when creating this message standard. Users of the BankServicesBillingStatement message are cautioned to be aware of any regulatory or legal requirement for invoices before replacing existing invoices.&#xD;&#xA;The BankServicesBillingStatement message can supply the detail supporting separate invoices or debits but it is not the invoice or advice of debit of record. The BankServicesBillingStatement message must accurately reflect all the charge and tax related events that occurred during the calendar month and how the FI and taxing authorities were compensated for these events. The BankServicesBillingStatement does not ask the financial institution to revise its established pricing and billing procedures. &#xD;&#xA;How, when and what the customer is actually charged for remains in place. The BankServicesBillingStatement message asks the financial institution to aggregate and report what actually happened during the calendar month.&#xD;&#xA;The BankServicesBillingStatement message is intended for use with the ISO 20022 Business Application Header."
  registrationStatus="Registered"
  messageSet="_9st4YaVzEeW0_oPI5GRpwg"
  xmlTag="BkSvcsBllgStmt"
  rootElement="Document"
  xmlns:xmi="http://www.omg.org/XMI">
  <messageBuildingBlock
    xmi:id="_bf9SD22PEei3KuUgpx7Xcw"
    nextVersions="_u4dOB9cAEeq_l4BJLVUF2Q"
    previousVersion="_sHrTEzqxEeWZFYSPlduMhw"
    name="ReportHeader"
    definition="Provides header details on the billing statement report."
    registrationStatus="Provisionally Registered"
    maxOccurs="1"
    minOccurs="1"
    xmlTag="RptHdr"
    complexType="_IXU44Xk4Eei6JsZKrqN0hQ" />
  <messageBuildingBlock
    xmi:id="_bf9SEW2PEei3KuUgpx7Xcw"
    nextVersions="_u4dOCdcAEeq_l4BJLVUF2Q"
    previousVersion="_sHrTFTqxEeWZFYSPlduMhw"
    name="BillingStatementGroup"
    definition="Group of bank services billing statements with the same sender and receiver characteristics."
    registrationStatus="Provisionally Registered"
    minOccurs="1"
    xmlTag="BllgStmtGrp"
    complexType="_BMC6W249EeiU9cctagi5ow" />
  <messageDefinitionIdentifier
    businessArea="camt"
    messageFunctionality="086"
    flavour="001"
    version="03" />
</messageDefinition>

ISO Building Blocks

The following items are used as building blocks to construct this message.