BR-07An Invoice shall contain the Buyer name (BT-44).

Official rule text

The invoice must contain the buyer name (BT-44) — the name the recipient expects the invoice under.

Severity
Error
Applies to
CII, UBL
Rule set
v2026-08-31
Checked on

Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.

Why does BR-07 happen?

Customer master data usually holds several name fields: display name, search term, invoice recipient. The mapping reads one that is empty for some customers because it is only maintained for searching.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.

UBL
normalize-space(cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) != ''
CII
normalize-space(rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeAgreement/ram:BuyerTradeParty/ram:Name) != ''

Source: rule set v2026-08-31

How do you fix BR-07?

Set BT-44 to the name of the invoice recipient: cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName in UBL, ram:BuyerTradeParty/ram:Name in CII. A differing buyer trading name goes in BT-45 as well — cac:PartyName/cbc:Name. Set only there, BT-44 stays empty and BR-07 goes on reporting a missing name while the XML plainly has one.

In the XML

A UBL fragment. The CII path is named above — same change, different element names.

Fails
<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:CityName>Bonn</cbc:CityName>
    </cac:PostalAddress>
  </cac:Party>
</cac:AccountingCustomerParty>
Fixed
<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:CityName>Bonn</cbc:CityName>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Behörde Bonn</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

Related rules

NormAPI provides technical validation, not tax or legal advice.