The EN 16931 rule requiring VAT to be computed from the taxable base multiplied by the rate, rounded to two decimals — not extracted from the gross total. The two formulas differ by a cent on many invoices, and the leftover must be declared as payment rounding in BT-114 rather than hidden inside the VAT amount.

Every monetary amount must carry a currencyID attribute. An amount without it passes XSD schema validation and fails Schematron, which is why it is the most common surprise rejection.

Why is my invoice rejected for PEPPOL-EN16931-R003?

Neither a buyer reference nor a purchase order reference was provided. Public sector buyers reject on this constantly, because that reference is how they match the invoice to their commitment.

EN 16931 business rules explained

Header

`BR-01`	An Invoice shall have a Specification identifier (BT-24). The CustomizationID is missing. Without it a receiver cannot tell which profile to validate against, so it refuses before reading anything else.
`BR-02`	An Invoice shall have an Invoice number (BT-1). No number, or an empty element. An empty tag counts as missing.
`BR-03`	An Invoice shall have an Invoice issue date (BT-2). Missing issue date, or one not in YYYY-MM-DD form.
`BR-04`	An Invoice shall have an Invoice type code (BT-3). Usually 380 for an invoice, 381 for a credit note. Sending a credit note as 380 is a common and expensive mix-up.
`BR-05`	An Invoice shall have an Invoice currency code (BT-5). Missing DocumentCurrencyCode. Note this is separate from putting currencyID on each amount — see BR-CL-04.

Parties

`BR-06`	An Invoice shall contain the Seller name (BT-27). The legal name, not a trading name or a logo.
`BR-07`	An Invoice shall contain the Buyer name (BT-44). Missing buyer name. The legal name of the party being billed, not a contact person or a department.
`BR-08`	An Invoice shall contain the Seller postal address (BG-5). An address group must be present even when the country alone would do.
`BR-09`	The Seller postal address (BG-5) shall contain a Seller country code (BT-40). Country code missing. It must be ISO 3166-1 alpha-2, not a country name.
`BR-10`	An Invoice shall contain the Buyer postal address (BG-8). Same as BR-08, on the buyer side: an address group must be present even when only the country is known.
`BR-11`	The Buyer postal address shall contain a Buyer country code (BT-55). Buyer country code missing. For reverse charge this is also what decides whether the transaction is cross-border.

Totals

`BR-12`	An Invoice shall have the Sum of Invoice line net amount (BT-106). Missing LineExtensionAmount on the document total.
`BR-13`	An Invoice shall have the Invoice total amount without VAT (BT-109). Missing TaxExclusiveAmount. This is the document net, which is not automatically the same as the sum of the lines once document-level discounts exist.
`BR-14`	An Invoice shall have the Invoice total amount with VAT (BT-112). Missing TaxInclusiveAmount. It must equal the net plus the total VAT, which is what BR-CO-15 then checks.
`BR-15`	An Invoice shall have the Amount due for payment (BT-115). Missing PayableAmount. It is not the same as the total when something was already paid.

Lines

`BR-16`	An Invoice shall have at least one Invoice line (BG-25). No InvoiceLine at all. An invoice for a lump sum still needs one line.
`BR-22`	Each Invoice line shall have an Invoiced quantity (BT-129). A line without a quantity. Zero is a quantity; absent is not.
`BR-24`	Each Invoice line shall have an Invoice line net amount (BT-131). Missing LineExtensionAmount on the line. Quantity times price is not enough — the computed amount has to be stated.
`BR-25`	Each Invoice line shall contain the Item name (BT-153). A line with a price but no description of what it is for.
`BR-27`	The Item net price (BT-146) shall NOT be negative. A discount sent as a negative line. UBL wants it as an AllowanceCharge, or spread across the lines.

VAT

`BR-45`	Each VAT breakdown (BG-23) shall have a VAT category taxable amount (BT-116). A VAT group without its taxable base. Every rate used on the invoice needs its own group with base, tax and rate.
`BR-46`	Each VAT breakdown (BG-23) shall have a VAT category tax amount (BT-117). A VAT group without its tax amount. The base alone does not let the receiver verify the arithmetic.
`BR-47`	Each VAT breakdown (BG-23) shall be defined through a VAT category code (BT-118). The category code is missing or is not one of the UNCL5305 values (S, Z, E, AE, K, G, O, L, M).
`BR-48`	Each VAT breakdown (BG-23) shall have a VAT category rate (BT-119). A VAT group without its rate. Zero-rated still carries a rate of 0, not an absent one.
`BR-S-05`	In an Invoice line where the VAT category code is "Standard rated" the invoiced item VAT rate (BT-152) shall be greater than zero. A line marked standard rated at 0%. If it really is zero, the category is Z or E, not S.

