Buyer phone number (BT-57) in an unaccepted format

What does this mean?

The field is optional. BT-57 is the telephone of the buyer's contact, at cac:AccountingCustomerParty/cac:Party/cac:Contact/cbc:Telephone. The rule does not ask for it — its message says «if exist» — it governs the shape when it is there: the first character is 0 or +, then digits only, no fewer than four and no more than fifteen. So 0501234567 passes, +966501234567 passes, and 00966501234567 passes because it starts with a zero followed by thirteen digits.

What fails is not a wrong number but a right number written another way: +966 50 123 4567 with its spaces, 050-123-4567 with its dashes, 966501234567 with neither a zero nor a plus, (011) 4567890 with its brackets. Every one of them reaches its owner; the rule accepts exactly one of them. The upper bound — fifteen digits after the plus — is the limit of the international E.164 standard itself, so any international number written in that form passes.

It is a warning: the invoice is accepted and the warning recorded in the response's warningMessages. But the number stays on a signed tax document in a shape the Authority has said it does not read, and an accounts department at the buyer matching the invoice against its own records finds a value that literally differs from theirs. We read each rule's message and severity from the compiled schematron, not the test that fires it: we take «number» in the message to mean the ASCII digits 0 to 9, and Arabic-Indic digits (٠٥٠) are different characters that we cannot promise the validator counts as digits.

Why does it happen?

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

• The online store sends the phone as the customer typed it at checkout — a separated country code and spaces, +966 50 123 4567 — and the system passes it into the XML without cleaning it. By far the most common cause.
• A country code with no prefix: 966501234567. Some systems store the number in E.164 form, drop the plus on the way in and never put it back on the way out.
• A number with dashes, brackets or dots from a manual form, or an extension written after it such as 0114567890 ext 12.
• A template that always writes the telephone element, even empty: <cbc:Telephone></cbc:Telephone> starts with neither a zero nor a plus and trips the same rule. An optional field is left out as a whole element, not left empty.
• A number in Arabic-Indic digits, or text in the phone field altogether, such as «none» or «same as office».

How to fix it

4 steps, then send the invoice again.

1. 1
   Normalise the number before writing it

   One step in the export path: strip everything that is not a digit, then restore the prefix. If the original began with a plus or with 00, write + followed by the digits; if it began with a single zero, leave it; if the country code arrived bare (966…), put a plus in front of it. In any language: remove every character outside 0-9, remembering whether the original started with a plus.

2. 2
   Count the digits, then decide: send it or drop it

   After the prefix, count: 4 to 15 digits is sent, anything else is not. The field is optional, an omitted element trips no code at all, and a wrong value trips this warning on every invoice to that buyer. Do not repair a short number by guessing a country code; a document with no number is better than one with an invented number.

3. 3
   Never write the element empty

   If the buyer has no phone, do not write cac:Contact at all, or write it with only what it has. An empty element trips the rule and serves nobody.

4. 4
   Fix the buyer record, not the accepted invoice

   An invoice accepted with this warning is issued and stays in your chain; it needs no note, and the warning does not ask for a reissue. Correct the number on the buyer record so the next invoice goes out right, and check their email while you are there (BR-KSA-86): the two usually come from the same source.

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