Attestwire › Rule reference › ATW-DECLARED-TOTAL-NOT-A-NUMBER

ATW-DECLARED-TOTAL-NOT-A-NUMBER A stated total must be a number, written with a decimal point

noun · Attestwire · fatal · BT-115

Your invoice was refused because one of its stated totals is present but is not a number: most often an amount written with a decimal comma, such as 1891,79, or an empty element. Every amount in an e-invoice is written with a dot and no thousands separator. This is Attestwire’s own finding: the official validator rejects the same file one step earlier, at the XML Schema check.

Business term

BT-115 — Document totals (BT-106 to BT-115)

Severity

fatal

Applies to

All profiles, on a document the library reads

The fix

Write the amount with a dot as the decimal separator and no thousands separator: 1891.79 rather than 1891,79 or 1.891,79. Formatting for a human reader belongs on the rendered invoice, never in the XML.

What the rule requires

Every monetary amount in both e-invoice syntaxes is an XML Schema decimal, and a decimal has exactly one decimal separator: the dot. 1891.79 is an amount; 1891,79, 1.891,79 and an empty element are not.

This finding covers the document totals the invoice states: the sum of line net amounts (BT-106), allowances and charges (BT-107, BT-108), the totals without and with VAT (BT-109, BT-112), the VAT totals (BT-110, BT-111) and the amount due (BT-115).

There is no EN 16931 business rule for this, which is why the id starts with ATW: it is ours. The official validator stops such a file at the XML Schema step, before any business rule runs, with an error like cvc-datatype-valid.1.2.1.

A passing value

<cbc:PayableAmount>1891.79</cbc:PayableAmount>

Why it exists

A total that cannot be read cannot be checked. Before this finding existed, the value was dropped, so the rules that compare totals, BR-CO-15 and BR-CO-16, had nothing to compare, and the document came back valid with no findings at all. A comma in an amount is how a German or French accounting system formats money for people, and it is the most common way this happens.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "ATW-DECLARED-TOTAL-NOT-A-NUMBER",
  "field": "BT-115",
  "severity": "fatal",
  "message": "The Amount due for payment (BT-115) is present in this document but could not be read as a number: the element holds \"12,34\". That is a decimal comma, which is how most of continental Europe writes an amount and is not how EN 16931 writes one: every monetary amount in both syntaxes is an xs:decimal, and xs:decimal has exactly one decimal separator, the dot. The value was left out of the invoice rather than guessed at, so nothing further compares it — BR-CO-15 and BR-CO-16 need a number on both sides. This is a finding of ours, not a rule of the regulation: the official validator rejects the same document one step earlier, at XML Schema validation, as cvc-datatype-valid.1.2.1.",
  "fix": "Write the amount with a dot decimal separator and no thousands separator: \"12.34\" rather than \"12,34\". Formatting for a human reader belongs in the rendered invoice, never in the XML.",
  "example": "<cbc:PayableAmount>1891.79</cbc:PayableAmount>",
  "xpath": "/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PayableAmount",
  "docsUrl": "https://github.com/attestwire/en16931#not-implemented-yet"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-CO-15 — the total with VAT, which needs this value as a number; BR-CO-16 — the amount due, likewise.