Zugferd Laravel Package

Product Decisions This Supports

• EU e-invoicing compliance roadmap. This package is the document-format layer for ZUGFeRD 2.x / Factur-X (hybrid PDF/A-3 + embedded XML) and XRechnung (pure CII/UBL XML). It directly supports the decision to ship "send and receive compliant e-invoices" as a product capability ahead of German B2B mandates and the French Factur-X/PPF timeline.
• Build vs. buy on invoice generation. A per-document API vendor (e-invoicing SaaS, PEPPOL access point) becomes a variable cost that scales with customer invoice volume. This library moves generation in-house at a fixed engineering cost under MIT — a strong option whenever invoice volume is high or margins are thin (marketplaces, high-frequency billing, ERP exports).
• Market expansion gate. Whether we can credibly bid for German public-sector (XRechnung is mandatory for Bundesbehörden) and DACH/Benelux B2B deals. This is often a hard tender requirement, not a nice-to-have, so it can be the deciding factor in go/no-go for a segment.
• Inbound as well as outbound. Supports reading/parsing supplier e-invoices, which unlocks accounts-payable ingestion, supplier portals, and "import your invoices" onboarding — a distinct roadmap item from outbound compliance.
• Data model and archiving decisions. Hybrid PDF/A-3 output implies we need to store both a human-readable rendering and the structured XML for audit/retention (GoBD-style requirements). That's a schema and storage-retention decision, not just a library call.
• Product surface choices. Whether electronic invoicing is a core feature, a download-format option on existing invoices, or an API endpoint for integrations — the library's profile/format flexibility lets us start narrow (one profile) and widen later.

When to Consider This Package

Consider it when:

• The backend is PHP/Laravel and invoices are already generated server-side; integration is a composer dependency and a mapping layer, not a new service.
• You need to produce XRechnung, ZUGFeRD, or Factur-X documents, or parse them on the way in.
• Invoice volume or per-document vendor fees make a managed API economically unattractive.
• Data residency, procurement, or customer contracts argue against shipping invoice contents through a third-party SaaS.
• You have engineering capacity to own the mapping from your invoice model to the standard's profiles (EN 16931, Comfort/Basic/Extended, XRechnung CIUS) and to track spec revisions.
• You want a low-commitment spike: MIT license means the evaluation cost is engineering hours only.

Look elsewhere when:

• You need the transport layer, not just the format: PEPPOL Access Point / AS4 messaging, SMP registration, or a certified French PDP. This library creates documents; it does not deliver them or make you a certified provider.
• You need legally defensible validation or signature with vendor indemnity — a certified/commercial provider carries that accountability, an MIT library does not.
• The stack isn't PHP, or the team is too small to absorb spec maintenance and test-fixture upkeep.
• Volume is low and compliance expertise is absent — a managed API's total cost of ownership is genuinely lower at small scale.
• You need deep ERP-specific mappings (SAP, DATEV exports) or multi-country clearance models (Italy SdI, Spain, Poland KSeF) — those are different regimes with different vendors.

How to Pitch It (Stakeholders)

For executives: EU electronic invoicing is becoming mandatory, and it is currently a blocker on DACH public-sector and B2B revenue. This is a mature, MIT-licensed PHP library that lets us generate and read compliant invoices (XRechnung, ZUGFeRD, Factur-X) inside our own product instead of paying a per-invoice vendor. It removes a recurring variable cost, keeps customer invoice data in our infrastructure, and carries no license lock-in. The engineering cost is a scoped integration plus ongoing spec maintenance — materially less than a year of per-document API fees at our projected volume.

For engineering: Pure PHP, composer-installable, no external services or extensions beyond typical PDF/XML handling. It handles document construction, profiles, and reading. What it does not provide is delivery (PEPPOL/AS4), certification, or archiving — we own the mapping from our invoice model, validation test fixtures, and a process for tracking standard revisions. Recommend a two-week spike: generate one XRechnung and one Factur-X hybrid from a real invoice, validate against the reference schemas and a viewer, then decide.

Honest caveat to state up front: this is a format library, not a compliance guarantee. If a customer or tender requires a certified provider or a managed PEPPOL connection, we will still need a partner for that layer. Position this as "we own the document, we partner for the pipe," and the risk profile is clear.