Skip to content

PEPPOL-EN16931-R043: Write the charge indicator as true or false, not 1 or 0

Peppol wants cbc:ChargeIndicator on document and line allowances and charges spelled as true or false. The schema also allows 1 and 0; Peppol does not.

Peppol BIS BillingFatal: the document is invalidAllowances and charges

The short answer

PEPPOL-EN16931-R043 fails when cbc:ChargeIndicator in a document-level or line-level cac:AllowanceCharge holds anything other than the words true or false. Write true for a charge and false for an allowance. In the recorded example the document charge was written as 1.

The UBL schema types the element as a boolean, which also permits 1 and 0, so the XSD layer passes and the EN 16931 layer reads 1 as a charge. Only the Peppol layer objects.

What the rule checks

The rule runs on each cac:AllowanceCharge directly under the document root and directly under each cac:InvoiceLine or cac:CreditNoteLine. It trims the text of cbc:ChargeIndicator and accepts exactly true or false, in lower case.

Surrounding whitespace is tolerated: true with spaces passed every layer when tried.

Spellings the schema refuses never reach this rule. TRUE failed the XSD layer when tried, and the EN 16931 and Peppol layers were skipped.

The price discount inside cac:Price is outside its scope. A 1 or 0 there is reported by PEPPOL-EN16931-R044, which accepts only false.

The EN 16931 rules compare the indicator as a boolean, so they still see 1 as a charge and 0 as an allowance. When tried with its reason removed, the charge written as 1 reported BR-CO-22 and BR-38 as well as this rule.

TermMeaningUBL element
-Allowance or charge indicator, document levelcac:AllowanceCharge/cbc:ChargeIndicator
-Allowance or charge indicator, line levelcac:InvoiceLine/cac:AllowanceCharge/cbc:ChargeIndicator (cac:CreditNoteLine in a credit note)

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

  • The serialiser writes booleans as 1 and 0, which the XML schema allows and some libraries do by default.
  • The value is copied from a database bit column or integer flag without conversion.
  • A generator driven by the XSD produces whichever lexical form of a boolean it prefers.
  • The flag is built with string formatting that yields True or TRUE, which fails even earlier, at the schema.

How to fix it

  1. Map the flag explicitly when writing the XML: a charge becomes the literal true, an allowance the literal false.
  2. Apply the same mapping to line-level entries, and write false on the price discount inside cac:Price.
  3. Check the meaning as well as the spelling. When the document allowance of the rich invoice was flagged true by mistake, it was counted as a charge: BR-CO-11, BR-CO-12 and BR-S-08 failed, and its allowance code 95 was rejected as a charge code.
  4. Validate again after the change. On a line, the corrected spelling also lets the Peppol line calculation count the entry.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: the document charge has 1 as its indicator

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>1</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Example document charge</cbc:AllowanceChargeReason>
  <!-- percentage, amount, base amount and tax category omitted from this fragment -->
</cac:AllowanceCharge>

Fragment of the corrected invoice: the indicator is the word true

<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>
  <cbc:AllowanceChargeReasonCode>CG</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Example document charge</cbc:AllowanceChargeReason>
  <!-- percentage, amount, base amount and tax category omitted from this fragment -->
</cac:AllowanceCharge>

Only the indicator of the document charge differs: 1 in the failing invoice, true in the corrected one. The failing document reports only PEPPOL-EN16931-R043. The XSD layer accepts 1 as a boolean, and the EN 16931 layer treats it as a charge, so the charge total of 3.50 and the Standard rated taxable amount still add up there.

What the validator reported

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

Where it applies

  • Applies to Invoice and CreditNote. A credit note with its document charge written as 1 reported only this rule when tried.
  • Reported by the Peppol layer only, as a fatal finding.
  • On a line the wrong spelling can bring a second Peppol finding. When the line allowance of the rich invoice was written as 0, PEPPOL-EN16931-R120 failed too, because the line net amount check subtracts only allowances spelled false and adds only charges spelled true.

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of PEPPOL-EN16931-R043 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.