Why does my Peppol invoice fail with BR-CO-17?

The VAT category tax amount on one of your TaxSubtotal blocks does not equal the taxable amount times the VAT rate, rounded to two decimals. The most common cause is a rounding-mode mismatch (banker's vs. half-up) or aggregating line-level VAT instead of computing from the category taxable amount.

Can Invoice Navigator auto-fix BR-CO-17?

Yes, with high confidence (0.96). We recompute the TaxAmount from cbc:TaxableAmount * cbc:Percent / 100 with deterministic round-half-up to two decimals, update the cac:TaxSubtotal, and recompute the parent cac:TaxTotal/cbc:TaxAmount and the LegalMonetaryTotal/TaxInclusiveAmount. The only case requiring manual review is when the rate or taxable amount itself looks wrong (e.g. 0.19 written instead of 19).

What is the difference between BR-CO-17 and BR-CO-14?

BR-CO-17 validates one category at a time: TaxAmount = TaxableAmount * Rate / 100. BR-CO-14 validates the document-level VAT total: cac:TaxTotal/cbc:TaxAmount (BT-110) = sum of category TaxAmount (BT-117). A single off-by-one in BR-CO-17 often cascades into BR-CO-14. Fix BR-CO-17 first.

Which rounding mode should I use for BR-CO-17?

Round half up (commercial rounding) at the category level. The schematron uses XPath `round((TaxableAmount * Percent) div 100 * 100) div 100`, which is half-up. Avoid banker's rounding (round-half-to-even) — it's the default in many languages (Python's `round`, Java's BigDecimal HALF_EVEN) and causes 0.01 drift on amounts ending in 5.

Error codes · EN 16931

BR-CO-17Fixable here

VAT category tax amount must equal taxable amount times rate

This is the rejection, word for word: „[BR-CO-17] BR-CO-17 fires when the VAT category tax amount (BT-117) on a TaxSubtotal does not equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119) divided by 100, rounded to two decimals. It's the single-category sibling of BR-CO-14 (sum of category tax amounts equals document VAT total) and one of the most common Peppol calculation failures.“

The schematron checks, for each cac:TaxTotal/cac:TaxSubtotal: `xs:decimal(cbc:TaxAmount) = round((xs:decimal(cbc:TaxableAmount) * xs:decimal(cac:TaxCategory/cbc:Percent)) div 100 * 100) div 100`. Failures arise from: (1) Banker's rounding vs. half-up rounding mismatches — financial systems often use round-half-to-even, schematron uses round-half-up. (2) Floating-point accumulation when category amounts are computed by summing line-level VAT instead of (taxable_amount * rate / 100). (3) Currency precision drift — emitting four decimals on TaxableAmount and two on TaxAmount creates rounding errors. (4) Multi-rate invoices where one TaxSubtotal is correct and another is off by 0.01. (5) Wrong VAT rate cast (e.g. 19 vs. 19.00 vs. 0.19) by a templating engine. (6) Negative TaxableAmount on credit notes flipped sign on TaxAmount differently.

What to have readyThe missing value from your purchase order, contract or bookkeeping.

What we doStep 1: For every cac:TaxTotal/cac:TaxSubtotal, read cbc:TaxableAmount (BT-116), cac:TaxCategory/cbc:Percent (BT-119), cbc:TaxAmount (BT-117). Step 2: Compute the expected TaxAmount as `round_half_up(TaxableAmount * Percent / 100, 2)`. Use Decimal arithmetic, not float — `Decimal(taxable) * Decimal(percent) / Decimal('100')` in Python with `ROUND_HALF_UP`. Step 3: Compare to the emitted TaxAmount. If different by exactly 0.01 it's a rounding-mode bug. If different by more, the TaxableAmount or rate is wrong. Step 4: Rewrite cbc:TaxAmount with the recomputed value, keeping the currencyID attribute and two-decimal formatting (`'{:.2f}'.format(value)`). Step 5: Recompute downstream totals: BT-110 (cbc:TaxAmount on cac:TaxTotal — sum of subtotal TaxAmount) and BT-112 (cbc:TaxInclusiveAmount). Step 6: Re-validate. BR-CO-17 should clear, and BR-CO-14 should also pass if the totals are recomputed correctly. Step 7: If the input data was wrong (rate cast as integer, taxable amount truncated), fix the source mapping — auto-fixing the symptom hides a recurring bug.

Choose the rejected invoiceor drop it here

XRechnung XML or ZUGFeRD PDF. Checking is free · corrected file €1.90 · the first every 30 days is free · no sign-up.

If you enter it yourself in your invoicing software

Before

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">190.01</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="EUR">190.01</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19.00</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>

After

<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
  <cac:TaxSubtotal>
    <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxCategory>
      <cbc:ID>S</cbc:ID>
      <cbc:Percent>19.00</cbc:Percent>
      <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
    </cac:TaxCategory>
  </cac:TaxSubtotal>
</cac:TaxTotal>

What the finding looks likeExample

FindingValue missing · BR-CO-17

From youThe missing value

ThenPassed

ProofSHA-256 and /verify link after the check

Often appears together with

BR-45Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116).BR-48VAT category rate required BR-AE-09Reverse charge VAT breakdown tax amount must be zero