Esr Bundle Laravel Package

Product Decisions This Supports

• Swiss-market invoicing capability: Whether to support Swiss customers end-to-end by generating compliant payment documents — orange inpayment slips (ESR/Einzahlungsschein) and, more importantly, Swiss QR invoices (QR-Rechnung). This is table-stakes for Swiss B2C/B2B billing and directly gates any "expand to Switzerland" roadmap item.
• QR-bill migration decision: Since the 2022 Swiss migration deadline, the QR-bill is the standard and orange ESR slips are legacy. This package sits on the seam between the two, so it informs the decision to migrate, dual-run during transition, or retire legacy slip generation.
• Build vs. buy vs. vendor: The domain logic (payment-part layout, reference numbers, QR payload) is genuinely fiddly and spec-driven. The realistic options are: adopt a library, vendor/fork this one, or outsource to a billing provider that already emits QR-bills (Stripe Invoicing, Bexio, Abacus, PostFinance). This package is a cheap way to price the "build" option before committing.
• Legacy estate triage: Primarily a maintenance-tier artifact — relevant if we inherit or audit a Symfony2-era billing system and need to understand or extend its PDF output. It is not a greenfield roadmap item.
• Concrete use cases: recurring subscriptions, membership dues, donations, and B2B invoices for CHF recipients that require a scannable payment part with a reference number.

Framework caveat that shapes every decision above: this brief frames the package as Laravel/PHP, but whatwedo/esr-bundle is a Symfony2 bundle. There is no Laravel service provider, and it depends on Symfony DI, Twig, and the Symfony2-era PDF stack. On a Laravel codebase this is a reference implementation to read, not a dependency to install. Treat the first decision as "do we port the logic or buy it," not "do we composer require it."

When to Consider This Package

Consider it when:

• You have an existing Symfony2 application already producing ESR slips and need QR-bill output with minimal disruption.
• You need offline, self-hosted PDF generation (no third-party API calls, no per-invoice SaaS fee) at low volume.
• Your team is small and willing to own a fork — the MIT license and compact surface area make vendoring viable.
• You are in a spike/evaluation phase and want a working reference for Swiss payment-part structure before choosing a long-term approach.

Look elsewhere when:

• Your stack is Laravel or Symfony 5.1+/6/7. Symfony2 is long end-of-life; the adaptation cost almost certainly exceeds writing the QR payload against a maintained library.
• Compliance and liability matter. QR-bill layout and payload are legally significant. A 12-star package with zero dependents offers no vendor assurance, no published security posture, and no test/compatibility guarantees you can point at in an audit.
• Maintained alternatives exist: sprain/swiss-qr-bill and similar actively developed Swiss QR-bill libraries cover the modern spec, and hosted billing providers bundle QR-bill output as a feature rather than a project.
• Volume is high or multi-currency: a PDF-generation library is the wrong layer; buy the invoicing pipeline.
• You are not billing Swiss recipients. Outside CHF/QR-bill requirements the package has no value.

How to Pitch It (Stakeholders)

To executives: This is a narrow, MIT-licensed component for producing Swiss payment slips and QR invoices — a real but bounded capability for any Swiss revenue. The strategic read is not "adopt this package," it's "we now know what Swiss invoicing costs to build in-house." The package itself is low-credibility as a dependency: 12 stars, zero downstream users, and it targets an end-of-life framework. Recommendation: spend a short spike using it as a reference, then either buy QR-bill support from our billing provider or adopt a maintained library. Do not put it on the critical path.

To engineering: The repository is a Symfony2 bundle, not a Laravel package — no service provider, Symfony DI and Twig coupling, dated PDF dependencies. Reading it is cheap and worthwhile for the ESR/QR payload specifics; wiring it into our stack is not. If we go the library route, evaluate sprain/swiss-qr-bill or equivalent first and treat this as a fallback reference. If we ever fork it, budget for ownership: no upstream community means every spec change lands on us.

To finance/ops: QR-bills are mandatory for Swiss invoice recipients and must render correctly first time — a malformed payment part means unpaid invoices and manual reconciliation. That argues for a supported, tested implementation over a lightly-used open-source bundle, even at a modest per-invoice cost from a provider.