DEV Community: PatrickPi1312

XRechnung aus PDF erstellen: Anleitung und API-Beispiel (2026)

PatrickPi1312 — Sun, 12 Jul 2026 12:47:28 +0000

Die E-Rechnungs-Pflicht ist da: In Deutschland müssen Unternehmen seit 2025 E-Rechnungen empfangen können, ab 2027/2028 auch ausstellen. In Österreich läuft e-Rechnung über ebInterface und Peppol. Das Problem für viele Betriebe: Die alte Software erzeugt nur ein PDF — verlangt wird aber eine strukturierte XRechnung oder ZUGFeRD. So schließt du die Lücke per API.

Schritt 1: PDF in strukturierte Daten umwandeln

Die Extraction-API liest ein PDF (oder Foto) und gibt Händler, Datum, Beträge und Positionen als JSON zurück:

curl -X POST "https://extract.installateur1210.at/v1/extract" \
  -H "X-API-Key: DEIN_KEY" -F "file=@rechnung.pdf"

Da es KI-gestützt ist: Ergebnis kurz prüfen, bevor du es weiterverwendest.

Schritt 2: Daten in eine gültige XRechnung wandeln

Die geprüften Felder gehen in den Generator — heraus kommt eine EN-16931-konforme XRechnung. Profil wählbar: xrechnung (DE), peppol (EU/Österreich), en16931:

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/generate?key=demo" \
  -H "Content-Type: application/json" \
  -d '{"invoice_number":"2026-001","issue_date":"2026-07-12","currency":"EUR",
       "seller":"Muster GmbH","seller_country":"AT","seller_vat":"ATU12345678",
       "buyer":"Kunde GmbH","buyer_country":"DE",
       "total_net":100,"tax_amount":20,"total_gross":120,
       "line_items":[{"name":"Leistung","quantity":1,"line_amount":100}]}'

Schritt 3: Amtlich prüfen

Das ist der Teil, den selbstgebaute Lösungen meist auslassen. Prüfe die XRechnung gegen den offiziellen KoSIT-Validator (EN 16931 + XRechnung-Schematron):

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/validate/official?key=demo" \
  -H "Content-Type: application/xml" --data-binary @rechnung.xml

Du bekommst ein Urteil (ACCEPTABLE/REJECTED) plus die konkret verletzten Geschäftsregeln (BR-CO-15, BR-DE-…).

Fazit

Aus „alte Software macht nur PDF" wird per Pipeline PDF → JSON → XRechnung — für Deutschland, Österreich und EU-weit über Peppol. EU-gehostet, keine Rechnungsdaten gespeichert, kostenloser Demo-Key demo. Beispiele: https://github.com/PatrickPi1312/xrechnung-api-examples

Keine Steuer- oder Rechtsberatung. Welches Format bereitet dir Probleme?

Verify emails at signup: MX, disposable and typo detection in one API call

PatrickPi1312 — Sun, 12 Jul 2026 12:37:32 +0000

A wrong or fake email at signup costs you later: bounced invoices, failed password resets, junk in your database, a hurt sender reputation. Catching it at the moment of signup is cheap. Here's a one-call check.

The call

curl "https://email.installateur1210.at/v1/email/verify?key=demo&email=ceo@stripe.com"

{
  "email": "ceo@stripe.com",
  "valid_syntax": true,
  "domain": "stripe.com",
  "has_mx": true,             // the domain can actually receive mail (live DNS)
  "is_disposable": false,     // not a throwaway domain
  "did_you_mean": null,       // typo suggestion, e.g. "gmial.com" -> "gmail.com"
  "deliverable": true,
  "score": 100,
  "risk": "low"
}

Catch typos before they cost you

The did_you_mean field is the quiet hero. A user typing john@gmial.com never gets your email — with:

curl "https://email.installateur1210.at/v1/email/verify?key=demo&email=john@gmial.com"
# -> "did_you_mean": "john@gmail.com"

…you can prompt "did you mean gmail.com?" right in the form.

Wire it into a form (JS)

const r = await fetch(`https://email.installateur1210.at/v1/email/verify?key=demo&email=${encodeURIComponent(email)}`);
const v = await r.json();
if (!v.deliverable) showWarning("This email doesn't look reachable.");
else if (v.did_you_mean) showHint(`Did you mean ${v.did_you_mean}?`);

Free demo key demo (50/day), EU-hosted, nothing stored. Good for signups, newsletters and checkout.

