InvoiceIn Reviews and Details

Questions & Answers

1. What makes InvoiceIn unique?

   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.

2. Why should a person choose InvoiceIn over its competitors?

   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.

3. How would you describe the primary audience of InvoiceIn?

   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.

4. What's the story behind InvoiceIn?

   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.

5. Which are the primary technologies used for building InvoiceIn?

   • 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.