Sample report — fictional data. This is a real run of the diagnostic engine on a synthetic Belgian test invoice with deliberate errors; every company name and number is fictional. In the monthly service, one report like this is produced per client folder from your bulk invoice export, and a person reviews every finding before it reaches you.
London Bridge Ventures
Peppol BIS 3.0 Draft Invoice Diagnostic — Belgium
| Prepared for | SAMPLE — client folder 'Atelier Verhaegen BV' (fictional data) |
|---|---|
| File received | BE-standard-invoice-BROKEN-DEMO.xml (7.0 KB) — received monthly batch — sample run |
| Report date | 21 Jul 2026 |
| Format detected | UBL 2.1 Invoice, Peppol BIS Billing 3.0 profile |
| Checked against | Peppol BIS Billing 3.0 — release 3.0.20 validation artefacts (OpenPeppol’s November 2025 release, mandatory from 23 Feb 2026: CEN-EN16931-UBL schematron v1.3.15 + PEPPOL-EN16931-UBL restrictions, compiled from the official OpenPeppol sources); findings organized into 31 client-readable checks |
Executive summary
This invoice does not yet conform to the published Peppol BIS Billing 3.0 checks executed. We found 11 client-readable blocker checks, covering 14 fatal validator assertions, plus 1 minor warning. Most need a change from your software vendor or IT — this report is the work order to send them.
Fix these first:
The work in numbers: 2 one-time configuration fixes · 2 need data added to customer or product records · 7 need your software vendor or IT · 1 technical finding for your IT or provider.
1 · Structure & profile
| # | Check (rule ID) | Result | Severity | Fix note |
|---|---|---|---|---|
| 1 | Well-formed UBL 2.1 XML, <Invoice>/<CreditNote> root in UBL namespace | PASS | Blocker | File structure reads correctly. |
| 2 | Specification identifier declares Peppol BIS Billing 3.0 (BR-01; PEPPOL-EN16931-R004, fatal) | PASS | Blocker | Correct Peppol BIS Billing 3.0 specification identifier present. |
| 3 | Business process (ProfileID) present and in the Peppol billing format (PEPPOL-EN16931-R001, R007) | PASS | Blocker | Billing-process label correct. |
| 4 | Document type code present, on the UNTDID 1001 invoice/credit-note lists and allowed by the profile (BR-04, BR-CL-01; PEPPOL-EN16931-P0100/P0101) | PASS | Blocker | Document type is on the accepted list for the billing process. |
| 5 | UTF-8 declared and consistent; special characters escaped | PASS | Blocker | Text encoding correct (UTF-8), no unescaped characters. |
| 6 | No empty elements anywhere in the document (PEPPOL-EN16931-R008) | FAIL | Blocker | The export writes empty fields into the file — fields that are present but contain nothing. The Peppol rule set rejects any empty element. Ask your software vendor or IT to change the export so fields with no value are left out entirely. Technical: PEPPOL-EN16931-R008 (fatal): document MUST not contain empty elements — drop empty tags at export. Technical: validator [peppol-en16931-r008, fatal] — Document MUST not contain empty elements. |
2 · Parties & identifiers
| # | Check (rule ID) | Result | Severity | Fix note |
|---|---|---|---|---|
| 7 | Invoice number and issue date present; dates formatted YYYY-MM-DD (BR-02, BR-03; PEPPOL-EN16931-F001) | PASS | Blocker | — |
| 8 | Invoice currency code present, ISO 4217 (BR-05, BR-CL-04; amount currencies BR-CL-03, PEPPOL-EN16931-CL007) | PASS | Blocker | — |
| 9 | Buyer reference or purchase-order reference present (PEPPOL-EN16931-R003) | FAIL | Blocker | The invoice carries neither a buyer reference nor an order number, and the network requires one of the two. Ask each customer what reference they want on invoices and store it in that customer's record — many systems can default it to the customer's own reference or the order number. Technical: PEPPOL-EN16931-R003 (fatal): cbc:BuyerReference or cac:OrderReference/cbc:ID must be present.Technical: validator [peppol-en16931-r003, fatal] — A buyer reference or purchase order reference MUST be provided. |
| 10 | Seller and buyer electronic (Peppol) address present, scheme from the published list (PEPPOL-EN16931-R020, R010; scheme per PEPPOL-EN16931-CL008, BR-CL-25, BR-CL-10) | PASS | Blocker | Electronic routing addresses present for both parties, schemes valid. |
| 11 | Belgian enterprise number valid where scheme 0208 is used — 10 digits + checksum (PEPPOL-COMMON-R043, fatal) | FAIL | Blocker | A Belgian enterprise number used on this invoice isn't valid — it must be the 10-digit KBO/BCE number, and the digits must pass the built-in checksum. Typically a typo, an old 9-digit value, or a VAT number pasted with its BE prefix. Fix it once — in company settings if it's yours, in the customer record if it's theirs — and every future invoice inherits it.Technical: scheme 0208 (KBO/BCE enterprise number) on cbc:EndpointID / cac:PartyIdentification/cbc:ID / cbc:CompanyID must match ^[0-9]{10}$ and pass mod-97 (PEPPOL-COMMON-R043, fatal). VAT BE0123456789 → identifier 0208:0123456789 (drop the BE).Technical: validator [peppol-common-r043, fatal] — Belgian enterprise number MUST be stated in the correct format. Technical: validator [peppol-common-r043, fatal] — Belgian enterprise number MUST be stated in the correct format. |
| 12 | Seller name and postal address with country code (BR-06, BR-08, BR-09) | PASS | Blocker | Seller identity block complete. |
| 13 | Buyer name and postal address with country code (BR-07, BR-10, BR-11) | PASS | Blocker | Buyer identity block complete. |
| 14 | Seller identifier for automatic matching; VAT identifiers country-prefixed (BR-CO-26; BR-CO-09) | FAIL | Blocker | Your company's identifier or VAT number is missing, or the VAT number lacks its country prefix — for a Belgian company the VAT identifier is written as BE followed by the 10 digits. One-time fix in company settings — copy it exactly from your VAT registration. Technical: BR-CO-26 (seller identifier, legal registration identifier or VAT identifier required); BR-CO-09 (VAT identifier prefixed by ISO 3166-1 country code, e.g. BE0123456789).Technical: validator [br-co-09, fatal] — [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’. |
3 · Lines, references & payment
| # | Check (rule ID) | Result | Severity | Fix note |
|---|---|---|---|---|
| 15 | At least one invoice line; each line has ID, quantity and unit code (BR-16, BR-21, BR-22, BR-23; unit per BR-CL-23) | PASS | Blocker | — |
| 16 | Each line has a net amount, item name and non-negative price (BR-24, BR-25, BR-26, BR-27) | PASS | Blocker | — |
| 17 | Line arithmetic: net amount = quantity × (price ÷ base quantity) ± line charges/allowances (PEPPOL-EN16931-R120, R121, R130) | FAIL | Blocker | The amount on one or more lines doesn't equal quantity × unit price (after line discounts and charges). This arithmetic comes from your software — ask your vendor or IT to fix where the line amount is calculated or rounded. Technical: PEPPOL-EN16931-R120 (line net amount arithmetic), R121 (base quantity > 0), R130 (price base quantity unit = invoiced quantity unit). Technical: validator [peppol-en16931-r120, fatal] — Invoice line net amount MUST equal (Invoiced quantity * (Item net price/item price base quantity) + Sum of invoice line charge amount - sum of invoice line allowance amount |
| 18 | Allowances and charges consistent: amounts, percentages, reasons (PEPPOL-EN16931-R040…R046; BR-31, BR-42) | N/A | — | No discounts or charges in this file; the allowance/charge consistency rules did not need to fire. |
| 19 | Payment: due date or payment terms when an amount is due; mandate reference for direct debit (BR-CO-25; PEPPOL-EN16931-R061) | FAIL | Blocker | The invoice shows an amount to be paid but carries neither a due date nor payment terms. Usually a one-time fix in your invoice template or payment settings. Technical: BR-CO-25 (amount due > 0 requires due date or payment terms); PEPPOL-EN16931-R061 (direct debit requires a mandate reference). Technical: validator [br-co-25, fatal] — [BR-CO-25]-In case the Amount due for payment (BT-115) is positive, either the Payment due date (BT-9) or the Payment terms (BT-20) shall be present. |
| 20 | Invoicing-period dates coherent: end ≥ start, line periods inside the document period (BR-29, BR-30; PEPPOL-EN16931-R110, R111) | N/A | — | No invoicing periods in this file; the period-coherence rules did not need to fire. |
4 · VAT logic
| # | Check (rule ID) | Result | Severity | Fix note |
|---|---|---|---|---|
| 21 | Every line carries a VAT category; categories from the UNCL5305 list (BR-CO-04; BR-CL-17) | PASS | Blocker | All lines categorized; all categories from the official list. |
| 22 | A VAT breakdown exists; each breakdown has taxable amount, tax amount, category and rate (BR-CO-18; BR-45…BR-48) | PASS | Blocker | Every VAT summary block is complete. |
| 23 | Standard-rated math: category taxable = sum of its lines; category tax = taxable × rate (BR-S-08, BR-S-09, BR-S-10; BR-CO-17) | FAIL | Blocker | The VAT figures don't add up within the standard-rated group — the amount taxed must equal the sum of the standard-rated lines, and that amount times the rate must equal the VAT charged. The arithmetic comes from your software; ask your vendor or IT. Technical: BR-S-08 (taxable = Σ standard-rated lines per rate), BR-S-09 / BR-CO-17 (tax = taxable × rate, ±0.01/rounding slack per the official formula), BR-S-10 (no exemption reason on standard rate). Technical: validator [br-s-08, fatal] — [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is "Standard rated", the VAT category taxable amount (BT-116) in a VAT breakdown (BG-23) shall equal the sum of Invoice line net amounts (BT-131) plus the sum of document level charge amounts (BT-99) minus the sum of document level allowance amounts (BT-92) where the VAT category code (BT-151, BT- |
| 24 | Zero-rated and exempt handling: 0 VAT charged; exempt breakdowns carry an exemption reason (BR-Z-08…10; BR-E-08…10) | N/A | — | No zero-rated or exempt (Z/E category) amounts in this file. |
| 25 | Reverse-charge package: buyer VAT ID, 0 VAT, reason code (BR-AE-01…BR-AE-10) | N/A | — | No reverse-charge (AE category) amounts in this file. |
| 26 | VAT totals consistent: total VAT = sum of category amounts; one tax total (+ accounting-currency rules) (BR-CO-14; PEPPOL-EN16931-R053…R055; BR-53) | PASS | Blocker | VAT totals consistent. |
5 · Totals & common failure patterns
| # | Check (rule ID) | Result | Severity | Fix note |
|---|---|---|---|---|
| 27 | Totals chain complete and exact (BR-12…BR-15; BR-CO-10, BR-CO-13, BR-CO-15, BR-CO-16) | FAIL | Blocker | The invoice totals don't add up — typically a rounding difference of a cent or two between the line amounts and the header totals. Even one cent rejects the whole file. Ask your software vendor or IT to fix where rounding happens (see the rounding check below for the usual root cause). Technical: BR-12…BR-15 (presence); BR-CO-10 (Σ line nets), BR-CO-13 (total without VAT), BR-CO-15 (total with VAT), BR-CO-16 (amount due) — classic per-receipt vs. per-line rounding drift; root cause usually check 30. Technical: validator [br-co-15, fatal] — [BR-CO-15]-Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110). Technical: validator [br-co-10, fatal] — [BR-CO-10]-Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131). Technical: validator [br-co-16, fatal] — [BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114). |
| 28 | Monetary amounts within 2 decimals (BR-DEC-* family) | FAIL | Blocker | Some amounts carry more than 2 decimal places, which the rule set rejects. Ask your software vendor or IT to round the constrained amounts to 2 decimals — unit prices may keep more precision; the caps sit on document and line totals. Technical: BR-DEC-01…BR-DEC-28 (document totals, VAT amounts, line amounts capped at 2 decimals; item net price is NOT capped). Technical: validator [br-dec-14, fatal] — [BR-DEC-14]-The allowed maximum number of decimals for the Invoice total amount with VAT (BT-112) is 2. |
| 29 | One currency throughout: every amount in the invoice currency (PEPPOL-EN16931-R051) | PASS | Blocker | All amounts carry the invoice currency. |
| 30 | One rounding strategy applied consistently | FAIL | Warning | Rounding happens in two different places in your billing chain, which is why the totals above don't add up. Pick one approach: keep exact figures at line level, round once on the final totals, and show any leftover cents as a separate rounding amount. A one-time change by your software vendor or IT. Technical: root cause of check 27 — header figure rounded upstream while lines keep exact figures. Official pattern: exact at line/breakdown level, single round at header, residual in PayableRoundingAmount (BT-114). Detected via drift on BR-CO-13/15/16. |
| 31 | Document stays inside the EN 16931 / BIS 3.0 subset (UBL-CR- / UBL-SR- / UBL-DT-* restrictions) | FAIL | Blocker | The file carries information fields outside the agreed European subset for e-invoices. Some receivers ignore them; strict receivers and some platforms reject the file or drop the extra data. Ask your software vendor or IT to keep the export inside the subset. Technical: UBL-CR-001…UBL-CR-681 (cardinality restrictions, warnings), UBL-SR- (syntax restrictions), UBL-DT- (data-type/attribute restrictions — mostly fatal). Severity shown reflects the worst finding mapped here. Technical: validator [ubl-cr-002, warning] — [UBL-CR-002]-A UBL invoice should not include the UBLVersionID or it should be 2.1 Technical: validator [ubl-dt-01, fatal] — [UBL-DT-01]-Amounts shall be decimal up to two fraction digits |
6 · Additional findings from the official validator (outside the 31-check frame)
| Rule ID | Flag | Validator message | Location |
|---|---|---|---|
peppol-en16931-r002 | fatal | Technical finding (ask your IT or provider): No more than one note is allowed on document level, unless both the buyer and seller are German organizations. | /*:Invoice[namespace-uri()='urn:oasis:names:specification:ubl:schema:xsd:Invoice-2'][1] |
Verdict
16 of 27 applicable checks passed (4 not applicable to this file).
11 blockers + 1 warning to resolve before this document goes out over Peppol.
The work splits into: 2 one-time configuration fixes · 2 need data added to customer or product records · 7 need your software vendor or IT · 1 technical finding for your IT or provider.
Next steps
Who runs the check
Yenyun Fu is a software developer focused on e-invoicing compliance tooling, including Peppol and UBL validation. Every check combines automated validation against the official published artefacts with human review, so the findings you receive can be used in a real conversation — with your finance team, your IT, or your Accredited Service Provider.
Prepared by Yenyun Fu · yenyun@londonbridgeventures.com · Draft-XML conformance diagnostic only — not tax advice or a production acceptance verdict. Final delivery, production validation and exchange remain with your Peppol Access Point provider.
Back to the monthly monitoring service for accountancy firms →