Rule reference

BR-CO-03 The invoice states the VAT point both as an explicit date (BT-7 = "2026-07-31") and as a code (BT-8 = "35"), and EN 16931 allows only one of the two

The invoice states the VAT point both as an explicit date (BT-7 = "2026-07-31") and as a code (BT-8 = "35"), and EN 16931 allows only one of the two. The tax point decides which VAT period the supply falls into and which rate applies if a rate changed — so two statements of it are two potentially different answers to a question that has one. The code form delegates the answer to a rule ("the invoice date", "the actual delivery date"); the date form states it outright. Pick the one your tax treatment actually rests on.

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-7 / BT-8
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-CO-03",
  "field": [
    "BT-7",
    "BT-8"
  ],
  "severity": "fatal",
  "message": "The invoice states the VAT point both as an explicit date (BT-7 = \"2026-07-31\") and as a code (BT-8 = \"35\"), and EN 16931 allows only one of the two. The tax point decides which VAT period the supply falls into and which rate applies if a rate changed — so two statements of it are two potentially different answers to a question that has one. The code form delegates the answer to a rule (\"the invoice date\", \"the actual delivery date\"); the date form states it outright. Pick the one your tax treatment actually rests on.",
  "fix": "Remove taxPointDate, or remove invoicingPeriod.descriptionCode — not both fields, one of them. Use the code when the tax point is derived by a standing rule, and the explicit date when it is not.",
  "example": "\"taxPointDate\": \"2026-07-31\"",
  "xpath": "/ubl:Invoice/cbc:TaxPointDate",
  "docsUrl": "https://attestwire.com/rules/BR-CO-03"
}

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
"taxPointDate": "2026-07-31"

The fix

Remove taxPointDate, or remove invoicingPeriod.descriptionCode — not both fields, one of them. Use the code when the tax point is derived by a standing rule, and the explicit date when it is not.

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