Attestwire › Rule reference › BR-CO-16
BR-CO-16 The amount due is the gross total, less what is already paid
noun · EN 16931 · fatal · BT-115
an amount due that is not what is owed minus what is paid.
Your invoice was refused because the amount it asks the customer to pay does not match the total after deducting what was already paid. The classic case is an invoice with a deposit whose “amount due” still shows the full total. In the standard the amount due is field 115, written BT-115, and BR-CO-16 is the rule that checks the deduction.
- Business term
BT-115— Amount due for payment- Severity
fatal- Applies to
All profiles
The fix
Record the deposit as paidAmount and let the amount due be computed, rather than computing the payable figure in your own code and stating both. If you must state it, subtract the deposit from the gross total. Subtracting it from the net is a common slip, and it leaves you short by the VAT on the deposit.
If the deposit was itself invoiced with VAT earlier, check your national rules on prepayment invoices before you net it here at all; some jurisdictions want the earlier document referenced rather than the amount deducted.
What the rule requires
The amount due for payment (BT-115) equals the invoice total with VAT (BT-112), minus the paid amount (BT-113), plus the rounding amount (BT-114).
BT-113 is a prepayment or deposit you have already received. It is stated positive and subtracted by the formula. Do not put a negative number in it, and do not model the deposit as a negative line.
BT-114 is signed, and that trips people up. It is the adjustment that makes the payable figure land on a round number, so rounding down carries a negative value. In this model the two fields are paidAmount and roundingAmount on the invoice itself, not inside declaredTotals.
The rule compares against declaredTotals.payableAmount when your input states it.
Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).
Failing and passing
validateInput({
// ...
lines: [{ id: "1", description: "Consulting", quantity: 10,
unitCode: "HUR", unitPrice: 150,
vatCategory: "S", vatRate: 19 }],
paidAmount: 500,
declaredTotals: { payableAmount: 1785.00 }, // <- BR-CO-16
});
// -> { valid: false, errors: [ { rule: "BR-CO-16", field: "BT-115", ... } ] }validateInput({
// ...
paidAmount: 500,
declaredTotals: { payableAmount: 1285.00 },
});
// -> { valid: true, errors: [] }Why it exists
The amount due is the only figure on the invoice that is an instruction: this is what to transfer. Everything above it describes the supply; this one moves money. That is why it gets its own rule rather than being assumed equal to the gross total.
The two differ on every invoice with a deposit, a retainer drawdown, or a cash-rounding adjustment, and a buyer’s payment run reads the amount due and nothing else. Overstate it and you get paid twice for the deposit.
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": "BR-CO-16",
"field": "BT-115",
"severity": "fatal",
"message": "BR-CO-16 requires the amount due for payment (BT-115) to equal BT-112 − paid amount (BT-113) + rounding amount (BT-114). You declared 1000.00 for BT-115, but the document's own stated figures give 1685.00 — a difference of -685.00 EUR. BT-113 (paid amount) is subtracted and BT-114 (rounding amount) is added — and BT-114 is signed, so a rounding-down carries a negative value. A payable amount that equals BT-112 on an invoice with a deposit is the usual shape of this failure.",
"fix": "Either correct the line data so it sums to your declared figure, or drop declaredTotals.payableAmount and let the library compute it. Note that EN 16931 sums *rounded* line amounts: round each line to 2 decimals first, then add — rounding only the final sum drifts by a cent or two on long invoices.",
"example": "\"declaredTotals\": { \"payableAmount\": 1685.00 }",
"docsUrl": "https://attestwire.com/rules/BR-CO-16"
}How our check differs
Same reachability condition as the rest of the family: no stated payableAmount, no comparison, no finding.
One narrower gap. BT-113 and BT-114 are read from your input as plain numbers. When a document is parsed, an unreadable value in either of those two elements is recorded as an unmapped note rather than as a defect, so a prepaid amount written 500,00 with a decimal comma does not reach this comparison, where the same problem in one of the six main totals would be reported as ATW-DECLARED-TOTAL-NOT-A-NUMBER.
An official validator rejects that document one step earlier, at XML Schema validation, so nothing is let through in practice, but our report will be quieter than KoSIT’s on that file.
See also: BR-CO-15 — where BT-112 comes from; ATW-DECLARED-TOTAL-NOT-A-NUMBER — a stated total that cannot be read as a number.