- \n
- How to read a validation message<\/a><\/li>\n\n\n
- Electronic address missing (PEPPOL-EN16931-R010, -R020, BR-62, BR-63)<\/a><\/li>\n\n\n
- Buyer reference or Leitweg-ID missing (BR-DE-15)<\/a><\/li>\n\n\n
- No VAT ID: seller identifier missing (BR-CO-26, BR-S-02)<\/a><\/li>\n\n\n
- German small businesses under \u00a7 19 UStG (category E)<\/a><\/li>\n\n\n
- VAT exemption without an exemption reason (BR-E-10, BR-G-10)<\/a><\/li>\n\n\n
- Reverse charge, intra-community supply, export (BR-AE-02, BR-IC-02, BR-G-02)<\/a><\/li>\n\n\n
- Self-billed invoice, type 389: who is the seller? (PEPPOL-EN16931-P0100)<\/a><\/li>\n\n\n
- Invoice type flagged in XRechnung (BR-DE-17)<\/a><\/li>\n\n\n
- Negative unit price (BR-27)<\/a><\/li>\n\n\n
- Units: H87, HUR, weeks (BR-CL-23)<\/a><\/li>\n\n\n
- PO box in the address<\/a><\/li>\n\n\n
- XRechnung: contact, post code or city missing (BR-DE-2 to BR-DE-9)<\/a><\/li>\n\n\n
- Early payment discount (Skonto) in the wrong format (BR-DE-18)<\/a><\/li>\n\n\n
- Delivery date or billing period missing (FX-SCH-A-000354, BR-DE-TMP-32)<\/a><\/li>\n\n\n
- Payment details missing or not matching (BR-DE-1, BR-61, BR-DE-19)<\/a><\/li>\n\n\n
- 1 cent difference in tax or total (BR-CO-14, BR-CO-17, BR-S-09)<\/a><\/li>\n\n\n
- Amounts do not match with the command line or JSON (PEPPOL-EN16931-R120, -R040)<\/a><\/li>\n\n\n
- Empty element in the XML (PEPPOL-EN16931-R008)<\/a><\/li>\n\n\n
- The recipient or portal rejects the invoice<\/a><\/li>\n\n\n
- PDF\/A-3 messages from validators<\/a><\/li>\n\n<\/ul>\n\n\n\n
How to read a validation message<\/h2>\n\n\n\n
You get validation messages in several places:<\/p>\n\n\n\n
- \n
- When creating:<\/strong> When you click \"Create invoice\", the e-invoice generator checks the invoice against the official rules of the chosen format. If it breaks a rule, you see \"The e-invoice breaks N rule(s) of its format.\" with a list. In the previous version of the generator you can also choose \"Check invoice\" beforehand.<\/li>\n\n\n
- In the form:<\/strong> Missing required details are marked in red. The previous version also reports \"There are invalid elements in the form. Please correct the fields marked in red and start the invoice creation again.\"<\/li>\n\n\n
- For a finished file:<\/strong> with the Validate e-invoice<\/a> tool, online or in the PDF24 Toolbox. How to read its report is explained on the page Open, view and validate e-invoices: reading the validation report<\/a>.<\/li>\n\n\n
- At the recipient:<\/strong> Invoice portals and validators such as the KoSIT validator (the validation tool for the German XRechnung) check against the same rules and show the same code.<\/li>\n\n<\/ul>\n\n\n\n
This is how an entry in the e-invoice generator is built:<\/p>\n\n\n\n
- \n
- on the left the code<\/strong> of the rule \u2013 red for an error, yellow for a notice (warning),<\/li>\n\n\n
- next to it PDF24's explanation<\/strong> in plain words,<\/li>\n\n\n
- below it in small print the original text of the rule<\/strong>, mostly in English, for the German XRechnung rules (BR-DE-\u2026) in German. Other validators show this text too,<\/li>\n\n\n
- \"Fix\" takes you straight to the field concerned.<\/li>\n\n<\/ul>\n\n\n\n
![\"Validation](\"https:\/\/help.pdf24.org\/en\/wp-content\/uploads\/sites\/3\/2026\/11\/einvoice-validation-result-br-de-15.png\")
An entry in the validation result: code, explanation, original text and the button to the field concerned<\/figcaption><\/figure>\n\n\n\n What the code tells you:<\/p>\n\n\n\n
- \n
- BR-\u2026<\/strong>: rules of the European standard EN 16931; they apply to every format.<\/li>\n\n\n
- BR-CO-\u2026<\/strong>: calculation rules and dependencies between fields (totals, identifiers).<\/li>\n\n\n
- BR-S-\u2026, BR-E-\u2026, BR-AE-\u2026, BR-IC-\u2026, BR-G-\u2026, BR-O-\u2026<\/strong>: rules per VAT category (S standard rate, E exempt, AE reverse charge, K intra-community supply, G export, O not subject to VAT).<\/li>\n\n\n
- BR-DE-\u2026<\/strong>: additional rules of the XRechnung for Germany. In Peppol, the same rules for German invoices are called DE-R-\u2026 (e.g. DE-R-015 = BR-DE-15).<\/li>\n\n\n
- PEPPOL-EN16931-\u2026<\/strong>: rules of the Peppol network. Some of them also apply to the XRechnung.<\/li>\n\n\n
- FX-SCH-\u2026<\/strong>: rules of ZUGFeRD or Factur-X.<\/li>\n\n\n
- BR-CL-\u2026<\/strong>: a code is not in the allowed list (unit, country, currency \u2026).<\/li>\n\n\n
- BT-\u2026<\/strong> and BG-\u2026<\/strong> in a message are not rules but field numbers of the standard. In the generator the BT number is shown in small print after the label, e.g. \"Buyer reference (BT-10)\".<\/li>\n\n<\/ul>\n\n\n\n
Important: which rules apply depends on the chosen format. The same invoice can be valid as \"PDF with e-invoice (ZUGFeRD)\" and have errors as an XRechnung, because the XRechnung requires more details. You should fix errors; notices (yellow) are recommendations \u2013 but some portals reject the invoice even then.<\/p>\n\n\n\n
Below the list you find \"Create invoice without validation\". It creates the file despite the errors. This only makes sense if you know for sure that your recipient does not need the detail concerned \u2013 otherwise they may reject the invoice.<\/p>\n\n\n\n
Electronic address missing (PEPPOL-EN16931-R010, -R020, BR-62, BR-63)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"Enter the buyer's electronic address (e.g. e-mail address or routing ID with the matching scheme).\" or \"Enter your own electronic address as seller (e.g. your e-mail address).\"<\/li>\n\n\n
- Original text of the rule: \"[PEPPOL-EN16931-R010]-Buyer electronic address MUST be provided\" or \"[PEPPOL-EN16931-R020]-Seller electronic address MUST be provided\"<\/li>\n\n\n
- Or: \"[BR-63]-The Buyer electronic address (BT-49) shall have a Scheme identifier.\" (for the seller BR-62, BT-34)<\/li>\n\n\n
- With Peppol also: \"[PEPPOL-EN16931-CL008] Electronic address identifier scheme must be from the codelist \"Electronic Address Identifier Scheme\"\" \u2013 PDF24: \"In Peppol the electronic address must be a Peppol identifier (e.g. scheme 0088 GLN or 9930 German VAT id), not an e-mail address.\"<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
The \"Electronic address\" (BT-49 for the invoice recipient, BT-34 for the biller) is the address an e-invoice is delivered to electronically. It is only required for the XRechnung<\/strong> and for Peppol<\/strong> \u2013 even for the XRechnung the rule is called PEPPOL-EN16931-R010. For ZUGFeRD, Factur-X and EN 16931 it is optional. So it is not a mandatory e-mail field for every invoice.<\/p>\n\n\n\n
Every electronic address comes with a scheme that says what kind of address it is (BR-62\/BR-63). In Peppol it must be a Peppol identifier; an e-mail address is not allowed there.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Under \"Invoice recipient\", enter the address your customer gave you in \"Electronic address\". Do the same for your own address under \"Biller\".<\/li>\n\n\n
- Choose the matching scheme next to it:\n\n
- \n
- an e-mail address: \"EM - Electronic mail\",<\/li>\n\n\n
- the Leitweg-ID of a German public authority: \"0204 - Leitweg-ID\",<\/li>\n\n\n
- in Peppol e.g. the German VAT ID: \"9930 - Germany VAT number\", or the Peppol ID your customer gives you.<\/li>\n\n<\/ul>\n<\/li>\n\n\n
- Do not use an e-mail address with Peppol. The message \"The electronic address does not match the selected type: an email address for the type \"EM - Electronic mail\", none for all other types.\" means that address and scheme do not go together.<\/li>\n\n<\/ol>\n\n\n\n
If the field is still shown as required for ZUGFeRD, update the PDF24 Creator<\/a>. In the current version it is only required for XRechnung and Peppol, and the same applies online.<\/p>\n\n\n\n
Buyer reference or Leitweg-ID missing (BR-DE-15)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"Enter the buyer reference \u2013 for invoices to German public authorities the Leitweg-ID the buyer gave you.\"<\/li>\n\n\n
- Original text of the XRechnung rule (in German): \"[BR-DE-15] Das Element \"Buyer reference\" (BT-10) muss \u00fcbermittelt werden.\" \u2013 in English, as the same rule reads in Peppol (DE-R-015): \"The element \"Buyer reference\" (BT-10) shall be provided.\"<\/li>\n\n\n
- In the form: \"This is required for an XRechnung \u2013 without it, public authorities reject the invoice.\" (previous version: \"This field is required for the XRechnung format. \u2026\")<\/li>\n\n\n
- With Peppol: \"[PEPPOL-EN16931-R003] A buyer reference or purchase order reference MUST be provided.\" \u2013 PDF24: \"Peppol requires a buyer reference or a purchase order number.\"<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
The XRechnung, the German e-invoice format for public authorities, always requires a buyer reference (BT-10). For German public authorities this is the Leitweg-ID<\/strong>, which routes the invoice to the right office, e.g. 991-33333TEST-33. For business customers who want an XRechnung it can be an order number or a cost centre \u2013 whatever your customer specifies. Peppol requires a buyer reference or a purchase order number.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- In the invoice data, enter your customer's Leitweg-ID or reference under \"Buyer reference\" (BT-10). It is usually in the order or purchase order.<\/li>\n\n\n
- Do not make up a Leitweg-ID: the last two digits are check digits. The new version of the generator then reports \"This is not a valid Leitweg-ID: it looks like 991-33333TEST-33, the last two digits are check digits. Please compare it with what the buyer gave you.\"<\/li>\n\n\n
- If your customer is not a public authority and does not need an XRechnung, choose a different format, e.g. \"PDF with e-invoice (ZUGFeRD)\" (previous version: \"PDF \/ ZUGFeRD \/ EN16931\"). There the buyer reference is optional.<\/li>\n\n<\/ol>\n\n\n\n
No VAT ID: seller identifier missing (BR-CO-26, BR-S-02)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"Give the seller a VAT ID, a trade ID or a seller ID \u2013 the tax number alone is not enough. Without a VAT ID, your supplier number at the customer or your company name will do as seller ID.\"<\/li>\n\n\n
- Original text: \"[BR-CO-26]-In order for the buyer to automatically identify a supplier, the Seller identifier (BT-29), the Seller legal registration identifier (BT-30) and\/or the Seller VAT identifier (BT-31) shall be present.\"<\/li>\n\n\n
- In the form: \"Please enter at least one: seller ID, trade ID or VAT ID.\"<\/li>\n\n\n
- Without any tax details also: \"As the seller, enter your VAT ID or your tax number.\" \u2013 original text \"[BR-S-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is \"Standard rated\" shall contain the Seller VAT Identifier (BT-31), the Seller tax registration identifier (BT-32) and\/or the Seller tax representative VAT identifier (BT-63).\" (in the XRechnung as BR-DE-16)<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
These are two different rules. For tax purposes the tax number is enough (BR-S-02). So that your customer's software can recognise you as a supplier automatically, the standard additionally requires an identifier: seller ID (BT-29), trade ID (BT-30) or VAT ID (BT-31). The tax number does not count for this \u2013 which is why you get the message even though you have entered a tax number. Many small businesses have neither a VAT ID nor a trade register entry.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Under \"Biller\", enter your \"Tax number\" (BT-32) if you have no VAT ID.<\/li>\n\n\n
- Also fill in the \"Seller ID\" (BT-29): your supplier number at the customer or simply your company name. The \"Use company name\" button in the hint at the field fills in the name.<\/li>\n\n\n
- If you have a VAT ID, it is enough on its own: \"VAT ID\" (BT-31) with the country code, e.g. DE123456789. Without the country code the validation reports BR-CO-09 (\"A VAT ID starts with the country code, e.g. DE123456789 (Greece: EL).\").<\/li>\n\n<\/ol>\n\n\n\n
German small businesses under \u00a7 19 UStG (category E)<\/h2>\n\n\n\n
In Germany, small businesses can use the small business rule of \u00a7 19 UStG and do not charge VAT. PDF24 has a setting for this.<\/p>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
Typical messages when the small business rule has been rebuilt by hand:<\/p>\n\n\n\n
- \n
- \"[BR-S-05]-In an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is \"Standard rated\" the Invoiced item VAT rate (BT-152) shall be greater than zero.\" \u2013 PDF24: \"With VAT category \"S\" (standard rate) the rate must be greater than 0. \u2026\"<\/li>\n\n\n
- \"[BR-E-10]-A VAT Breakdown (BG-23) with VAT Category code (BT-118) \"Exempt from VAT\" shall have a VAT exemption reason code (BT-121) or a VAT exemption reason text (BT-120).\"<\/li>\n\n\n
- Often BR-CO-26 as well (see No VAT ID<\/a>).<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
Invoicing without VAT does not mean \"standard rate at 0 %\" in an e-invoice, but VAT category E<\/strong> (exempt) with an exemption reason. PDF24 enters the reference to \u00a7 19 UStG as the exemption reason when you switch the rule on.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Under \"Biller\", choose the option \"German small business rule according to \u00a7 19 UStG\" in \"Applicable rule\". In the new version you can also do this in \"My profile\" (\"Are you a small business under \u00a7 19 UStG (German VAT exemption)?\").<\/li>\n\n\n
- The generator sets all line items to \"E\" (exempt, 0 %) and tells you how many it has changed. The exemption reason in the invoice is written in the language of the invoice; in English: \"No tax shown, as small business owner according to \u00a719 UStG.\"<\/li>\n\n\n
- If you switch the rule off again, the line items get their previous VAT rate back \u2013 check the rates then.<\/li>\n\n\n
- Enter your \"Tax number\" and a \"Seller ID\" (see No VAT ID<\/a>).<\/li>\n\n<\/ol>\n\n\n\n
Whether the small business rule applies to you is something to clarify with your tax adviser.<\/p>\n\n\n\n
VAT exemption without an exemption reason (BR-E-10, BR-G-10)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"This VAT category needs an exemption reason (text or code), e.g. \"Intra-community supply\".\"<\/li>\n\n\n
- Original text e.g. \"[BR-E-10]-A VAT Breakdown (BG-23) with VAT Category code (BT-118) \"Exempt from VAT\" shall have a VAT exemption reason code (BT-121) or a VAT exemption reason text (BT-120).\" \u2013 likewise BR-G-10 (export), BR-AE-10 (reverse charge), BR-IC-10 (intra-community supply).<\/li>\n\n\n
- The other way round: \"This VAT category has no exemption reason \u2013 remove the text and code of the exemption reason.\" (for S standard rate and Z zero rated)<\/li>\n\n\n
- Or: \"The VAT category and the exemption reason code do not match (e.g. VATEX-EU-G belongs to \"G\" export, VATEX-EU-IC to \"K\" intra-community supply). Adjust one of them.\"<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
If you do not charge VAT, you have to say why. For this, every line of the VAT breakdown has an \"Exemption reason\" (BT-120, free text) and an \"Exemption reason code\" (BT-121, from the VATEX list). One of the two is enough.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Choose the right \"Tax category\" for each line item.<\/li>\n\n\n
- In the \"Taxes\" section there is one line per VAT category. Fill in the \"Exemption reason\" there (e.g. the legal provision under which the supply is exempt) or choose an \"Exemption reason code\".<\/li>\n\n\n
- For \"AE\" (reverse charge) and \"K\" (intra-community supply) PDF24 sets the code (VATEX-EU-AE or VATEX-EU-IC) itself. For \"G\" (export) choose e.g. VATEX-EU-G.<\/li>\n\n<\/ol>\n\n\n\n
Which VAT category and which exemption reason are right for your supply is something to clarify with your tax adviser.<\/p>\n\n\n\n
Reverse charge, intra-community supply, export (BR-AE-02, BR-IC-02, BR-G-02)<\/h2>\n\n\n\n
Reverse charge (AE), also for customers without a VAT ID<\/h3>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"For reverse charge (AE), you need your VAT ID or tax number as the seller (or your tax representative's VAT ID) and the buyer's VAT ID or trade ID \u2013 the trade ID is enough if the buyer has no VAT ID, e.g. a company outside the EU.\"<\/li>\n\n\n
- Original text: \"[BR-AE-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is \"Reverse charge\" shall contain the Seller VAT Identifier (BT-31), the Seller Tax registration identifier (BT-32) and\/or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) and\/or the Buyer legal registration identifier (BT-47).\"<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
With \"AE - Reversal of the tax liability\" the customer owes the VAT. That is why the invoice must identify both sides clearly. If your customer has no VAT ID \u2013 a company in Switzerland, for example \u2013 their trade ID is enough.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Under \"Invoice recipient\", enter the \"VAT ID\" (BT-48) or, without a VAT ID, the \"Trade ID\" (BT-47), e.g. the commercial register number.<\/li>\n\n\n
- Under \"Biller\", your VAT ID or tax number.<\/li>\n\n\n
- PDF24 sets the exemption code VATEX-EU-AE itself. The new version can also fill in the text \"Reverse charge (\u00a7 13b UStG)\" (the German legal reference; written in the language of the invoice).<\/li>\n\n<\/ol>\n\n\n\n
Intra-community supply (K)<\/h3>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- \"[BR-IC-02]\u2026shall contain the Seller VAT Identifier (BT-31) or the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48).\" \u2013 PDF24: \"For intra-community supplies (K), both the seller and the buyer need a VAT ID \u2013 a tax number is not enough here.\"<\/li>\n\n\n
- \"[BR-IC-11]\u2026the Actual delivery date (BT-72) or the Invoicing period (BG-14) shall not be blank.\" \u2013 PDF24: \"For intra-community supplies the delivery date or the invoicing period is required.\"<\/li>\n\n\n
- \"[BR-IC-12]\u2026the Deliver to country code (BT-80) shall not be blank.\" \u2013 PDF24: \"For intra-community supplies the country of delivery is required (delivery address, country).\"<\/li>\n\n<\/ul>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Enter the VAT ID under \"Biller\" and \"Invoice recipient\".<\/li>\n\n\n
- Fill in the \"Delivery\/Service date\" (BT-72) or the \"Billing period\".<\/li>\n\n\n
- Under \"Delivery address\", choose at least the \"Country\" (BT-80).<\/li>\n\n<\/ol>\n\n\n\n
Export to a country outside the EU (G)<\/h3>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"For exports outside the EU (G), enter your VAT ID as the seller.\" (rule BR-G-02)<\/li>\n\n\n
- and, without an exemption reason, BR-G-10 (see Exemption reason<\/a>).<\/li>\n\n<\/ul>\n\n\n\n
How to fix it in PDF24:<\/strong> Enter your \"VAT ID\" under \"Biller\" and in the \"Taxes\" section choose e.g. VATEX-EU-G as the \"Exemption reason code\".<\/p>\n\n\n\n
Not subject to VAT (O)<\/h3>\n\n\n\n
With \"O - Services outside the scope of tax application\" the validation reports BR-O-02 if a VAT ID is entered: \"With \"Not subject to VAT\" (O) the seller must not state a VAT ID \u2013 remove it or choose another VAT category.\" The rule does not only forbid your \"VAT ID\" (BT-31) with \"O\", but also the VAT ID of a tax representative (BT-63) and the buyer's \"VAT ID\" (BT-48) \u2013 so remove the VAT ID under \"Invoice recipient\" as well. Original text: \"[BR-O-02]-An Invoice that contains an Invoice line (BG-25) where the Invoiced item VAT category code (BT-151) is \"Not subject to VAT\" shall not contain the Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) or the Buyer VAT identifier (BT-48).\" In addition, \"O\" must not be combined with other VAT categories in one invoice (BR-O-11).<\/p>\n\n\n\n
Which VAT category applies to a supply abroad (AE, K, G or O) is something to clarify with your tax adviser.<\/p>\n\n\n\n
Self-billed invoice, type 389: who is the seller? (PEPPOL-EN16931-P0100)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- With Peppol: PDF24 \"This invoice type is not allowed in Peppol (e.g. 389 self-billing). \u2026\", original text \"Invoice type code MUST be set according to the profile.\"<\/li>\n\n\n
- Or uncertainty when filling in the form: where does the supplier's tax number go? There is no \"Tax number\" field under the invoice recipient.<\/li>\n\n<\/ul>\n\n\n\n
Why:<\/strong> Peppol BIS Billing, the format PDF24 creates for Peppol, does not know type 389. The XRechnung and ZUGFeRD allow it; ask the recipient in which of these formats they accept the self-billed invoice.<\/p>\n\n\n\n
Who goes where?<\/strong> In a self-billed invoice (type 389, issued by the customer), too, the supplier \u2013 the one who provided the goods or services \u2013 is the \"Biller\", with their tax number or VAT ID. The customer who issues the self-billed invoice is the \"Invoice recipient\". The page Self-billed invoice (type 389): who goes where?<\/a> explains this step by step, including the difference to a credit note that cancels an invoice (381).<\/p>\n\n\n\n
Invoice type flagged in XRechnung (BR-DE-17)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"XRechnung expects the invoice types 326, 380, 381, 384, 389 and 875 to 877 only. For a down payment invoice choose 326 (partial invoice), in construction 875.\"<\/li>\n\n\n
- Original text of the XRechnung rule (a notice, not an error; in German): \"[BR-DE-17] Mit dem Element \"Invoice type code\" (BT-3) sollen ausschlie\u00dflich folgende Codes aus der Codeliste UNTDID 1001 \u00fcbermittelt werden: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) und 381 (Credit note),875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).\" \u2013 in English (Peppol, DE-R-017): \"The element \"Invoice type code\" (BT-3) should only contain the following values from code list UNTDID 1001: 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice), 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).\"<\/li>\n\n\n
- For an invoice correction without a reference: \"[BR-DE-26] Wenn im Element Invoice type code (BT-3) der Code 384 (Corrected invoice) \u00fcbergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.\" \u2013 in English (DE-R-026): \"If \"Invoice type code\" (BT-3) contains the code 384 (Corrected invoice), \"PRECEDING INVOICE REFERENCE\" (BG-3) should be provided at least once.\" PDF24: \"For a corrected invoice (384), enter the number of the original invoice as the invoice reference.\"<\/li>\n\n\n
- With Peppol: \"Peppol allows the invoice types 326 (partial invoice) and 384 (corrected invoice) only when both buyer and seller are in Germany.\" (PEPPOL-EN16931-P0112)<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
For a down payment invoice, \"386 - Advance Payment Invoice\" is often chosen. The XRechnung provides 326 (partial invoice) for this, or 875 for construction work. It is only a notice, but public authority portals may still reject such invoices.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Under \"Invoice type\", choose \"326 - Partial invoice\" or \"875 - Partial invoice for construction work\".<\/li>\n\n\n
- With \"384 - Invoice correction\", enter the number of the original invoice as the \"Invoice reference\".<\/li>\n\n<\/ol>\n\n\n\n
How to create down payment, partial final and final invoices is explained on the page Down payment, final invoice, credit note, correction and serial invoices<\/a>.<\/p>\n\n\n\n
Negative unit price (BR-27)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"The unit price (net) must not be negative. For a credit or a return use a negative quantity.\"<\/li>\n\n\n
- Original text: \"[BR-27]-The Item net price (BT-146) shall NOT be negative.\"<\/li>\n\n<\/ul>\n\n\n\n
How to fix it in PDF24:<\/strong> Keep the \"Unit price\" positive. For a single return or minus item on an invoice, e.g. returned deposit bottles, enter a negative quantity, e.g. -1. For a discount on the whole invoice use \"Add allowance\".<\/p>\n\n\n\n
A self-billed invoice (389) or a credit note that cancels an invoice (381), on the other hand, is a document of its own with its own invoice type, and the amounts stay positive \u2013 no negative quantities. How this works is explained on the page Cancel or correct an invoice<\/a>.<\/p>\n\n\n\n
Units: H87, HUR, weeks (BR-CL-23)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- The PDF shows \"1 H87\" instead of \"1 pc\", or \"HUR\" instead of \"h\".<\/li>\n\n\n
- When validating: \"The unit of this line is not a code of UN\/ECE Recommendation 20\/21 \u2013 often taken over from an imported invoice or a saved line. Choose a unit from the list, e.g. H87 (piece).\" Original text: \"[BR-CL-23]-Unit code MUST be coded according to the UN\/ECE Recommendation 20 with Rec 21 extension\"<\/li>\n\n\n
- With serial invoices from Excel: \"Unknown unit\".<\/li>\n\n<\/ul>\n\n\n\n
Why<\/strong><\/p>\n\n\n\n
In the XML of an e-invoice the unit is a code from a fixed list: H87 for piece, HUR for hour, WEE for week, LS for lump sum, C62 for \"one\". Your own abbreviations are not allowed there. In the readable PDF, PDF24 has shown the usual symbol for common units since version 11.32.0 (online for longer), in the language of the invoice \u2013 e.g. \"pc\" instead of H87 on an English invoice.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Choose the unit from the list under \"Unit\". If it is not there, the search icon next to it (\"Find a unit\") finds all units of the list, e.g. \"Week\".<\/li>\n\n\n
- If a different word should appear in the PDF, enter it in the small \"Symbol\" field after the unit. The XML keeps the code.<\/li>\n\n\n
- If the validation reports BR-CL-23 for an imported or saved line item, choose the unit there again.<\/li>\n\n<\/ol>\n\n\n\n
\"Unknown unit\" with serial invoices: which names and abbreviations the table understands is explained on the page Serial invoices: units in the table<\/a>.<\/p>\n\n\n\n
![\"A](\"https:\/\/help.pdf24.org\/en\/wp-content\/uploads\/sites\/3\/2026\/11\/einvoice-validation-unit-symbol.png\")
Choose the unit from the list; a word of your own for the PDF goes into the \"Symbol\" field<\/figcaption><\/figure>\n\n\n\n PO box in the address<\/h2>\n\n\n\n
What you see:<\/strong> There is no separate \"PO box\" field; the address only has \"Street 1\", \"Street 2\", \"Addition\", \"Post code\" and \"City\".<\/p>\n\n\n\n
Why:<\/strong> The EN 16931 standard has no separate PO box field. The first address line is meant for the street and house number or<\/strong> the PO box.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- Enter the PO box in \"Street 1\", e.g. \"PO Box 10 20 30\" (in Germany \"Postfach 10 20 30\").<\/li>\n\n\n
- Enter the post code of the PO box in \"Post code\" and the town in \"City\".<\/li>\n\n\n
- For the XRechnung, post code and city of both the biller and the invoice recipient are required (see XRechnung required details<\/a>).<\/li>\n\n<\/ol>\n\n\n\n
XRechnung: contact, post code or city missing (BR-DE-2 to BR-DE-9)<\/h2>\n\n\n\n
What you see<\/strong> (original texts of the XRechnung rules in German, the English wording of the same Peppol rule DE-R-\u2026 and the PDF24 hint in brackets)<\/p>\n\n\n\n
- \n
- \"[BR-DE-2] Die Gruppe \"SELLER CONTACT\" (BG-6) muss \u00fcbermittelt werden.\" \u2013 in English: \"The group \"SELLER CONTACT\" (BG-6) shall be provided.\" (\"Add a seller contact with name, phone and e-mail.\")<\/li>\n\n\n
- BR-DE-5, BR-DE-6, BR-DE-7: the name, phone number or e-mail address of the contact person is missing \u2013 in English e.g. \"The element \"Seller contact point\" (BT-41) shall be provided.\", likewise for BT-42 (phone) and BT-43 (e-mail).<\/li>\n\n\n
- \"[BR-DE-3] Das Element \"Seller city\" (BT-37) muss \u00fcbermittelt werden.\" \u2013 in English: \"The element \"Seller city\" (BT-37) shall be provided.\" Likewise BR-DE-4 (seller post code), BR-DE-8 and BR-DE-9 (buyer city and post code).<\/li>\n\n\n
- Notices BR-DE-27 (\"The phone number of the seller's contact should contain at least three digits.\") and BR-DE-28 (\"The email address of the seller's contact looks invalid. \u2026\").<\/li>\n\n<\/ul>\n\n\n\n
Why:<\/strong> The XRechnung requires more than the standard: a contact person at the biller who can be reached, and complete addresses.<\/p>\n\n\n\n
How to fix it in PDF24:<\/strong> Under \"Biller\", fill in \"Name\", \"Phone\" and \"E-Mail\" in the \"Contact\" section, and \"Post code\" and \"City\" for both parties. A mobile number is fine as the phone number.<\/p>\n\n\n\n
Early payment discount (Skonto) in the wrong format (BR-DE-18)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"Discount entries in the payment terms must look exactly like this: #SKONTO#TAGE=14#PROZENT=2.00# (upper case, no blanks, percent with a point and two decimals). \"Add early payment discount\" enters them correctly and corrects existing lines.\"<\/li>\n\n\n
- Original text of the XRechnung rule (in German, shortened): \"[BR-DE-18] Skonto Zeilen in \u2026 muessen diesem regul\u00e4rem Ausdruck entsprechen: \u2026 Die Informationen zur Gew\u00e4hrung von Skonto m\u00fcssen wie folgt im Element \"Payment terms\" (BT-20) \u00fcbermittelt werden: \u2026\" \u2013 in English (Peppol, DE-R-018, shortened): \"Information on cash discounts for prompt payment (Skonto) shall be provided within the element \"Payment terms\" BT-20 in the following way: First segment \"SKONTO\", second segment amount of days (\"TAGE=N\"), third segment percentage (\"PROZENT=N\"). \u2026\"<\/li>\n\n<\/ul>\n\n\n\n
Why:<\/strong> So that your customer's software can deduct the discount itself, the German XRechnung expects it in the \"Payment terms\" (BT-20) in a fixed form. Every line that starts with # is read as a discount line and must match exactly: \"2%\" instead of \"2.00\", a comma instead of a point, lower case or spaces all lead to BR-DE-18.<\/p>\n\n\n\n
How to fix it in PDF24:<\/strong> In the new version, enter the discount with \"Add or change early payment discount\"; \"Correct automatically\" there fixes wrong lines. In the previous version you write the lines yourself. How both work, with examples and all the rules, is explained on the main page under How do I grant an early payment discount (Skonto) in an e-invoice?<\/a><\/p>\n\n\n\n
Delivery date or billing period missing (FX-SCH-A-000354, BR-DE-TMP-32)<\/h2>\n\n\n\n
What you see<\/strong><\/p>\n\n\n\n
- \n
- PDF24: \"Enter the delivery date or the invoicing period (required for ZUGFeRD \/ Factur-X).\"<\/li>\n\n\n
- Original text with ZUGFeRD\/Factur-X (rule FX-SCH-A-000354): \"[BR-FX-EN-04]-An invoice that is not a down payment invoice (code 386) must contain either BT-72 \"Actual delivery date\", BG-14 \"Invoicing period\" or BG-26 \"Invoice line period\" in each invoice item to indicate the delivery\/service date. If BT-72 is not used, at least the country of delivery (BT-80) must be specified for technical reasons.\"<\/li>\n\n\n
- With the XRechnung (a notice, in German): \"[BR-DE-TMP-32] Eine Rechnung sollte zur Angabe des Liefer-\/Leistungsdatums entweder BT-72 \"Actual delivery date\", BG-14 \"Invoicing period\" oder in jeder Rechnungsposition BG-26 \"Invoice line period\" enthalten.\" \u2013 i.e. the invoice should contain the actual delivery date, the invoicing period or an invoice line period in every line.<\/li>\n\n\n
- With dates the wrong way round: \"[BR-29]-If both Invoicing period start date (BT-73) and Invoicing period end date (BT-74) are given then the Invoicing period end date (BT-74) shall be later or equal to the Invoicing period start date (BT-73).\" \u2013 PDF24: \"The end of the billing period must not be before its start.\"<\/li>\n\n<\/ul>\n\n\n\n
Why:<\/strong> An invoice must say when the goods were delivered or the service was provided \u2013 as a date or as a period. In Germany, \u00a7 14 UStG also requires this on every invoice.<\/p>\n\n\n\n
How to fix it in PDF24<\/strong><\/p>\n\n\n\n
- \n
- In the invoice data, enter the \"Delivery\/Service date\" (BT-72) \u2013 or a \"Billing period\" from \u2026 to \u2026 (the new version has \"This month\" for this).<\/li>\n\n\n
- If the service was provided on the invoice date, enter the same date.<\/li>\n\n\n
- Periods of individual line items must lie within the invoice's period (PEPPOL-EN16931-R110: \"An item's billing period must lie within the invoice's billing period.\").<\/li>\n\n<\/ol>\n\n\n\n
Payment details missing or not matching (BR-DE-1, BR-61, BR-DE-19)<\/h2>\n\n\n\n
What you see<\/strong> (original text, PDF24 hint in brackets)<\/p>\n\n\n\n
- \n
- BR-CO-\u2026<\/strong>: calculation rules and dependencies between fields (totals, identifiers).<\/li>\n\n\n
- next to it PDF24's explanation<\/strong> in plain words,<\/li>\n\n\n
- In the form:<\/strong> Missing required details are marked in red. The previous version also reports \"There are invalid elements in the form. Please correct the fields marked in red and start the invoice creation again.\"<\/li>\n\n\n
- Electronic address missing (PEPPOL-EN16931-R010, -R020, BR-62, BR-63)<\/a><\/li>\n\n\n