{"id":29092,"date":"2026-08-06T07:00:08","date_gmt":"2026-08-06T07:00:08","guid":{"rendered":"https:\/\/bilnex.io\/en\/peppol-invoice-validation-steps\/"},"modified":"2026-08-06T07:00:08","modified_gmt":"2026-08-06T07:00:08","slug":"peppol-laskun-validointivaiheet","status":"publish","type":"page","link":"https:\/\/bilnex.io\/fi\/peppol-laskun-validointivaiheet\/","title":{"rendered":"Peppolin verkkolaskun validointi: 5 vaihetta ennen l\u00e4hett\u00e4mist\u00e4"},"content":{"rendered":"<article class=\"article-content-section article-content article-single\">\n<div class=\"container content-area\">\n<div class=\"text-content ce-answer\">\n<h2 id=\"a-valid-pdf-doesn-t-mean-a-valid-peppol-e-invoice\">A valid PDF doesn&#8217;t mean a valid Peppol e-invoice<\/h2>\n<p>A PDF that looks perfect can still fail Peppol validation, because Peppol (the pan-European e-invoice delivery network) checks the structured data behind an invoice, not how it looks on screen. Before you send, you need to check three separate layers: the XML file&#8217;s structure, whether its content meets EN 16931 (the European e-invoice content standard that sets out which data fields an invoice must contain), and Peppol&#8217;s own business rules, which sit inside the BIS Billing 3.0 specification. According to openPeppol&#8217;s <a href=\"https:\/\/docs.peppol.eu\/poacc\/billing\/3.0\/2024-Q4\/compliance\/\">documentation<\/a>, a message counts as compliant if the currently active rules find no fatal errors. Warnings don&#8217;t break compliance. Just as important: <a href=\"https:\/\/ec.europa.eu\/digital-building-blocks\/sites\/spaces\/DIGITAL\/pages\/467108940\/Validations\">validation artefacts check<\/a> the invoice message itself, not whether the buyer&#8217;s system will actually accept or pay it. A green light at validation and &#8220;the invoice is paid&#8221; are still several steps apart.<\/p>\n<h2 id=\"what-does-the-five-step-check-look-like-before-you-hit-send\">What does the five-step check look like before you hit send?<\/h2>\n<p>This process works the same way whether you&#8217;re using an ERP system, accounting software or an operator&#8217;s portal:<\/p>\n<ul>\n<li><strong>Export the XML:<\/strong> generate a UBL or CII file (the two structured formats invoices are exchanged in). Without one, there&#8217;s nothing to validate in the first place.<\/li>\n<li><strong>Run the schema and business-rule check:<\/strong> structural validation first, then Schematron rules (a language for checking the relationships between fields inside an XML file), which look at totals, codes, and how the fields tie together.<\/li>\n<li><strong>Fix fatal errors:<\/strong> <a href=\"https:\/\/docs.peppol.eu\/poacc\/billing\/3.0\/2024-Q4\/compliance\/\">openPeppol&#8217;s rule<\/a> is that a sender must not send a message that isn&#8217;t BIS-compliant. That&#8217;s a hard requirement, not a suggestion.<\/li>\n<li><strong>Check the recipient&#8217;s Peppol capability:<\/strong> confirm the buyer is actually registered on the network and can receive the specific document type you&#8217;re sending.<\/li>\n<li><strong>Keep the validation result:<\/strong> hold on to the report and the delivery confirmation. That&#8217;s the first thing anyone will ask for when an invoice &#8220;disappears.&#8221;<\/li>\n<\/ul>\n<h2 id=\"which-validator-does-which-job\">Which validator does which job?<\/h2>\n<p>XSD, or XML schema (the file that defines what counts as valid XML), checks whether a file is correct XML at all: elements in the right place, required fields present. Schematron checks something else entirely: business rules and the relationships between elements, for example whether the sum of the line items matches the invoice total. Per the <a href=\"https:\/\/ec.europa.eu\/digital-building-blocks\/sites\/spaces\/DIGITAL\/pages\/467108940\/Validations\">European Commission&#8217;s explanation<\/a>, Schematron doesn&#8217;t check XML structure by itself, so pair it with a schema check, or use a tool that runs both at once. The Commission offers a <a href=\"https:\/\/ec.europa.eu\/digital-building-blocks\/sites\/spaces\/DIGITAL\/pages\/467108940\/Validations\">free validation service<\/a> for exactly this, no registration needed, and Latvia&#8217;s tax authority points businesses to it directly before they submit an XML invoice to the VID. If you send invoices through an operator or accounting software that already validates internally, you don&#8217;t need to run every single invoice through a separate tool by hand. That&#8217;s fine for everyday use. But when you&#8217;re testing new XML-generation logic, run it through a standalone validator anyway.<\/p>\n<h2 id=\"reading-the-report-fatal-error-before-warning-after\">Reading the report: fatal error before, warning after<\/h2>\n<p>A fatal error means the invoice isn&#8217;t BIS-compliant and must not be sent. A warning means the invoice is technically acceptable but worth a second look. In practice, problems cluster around five spots: seller and buyer identifiers (wrong scheme or wrong registry code), VAT category and rate, line and total amounts (rounding errors slip in easily), the payable amount together with its currency code, and the reference number alongside the payment due date. If an invoice line reads \u20ac100 plus 22% VAT but the total-amount field shows a different number, the validator throws a fatal error, rightly so, because that figure goes straight into the buyer&#8217;s accounting system.<\/p>\n<h2 id=\"how-do-you-check-delivery-separately-from-validity\">How do you check delivery separately from validity?<\/h2>\n<p>A structurally correct invoice still isn&#8217;t guaranteed to arrive. Checking Peppol&#8217;s content and business rules is one thing; routing across the Peppol network is another. Before sending, check whether the buyer&#8217;s endpoint actually supports the specific document type you&#8217;re about to send. The <a href=\"https:\/\/peppol.org\/tools-support\/peppol-directory\/\">Peppol Directory<\/a> is a publicly searchable list of registered recipients, but keeping an entry current is up to the service provider, not a legal obligation, so a perfectly valid recipient can still be missing from it. If you&#8217;re unsure, ask the buyer directly for their Peppol identifier rather than trusting that the Directory shows everything.<\/p>\n<h2 id=\"what-changes-in-august-2026\">What changes in August 2026?<\/h2>\n<p>BIS Billing 3.0 version 3.0.20 (with its hotfix) has been mandatory since 23 February 2026, but <a href=\"https:\/\/docs.peppol.eu\/poacc\/billing\/3.0\/upcoming\/release-notes\/\">version 3.0.21<\/a> becomes mandatory on 17 August 2026. The update fixes an error in the electronic address scheme (EAS, the code that shows which system a company&#8217;s identifier is registered under) code list and removes 14 codes that no longer work, which means a check run against the old validator can now give you a false result. The same version adds an optional profile that lets a sender get a formal invoice response, but this requires a separate SMP registration (Service Metadata Publisher, the directory entry that tells the network where to route a company&#8217;s invoices) and doesn&#8217;t arrive automatically on every invoice. If you&#8217;re running an off-the-shelf solution, ask your operator in writing when they&#8217;re moving their validation artefacts to the new version. If you generate your own XML, update your validation rules before 17 August 2026. Otherwise your own software will keep approving invoices against rules Peppol no longer accepts.<\/p>\n<h2 id=\"estonia-and-latvia-local-checks\">Estonia and Latvia: local checks<\/h2>\n<p>In Estonia, a company entered in the <a href=\"https:\/\/www.riigiteataja.ee\/akt\/107012025012?tegevus=salvesta-link\">business register<\/a> as an e-invoice recipient has been able, since 1 July 2025, to require sellers to send invoices in the EN 16931-1 standard. An invoice meeting that standard counts as correctly formatted, though the two parties can still agree on a different suitable standard instead. This doesn&#8217;t make Peppol mandatory for every B2B invoice in Estonia; it just means a registered recipient can insist on the format.<\/p>\n<p>Latvia&#8217;s timeline runs on more layers. <a href=\"https:\/\/www.vid.gov.lv\/lv\/e-rekini\">VID<\/a> (Latvia&#8217;s tax authority) explains that e-invoices have been mandatory for B2G, G2B and G2G transactions (business-to-government, government-to-business and government-to-government) since 1 January 2025, and submitting e-invoice data to VID itself became mandatory on 1 January 2026. Data has to reach VID within five working days of the invoice being sent. In the B2B segment, submitting that data stays voluntary until the end of 2027, but VID still recommends running the XML file through the same free European Commission validation service you&#8217;d use for a Peppol invoice before filing it. These are two separate obligations, content compliance and timely submission to VID, and they&#8217;re worth tracking on two separate checklists rather than assuming your operator covers both without you checking.<\/p>\n<h2>FAQ<\/h2>\n<h3>Kas kehtiv PDF t\u00e4hendab, et Peppol e-arve on valideeritud ja sobib saatmiseks?<\/h3>\n<p>Ei. Peppol valideerib struktureeritud e-arve s\u00f5numi andmed (XML), mitte PDF-i v\u00e4limust. Enne saatmist tuleb eraldi kontrollida XML-i struktuuri, EN 16931 sisu ning Peppol\/BIS Billing 3.0 \u00e4ritreegleid.<\/p>\n<h3>Millised on 5 sammu enne Peppol e-arve saatmist?<\/h3>\n<p>Esiteks ekspordi arve XML (UBL v\u00f5i CII). Seej\u00e4rel k\u00e4ivita skeemi ja \u00e4ritreeglite kontroll. Paranda fataalsed vead BIS-iga koosk\u00f5lasoleku j\u00e4rgi, kontrolli saaja Peppol-v\u00f5imekust ning s\u00e4ilita valideerimise raport ja kinnitus.<\/p>\n<h3>Mis vahe on skeemi (XSD) ja \u00e4ritreigli (Schematron) kontrollil?<\/h3>\n<p>XSD kontrollib, kas fail on korrektne XML: kohustuslikud elemendid ja struktuur. Schematron kontrollib \u00e4ritreegleid ja elementidevahelisi seoseid, n\u00e4iteks kas rea- ja kogusummad klapivad.<\/p>\n<h3>Mis muutub BIS Billing 3.0 uue versiooniga alates 17. augustist 2026?<\/h3>\n<p>Uus BIS Billing 3.0 versioon 3.0.21 muutub kohustuslikuks 17.08.2026. Muudatus parandab elektroonilise aadressiskeemi (EAS) koodinimekirja vea ja eemaldab 14 mittet\u00f6\u00f6tavat koodi, mis v\u00f5ib vana valideerimise loogikaga anda vale tulemuse.<\/p>\n<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"Kas kehtiv PDF t\u00e4hendab, et Peppol e-arve on valideeritud ja sobib saatmiseks?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Ei. Peppol valideerib struktureeritud e-arve s\u00f5numi andmed (XML), mitte PDF-i v\u00e4limust. Enne saatmist tuleb eraldi kontrollida XML-i struktuuri, EN 16931 sisu ning Peppol\/BIS Billing 3.0 \u00e4ritreegleid.\"}},{\"@type\":\"Question\",\"name\":\"Millised on 5 sammu enne Peppol e-arve saatmist?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Esiteks ekspordi arve XML (UBL v\u00f5i CII). Seej\u00e4rel k\u00e4ivita skeemi ja \u00e4ritreeglite kontroll. Paranda fataalsed vead BIS-iga koosk\u00f5lasoleku j\u00e4rgi, kontrolli saaja Peppol-v\u00f5imekust ning s\u00e4ilita valideerimise raport ja kinnitus.\"}},{\"@type\":\"Question\",\"name\":\"Mis vahe on skeemi (XSD) ja \u00e4ritreigli (Schematron) kontrollil?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"XSD kontrollib, kas fail on korrektne XML: kohustuslikud elemendid ja struktuur. Schematron kontrollib \u00e4ritreegleid ja elementidevahelisi seoseid, n\u00e4iteks kas rea- ja kogusummad klapivad.\"}},{\"@type\":\"Question\",\"name\":\"Mis muutub BIS Billing 3.0 uue versiooniga alates 17. augustist 2026?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Uus BIS Billing 3.0 versioon 3.0.21 muutub kohustuslikuks 17.08.2026. Muudatus parandab elektroonilise aadressiskeemi (EAS) koodinimekirja vea ja eemaldab 14 mittet\u00f6\u00f6tavat koodi, mis v\u00f5ib vana valideerimise loogikaga anda vale tulemuse.\"}}]}<\/script><\/p>\n<\/div>\n<\/div>\n<\/article>\n<style>.ce-answer{max-width:760px;margin:0 auto;padding:8px 20px 48px;line-height:1.65}.ce-answer h2{margin:1.5em 0 .55em;line-height:1.3}.ce-answer h3{margin:1.1em 0 .45em}.ce-answer p{margin:0 0 1em}.ce-answer ul,.ce-answer ol{margin:0 0 1em;padding-left:1.4em}.ce-answer li{margin:.25em 0}.ce-answer table{border-collapse:collapse;width:100%;margin:0 0 1.2em}.ce-answer th,.ce-answer td{border:1px solid #ddd;padding:8px 10px;text-align:left}.ce-answer blockquote{border-left:3px solid #ccc;margin:1em 0;padding:6px 14px}.ce-answer sup a{text-decoration:none}.ce-answer-title{margin:.6em 0 .4em}<\/style>\n","protected":false},"excerpt":{"rendered":"<p>Peppol-verkkolaskun XML-tiedostojen, EN 16931 -sis\u00e4ll\u00f6n ja liiketoimintas\u00e4\u00e4nt\u00f6jen tarkistaminen \u2013 ja mit\u00e4 muutoksia tulee 17. elokuuta 2026.<\/p>","protected":false},"author":8,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-29092","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/pages\/29092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/comments?post=29092"}],"version-history":[{"count":0,"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/pages\/29092\/revisions"}],"wp:attachment":[{"href":"https:\/\/bilnex.io\/fi\/wp-json\/wp\/v2\/media?parent=29092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}