FAQ

Does it send invoices over Peppol?

No. It produces and checks the documents. Sending them needs a Peppol access point, which handles the network, the AS4 transport and the participant lookup.

validate() accepted an invoice that the Peppol validator rejects. Why?

Most likely the national rules. The official Peppol validator applies them by the supplier's country; this library runs them only when you list them, and version 0.1.0 has the Danish rules only (dkRuleset). The German, Greek, Icelandic, Italian, Dutch, Norwegian and Swedish rules of the Peppol release are in the rule index but not implemented yet. See which rules run by default.

How do I validate a Spanish invoice?

There is no Spanish ruleset because Peppol has no Spanish national rules. A Spanish invoice is validated with EN 16931, and with the Peppol rules when it declares the Peppol customization id.

Why is my French profile id rejected?

Peppol BIS Billing 3.0.21 knows two profile ids: billing (urn:fdc:peppol.eu:2017:poacc:billing:01:1.0) and billing with response (urn:peppol:bis:billing_with_response). PROFILE_IDS lists exactly those. Any other id, including the French profile ids, is unknown to the Peppol rules, and PEPPOL-EN16931-R007 fails.

Is it as strict as the official Schematron?

The rules are ports of the Schematron asserts of the pinned release, with the specification's ids, messages and severities, and they run against the official per-rule test sets of Peppol and CEN. Where the port differs from the Schematron on purpose, the difference is listed below. A conformance job also runs the official XSDs and Schematron next to the library over every official document and test fragment; the rule index shows, per rule, where it is implemented, how many official tests exercise it and whether the two agree.

How fast is it?

This release publishes no performance figures; performance work is planned for a later release. CI enforces bundle size budgets for the packages (.size-limit.json).

Known limitations

• DK-R-004 and price allowances. The Peppol syntax has no reason code or reason on a price allowance (cac:Price/cac:AllowanceCharge), so the model has no place for them: the parser reports them as UBL-CR warnings and drops them. DK-R-004, whose Schematron context also covers price allowances, can therefore check only document and line allowances and charges.
• Checked on XML or on the model. Some structural rules can only be seen in the XML. UBL-SR-12 and UBL-SR-13 (one seller VAT identifier and one tax registration identifier) are checked by the parser for XML and by the validator for built documents. UBL-SR-48 (exactly one VAT category per line) is checked by the parser only; on a built document without a category, BR-CO-04 reports it. Use validateXml() for XML so that you get both.
• UBL-SR-19, UBL-SR-20 and UBL-SR-21 (payee name). The validator compares the model's payee name with the seller's registration name. The Schematron compares every name the XML holds, so the two disagree for a payee with a second party name, a seller with a second registration name, or a second payee. Each of those documents is already invalid for another reason (UBL-SR-19, UBL-SR-09 or EINV-XML-CARDINALITY).
• Unreachable syntax rules. UBL-CR-674 names an element UBL 2.1 does not have (cbc:PrimaryAccountNumber), and UBL-SR-23 a path UBL cannot hold, so neither can fire on a schema-valid document. UBL-CR-629 and UBL-CR-630 name cbc:ValidityPeriod and cbc:PriceList, which exist only as cac: aggregates; the parser matches the aggregates.