Laravel Szamlazzhu Laravel Package

Product Decisions This Supports

• Market expansion into Hungary: Issuing invoices to Hungarian customers requires NAV-compliant e-invoicing (Online Számla). This package is the integration layer between a Laravel app and Szamlazz.hu, a licensed Hungarian invoicing provider — so it directly enables "can we sell in Hungary?" decisions without building tax-authority integrations in-house.
• Build vs. buy for billing/invoicing: strong evidence for buy the provider, buy the adapter. Direct NAV integration means owning schema changes, XML/JSON payload correctness, and compliance audits; this package reduces that to configuration plus a service call.
• Roadmap enablement: invoices generated from app events (orders, subscriptions, credit notes, proforma → final invoice conversion), invoice PDF retrieval and delivery, and per-customer billing data. These are the standard building blocks for a billing feature set in a Laravel product.
• Framework upgrade planning: release 1.8 adds Laravel 13 support. That removes a "we can't upgrade the framework because of the invoicing dependency" blocker and keeps the package viable across the next major Laravel cycle — a real factor in upgrade sequencing.
• Operational quality / support cost: 1.8 expands coverage of the Szamlazz.hu API error messages, which improves exception granularity. Better error classification means fewer ambiguous billing failures, faster incident triage, and more reliable retry/alerting logic — a support-cost decision, not just a technical nicety.
• Explicit non-goals: this package is not a payments processor, not a subscription/dunning engine, and not a tax-calculation engine. Decisions about those belong to Cashier, a PSP, or a billing platform.

When to Consider This Package

Consider it when:

• You have a Laravel application (the package now spans the 8 → 13 range, per 1.8) and are on, or willing to adopt, Szamlazz.hu as your invoicing agent.
• You need NAV-compliant invoices, or you need to bill Hungarian customers with correct Hungarian invoice fields (ÁFA/tax rates, NAV identifiers, Hungarian-language documents).
• Your team is small and you do not want to own NAV Online Számla API compliance, payload versioning, or provider-side schema changes.
• You want a thin, unopinionated wrapper that leaves domain modelling (when to invoice, what to charge) in your application, rather than an opinionated billing platform.
• You are comfortable wrapping third-party code behind your own interface so the provider can be swapped later.

Look elsewhere when:

• You are not on Laravel, or you prefer a framework-agnostic client — use Szamlazz.hu's API directly or a PSR-compatible HTTP client.
• You are not selling into Hungary and have no NAV obligation — Stripe Invoicing, InvoiceNinja, or similar will be a better fit.
• You need full billing: subscriptions, proration, usage metering, dunning, tax engine — evaluate Laravel Cashier, Lago, or Chargebee instead.
• You need multi-country e-invoicing or PEPPOL interoperability — go to a PEPPOL access point or a provider with broader jurisdictional coverage.
• You require a contractual SLA or vendor-backed support. This is a community, MIT-licensed package with a narrow maintainer base; treat maintainer continuity and issue-response time as adoption risks and mitigate with version pinning and your own adapter layer.
• You need exhaustive coverage of every Szamlazz.hu endpoint — verify the specific calls you need (reverse invoices, annulment, receipt/nyugta flows) before committing.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed adapter that lets our Laravel product issue legally compliant Hungarian invoices through Szamlazz.hu, a licensed provider. It is the difference between entering the Hungarian market in weeks versus owning a tax-authority integration indefinitely. The newest release (1.8) adds Laravel 13 support — so it does not become a blocker in our next framework upgrade — and improves provider error reporting, which reduces billing-related support load. Risk profile: low code surface, no lock-in beyond the provider choice, and we will isolate it behind our own interface so it can be replaced.

For engineering: The package is a thin, config-driven service wrapper over the Szamlazz.hu agent API. In 1.8, two changes matter to us: Laravel 13 compatibility, which clears the upgrade path, and expanded API error messages, which means we can distinguish transient from permanent invoice failures and build proper retry and alerting behaviour instead of catching a single opaque exception. Recommended adoption posture: pin the version, wrap it in our own InvoiceService interface, add integration tests against the Szamlazz.hu sandbox, and add alerting on invoice issuance failures. Caveats to flag: community-maintained with a small maintainer pool, so review the test suite and open-issue backlog as part of the decision, and confirm the specific API endpoints we need are covered before we commit.