Turn a PDF invoice into structured JSON — then into a valid XRechnung

PatrickPi1312 — Sun, 12 Jul 2026 12:37:27 +0000

Here's a problem millions of small businesses hit in 2026: their old software only prints PDF invoices, but the law increasingly requires a structured e-invoice (XRechnung, ZUGFeRD, Peppol). You can bridge that gap in two API calls: extract the PDF into data, then generate a compliant e-invoice.

Step 1 — PDF (or photo) → structured JSON

Send the document to the extraction endpoint and get back the fields — merchant, date, currency, totals and line items:

curl -X POST "https://extract.installateur1210.at/v1/extract" \
  -H "X-API-Key: YOUR_KEY" \
  -F "file=@invoice.pdf"

{
  "merchant": "ACME GmbH",
  "date": "2026-07-12",
  "currency": "EUR",
  "subtotal": 100.00, "tax": 20.00, "total": 120.00,
  "line_items": [{ "description": "Consulting", "quantity": 1, "amount": 100.00 }]
}

It's AI-based, so review the result before you rely on it — layouts vary.

Step 2 — JSON → valid XRechnung / Peppol

Feed those fields into the e-invoice generator and get a compliant EN 16931 XML (validated ACCEPTABLE by the official KoSIT validator):

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/generate?key=demo" \
  -H "Content-Type: application/json" \
  -d '{"invoice_number":"AT-2026-001","issue_date":"2026-07-12","currency":"EUR",
       "seller":"ACME GmbH","seller_country":"AT",
       "buyer":"Client Ltd","buyer_country":"DE",
       "total_net":100,"tax_amount":20,"total_gross":120,
       "line_items":[{"name":"Consulting","quantity":1,"line_amount":100}]}'

The whole point

Old PDF-only billing tool on one end, EU e-invoicing mandate on the other — and a two-step pipeline in between: PDF → JSON → XRechnung. Both APIs are EU-hosted and store no document data. Extraction needs its own key (free tier available); the e-invoice API has a public demo key demo.

Examples: https://github.com/PatrickPi1312/xrechnung-api-examples

How to create a valid XRechnung (EN 16931) e-invoice in 5 minutes

PatrickPi1312 — Sun, 12 Jul 2026 12:29:37 +0000

E-invoicing is now mandatory across much of the EU (Germany B2B from 2025, Austria e-Rechnung, Peppol EU-wide), and a lot of software suddenly needs to emit a valid XRechnung / Peppol invoice — not a PDF. Here's the shortest path I've found, without becoming an EN 16931 expert.

1. Start from a neutral JSON

You don't hand-write UBL. You describe the invoice in plain JSON and let the API produce the XML:

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/generate?key=demo" \
  -H "Content-Type: application/json" \
  -d '{
    "invoice_number": "AT-2026-001",
    "issue_date": "2026-07-12",
    "currency": "EUR",
    "seller": "My Company GmbH", "seller_country": "AT", "seller_vat": "ATU12345678",
    "buyer": "Client Ltd", "buyer_country": "DE",
    "total_net": 100, "tax_amount": 20, "total_gross": 120, "vat_rate": 20,
    "line_items": [{ "name": "Consulting", "quantity": 1, "line_amount": 100 }]
  }'

The profile field switches the target: peppol (EU-wide, incl. Austria — the default), xrechnung (Germany) or en16931.

2. Prove it's actually compliant

This is the part most home-grown solutions skip. The output above is validated ACCEPTABLE by the official German KoSIT validator (EN 16931 + XRechnung Schematron). You can check any invoice yourself:

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/validate/official?key=demo" \
  -H "Content-Type: application/xml" --data-binary @invoice.xml

It returns a verdict plus the exact failed business rules (BR-CO-15, BR-DE-…), so you know why something is rejected.

3. Read incoming invoices too — including ZUGFeRD PDFs

Incoming invoices arrive in many shapes. Parse XRechnung (UBL), ZUGFeRD (CII) or Austrian ebInterface into one clean JSON — and yes, you can throw a ZUGFeRD PDF straight in; the embedded XML is extracted for you:

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/parse?key=demo" \
  -H "Content-Type: application/pdf" --data-binary @zugferd.pdf

4. Convert between formats

Got an Austrian ebInterface file but need Peppol? One call:

curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/convert?to=peppol&key=demo" \
  -H "Content-Type: application/xml" --data-binary @ebinterface.xml

Wrap-up

