| 开发者 | ekremtekerek |
|---|---|
| 更新时间 | 2026年9月18日 22:09 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
BT-48 / BR-AE-09. Without it the exemption cannot be
justified and the invoice is rejected.BT-112 / BR-CO-15. Validators reject totals that
do not reconcile, even by one cent.FR40303265045, not 40303265045. WooCommerce has no field for
this, so Deklera stores it.Yes. Deklera includes a plain fallback template. If you already use a PDF invoice plugin such as WooCommerce PDF Invoices & Packing Slips, Deklera embeds the XML into that plugin's PDF instead, so your own design and branding are kept. The built-in template embeds its own font, so it writes any European alphabet and the finished Factur-X passes PDF/A-3 validation, which France requires. When another plugin produces the PDF, PDF/A conformance is up to that plugin.
Deklera produces documents that conform to EN 16931 and, on the Pro plan, verifies them against the official rule set before they leave your site. Whether a specific tax authority accepts a specific invoice also depends on your registration, your provider and rules that change over time. No plugin can promise that, and any that does is not being honest with you.
If your store is in Poland, yes: FA(3) invoices are submitted to KSeF, because there an invoice does not legally exist until KSeF has accepted it. That is the whole point of the Polish system. Everywhere else, no. On Pro, the document is sent to the validation service described under External services, and only if you enable it.
Most WooCommerce invoice plugins already produce the file, and several produce it for nothing. So does Deklera: the entire free version is the format work — pre-flight report, Factur-X, XRechnung, credit notes, versioned archive — and nothing in it is switched off. That is the entry ticket, not the product. Producing a file is easy. Knowing whether the data behind it will survive the rules is not, and that is the part that costs you weeks when it goes wrong. So Deklera does the part nobody else checks. The report tells you which orders would be rejected before you issue them. Pro runs the finished document through the official rule set — the one that compiles to XSLT 2.0, which PHP cannot execute, which is why it runs as a service rather than on your site. If you already pay to send invoices over Peppol, this does not replace that. It is the check you run first, so that what you send comes back accepted.
France (Factur-X, facture électronique), Germany (XRechnung, E-Rechnung) and Poland (KSeF FA(3)) are fully supported, and each one is measured against that country's own official validator before a release goes out. Other EU countries receive EN 16931 CII output, the common semantic standard behind all of them. Read that as the European baseline, not as your national profile. Several member states run their own mandatory format and their own platform — Italy's FatturaPA through the SdI is the clearest example — and Deklera does not produce those. If your country runs its own system, confirm that EN 16931 CII is accepted there before you rely on this plugin for it. Poland is supported, and it works differently from the others. KSeF is not just a format: an FA(3) invoice does not legally exist until KSeF has accepted it and assigned a number. So for Poland, Deklera does send: it submits each invoice to KSeF, waits for the number and records it against the order. This is the one case where the plugin transmits, because producing the file without sending it would leave you holding something that looks like an invoice and is not one. You need a KSeF token from your KSeF account. Start in the test environment — invoices sent there have no legal effect — and switch to production when you are satisfied. One limit worth stating plainly, because you would rather read it here than find it out later. The FA(3) document itself is generated against the Ministry's official XSD and validated against it. The submission client is written to the Ministry's own API specification — authentication, the encrypted session, the upload and the status polling — but it has not yet been exercised against a live KSeF account, because even the test environment needs a token issued from a Polish taxpayer's account. If you run it and something does not match, open an issue with what came back and it will be fixed. One thing to check if you issue VAT-exempt invoices: KSeF requires the legal basis for the exemption and keeps three separate fields for it — a Polish act, an EU directive, or another basis. Deklera reads your exemption reason and picks the matching field; if the text names no recognisable provision, it uses "other". That is a best effort, not a legal opinion, so have your accountant confirm the basis you record is the right one.
Yes, and not in the "crippled demo" sense. The free version does everything the plugin itself is capable of: it scans your orders, reports every problem it finds, generates real Factur-X and XRechnung documents, produces credit notes for refunds, archives every version with a hash, and generates a document automatically when an order completes. Nothing in the code is switched off by a licence. Pro adds one thing, because it is the one thing the plugin cannot do on its own: validation against the official EN 16931 rule set before a document is issued. That rule set compiles to XSLT 2.0 and PHP's XSL extension only supports XSLT 1.0, so the check runs on a hosted service instead of on your site. See External services above.