InvoiceIn VS xmlvalid

InvoiceIn's answer

It only does the receiving half — and does every European format through one endpoint.

Most e-invoicing products are networks: they sign you up, connect you to Peppol, and send on your behalf. InvoiceIn does none of that. It takes a file that already arrived — over Peppol, by e-mail, by portal download, by a customer upload — and turns it into data you can use.

• One endpoint accepts XRechnung, ZUGFeRD/Factur-X, Peppol BIS 3, EN 16931 UBL, CII D16B, FatturaPA and KSeF FA(2)/FA(3), as XML or as a hybrid PDF.
• The output shape is the same whatever came in: canonical EN 16931 JSON, fields named by their BT/BG number.
• Every validation finding carries a plain-language fix in five languages, not just a rule id.
• Nothing is stored. The file is parsed in memory and discarded with the response.

xmlvalid's answer:

• Schema validation and e-invoicing business rules in one place: XSD, DTD and RelaxNG, plus 7,700+ Schematron rules of EN 16931, Peppol BIS and PINT, XRechnung, Factur-X and national formats from France and Italy to Saudi Arabia, Mexico and Brazil
• Built for large files: a streaming Rust engine (libxml2 compiled to WebAssembly) validates documents up to 1 GB in the browser with flat memory (5 GB tested)
• 177 official schemas ready to use, and e-invoice profiles detected automatically from the document
• E-invoice PDFs (Factur-X, ZUGFeRD, ISDOC) checked whole: the XML inside, PDF/A, and the PDF's text against the XML
• Every error links to a page explaining why it fails and how to fix it, for libxml2, Java and .NET messages
• The same checks in CI and integrations: REST API, SOAP, MCP server for AI agents, CLI, GitHub Action, n8n

InvoiceIn's answer

Against the open-source libraries — Mustang, the KoSIT validator, the Factur-X toolkits: they are excellent and free, and they are Java or Python packages you host, update, and keep in sync with quarterly rule-set releases. If your stack is PHP, Node or Ruby on shared hosting, that is not a small ask. InvoiceIn is an HTTP call.

Against the platforms — Basware, Avalara, Tradeshift: they solve the whole procure-to-pay problem, with onboarding, contracts and seat pricing. If all you need is to read the invoices you already receive, that is a large purchase for a small job.

InvoiceIn sits in between: no infrastructure to run, no platform to join. Pay per document, credits never expire, and the first 20 a day need no key at all.

xmlvalid's answer:

• Desktop editors (XMLSpy, Oxygen) are powerful but expensive and need installing; xmlvalid works in the browser for free
• Simple online validators check one schema and stop at a few MB; xmlvalid streams up to 1 GB and ships schemas with all their imports
• E-invoice validators (KoSIT, Peppol testbeds) check one format each and have no CI tooling; xmlvalid covers many formats and countries, reads PDF invoices, and has an API, CLI and GitHub Action
• Documents are validated in the browser and not uploaded

InvoiceIn's answer

Two groups, arriving for different reasons.

Product teams at accounting, AP and ERP vendors, e-commerce and shop-plugin developers, and agencies building tooling for SMBs. Their users started receiving e-invoices and now have to read them — and writing a parser per format, then maintaining it, is not the product they set out to build.

In-house finance and AP teams in Germany, France, Italy and Poland, where receiving is already mandatory or becomes so in 2026–27, and supplier files arrive in whatever format the supplier chose.

xmlvalid's answer:

• Developers and integrators building or receiving e-invoices (Peppol, XRechnung, Factur-X, FatturaPA, KSeF, ZATCA, CFDI, NF-e, UBL, CII)
• ERP and accounting software vendors preparing for national e-invoicing mandates
• Teams that exchange XML with partners: payments (ISO 20022), healthcare (HL7 CDA, FHIR), feeds and sitemaps
• DevOps engineers who want XML checks in CI pipelines
• Anyone who needs to validate a large XML file quickly without installing software

InvoiceIn's answer

Every EU e-invoicing mandate is written from the sender's side: issue in a structured format, deliver over a network. The receiving side got far less attention — even though that is where the obligation lands first. German businesses have had to be able to receive since January 2025; French ones since September 2026.

So a company that must accept e-invoices finds two kinds of tooling: Java libraries it has to host and keep current, or full networks it has to join. Nothing in between for the plain question — I have this file, what does it say, and is it valid?

InvoiceIn is that in-between piece, built by a small independent studio that ships narrow, oddly specific products.

xmlvalid's answer:

xmlvalid is built and run by Oleksii Babintsev, a developer from Ukraine, so questions and bug reports reach the person who builds the engine. It started as a streaming validator for XML files too large for typical online tools, and grew into e-invoicing as countries made structured invoices mandatory: business rules for EN 16931, Peppol, XRechnung and national formats in 24 countries, PDF invoices, an API, CLI and GitHub Action for CI, and monitors for XML feeds. While building it, we found and fixed a slowdown in libxml2's validation of large files and contributed the fix upstream. It launched in October 2026

InvoiceIn's answer

• Python + FastAPI for the API.
• lxml for XML parsing and XSD validation.
• The official Schematron rule sets, compiled to XSLT 2.0 and executed on SaxonC — the same artefacts the KoSIT validator uses, so a finding here matches a finding there.
• pikepdf to pull the embedded XML out of ZUGFeRD and Factur-X hybrid PDFs.
• WeasyPrint for the human-readable PDF rendering.
• Deployed as a Docker container on a European server, behind Cloudflare.

xmlvalid's answer:

• Rust and libxml2 (validation engine), compiled to WebAssembly
• SaxonJS (Schematron business rules)
• veraPDF (PDF/A checks)
• Laravel and Livewire (PHP)
• Tailwind CSS
• PostgreSQL, Redis, Meilisearch
• Cloudflare