Reverse charge

`BR-AE-02`	An Invoice with a reverse charge line shall contain the Seller VAT identifier (BT-31). Reverse charge without your own VAT number on the document.
`BR-AE-03`	An Invoice with a reverse charge line shall contain the Buyer VAT identifier (BT-48). Reverse charge without the buyer VAT number. This is the one that turns an exemption into a liability.
`BR-AE-10`	A VAT breakdown with category "Reverse charge" shall have an exemption reason code or text (BT-121 / BT-120). No reason given for charging no VAT. The receiver has to be told why.

Intra-community

`BR-IC-03`	An Invoice with an intra-community supply line shall contain the Buyer VAT identifier (BT-48). An intra-community supply without the buyer number is simply a domestic sale as far as the rule is concerned.
`BR-IC-11`	An intra-community supply shall have the actual delivery date (BT-72) or an invoicing period. Delivery date missing, so we set it equal to the invoice date. Fix it if they differ — the delivery date decides the reporting period.
`BR-IC-12`	An Invoice with an intra-community VAT breakdown shall have the Deliver to country code (BT-80). Where the goods actually went is missing, and that is what makes the supply intra-community.

Consistency

The arithmetic rules

`BR-CO-09`	The Seller VAT identifier (BT-31) shall have an ISO 3166-1 alpha-2 prefix. A VAT number sent without its country prefix, or with the wrong one.
`BR-CO-10`	Sum of Invoice line net amount (BT-106) = Σ Invoice line net amount (BT-131). The document total does not equal the sum of its lines. Usually a rounding done in the wrong place.
`BR-CO-14`	Invoice total VAT amount (BT-110) = Σ VAT category tax amount (BT-117). Classic symptom of rounding VAT per line instead of per category. Round once, per rate.
`BR-CO-15`	Invoice total with VAT (BT-112) = total without VAT (BT-109) + total VAT (BT-110). The gross does not equal net plus tax. Often a cent lost to a rounding that was never declared.
`BR-CO-16`	Amount due (BT-115) = total with VAT (BT-112) − paid (BT-113) + rounding (BT-114). A partial payment or a rounding adjustment was not carried into the amount due.
`BR-CO-17`	VAT category tax amount (BT-117) = taxable amount (BT-116) × (rate (BT-119) / 100), rounded to two decimals. The one that rejects most invoices. VAT must be computed FROM the base, never extracted from the gross — the two differ by a cent. The leftover belongs in BT-114 as payment rounding, not inside the VAT figure.

Codes

`BR-CL-04`	Every amount shall carry a currency identifier. An amount without currencyID. It passes the XSD and fails Schematron, which is why it surprises people.
`BR-DEC`	Elements shall not be present and empty. <cbc:ID></cbc:ID> is there but says nothing. A naive “is the tag present” check misses this entirely.

Peppol

`PEPPOL-EN16931-R001`	Business process MUST be provided. ProfileID missing. Required by Peppol even though plain EN 16931 does not ask for it.
`PEPPOL-EN16931-R002`	No more than one note is allowed on document level. Several free-text notes at document level. Merge them into one.
`PEPPOL-EN16931-R003`	A buyer reference or purchase order reference MUST be provided. Neither BuyerReference nor an order reference. Public buyers reject on this constantly.
`PEPPOL-EN16931-R004`	Specification identifier MUST start with "urn:cen.eu:en16931:2017". A CustomizationID that is not an EN 16931 profile, or a typo in it.
`PEPPOL-EN16931-R010`	Buyer electronic address MUST be provided. No EndpointID for the buyer, so the network has nowhere to deliver it.
`PEPPOL-EN16931-R020`	Seller electronic address MUST be provided. No EndpointID for the seller, or no EAS scheme code for the seller country.

This list is generated from the validator, not written beside it

A reference page that drifts from the code is worse than none, so a test fails the build if a rule is added to the validator and not to this page. What you read here is what actually runs.

Paste an invoice Peppol EAS codes

EN 16931 business rulesWhat each one means when it fails.