Attestwire › Rule reference › ATW-CREDIT-NOTE-NEGATIVE-AMOUNTS
ATW-CREDIT-NOTE-NEGATIVE-AMOUNTS This document is a credit note (BT-3 = "381") and states negative amounts: line 1 has a net amount (BT-131) of -1500
This document is a credit note (BT-3 = "381") and states negative amounts: line 1 has a net amount (BT-131) of -1500. EN 16931 credit notes carry **positive** amounts — the document type is what conveys the direction of the money, and stating it twice reverses it. A credit note for 500.00 says 500.00; a credit note for −500.00 says the buyer owes 500.00 more, which is an invoice. The two idioms are both lawful separately: a "negative invoice" (BT-3 = "380" with negative amounts) is a different, equally legal construct, and the schematron rejects neither, so no validator will stop this. That is exactly why it is worth saying here.
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-3 / BT-131- Severity
warning
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "ATW-CREDIT-NOTE-NEGATIVE-AMOUNTS",
"field": [
"BT-3",
"BT-131"
],
"severity": "warning",
"message": "This document is a credit note (BT-3 = \"381\") and states negative amounts: line 1 has a net amount (BT-131) of -1500. EN 16931 credit notes carry **positive** amounts — the document type is what conveys the direction of the money, and stating it twice reverses it. A credit note for 500.00 says 500.00; a credit note for −500.00 says the buyer owes 500.00 more, which is an invoice. The two idioms are both lawful separately: a \"negative invoice\" (BT-3 = \"380\" with negative amounts) is a different, equally legal construct, and the schematron rejects neither, so no validator will stop this. That is exactly why it is worth saying here.",
"fix": "Make the amounts positive and leave invoiceTypeCode at \"381\". If you meant a negative invoice instead, set invoiceTypeCode to \"380\" and keep the negative amounts. Either is fine; both together is not. Whichever you pick, name the invoice being adjusted in precedingInvoices (BT-25) so the receiver can net the two documents.",
"example": "\"invoiceTypeCode\": \"381\", \"lines\": [{ \"quantity\": 2, \"unitPrice\": 250 }]",
"xpath": "/ubl:CreditNote/cac:CreditNoteLine/cbc:LineExtensionAmount",
"docsUrl": "https://github.com/attestwire/en16931#not-implemented-yet"
}
xpath locates the element in a UBL
document, which is where a KoSIT or Peppol validator will report the
same problem. It is a UBL path on every profile. A
xrechnung-cii or facturx-en16931 invoice
gets the same string, so map it to the CII element yourself.
A passing value
"invoiceTypeCode": "381", "lines": [{ "quantity": 2, "unitPrice": 250 }]The fix
Make the amounts positive and leave invoiceTypeCode at "381". If you meant a negative invoice instead, set invoiceTypeCode to "380" and keep the negative amounts. Either is fine; both together is not. Whichever you pick, name the invoice being adjusted in precedingInvoices (BT-25) so the receiver can net the two documents.