Rule reference

BR-DEC-16 The paid amount (BT-113) is 10.005, which carries 3 decimals; EN 16931 allows at most 2

The paid amount (BT-113) is 10.005, which carries 3 decimals; EN 16931 allows at most 2. BT-113 is money that has already moved — a deposit, a prepayment, a part-settlement — so it is by definition a figure some bank has already booked to the cent, and a value with more precision than that describes a payment nobody made. It also feeds BT-115 directly (BR-CO-16 derives the amount due from it), so the extra digits propagate into the one number the buyer actually pays.

This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.

Business term
BT-113
Severity
fatal

What the library returns

The exact object in result.errors when this rule fires. Generated by running @attestwire/en16931, not transcribed:

TeachingError
{
  "rule": "BR-DEC-16",
  "field": "BT-113",
  "severity": "fatal",
  "message": "The paid amount (BT-113) is 10.005, which carries 3 decimals; EN 16931 allows at most 2. BT-113 is money that has already moved — a deposit, a prepayment, a part-settlement — so it is by definition a figure some bank has already booked to the cent, and a value with more precision than that describes a payment nobody made. It also feeds BT-115 directly (BR-CO-16 derives the amount due from it), so the extra digits propagate into the one number the buyer actually pays.",
  "fix": "Round paidAmount to 2 decimals, taking the value from the payment record rather than recomputing it from a percentage of the invoice total.",
  "example": "\"paidAmount\": 500.00",
  "xpath": "/ubl:Invoice/cac:LegalMonetaryTotal/cbc:PrepaidAmount",
  "docsUrl": "https://attestwire.com/rules/BR-DEC-16"
}

xpath locates the element in the generated UBL document, which is where a KoSIT or Peppol validator will report the same problem.

A passing value

the shape this field expects
"paidAmount": 500.00

The fix

Round paidAmount to 2 decimals, taking the value from the payment record rather than recomputing it from a percentage of the invoice total.

Arrived from a stack trace? The docsUrl on every error links straight here. Something wrong on this page — tell us.