Free demo key demo (50/day), EU-hosted, no invoice data stored. Full code examples (Node, Python, PHP): https://github.com/PatrickPi1312/xrechnung-api-examples

Not legal or tax advice — but a fast way to stop wrestling with EN 16931 by hand. What format is giving you trouble?

Add a scan-to-pay SEPA QR code (EPC/Girocode) to your invoices

PatrickPi1312 — Sun, 12 Jul 2026 12:29:13 +0000

Across the SEPA area, banking apps can scan an EPC QR code (a.k.a. Girocode) to pre-fill a bank transfer — recipient, IBAN, amount, reference. Putting one on your invoices or payment pages measurably speeds up getting paid. Here's how to generate one with a single request.

The one-liner

curl "https://api.installateur1210.at/v1/epc-qr?key=demo\
&name=ACME%20GmbH&iban=DE89370400440532013000\
&amount=99.50&remittance=Invoice%202026-001" -o qr.png

That's a spec-compliant EPC069-12 QR as PNG (or format=svg). The IBAN is validated server-side (mod-97), so you get a clear error instead of a broken code.

Embed it directly in HTML

No backend needed — it's just an image URL:

<img alt="Pay by bank transfer"
  src="https://api.installateur1210.at/v1/epc-qr?key=demo&name=ACME%20GmbH&iban=DE89370400440532013000&amount=99.50&remittance=Invoice%202026-001">

Node.js

const p = new URLSearchParams({
  key: "demo", name: "ACME GmbH", iban: "DE89370400440532013000",
  amount: "99.50", remittance: "Invoice 2026-001",
});
const res = await fetch(`https://api.installateur1210.at/v1/epc-qr?${p}`);
await require("fs/promises").writeFile("qr.png", Buffer.from(await res.arrayBuffer()));

Validate an IBAN separately

curl "https://api.installateur1210.at/v1/iban/DE89370400440532013000?key=demo"

Free demo key demo, EU-hosted, nothing stored. Handy for invoicing tools, clubs, utilities and checkout flows in the euro area.

EU e-invoicing for developers: XRechnung vs ZUGFeRD vs ebInterface vs Peppol

PatrickPi1312 — Sun, 12 Jul 2026 12:07:42 +0000

If you build accounting, ERP, shop or billing software and sell into Europe, e-invoicing has probably landed on your roadmap whether you wanted it or not. Germany's B2B mandate, Austria's e-Rechnung, and the EU-wide Peppol push all point the same way: structured e-invoices are becoming the default, and PDFs-by-email are on the way out.

The confusing part isn't the concept. It's that "e-invoice" means four or five different things depending on the country and the day. This post is the map I wish I'd had.

What "e-invoice" actually means

An e-invoice is not a PDF. A PDF is a picture of an invoice for humans. An e-invoice is structured data a machine can read without OCR or guesswork. That distinction is the whole point of the regulation: automated processing, fewer errors, less fraud.

The good news: underneath all the acronyms there is one shared model — the European standard EN 16931. It defines the semantics: what fields an invoice must contain (seller, buyer, invoice number, dates, line items, VAT breakdown, totals) and business rules between them (e.g. grand total = net + tax). Everything below is a flavour of the same core.

The two syntaxes

EN 16931 can be expressed in two XML syntaxes:

UBL 2.1 (OASIS Universal Business Language) — the more common one, used by Peppol and XRechnung.
UN/CEFACT CII (Cross Industry Invoice) — used inside ZUGFeRD/Factur-X.

Same information, different element names. In UBL the invoice number is cbc:ID; in CII it's ram:ID inside rsm:ExchangedDocument. If you parse by local element name and map to a neutral model, you can support both with one code path — more on that below.

The format zoo

Format	Country	Syntax	Shape
XRechnung	Germany 🇩🇪	UBL or CII	Pure XML. A German CIUS (national profile) of EN 16931, maintained by KoSIT.
ZUGFeRD / Factur-X	Germany 🇩🇪 / France 🇫🇷	CII	Hybrid: a PDF/A-3 with the XML embedded inside the PDF. Human-readable and machine-readable in one file.
ebInterface	Austria 🇦🇹	own XML schema	Austria's national standard (maintained by AUSTRIAPRO), predates EN 16931. Still widely used in AT.
Peppol BIS Billing 3.0	EU-wide 🇪🇺	UBL	Not a file format so much as an interoperability profile transported over the Peppol network. The de-facto EU lingua franca.

A few things that trip people up:

