Attestwire › Rule reference › BR-CO-15

BR-CO-15 The total with VAT is the net total plus the VAT total

noun · EN 16931 · fatal · BT-112

net plus VAT that does not make gross. It should.

Your invoice was refused because its total including VAT is not its total before VAT plus its VAT. This is the simplest sum on the invoice, so a failure here usually means one of the two figures underneath it is wrong and this one followed. In the standard the total with VAT is field 112, written BT-112, and BR-CO-15 is the rule that checks the addition.

Business term

BT-112 — Invoice total amount with VAT

Severity

fatal

Applies to

All profiles

The fix

Before you touch this total, look at whether BR-CO-13 or BR-CO-14 also fired. This rule very often breaks as a consequence rather than a cause: fix the net total or the VAT total and the gross total falls into place. If BR-CO-15 is the only finding, the addition itself is the problem, and the usual culprit is a gross figure carried over from a template or a legacy field while the two figures under it were recomputed.

Correct it in declaredTotals.taxInclusiveAmount, or leave that out and let the library compute it.

What the rule requires

The invoice total with VAT (BT-112) equals the invoice total without VAT (BT-109) plus the invoice total VAT amount (BT-110).

Note what is not in it. Any deposit already paid (BT-113) and any rounding adjustment (BT-114) come off later, at BR-CO-16. BT-112 is the gross value of the supply, not the amount you are asking for today.

The rule compares against declaredTotals.taxInclusiveAmount when you state it.

Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).

Failing and passing

validateInput({
  // ...
  lines: [{ id: "1", description: "Consulting", quantity: 10,
            unitCode: "HUR", unitPrice: 150,
            vatCategory: "S", vatRate: 19 }],
  declaredTotals: { taxInclusiveAmount: 1780.00 },   // <- BR-CO-15
});
// -> { valid: false, errors: [ { rule: "BR-CO-15", field: "BT-112", ... } ] }

validateInput({
  // ...
  declaredTotals: { taxInclusiveAmount: 1785.00 },
});
// -> { valid: true, errors: [] }

Why it exists

This is the number a person looks at. It goes on the remittance advice, it gets approved, and a buyer’s system checks it against the purchase order. Tying it to the net total plus the VAT total by rule means the headline figure and the tax detail underneath it cannot drift apart, which they otherwise do the first time somebody adds a charge to one and not the other.

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-15",
  "field": "BT-112",
  "severity": "fatal",
  "message": "BR-CO-15 requires the invoice total with VAT (BT-112) to equal BT-109 + BT-110. You declared 1.00 for BT-112, but the document's own stated figures give 2.00 — a difference of -1.00 EUR. Check whether one of BT-109 or BT-110 is also flagged above; BR-CO-15 often fails only as a consequence.",
  "fix": "Either correct the line data so it sums to your declared figure, or drop declaredTotals.taxInclusiveAmount 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\": { \"taxInclusiveAmount\": 2.00 }",
  "docsUrl": "https://attestwire.com/rules/BR-CO-15"
}

How our check differs

See also: BR-CO-13 — where BT-109 comes from; BR-CO-14 — where BT-110 comes from; BR-CO-16 — what is still deducted after BT-112.