Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for Peppol e-invoicing. This package sits in the "build" column: it gives your PHP/Laravel team library-level primitives for producing Peppol-compliant invoice documents rather than renting a per-invoice SaaS API. The decision it informs is whether compliance capability lives in your codebase or in a third-party invoice network.
• Mandate-driven roadmap sequencing. EU/EEA B2B e-invoicing obligations are landing on staggered national timelines (Belgium, Germany, France, Poland, Romania and others). A library dependency like this determines whether "send compliant e-invoices to public-sector and B2B buyers" is a one-sprint integration or a multi-quarter programme. That directly shapes which markets you can sell into and when.
• Scope boundary between document generation and network delivery. The critical PM question this package forces you to answer: are you buying document generation (UBL/BIS Billing 3.0 payloads) while still needing a certified Access Point for SMP registration, AS4 transport, and certificates, or does the package cover the whole path? Getting this boundary wrong is the single most common source of compliance-project overrun. Confirm against the source before committing roadmap dates.
• Vendor lock-in and unit economics. A self-hosted library converts a per-invoice marginal cost into an engineering fixed cost. That trade is favourable above a volume threshold and unattractive below it — a decision PM owns, not engineering.
• Buyer-facing commitments. Once invoice delivery runs through this code path, finance and support teams inherit an obligation ("invoices reach the buyer's Access Point"). That has SLA, retry, and reconciliation implications that belong on the roadmap alongside the integration work.

On v0.3.0 specifically: the release ships with no human-readable notes — only an autogenerated changelog diff link. That is a process signal, not a feature signal. As PM, treat the diff as the source of truth, assume breaking changes are live (0.x semver permits them in a minor bump by design), and pin the previous minor until someone on the team has read the diff. Do not let a bare changelog link trigger an automatic upgrade in a regulated code path.

When to Consider This Package

Adopt when:

• Your stack is PHP/Laravel and you have in-house engineers who will own the integration.
• You need to generate Peppol BIS Billing 3.0 / UBL invoice documents and want to avoid hand-rolling the schema, code lists, and validation rules.
• You have, or are prepared to contract, a certified Access Point for transport and network registration — and you understand this library is the payload layer in that arrangement.
• Invoice volume is high enough that per-document SaaS pricing is a real line item.
• You can absorb pre-1.0 churn: pinning exact versions, reviewing diffs, wrapping the dependency behind an internal interface so a swap stays cheap.

Look elsewhere when:

• You need a certified end-to-end Peppol Access Point, SMP registration, or AS4 delivery with a contractual SLA. That is a provider relationship, not a Composer dependency.
• Your stack is not PHP, or the invoicing service is a separate polyglot service you would rather not couple to Laravel conventions.
• You have no EU/EEA invoicing exposure — the domain complexity buys you nothing.
• You need a 1.0 API guarantee, published security posture, or a support contract. At 0.x, none of these are on offer.
• Your finance function wants managed compliance updates (rule changes, national CIUS variants) handled by a vendor rather than by your own release cycle.
• The team cannot afford to own schema-level correctness and its test fixtures indefinitely. Compliance code that nobody maintains is a liability, not an asset.

Gate before any pilot: read the v0.2.0→v0.3.0 diff, confirm whether the package stops at document construction or reaches into transport, and check the licence and issue-tracker activity against your procurement rules.

How to Pitch It (Stakeholders)

For executives — one paragraph: We are evaluating an open-source PHP library that produces Peppol-compliant e-invoice documents. It is an accelerator, not a compliance guarantee: it can shorten the engineering work to emit legally-shaped invoices, and it avoids per-invoice vendor fees at volume, but it does not make us a certified Peppol Access Point and it does not transfer legal liability for invoice validity to anyone. The current release is pre-1.0 and shipped without release notes, so the recommendation is a time-boxed technical spike behind an internal abstraction layer — not a production commitment — with a costed fallback to a managed provider if the spike shows the payload layer is the easy part and transport/certification is where the real work sits.

For engineering — the framing they need: treat this as an untrusted, fast-moving dependency in a correctness-critical path. Pin exact versions, read the v0.3.0 diff before touching the lockfile, and isolate it behind our own invoice-payload interface so that swapping to a vendor SDK — or to a managed Access Point's API — is a bounded change. Own the test fixtures: real validator output against BIS Billing 3.0 is the only evidence that matters. Surface the v0.3.0 notes gap to the maintainers; if the project cannot publish readable changelogs, assume API churn and plan capacity for it.

For finance and support — what changes for them: invoice delivery becomes a system we operate rather than a service we call. That means retry and reconciliation processes, an owner for delivery failures, and a clear escalation path when a buyer's Access Point rejects a document. Budget for that operational surface, not just the integration sprint.