XRechnung is not a file type, it's a profile. An XRechnung document can be UBL or CII. Don't assume the syntax from the name.
ZUGFeRD is a PDF. The structured data lives in an embedded XML attachment (CII). To process it you first extract that XML, then treat it like any CII invoice. ZUGFeRD even has an XRECHNUNG profile so one file can satisfy both worlds.
ebInterface is its own thing. Austrian invoices you receive may well be ebInterface, not EN 16931. If your parser only knows UBL/CII, it will silently choke on AT invoices.
Peppol is the network, BIS Billing 3.0 is what flows over it. You send via an Access Point using the 4-corner model; the payload is EN 16931 UBL.

Why the deadlines matter (the short version)

Germany: since 1 Jan 2025, every B2B business must be able to receive EN 16931 e-invoices. Issuing becomes mandatory for larger companies from 2027 and for everyone from 2028. Accepted formats: XRechnung and ZUGFeRD (both EN 16931-compliant).
Austria: B2G has required structured invoices for years (ebInterface or Peppol via USP / e-rechnung.gv.at).
EU (ViDA): the "VAT in the Digital Age" package pushes structured e-invoicing and digital reporting across the bloc over the coming years.

Translation for us: a lot of software suddenly needs to read and write these formats, and most teams don't want to become EN 16931 experts to do it.

Doing it in code

The pragmatic approach for reading invoices is to normalise on parse: walk the XML by local element name, detect the syntax, and emit one neutral JSON shape regardless of whether the source was UBL, CII or ebInterface. Here's the idea in Python:

import xml.etree.ElementTree as ET

def local(tag):  # strip namespace
    return tag.split("}")[-1] if "}" in tag else tag

def detect(root):
    ns = root.tag.split("}")[0].lower()
    name = local(root.tag)
    if name == "Invoice" and "ebinterface" in ns: return "ebInterface (AT)"
    if name == "Invoice": return "UBL (XRechnung/Peppol)"
    if name == "CrossIndustryInvoice": return "CII (ZUGFeRD)"
    return "unknown"

From there you collect the fields you care about across the syntaxes (invoice number, dates, seller/buyer, VAT, totals, lines), validate the EN 16931 required fields, and check the arithmetic. Generating is the reverse: take a neutral JSON object and emit valid UBL with the right CustomizationID/ProfileID for your target profile (Peppol for EU/AT, XRechnung for DE).

If you'd rather not build and maintain all of that, I put the whole thing behind a small API while solving it for my own trades business in Vienna. Free demo key demo, EU-hosted, no data stored:

# Generate a Peppol/EU invoice (works for Austria too)
curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/generate?key=demo" \
  -H "Content-Type: application/json" \
  -d '{
    "invoice_number": "AT-2026-001",
    "issue_date": "2026-07-12",
    "currency": "EUR",
    "seller": "My Company GmbH", "seller_country": "AT", "seller_vat": "ATU12345678",
    "buyer": "Client Ltd", "buyer_country": "DE",
    "total_net": 100, "tax_amount": 20, "total_gross": 120, "vat_rate": 20,
    "line_items": [{"name": "Consulting", "quantity": 1, "line_amount": 100}]
  }'

# Validate an incoming XML against EN 16931 (UBL, CII or ebInterface)
curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/validate?key=demo" \
  -H "Content-Type: application/xml" --data-binary @incoming-invoice.xml

# Parse any of the formats into clean JSON
curl -X POST "https://einvoice.installateur1210.at/v1/einvoice/parse?key=demo" \
  -H "Content-Type: application/xml" --data-binary @incoming-invoice.xml

The generate endpoint takes a profile (peppol for EU/Austria, xrechnung for Germany, or plain en16931), so the same JSON can target different countries.

Gotchas worth knowing before you ship

Don't infer syntax from the format name. Detect it from the XML root/namespace.
ZUGFeRD = extract the embedded XML first. The PDF wrapper is not the data.
Austria will send you ebInterface. Handle it or you'll drop real invoices.
Validate the maths, not just the schema. A schema-valid invoice can still have net + tax ≠ gross; EN 16931 business rules catch that.
Currency and country codes are required fields, and buyers increasingly need a valid VAT ID and buyer reference — don't leave them blank.

E-invoicing looks intimidating from the outside, but it's really one semantic model wearing several national costumes. Map the costumes once and the rest is plumbing.

Which country's format is giving you the most trouble? I'm actively adding coverage — happy to hear what to support next.