Pro no longer needs a separate validation key: your licence now authorises\nofficial validation on its own. If you had pasted a key, it keeps working. The\norder screen also names the rule when a document is refused.<\/p>","0.3.2":"
Adds a user guide and fixes the Pro setup screen, which previously left you\nwith two empty fields and no explanation. Nothing to do after upgrading.<\/p>","0.3.1":"
Fixes a Pro-only problem: the first validation of the day could be reported\nas "service unavailable". Nothing to do after upgrading.<\/p>","0.3.0":"
The plugin is now called Deklera. Settings and the archive do not carry over:\nre-enter your VAT number, your KSeF token, and on Pro your licence. Invoices\nalready registered with KSeF keep their numbers and are unaffected.<\/p>","0.2.1":"
Polish stores that issue VAT-exempt invoices should reissue any exempt invoice\nsent with 0.2.0; the exemption basis was recorded in the wrong field.<\/p>","0.2.0":"
Adds Poland (KSeF). Polish stores must enter a KSeF token; other stores are\nunaffected.<\/p>","0.1.0":"
First release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3701585,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3701585,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3701585,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3701585,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["0.3.10","0.3.11"],"block_files":[],"assets_screenshots":{"screenshot-1.jpg":{"filename":"screenshot-1.jpg","revision":3701585,"resolution":"1","location":"assets","locale":"","width":1568,"height":698},"screenshot-2.jpg":{"filename":"screenshot-2.jpg","revision":3701585,"resolution":"2","location":"assets","locale":"","width":1568,"height":698},"screenshot-3.jpg":{"filename":"screenshot-3.jpg","revision":3701585,"resolution":"3","location":"assets","locale":"","width":1568,"height":698}},"screenshots":{"1":"The pre-flight report: how many recent orders would be rejected, and why.","2":"Findings grouped by root cause, each with the EN 16931 rule reference.","3":"The e-invoice box on the order screen, with document versions and history."}},"plugin_section":[],"plugin_tags":[267987,226218,252347,286,263529],"plugin_category":[45],"plugin_contributors":[281411],"plugin_business_model":[],"class_list":["post-363450","plugin","type-plugin","status-publish","hentry","plugin_tags-e-rechnung","plugin_tags-factur-x","plugin_tags-ksef","plugin_tags-woocommerce","plugin_tags-xrechnung","plugin_category-ecommerce","plugin_contributors-ekremtekerek","plugin_committers-ekremtekerek"],"banners":{"banner":"https:\/\/ps.w.org\/deklera\/assets\/banner-772x250.png?rev=3701585","banner_2x":"https:\/\/ps.w.org\/deklera\/assets\/banner-1544x500.png?rev=3701585","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/deklera\/assets\/icon-128x128.png?rev=3701585","icon_2x":"https:\/\/ps.w.org\/deklera\/assets\/icon-256x256.png?rev=3701585","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/deklera\/assets\/screenshot-1.jpg?rev=3701585","caption":"The pre-flight report: how many recent orders would be rejected, and why."},{"src":"https:\/\/ps.w.org\/deklera\/assets\/screenshot-2.jpg?rev=3701585","caption":"Findings grouped by root cause, each with the EN 16931 rule reference."},{"src":"https:\/\/ps.w.org\/deklera\/assets\/screenshot-3.jpg?rev=3701585","caption":"The e-invoice box on the order screen, with document versions and history."}],"raw_content":"\n
Producing e-invoice XML is the easy part. The hard part is that WooCommerce\norder data is rarely clean enough for it<\/strong> \u2014 and you find out weeks later, when\nan invoice comes back rejected and you have to work out which of two hundred\nbusiness rules you broke.<\/p>\n\n Deklera starts at that problem, not at the XML.<\/p>\n\n Install it, open the report, and it tells you in plain language which of your\nrecent orders would be rejected and why. Then it produces the document your\ncountry requires \u2014 XRechnung<\/strong> in Germany, Factur-X<\/strong> in France,\nKSeF FA(3)<\/strong> in Poland \u2014 and, on the Pro plan, checks it against the\nofficial<\/strong> EN 16931 rule set before it is issued.<\/p>\n\n Want to see what the official rule set says about an invoice before you install\nanything? Paste one here, no sign-up, nothing stored:\nhttps:\/\/ekremtekerek.github.io\/deklera\/check\/<\/p>\n\n This is what the plugin is for. It scans your orders and reports, for each\nproblem: what happened, why it matters, the exact rule reference, and where to\nfix it. No jargon, no \"invalid order\".<\/p>\n\n Real examples from the report:<\/p>\n\n Findings are grouped by root cause, so a store-wide problem is reported once \u2014\nnot repeated on every order.<\/p>\n\n Other things it catches:<\/p>\n\n When Deklera has to make a judgement call \u2014 is this a service or goods? \u2014 it\nsays so and marks the order for review instead of guessing silently. You can\noverride it with a filter.<\/p>\n\n Deklera maps each order to the EN 16931 semantic model and produces the format\nyour country requires:<\/p>\n\n The tax category (standard, reverse charge, intra-community supply, export) is\nderived from where the seller and buyer are, not guessed from the rate alone.\nWhere a decision is uncertain, Deklera says so instead of silently guessing.<\/p>\n\n Documents are archived and never overwritten. Regenerating creates a new\nversion; the old one stays, because quietly replacing an issued invoice is not\nsomething an audit will forgive.<\/p>\n\n It does not transmit invoices, except to KSeF.<\/strong> Deklera produces the\ndocument and checks it; delivery goes through your own accredited provider \u2014 a\nPDP in France, a Peppol access point elsewhere. Poland is the exception,\nbecause there an unsent file is not an invoice at all. If you are looking for a\nplugin that sends invoices to a network, this is not it, and you should not buy\nit expecting that.<\/p>\n\n It also does not guarantee legal compliance<\/strong>. No software can. Whether a\nspecific invoice is accepted depends on your registration, your provider and\nrules that change over time. What Deklera can honestly promise is narrower and\nmore useful: it tells you when your data will fail the standard, and it checks\nthe finished document against the official rule set before you issue it.<\/p>\n\n Shops that already know they need e-invoicing and want to find out, now,\nwhether their order data is ready \u2014 rather than discovering it one rejection\nat a time.<\/p>\n\n France requires e-invoicing from September 2026, small businesses from\nSeptember 2027. Poland's KSeF already covers most VAT-registered businesses.\nGermany accepts XRechnung and ZUGFeRD today, and under the\nE-Rechnungspflicht<\/em> every business there has had to be able to receive an\ne-invoice since January 2025.<\/p>\n\n Official validation service (Pro only, optional)<\/strong><\/p>\n\n The Pro version can validate each document against the official EN 16931\nSchematron rule set. This validation cannot run inside WordPress: the rule set\ncompiles to XSLT 2.0, and PHP's XSL extension only supports XSLT 1.0.<\/p>\n\n When enabled, the invoice XML is sent over HTTPS to a validation service\noperated by the plugin author. The XML contains your invoice data, including\nseller and buyer names, addresses, VAT numbers and line items. It is processed\nin memory to produce the validation report and is not stored.<\/p>\n\n This service is off by default<\/strong> and only runs on the Pro plan after you enter\nan endpoint and licence key.<\/p>\n\n KSeF (Poland only, required for Polish stores)<\/strong><\/p>\n\n If your store is based in Poland, each generated FA(3) invoice is submitted to\nthe Polish Ministry of Finance's National e-Invoice System (KSeF). This is not\noptional for Polish stores: an FA(3) file has no legal standing until KSeF\naccepts it and assigns a number.<\/p>\n\n The invoice is encrypted on your site before it leaves it, and sent over HTTPS.\nIt contains your invoice data: seller and buyer names, addresses, tax\nidentifiers and line items. You choose the environment; the test environment\nhas no legal effect.<\/p>\n\n Stores outside Poland never contact KSeF.<\/p>\n\n The free version performs no other external requests, apart from the language\npack downloads that WordPress itself makes.<\/p>\n\n\n On the Pro plan there is nothing more to set up. Activating your licence\nswitches official validation on; the plugin authorises itself with that\nlicence, so there is no second key to paste.<\/p>\n\n The full guide<\/strong> \u2014 what the findings mean, when documents are produced and\nwhere they are stored, credit notes, the Polish KSeF flow, and the available\nfilters \u2014 is at\nhttps:\/\/github.com\/ekremtekerek\/deklera\/blob\/main\/docs\/GUIDE.md<\/p>\n\n\n Yes. Deklera includes a plain fallback template. If you already use a PDF\ninvoice plugin such as WooCommerce PDF Invoices & Packing Slips, Deklera embeds\nthe XML into that plugin's PDF instead, so your own design and branding are kept.<\/p>\n\n The built-in template embeds its own font, so it writes any European alphabet\nand the finished Factur-X passes PDF\/A-3 validation, which France requires. When\nanother plugin produces the PDF, PDF\/A conformance is up to that plugin.<\/p><\/dd>\n Deklera produces documents that conform to EN 16931 and, on the Pro plan,\nverifies them against the official rule set before they leave your site. Whether\na specific tax authority accepts a specific invoice also depends on your\nregistration, your provider and rules that change over time. No plugin can\npromise that, and any that does is not being honest with you.<\/p>\n\n What can be shown is the measurement. I ran my own output through KoSIT's\nofficial validator configuration before release; the first run failed six\nrules, every one of them a field EN 16931 leaves optional and Germany makes\nmandatory. The whole thing is written up, failures included:\nhttps:\/\/ekremtekerek.github.io\/deklera\/measured\/ (also in German at\n\/de\/measured\/ and Polish at \/pl\/measured\/)<\/p>\n\n Ask the same question of any vendor you are considering: can I see your\nvalidator report?<\/p><\/dd>\n If your store is in Poland, yes: FA(3) invoices are submitted to KSeF, because\nthere an invoice does not legally exist until KSeF has accepted it. That is the\nwhole point of the Polish system.<\/p>\n\n Everywhere else, no. On Pro, the document is sent to the validation service\ndescribed under External services<\/strong>, and only if you enable it.<\/p><\/dd>\n Most WooCommerce invoice plugins already produce the file, and several produce\nit for nothing. So does Deklera: the entire free version is the format work \u2014\npre-flight report, Factur-X, XRechnung, credit notes, versioned archive \u2014 and\nnothing in it is switched off.<\/p>\n\n That is the entry ticket, not the product. Producing a file is easy. Knowing\nwhether the data behind it will survive the rules is not, and that is the part\nthat costs you weeks when it goes wrong.<\/p>\n\n So Deklera does the part nobody else checks. The report tells you which orders\nwould be rejected before<\/strong> you issue them. Pro runs the finished document\nthrough the official rule set \u2014 the one that compiles to XSLT 2.0, which PHP\ncannot execute, which is why it runs as a service rather than on your site.<\/p>\n\n If you already pay to send invoices over Peppol, this does not replace that.\nIt is the check you run first, so that what you send comes back accepted.<\/p><\/dd>\n France (Factur-X, facture \u00e9lectronique<\/em>), Germany (XRechnung, E-Rechnung<\/em>)\nand Poland (KSeF FA(3)) are fully supported, and each one is measured against\nthat country's own official validator before a release goes out.<\/p>\n\n Other EU countries receive EN 16931 CII output, the common semantic standard\nbehind all of them. Read that as the European baseline, not as your national\nprofile.<\/strong> Several member states run their own mandatory format and their own\nplatform \u2014 Italy's FatturaPA through the SdI is the clearest example \u2014 and\nDeklera does not produce those. If your country runs its own system, confirm\nthat EN 16931 CII is accepted there before you rely on this plugin for it.<\/p>\n\n Poland<\/strong> is supported, and it works differently from the others. KSeF is not\njust a format: an FA(3) invoice does not legally exist until KSeF has accepted\nit and assigned a number. So for Poland, Deklera does send: it submits each\ninvoice to KSeF, waits for the number and records it against the order.<\/p>\n\n This is the one case where the plugin transmits, because producing the file\nwithout sending it would leave you holding something that looks like an\ninvoice and is not one.<\/p>\n\n You need a KSeF token from your KSeF account. Start in the test environment \u2014\ninvoices sent there have no legal effect \u2014 and switch to production when you\nare satisfied.<\/p>\n\n One limit worth stating plainly, because you would rather read it here than\nfind it out later. The FA(3) document itself is generated against the\nMinistry's official XSD and validated against it. The submission<\/strong> client is\nwritten to the Ministry's own API specification \u2014 authentication, the\nencrypted session, the upload and the status polling \u2014 but it has not yet been\nexercised against a live KSeF account, because even the test environment needs\na token issued from a Polish taxpayer's account. If you run it and something\ndoes not match, open an issue with what came back and it will be fixed.<\/p>\n\n One thing to check if you issue VAT-exempt invoices: KSeF requires the legal\nbasis for the exemption and keeps three separate fields for it \u2014 a Polish act,\nan EU directive, or another basis. Deklera reads your exemption reason and\npicks the matching field; if the text names no recognisable provision, it uses\n\"other\". That is a best effort, not a legal opinion, so have your accountant\nconfirm the basis you record is the right one.<\/p><\/dd>\n Yes, and not in the \"crippled demo\" sense. The free version does everything\nthe plugin itself is capable of: it scans your orders, reports every problem\nit finds, generates real Factur-X and XRechnung documents, produces credit\nnotes for refunds, archives every version with a hash, and generates a\ndocument automatically when an order completes. Nothing in the code is\nswitched off by a licence.<\/p>\n\n Pro adds one thing, because it is the one thing the plugin cannot do on its\nown: validation against the official<\/strong> EN 16931 rule set before a document\nis issued. That rule set compiles to XSLT 2.0 and PHP's XSL extension only\nsupports XSLT 1.0, so the check runs on a hosted service instead of on your\nsite. See External services<\/strong> above.<\/p><\/dd>\n\n<\/dl>\n\n\nThe pre-flight check<\/h4>\n\n
\n
BT-48 \/ BR-AE-09<\/code>. Without it the exemption cannot be\njustified and the invoice is rejected.<\/li>\nBT-112 \/ BR-CO-15<\/code>. Validators reject totals that\ndo not reconcile, even by one cent.<\/li>\n<\/ul>\n\n\n
Generating documents<\/h4>\n\n
\n
What this plugin does not do<\/h4>\n\n
Who this is for<\/h4>\n\n
External services<\/h3>\n\n
\n
\n
\n
FR40303265045<\/code>, not 40303265045<\/code>. WooCommerce has no field for\nthis, so Deklera stores it.<\/li>\n\n
Does it work without a PDF invoice plugin?<\/h3><\/dt>\n
Will my invoices be accepted?<\/h3><\/dt>\n
Does it send my invoices anywhere?<\/h3><\/dt>\n
How is this different from the other invoice plugins?<\/h3><\/dt>\n
Which countries are supported?<\/h3><\/dt>\n
Is the free version actually usable?<\/h3><\/dt>\n
0.3.11<\/h4>\n\n
\n
0.3.10<\/h4>\n\n
\n
0.3.9<\/h4>\n\n
\n
0.3.8<\/h4>\n\n
\n
0.3.7<\/h4>\n\n
\n
0.3.6<\/h4>\n\n
\n
0.3.5<\/h4>\n\n
\n
0.3.4<\/h4>\n\n
\n
0.3.3<\/h4>\n\n
\n
0.3.2<\/h4>\n\n
\n
0.3.1<\/h4>\n\n
\n
0.3.0<\/h4>\n\n
\n
0.2.1<\/h4>\n\n
\n
0.2.0<\/h4>\n\n
\n
0.1.0<\/h4>\n\n
\n