Buyer email address (BT-58) in an unaccepted format

What does this mean?

The field is optional. BT-58 is the email of the buyer's contact, at cac:AccountingCustomerParty/cac:Party/cac:Contact/cbc:ElectronicMail. The message describes the accepted pattern piece by piece as [email protected]: before the @, Latin letters, digits, dots, underscores and hyphens, starting and ending with a letter or digit; the domain, letters, digits, dots and hyphens, starting and ending with a letter or digit; and a final extension of Latin letters, no fewer than two and no more than three. Several addresses are separated by a semicolon ;.

That pattern is narrower than the definition of an email address in the internet standards, and that is the trap: addresses that work and reach their owner fall outside it. By the letter of the message, [email protected] fails because the plus sign is not on the list, and [email protected] fails because its extension is six letters against a limit of three, while [email protected] passes because the final extension is sa and the domain is company.com. We read each rule's message and severity from the compiled schematron, not the test that fires it, so what we say about long extensions is a reading of the message, not an observation from a live run.

It is a warning: the invoice is accepted and the warning recorded with it. The cost is that the signed document carries an address the Authority does not accept, and any system at the buyer that reads the XML to learn where to route the document finds an address off the agreed pattern. This field has nothing to do with the email the invoice is actually sent to: that goes from your system to the buyer's inbox; this is text inside the document.

Why does it happen?

Ordered from the most common to the least — your cause is most likely the first or the second.

• An address with a plus sign or another character outside the list before the @, such as a tagged Gmail address [email protected], or an address with quotation marks.
• A domain extension of four letters or more, by the letter of the message: .info, .store, .online, .shop. The domain is real and the address works; the pattern in the message stops at three.
• A space or a line break at the end of the value, carried over from a spreadsheet or an untrimmed form field; the name together with the address as Accounts <[email protected]>; or a mailto: prefix copied from a link.
• Several addresses separated by an ordinary comma , instead of the semicolon the message names.
• A domain in Arabic or other non-Latin letters (.السعودية), a dot at the start or end of the local part, or an address with no dot in its domain at all, such as user@localhost.
• A template that always writes cbc:ElectronicMail, even empty: an empty string is not on the pattern, and an optional element is left out, not left empty.

How to fix it

4 steps, then send the invoice again.

1. 1
   Trim the value and check it against the pattern the message describes

   Before writing: strip spaces and line breaks from both ends, remove any display name, angle brackets and mailto: prefix, then test what is left with an expression that follows the message letter by letter: ^[A-Za-z0-9]([A-Za-z0-9._-]*[A-Za-z0-9])?@[A-Za-z0-9]([A-Za-z0-9.-]*[A-Za-z0-9])?\.[A-Za-z]{2,3}$. Several addresses are separated by ; and each is tested on its own.

2. 2
   What does not match is not sent — and not repaired by guessing

   A correct address outside the pattern, such as one with a long extension or a plus sign, must not be edited to pass: removing the plus makes an address that belongs to someone else. Drop the element from the XML and keep the address on your record for correspondence. The field is optional, and an omitted element trips no code.

3. 3
   Keep the correspondence email apart from the document email

   The email you send the invoice to stays as it is, even off the pattern; it is yours, and the Authority does not check it. What is checked is only what you write inside the document, so do not make the two one field in your system if your customers use addresses the pattern does not accept.

4. 4
   Fix the record, not the accepted invoice

   An invoice that carried the warning is issued and stays in your chain, and needs no note. Correct the address on the buyer record, and check their phone while you are there (BR-KSA-85): the source is usually the same.

This code does not block acceptance, so the invoice you have is compliant. Correct the data so the warnings disappear from future invoices.

Frequently asked questions