SchemaGuard by Ironbark Digital · EN 16931 / Peppol / XRechnung Reference
← All 294 EN 16931 / Peppol Rules & Live Validator
FATAL Official EN 16931 / Peppol / CIUS Rule BT/BG Fields: BT-3

PEPPOL-EN16931-P0101 — E-Invoice Validation Rule & Fix

Fixture ID: peppolBadCreditNoteTypeCode · XPath: /ubl:CreditNote/cbc:CreditNoteTypeCode

1. Why This Rule Triggers (Diagnostic Message)

The document type code (BT-3) is "261", which makes this a credit note — and billing process 01 does not admit that code on a credit note. Peppol scopes its type codes by business process *and* by document: the ProfileID this library emits is urn:fdc:peppol.eu:2017:poacc:billing:01:1.0, and inside it a credit note may carry only 381, 396, 81, 83 or 532. That is a much shorter list than the twenty-six codes PEPPOL-EN16931-P0100 allows on an invoice, and the two lists share nothing — which is deliberate, because in UBL the code lands in a different element on a different root document (cbc:CreditNoteTypeCode on ubl:CreditNote, not cbc:InvoiceTypeCode on ubl:Invoice) and the receiving system branches on that. Note that BR-CL-01 admits a wider credit-note list than this one, so passing it says nothing here. This is a Peppol BIS Billing 3.0 profile rule: it applies because profile is "peppol-bis-3". It does not apply to the en16931, xrechnung-ubl or xrechnung-cii profiles, whose validators will accept the same document.

2. How to Fix PEPPOL-EN16931-P0101

Use "381" for an ordinary credit note, which is what almost every credit note in practice is. "396" is a factored credit note, "532" a forwarder's credit note. If you meant to issue an invoice rather than a credit note, set invoiceTypeCode to "380" — this build picks the document type from BT-3 alone, so the code is what decided you are looking at this rule and not PEPPOL-EN16931-P0100.

3. Valid Code / Payload Example

"invoiceTypeCode": "381"
Test & Validate XML / JSON in Live SchemaGuard Validator →