Zugferd Laravel Laravel Package

Product Decisions This Supports

• Regulatory go/no-go for EU e-invoicing: Informs the decision to ship native ZUGFeRD/Factur-X/XRechnung output versus pushing customers to a third-party clearing network. Germany’s receive mandate (2025) and issue mandate (2027–2028) plus France’s 2026–2027 rollout make this a dated, non-optional roadmap item for any DACH/FR B2B product.
• Build vs. buy: Provides a credible “build” baseline — a Laravel-native wrapper over a mature PHP library — to price against SaaS providers (Storecove, Pagero, Unifiedpost, etc.). The comparison is roughly 4–8 engineer-weeks of in-house XML/PDF-A-3 work plus validation and test fixtures versus per-invoice or subscription vendor fees.
• Feature scope definition: Helps scope the MVP as generate (hybrid PDF + embedded XML, and standalone XRechnung XML), then parse/receive (inbound supplier invoices), then validate (schematron/EN 16931 conformance). Each is a distinct release milestone; the package covers generation and parsing but not full validation.
• Market expansion sequencing: Supports prioritizing a DACH-first or France-first entry, since ZUGFeRD 2.x is the German hybrid standard and Factur-X is France’s profile of the same EN 16931 data model — one implementation can serve both.
• Architecture and dependency decisions: Signals whether e-invoicing belongs in-app (Laravel service provider + facade) or behind an internal “documents” service, which matters for teams planning multi-language or multi-tenant stacks.
• Roadmap risk register: The 43-star count, single-maintainer profile, and wrapper-of-a-wrapper structure become an explicit dependency-risk line item with a mitigation plan (fork rights under MIT, pinned versions, contract tests against EN 16931 fixtures).

When to Consider This Package

Adopt when:

• The product is Laravel/PHP, the team already owns the invoicing domain model, and you want invoice documents produced in-process rather than round-tripped through an external API.
• Target customers are German or French B2B/B2G buyers who expect ZUGFeRD/Factur-X PDFs or XRechnung XML alongside (or instead of) PDF invoices.
• You need both directions — emitting compliant documents to customers and ingesting supplier invoices — and want one library rather than two vendors.
• Volume is low-to-moderate (thousands, not millions, of documents/month) and generation latency of hundreds of milliseconds is acceptable inline.
• You want MIT-licensed, self-hosted code with no per-document metering, and you have PHP engineers who can read the upstream horstoeko/zugferd library when edge cases appear.
• You need an MVP or pilot fast — a compliance demo for a design partner in days, not a quarter.

Look elsewhere when:

• You need Peppol BIS, UBL, or non-EU formats at parity; this package is deliberately narrow.
• You require certified conformance validation (schematron/EN 16931 rule sets), audit trails, or a vendor SLA — pair with a validation service or a network provider instead.
• Legal/qualified electronic signature or sealing is a hard requirement in your segment; that is outside this wrapper’s remit.
• The stack is not Laravel (Symfony, Node, Python, Java) — the underlying horstoeko/zugferd library may still apply, but this package adds little.
• Volumes are very high or spiky, or documents must be archived immutably for statutory retention periods — a managed service with retention guarantees is the safer buy.
• Your procurement or security review rejects single-maintainer, low-adoption dependencies for revenue-critical paths; in that case budget for internal ownership or a commercial support arrangement.

How to Pitch It (Stakeholders)

To executives: “EU e-invoicing is becoming mandatory in our two largest target markets, and buyers will start rejecting non-compliant invoices. This package lets us ship compliant German and French invoice formats inside our existing Laravel product at effectively zero licensing cost, in weeks rather than a quarter. It converts a regulatory deadline into a competitive feature — ‘we’re already compliant’ — instead of a scramble or a per-invoice vendor bill. The main caveat is that it’s a small open-source project, so we should treat it as a component we own: pin versions, add our own contract tests, and keep the MIT-licensed fork option open. My recommendation is to prototype against a design partner this quarter and revisit a managed provider only if volume or audit requirements outgrow it.”

To engineering: “Thin Laravel wrapper — service provider plus facade — around the established horstoeko/zugferd PHP library. You get ZUGFeRD 2.x / Factur-X hybrid PDF generation (PDF/A-3 with embedded XML), standalone XRechnung XML, and parsing of inbound documents. It does not give you conformance validation, digital sealing, storage, or delivery. Plan the work as: (1) map our invoice domain model to the EN 16931 data model — this is the real cost, not the library; (2) wrap generation behind an internal interface so we can swap implementations; (3) build a fixture suite of golden files validated externally, since the library won’t validate for us; (4) pin the version and add a smoke test that runs on every dependency bump. Budget the integration at a few engineer-weeks, not days, and treat the dependency as ours to maintain.”