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.
| Term | Meaning | UBL element |
|---|---|---|
| - | Allowance or charge indicator, document level | cac:AllowanceCharge/cbc:ChargeIndicator |
| - | Allowance or charge indicator, line level | cac: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
TrueorTRUE, which fails even earlier, at the schema.
How to fix it
- Map the flag explicitly when writing the XML: a charge becomes the literal
true, an allowance the literalfalse. - Apply the same mapping to line-level entries, and write
falseon the price discount insidecac:Price. - Check the meaning as well as the spelling. When the document allowance of the rich invoice was flagged
trueby mistake, it was counted as a charge:BR-CO-11,BR-CO-12andBR-S-08failed, and its allowance code95was rejected as a charge code. - 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
- The failing invoice reports PEPPOL-EN16931-R043. The corrected document passes every layer with no findings.Download the failing XMLDownload the corrected XML
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
InvoiceandCreditNote. A credit note with its document charge written as1reported 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-R120failed too, because the line net amount check subtracts only allowances spelledfalseand adds only charges spelledtrue.
Related rules
- PEPPOL-EN16931-R044 covers the indicator of the price discount, which must be false
- PEPPOL-EN16931-R120 leaves a line allowance or charge out of its calculation unless it is spelled true or false
- BR-CO-22 is one of the EN 16931 rules that still treats an indicator of 1 as a charge
- Browse every rule in the reference
- Background: How Peppol invoice validation actually works
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.
